[Kamq]

> My "actual job" isn't to write code, but to solve problems.

Yes, and there's often a benefit to having a human have an understanding of the concrete details of the system when you're trying to solve problems.

> That has increasingly shifted to "just" reviewing code

It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.

[laurentiurad]

It's like any other muscle, if you don't exercise it, you will lose it.

It's important that when you solve problems by writing code, you go through all the use cases of your solution. In my experience, just reading the code given by someone else (either a human or machine) is not enough and you end up evaluating perhaps the main use cases and the style. Most of the times you will find gaps while writing the code yourself.

[jvanderbot]

> often a benefit to having a human have an understanding of the concrete details of the system

Further elaborating from my experience.

1. I think we're in the early stages, where agents are useful because we still know enough to coach well - knowledge inertia.

2. I routinely make the mistake of allowing too much autonomy, and will have to spend time cleaning up poor design choices that were either inserted by the agent, or were forced upon it because I had lost lock on the implementation details (usually both in a causal loop!)

I just have a policy of moving slowly and carefully now through the critical code, vs letting the agent steer. They have overindexed on passing tests and "clean code", producing things that cause subtle errors time and time again in a large codebase.

> burn the time to understand it.

It seems to me to be self-evident that writing produces better understanding than reading. In fact, when I would try to understand a difficult codebase, it often meant that probing+rewriting produced a better understanding than reading, even if those changes were never kept.

[vidarh]

> It takes longer to read code than to write code if you're trying to get the same level of understanding. You're gaining time by building up an understanding deficit. That works for a while, but at some point you have to go burn the time to understand it.

This is true whether an AI wrote the code or a co-worker, except the AI is always on hand to answer detailed questions about the code, do detailed analysis, and run extensive tests to validate assumptions.

It is very rarely productive any more to dig into low level code manually.

[Kamq]

> This is true whether an AI wrote the code or a co-worker

I agree. I just don't think code reviews are as load bearing as everyone seems to think. They're important, but not nearly enough.

[jplusequalt]

>very rarely productive any more to dig into low level code manually

What data are you basing this assumption on?

[vidarh]

A couple of years of first hand experience delivering things far faster than I could before, and helping teams do the same.

[allreduce]

What industry are you working in?