I am one of the ones who reviews code and pushes projects to the finish line for people who use AI like you. I hate it. The code is slop. You don’t realize because you aren’t looking close enough, but we do and it’s annoying
I disagree with the characterization as "slop", if the tools are used well. There's no reason the user has to submit something that looks fundamentally different from what they would handwrite.
You can't simply throw the generated code over the wall to the reviewer. You have to put in the work to understand what's being proposed and why.
Lastly, an extremely important part of this is the improvement cycle.
The tools will absolutely do suboptimal things sometimes, usually pretty similar to a human who isn't an expert in the codebase. Many people just accept what comes out. It's very important to identify the gaps between the first draft, what was submitted for code review, and the mergeable final product and use that information to improve the prompt architecture and automation.
What I see is a tool that takes a lot of investment to pay off, but where the problems for operationalizing it are very tractable, and the opportunity is immense.
I'm worried about many other aspects, but not the basic utility.
Here’s the thing, they say all the same things you just said in this comment. Yet, the code I end up having to work in is still bad. It’s 5x longer than it needs to be and the naming is usually bad so it takes way longer to read than human code. To top it off, very often it doesn’t integrate completely with the other systems and I have to rewrite a portion which takes longer because the code was designed to solve for a different problem.
If you are really truly reviewing every single line in a way that it is the same as if you hand wrote it… just hand write it. There’s no way you’re actually saving time if this is the case. I don’t buy that people are looking at it as deeply as they claim to be.
> If you are really truly reviewing every single line in a way that it is the same as if you hand wrote it… just hand write it.
I think this is only true for people who are already experts in the codebase. If you know it inside-out, sure, you can simply handwrite it. But if not, the code writing is a small portion of the work.
I used to describe it as this task will take 2 days of code archaeology, but result in a +20/-20 change. Or much longer, if you are brand new to the codebase. This is where the AI systems excel, in my experience.
If the output is +20/-20, then there's a pretty good chance it nailed the existing patterns. If it wrote a bunch more code, then it probably deserves deeper scrutiny.
In my experience, the models are getting better and better at doing the right thing. But maybe this is also because I'm working in a codebase where there are many example patterns in the codebase to slot into and the entire team is investing heavily in the agent instructions and skills, and the tooling.
It may also have to do with the domain and language to some extent.
Yes, the code archaeology is the time consuming part. I could use an LLM to do that for me in my co-workers generated code, but I don’t want to because when I have worked with AI I have found it to typically create overly-complex and uncreative solutions. I think there may be some confirmation bias with LLM coders where they look at the code and think it’s pretty good, so they think it’s basically the same way they would have written it themselves. But you miss a lot of experiences compared to when you’re actually in the code trenches reading, designing, and tinkering with code on your own. Like moving around functions to different modules and it suddenly hits you that there’s actually a conceptual shift you can make that allows you to code it all much simpler, or recalling that shareholder feedback from last week that — if worked with —could allow you a solution pathway that wasn’t viable with the current API design. I have also found that LLMs make assumptions about what parts of the code base can and can’t be changed, and they’re often inaccurate.
> But you miss a lot of experiences compared to when you’re actually in the code trenches reading, designing, and tinkering with code on your own.
Completely agree. Working with this tooling is a fundamentally different practice.
I'm not trying to suggest that agentic coding is superior in every way. I simply believe that in my own experience, the current gains exceed the drawbacks by a large margin for many applications, and that significantly higher gains are within close reach (e.g. weeks).
I spent years in management, and it's not dissimilar to that transition. In my first role as a manager, I found it very difficult to divest myself of the need to have fine-grained knowledge of and control over the team's code. That doesn't scale. I had to learn to set people up for success and manage from a place of uncertainty. I had to learn to think like a risk manager instead of an artisan.
I'll also say that when it comes to solution design, I have found it very helpful to ask the agent to give me options when it comes to solutions that look suboptimal. Often times, I can still find great refactor opportunities, and I can have agent draw up plans for those improvements and delegate them to parallel sessions, where the focus can be safely executing a feature-neutral refactor.
Separately from that, I would note that the business doesn't always need us to be making conceptual shifts. Great business value can be delivered with suboptimal architecture.
It is difficult to swallow, but I think that those of us whose market value is based on our ability to develop systems by manipulating code and getting feedback from the running product will find that businesses believe that machines can do this work more than good enough and at vastly higher scale.
For the foreseeable future, there will be places where hands-on coding is superior, but I see that becoming more the exception than the norm, especially in product engineering.
Your perspective is quite thoughtful, thank you. I do agree that if you are just fixing a bug or updating function internals, +20/-20 is certainty good enough and I wouldn’t oppose AI used there.
I am going to have to agree to disagree overall though, because the second there is something the AI can’t do the maintenance time for a human to learn the context and solve the problem skyrockets (in practice, for me) in a way I find unacceptable. And I may be wrong, but I don’t see LLMs being able to improve to close that gap soon because that would require a fundamental shift away from what the LLMs are under the hood.
You can't simply throw the generated code over the wall to the reviewer. You have to put in the work to understand what's being proposed and why.
Lastly, an extremely important part of this is the improvement cycle. The tools will absolutely do suboptimal things sometimes, usually pretty similar to a human who isn't an expert in the codebase. Many people just accept what comes out. It's very important to identify the gaps between the first draft, what was submitted for code review, and the mergeable final product and use that information to improve the prompt architecture and automation.
What I see is a tool that takes a lot of investment to pay off, but where the problems for operationalizing it are very tractable, and the opportunity is immense.
I'm worried about many other aspects, but not the basic utility.