The absolute least worst outcome is they chew up your token budget. But what tends to happen, and this is much more serious, is they poison future work and make further modification of the codebase more burdensome and error prone.
Seeing LLM comments in other peoples code is very upsetting because theres just so much meaningless noise.
It usually only takes one of those in the context for the model to reorient its behavior for future edits.
Agreed.
Probably better to add whatever instructions it takes so that the agent doesn't write comments, at all, ever. If you need comments to understand the agent's code, the necessary information should already be in a conversation somewhere; and you should summarize it yourself, because the comment will be for your own benefit. Otherwise you are letting past-agent steer future-agent more or less at random.
I guess my thought / question is: this is your code. Why are you submitting the code to the git repo like that, with all the wrong text? I get making mistakes here or there; but ... everywhere? Enough that it's causing huge problems you can't quickly correct?
And ... aren't you lucky you still *have* the context in your mind? What if you hadn't caught it, or someone else had done that and you inherited that code with those wrong comments that you let through the PR and into the main branch?
1. It writes SO MUCH code, in minutes, that theres no way I as a human can review it.
2. I am not very motivated to read/review this code anyway: it was cheaply written, by some _thing_ that is not going to improve from my feedback.
3. If you DO review it conscientiously , it becomes a never ending thing: you keep finding issue upon issue.
4. If you report the issues for fixes, the fixes normally fix that immediate issue, and typically add another parallel path/another option/another 100-odd lines of code, instead of a structural fix.
5. If the code base is large, and if you let AI write a meaningful amount of code in it, its no longer _your_ code. You lose the depth+width of understanding needed to reason thru things mentally, cause you no longer KNOW enough about the code.
6. If you do review seriously, and either fix things yourself, or have the ai/harness fix the issues for you, the rounds of fixes take so long, if you look back you realize it would have been better to just do it yourself in the first place.
My personal opinion there are really only two choices:
A. If you want to build FAST, using an agent, just let the agent write tests, validations, extensively, have it keep running them (it likes to call them gates), and just let it loose. Give up on the idea that its your code, and that you understand it. The bottom line becomes: does it work, and WHEN it breaks in weird ways, just use the agent to find and fix the issue (probably breaking something else in the process).
B. limit AI use for non trivial, prod-quality projects to limited research, very tiny targeted changes, write most of the code yourself still, and review every line. You won't get much speedup, maybe 20-30%, but it will still be YOUR code, and you will still be able to reason about it.
I don’t want a vibe-coded, mass-produced diabetes tracking app, or banking tool, or tax management software. I don’t want a vibe-coded power grid analysis software.
I don’t care if a person’s little, local scripting thing is vibe-coded. I don’t care if an artist’s 0->1 game code is vibe-coded; but that’s not what a lot of the things we’re talking about here really are.
That’s not “disposable prototyping” that’s whole versions of the codebase written with barely a human in sight.
These are basic: they work for human coders and are typically quick to setup. But gates at this level are far from enough for agentic coding. You need an extensive test suite/e2e suite/benchmark suite. Typically much larger than the code base itself: This is what enables those "i ported bun to rust in a weekend" headlines. Where ever such extensive 'gates', high quality ones, already exist, the agent can do a good job of making things work, cause it can automatically iterate.
But: every hole, every gap in coverage, will be eventually found by the coding agent and 'exploited'. So you need full, extensive coverage.
This suite itself is a LOT of work, much more than what it would be if you only had to worry about human coders. So if YOU are writing the gates yourself, you are going to fall between A and B: you still have a convoluted, unreliable, impossible-to-reason-about prod app, AND it still took you eons to build it cause you spent that time writing the gates. This is no win at all, on either front.
Where gates, extensive ones, help in route A is they can significantly reduce the churn/spinning, fix-x-break-y, to just the parts that are gaps in coverage (which the agent will keep finding at a ridiculous rate). And your work would be to have it ALSO keep filing in those gaps with more tests/etc.
One of the reasons go coding with agents works better than other langs is cause I even include AST based enforcements in my governance suite. Its still route A, but with somewhat more confidence, somewhat less frustration.
100k lines of app code? 300-500k lines of test, sort of thing.
I am now looking at 9 to 10x the app code, for non trivial stuff. And this is not just the usual unit/integration/e2e suites too. Extensive deadcode, field use, code shape tests (ast walking) - god objects, 15-param helpers, wrapper-piled-upon-wrapper, badly named (a skill) functions/methods/objects, path-dependent artifacts, etc. There is no way I could have written all this manually.
It doesn't guarentee high quality OR reliability or readability or maintainability, but does reduce churn and makes me feel a bit more confident about deploying route A work product in prod.
I used to. I've stopped in recent months, only because I just can't keep up with the pace it's churning out the code. If I was to read it, it would take multiples longer to develop anything, maybe into orders of magnitude longer. Occasionally I'll dip in just to get a sense of things, especially if it's struggling with something, or at the opposite end, if it's completely trivial. But I'm hardly reading anything now.
And if you’re not reading your own work, is someone else during the PR? Are you reading other people’s PRs?
How do you know what your product does and how it does it?
And that’s just the stuff where the house of cards failed quickly.
Mostly it proves as a valid approach, barring the bugs the model can introduce to value-demonstrating benchmarks which can of course skew the evidence on hypotheses, and thus code trajectory the model opts to go with.
The problem I see with this is really that I am not anymore under the control but I am not sure I see other alternative. I am becoming more and more like a system observer with surface-level understanding of the system rather than the engineer with zoomed-in level of understanding of how the code actually behaves. Perhaps we're transitioning into a QA roles present.
LLMs are fantastic at faking those
According to my enterprise architect I shouldn't be reviewing code, it's a waste of time in this new reality.
I'm still doing it because it's going to be me answering that 3 AM call. But I don't know for how long I'll be allowed to swim upstream like that.
LLM written PR descriptions and comments are a sight to behold. I am not sure how stuff can be written so cryptically. It seems that LLMs just make up what ever terminology so that it can cram as much details into a single sentence as possible! I generally just paste it to chatgpt and ask it to decrypt it.
The problem here is that after a while it is impossible to detect when such potential abstractions is overlooked in the generated code. Because it has become hard to reason about the existing code.
Not all work is green field.
I find myself having to use Claude to untangle its own mess piece by piece, a as it charged full steam ahead with the design we made together. However, not everything can be foreseen in a design, unless you go full waterfall. Sometimes I find myself in front of a mountain of bad abstractions stemming from a subtle oversight in the design. Before AI coding, I would find details while coding and catch them in time before they became sinful abominations
You choose your level of effort and involvement. The LLM can write whatever you tell it to write. If you send a drawing of an app and say "make this" then you'll get whatever it comes up with. If you tell it how to make it then it will make it the way you tell it to.
If your AI code is trash that's because you're trash at directing it.
[1] Not sure if I read that or came up with it.
So all of that happens before the manual review and usually catches a lot of the 3-5 line comments it inevitably adds.
You may have to write your own linter for that specifically.
You’re using a non-deterministic algorithm to generate output. If you want deterministic rules applied to it, you have to use deterministic systems to do it.
E999: human generated comment :-)
```
## Comments
Use comments extremely sparingly. Most comments should be at the request of the user. When something warrants a comment, keep it to one or two lines: what the code does and why it's necessary. No background narrative, no replaying the investigation or failure mode, nothing a test name or the commit message already says. Applies to specs too. If a comment needs a paragraph, make the code clearer instead.
```
The comments Claude was leaving got absolutely out of control. Just lines and lines of LLM drivel that was barely intelligible and not remotely relevant to what a code comment should be used for.
It deleted the comments, and when I asked why it did that even though I expressedly asked it not to, it responded that me prompting it in the first place explicit permission. I have no idea if that's the actual reason or just some post-hoc explanation.
But I genuinely don't think it's possible to just have these things be completely, 100%, indpenedent and also solve deep problems that need to also be understood by people in a people-based organization context.
Just be clear, it can't know, and by asking you're just making it roleplay as someone excusing themselves.
It's very unlikely that the choice to remove the comment was driven by an internal monologue based on learned criteria that it can refer to. The sampler most likely picked tokens to remove it while writing the patch, because that's what the statistics modelled, and that's it.
The new model can only guess/hallucinate when ordered to give reasons.
It's like having an actor play a role while wearing a hat. Then the next actor comes, puts on the same hat, and we're asking them to explain why "they" did something while there was someone else playing the role.
LLMs inserting code comments makes zero sense by definition.
That’s why they’re always doing the “it’s not X, it’s Y” kind of patterns. It’s reinforcement.
Catching code desyncing from it is a valuable place to reconsider assumptions and maybe even invariants.
Not completely, because anyone who reviews the code in the future does not have access to your original prompt, so theoretically leaving a comment that explains the "why" portion of the prompt would be useful. LLMs rarely do that, though.
AI can't read your mind, and it will read what you (or anyone else) wrote.
I feel like I'm losing my mind, what the fuck is wrong with all of you?
They spent 3 years pretending that their magic robot made them 10x harder/better/faster/stronger than the lazy peons rubbing shoulders with them and now the bill has come due.