Live data from Hacker News

When I reject AI code even if it works

vinibrasil.com

41–50 of 184 posts

Re: When I reject AI code even if it works

#41
post #26

And again this makes me wonder, is AI really helping if this much review and rework is needed for all the code it writes?

I mean, the reality is a ton of folks in the industry, myself included, are writing glorified CRUD apps in their day jobs. We're building into existing an codebase with established infrastructure and ways of working. What we're building isn't inherently complex or very interesting.

Meanwhile, those codebases often require a ton of boilerplate and drudgery to get anything done.

In these spaces it's very easy to read and comprehend AI generated output and review it fairly quickly. So the time savings from dealing with all that boilerplate and conforming with all that existing infrastructure are potentially substantial.

Re: When I reject AI code even if it works

#42

I use 3 AI's (Claude, GPT and Gemini) to review each other's design plans and implementation on the same code base. Each often catches problems the others miss. I try to make sure the architecture docs of the code base are refreshed regularly based on recent changes, so it's easier for humans and AI agents to make sense of the code. I also regularly stop all other developments and just focus on auditing the code base…

You’ve transitioned from “individual contributor” to “manager”! (;->

Re: When I reject AI code even if it works

#43
post #40

Coding with AI eventually comes down to two paths, I've realized. One is using AI exclusively for everything. The other is not using it at all. There is almost no middle ground. The reason is that as the complexity and depth of the problem increase, the code AI generates increasingly follows enterprise level patterns. The deeper the meaning of what I input, the more AI tends to produce code that goes beyond my own ar…

You can also just use AI and keep the scale of your changes small rather than refactoring the whole app with a change? This isn't super-weird.

Re: When I reject AI code even if it works

#44
post #40

Coding with AI eventually comes down to two paths, I've realized. One is using AI exclusively for everything. The other is not using it at all. There is almost no middle ground. The reason is that as the complexity and depth of the problem increase, the code AI generates increasingly follows enterprise level patterns. The deeper the meaning of what I input, the more AI tends to produce code that goes beyond my own ar…

You can also just use AI and keep the scale of your changes small rather than refactoring the whole app with a change? This isn't super-weird.

As you know, the boundary ultimately depends on code quality. The problem is that AI generates code that looks high quality even outside my area of expertise, at least from my perspective. So now the boundary has to be redrawn. Refactoring usually ends up redefining those boundaries. At that point, the question becomes: do I rewrite my own code, or do I reject the AI code? Those are the two choices left.

In the end, an exceptionally skilled programmer might be able to keep their core domain intact, but I think the vast majority would find that very difficult. So it might be possible once you cross a certain threshold, but considering the sheer amount of code required to deliver a single modern program, it's hard to know which parts to focus on. However, my perspective might be different because I'm coming from the point of view of delivering a working program, not from the perspective of open source development

Re: When I reject AI code even if it works

#45

If we rephrased this to "When I reject my coworkers code even if it works" and give the same reasons there would be zero dissent. There is this weird idea that seems to come up with AI that any solution must be good and adequate. Software Engineering is all about rejecting code that works for the right code that works.

Yeah, but I think there's a difference here: If your coworker puts up code that you don't understand quickly, in most environments people give it an approval, as withholding approval is meant to indicate that there's a problem with the code. It's very rare that you'd actually force them to wait to merge until they've explained the code to your satisfaction.

(There are workplaces where that's the norm, I know -- it tends to be a thing with smaller teams with codebases that everyone understands fully, and much less a thing with larger teams where different people have areas of the code they understand more than others.)

With AI code, though, it's _your code_ and you can't give it a lgtm, you actually need to dig at it until you do fully understand it, fully agree with it, and could justify it to a hostile reviewer. It's a different level of rigor.

Not all engineers apply that rigor, though, which becomes a problem.

Re: When I reject AI code even if it works

#46
post #27

Earlier quoted context omitted.

> There are a lot of workplaces where there isn’t a good mechanism to push back on this and the tech debt just keeps growing. If the "big ball of spaghetti" theory holds, where software companies who can't manage the debt stumble over themselves as they continue to add to the big ball of spaghetti code, I guess we'll see a row of companies declaring "software bankruptcy" or something in some/many months, depending on…

Coding agents have been better than the average "enterprise" programmer for a while now and nobody wants to admit it or talk about it. I have never seen an agent output an implementation called FooImpl that's tens of thousands of LOC in a single file, but I have seen plenty of human code like this. People call coding agents bad because they don't know the asinine meaningless conventions at their particular company wh…

> that's tens of thousands of LOC in a single file

Why is this worse than splitting it across 1k files?

Re: When I reject AI code even if it works

#47

I think a particular failing with developers embracing AI is fighting the sunk cost fallacy. While you might not have spent as much time putting together a non-working solution, you still did spend time working with the agent to slap together a non-working solution. Being able to step back and say "this was a failure and we need to discard the day's work and start over" is still hard with LLMs.

Completely disagree. I think this is one of the big wins of agentic engineering. When you look back at your own completed change and realize that you made it too complicated because your initial abstraction was wrong, you have to debate long and hard about whether it's worth going back and redoing the work -- is the abstraction actually that bad? Would you really get a huge win by changing it, enough to justify spending another day on the task?

But with the agent, you know that the change will be relatively quick and easy, so the bar to tell it to shift approaches is much, much lower.

Re: When I reject AI code even if it works

#48
post #40

Coding with AI eventually comes down to two paths, I've realized. One is using AI exclusively for everything. The other is not using it at all. There is almost no middle ground. The reason is that as the complexity and depth of the problem increase, the code AI generates increasingly follows enterprise level patterns. The deeper the meaning of what I input, the more AI tends to produce code that goes beyond my own ar…

Own the design and let AI write the code. Spend the extra free time on becoming a better/broader architect.

Re: When I reject AI code even if it works

#49
post #26

And again this makes me wonder, is AI really helping if this much review and rework is needed for all the code it writes?

Most code they write is obviously fine. Much of the rest isn't obviously fine, but is in fact fine once you've gone through understanding it. But yes, there's some that still benefits from a human eye.

(For as long as that's true, "software developer" is still a job. It's not clear for how long it will be true.)

Re: When I reject AI code even if it works

#50

If you reject AI code that works then your mindset is still too hands on. Put another way - you still have some loops to work on taking yourself out of. The agent should’ve delivered code that was acceptable as a first pass. Agents respond really well to feedback! They have no ego and they’ll happily improve code if told where and how. But you need to provide the tools that provide that feedback without your involvem…

The problem I have with this kind of approach is 1) it emphasizes scaling up a much as possible, which I don't believe is necessarily the most valuable thing, and 2) I really don't want my job to be band aiding agent problems, because it's like herding cats and there will never be an end to it. I'd rather just...get hands on and be involved in the code I am working to create.
Post reply on HN