[acjohnson55]

> 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.

[whaleidk]

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.

[acjohnson55]

> 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.

[whaleidk]

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.

[acjohnson55]

This was a really interesting conversation, and I learned a lot from your thoughts and everyone else's on this thread.

As I said up top:

> LLMs are the first technology where everyone literally has a different experience.

I totally believe you when you say that you have not found these tools to be net useful. I suspect our different perceptions probably come from a whole bunch of things that are hard to transmit over a discussion like this. And maybe factors we're not even aware of -- I am benefiting from a lot of investment my company has made into all of the harness around this.

But I do pretty strongly believe that I'm not hallucinating how well it's all working in my specific context.