While I use Claude a lot for my Omarchy plugins and Linux optimization/failure detection, I don’t use it for writing and note-taking, especially for coming up with unique ideas and driving them home by writing them through to the end.
It's so hard to finish an idea that is not yours and is just suggested by AI.
lupire · 2026-08-26 16:34:29 UTC
It's also hard to finish an idea that is mine.
zazuke · 2026-08-26 18:49:36 UTC
hehe :D
synalx · 2026-08-26 16:12:01 UTC
I have this problem even in codebases. Claude will work on something, and add detailed comments in which it extrapolates the from the design and confidently states intentions and decisions which aren't actually grounded in reality. Then, later sessions suffer when it reads back those hallucinations and treats them as canonical.
mrtesthah · 2026-08-26 16:31:21 UTC
Probably good to establish canonical spec documents up front that it can use and maintain as an independent reference?
lupire · 2026-08-26 16:33:22 UTC
Doesn't need to be "up front", but you do need to curate the context.
AI can't read your mind, and it will read what you (or anyone else) wrote.
pydry · 2026-08-26 16:46:08 UTC
It can't but it will try and getting it to stop is often infeasible.
Sharlin · 2026-08-26 17:05:09 UTC
Humans can’t read minds either, but most humans aren’t so dumb as to forget what is a normative spec and what is just their own current, evolving model of the problem space. (Though some humans certainly are…)
rendaw · 2026-08-26 18:15:42 UTC
That doesn't solve the problem of it hallucinating more design details and putting them in comments. The solution to too much authoritative documentation isn't more authoritative documentation.
pc86 · 2026-08-26 18:35:05 UTC
Comments exist for humans to understand the why of the code, including perhaps external dependencies/assumptions/requirements.
LLMs inserting code comments makes zero sense by definition.
pavlov · 2026-08-26 18:52:22 UTC
That’s not true because LLMs clearly benefit from having multiple statements representing aspects of the same thing.
That’s why they’re always doing the “it’s not X, it’s Y” kind of patterns. It’s reinforcement.
selcuka · 2026-08-27 02:52:25 UTC
> LLMs inserting code comments makes zero sense by definition.
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.
hombre_fatal · 2026-08-27 06:57:58 UTC
LLMs benefit from knowing the why, the intent, and the reason/justification for code to exist, too.
Catching code desyncing from it is a valuable place to reconsider assumptions and maybe even invariants.
throwaway613746 · 2026-08-26 16:41:42 UTC
Anthropic hopes you just eventually give up and become completely dependent on Claude. Toss in 10 (or more) other developers with way less discipline and you will become dissillusioned with Claude's overengineered, incomprehensible, technosalad and your demise is pretty much guaranteed.
recursive · 2026-08-26 21:20:56 UTC
Retirement feels farther away than ever.
bsjdhdudj · 2026-08-26 16:51:07 UTC
why would you not delete the comments? why are they saved or checked in? don't you read the code? and if you don't: ISN'T THIS WHY YOU NEED TO?
I feel like I'm losing my mind, what the fuck is wrong with all of you?
dan_gggggg · 2026-08-26 17:10:30 UTC
> 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.
post-it · 2026-08-26 18:34:11 UTC
I've been whittling my way towards having Claude write zero comments in code. They're pretty much never helpful.
sdeframond · 2026-08-26 18:41:56 UTC
How do you do it?
ch4s3 · 2026-08-26 18:52:04 UTC
You could probably add linting rules to your tool of choice and tell claude that your lint tool has to pass.
demibabs · 2026-08-26 19:10:54 UTC
but then no human generated comments allowed either, right?
ch4s3 · 2026-08-26 19:15:16 UTC
I'd do this by only running the linter locally and using this as a custom rule for the LLM, but I need to think about it a bit harder.
devmor · 2026-08-26 19:33:43 UTC
There is probably something you can do to only apply some rules to the actual changed lines in a git diff.
You may have to write your own linter for that specifically.
notsirius · 2026-08-26 20:17:40 UTC
you'd probs want a commit hook for that
unleaded · 2026-08-26 22:35:00 UTC
Does "don't write comments" not work?
jaggederest · 2026-08-27 00:16:43 UTC
about as effective as don't make mistakes... For anthropic's models at least
devmor · 2026-08-27 20:02:21 UTC
It’ll work sometimes.
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.
oblio · 2026-08-27 08:56:26 UTC
Most lint tools allow exceptions if you add a special marker. I think even allow custom user exceptions.
E999: human generated comment :-)
gmueckl · 2026-08-27 09:08:10 UTC
But then the LLMs sees the syntax and is likely able to mimic it.
oblio · 2026-08-27 09:56:48 UTC
Shouldn't the "human generated comment" part be a strong hint not to?
gmueckl · 2026-08-28 05:20:47 UTC
As if LLMs would ever not ignore explicit instructions if they stand in the way of a goal...
nottorp · 2026-08-27 08:23:37 UTC
I just delete them most of the time. But I keep my LLMs on a short leash. No 40000 line PRs.
justbees · 2026-08-27 11:15:44 UTC
I include a rule in the initial PR prep that it runs. So there's a hard limit to the length of the comments and what type of comments it can write and they get flagged in the review. It also reads the comments and checks for consistency with the following code so they don't drift. And the reviewer is a completely different agent/different model.
So all of that happens before the manual review and usually catches a lot of the 3-5 line comments it inevitably adds.
bartread · 2026-08-26 19:19:07 UTC
Delete the comments: I’ve gone on a tear with these recently because they’re nothing but trouble.
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.
LoganDark · 2026-08-26 19:26:52 UTC
Absolutely. IMO, comments can explain historical reasoning for the code, but refactorings can benefit heavily from rethinking ideas from scratch, as opposed to trying to follow the same reasons. LLMs tend to be misguided by comments, probably by treating them as instructions. Ergo, get rid of them.
acedTrex · 2026-08-26 19:52:41 UTC
I completely block all LLM comments via pi extension, it makes using them significantly more enjoyable. If the LLM wants to add a comment it must ASK me explicitly to do so.
Seeing LLM comments in other peoples code is very upsetting because theres just so much meaningless noise.
copperx · 2026-08-26 20:36:29 UTC
What's the extension, please?
gessha · 2026-08-27 12:41:12 UTC
Author probably cobbler it together themselves.
furst-blumier · 2026-08-26 23:38:04 UTC
Which extension is it?
acedTrex · 2026-08-27 14:33:26 UTC
Its a personal extension i wrote myself, maybe I should put it up somewhere.. Its so simple though i dont know if its worth it vs just "go build it yourself"
zahlman · 2026-08-27 01:39:11 UTC
What happens when the LLM tries to defy this? Is the file-write rejected, or does the extension just strip comments from what gets written, or just what?
acedTrex · 2026-08-27 14:34:23 UTC
I have it set up to pop up an approval dialogue that shows me the comments its trying to write and if i reject it the model is told essentially "no comments allowed, retry the patch without them."
It usually only takes one of those in the context for the model to reorient its behavior for future edits.
zahlman · 2026-08-27 01:38:16 UTC
> 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.
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.
trenchgun · 2026-08-27 05:28:39 UTC
Why delete comments! Constrained grammar!
Make invalid state unrepresentable.
vaylian · 2026-08-27 08:13:15 UTC
Comments explain why the design is the way it is. If you later need to refactor the code, you probably won't remember the reasoning behind it and you don't know if it will be safe to remove or change parts of the design.
ThunderSizzle · 2026-08-27 10:32:03 UTC
I use comments for external domain constraints (e.g. this table has three types of records in them that we use for different purposes - I might have the LLM agent be a bit thorough and clearer with the explanation, but I found those type of comments very much helped future iterations)
rco8786 · 2026-08-26 19:25:54 UTC
We have this in our harness markdown:
```
## 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.
preommr · 2026-08-26 20:15:25 UTC
I've had codex delete useful (albeit not directly relevant or perhaps messy wip notes) comments, even though I explicitly have it in my agents.md not to delete comments, and ask for permission if it thinks it should.
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.
recursive · 2026-08-26 21:34:38 UTC
There might not be an "actual" reason that's expressible in human-comprehensible language.
wafflemaker · 2026-08-27 05:59:59 UTC
Moreover, even if there was a reason, it was there "in the model" at the moment of generation.
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.
debugnik · 2026-08-27 09:34:53 UTC
> and when I asked why it did that even though I expressedly asked it not to
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.
coder-pm · 2026-08-26 20:40:45 UTC
My approach is to keep the comments only with a references. My LLM based projects always have the decision log where are my decisions while working on the features are stored with the date. I found this useful to actually trace why something is in the codebase. It's much easier for both me and the LLM to navigate through the big projects where I spent months and dozens of full night sessions executing my plans with --dangerously-skip-permissions. In the morning I was answering all the model questions and iterating like that. Honestly, try that.
Utilera · 2026-08-27 06:15:56 UTC
This is almost worse in code because the hallucination starts looking like documentation
andai · 2026-08-27 08:35:17 UTC
A computer cannot be held accountable. Therefore, a computer must never make a decision. -IBM, 1979 (paraphrased)
gmueckl · 2026-08-27 09:13:34 UTC
Even worse to me is the tendency to not properly rewrite when prompted to change something in a text. It will always add to the document instead of replacing any obsolete information. The lengths it goes to to turn every document into a (useles) decision log is astounding and annoying.
t-writescode · 2026-08-27 09:15:18 UTC
So, I admit that I'm finally getting into this "let Claude help you write code" stuff, and I'm enjoying it a bit for the stuff I, honestly, just don't want to write; but ... I still read it. I still review it. I still look at the code like I'm peer-reviewing it and go, "Uh ... I don't like this area at all. That's going to be really hard to debug at 3am" and so on.
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?
bojan · 2026-08-27 09:42:47 UTC
> Why are you submitting the code to the git repo like that, with all the wrong text?
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.
qsera · 2026-08-27 10:42:20 UTC
I have found manual reviewing of LLM generated code to be an uphill battle. LLMs does not believe in abstraction. So complexity spills everywhere. Some details in the lowest level might be handled separately in more than one place, at the higher levels. In a short while it is a copiously documented unreadable mess (both code and documentation).
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.
sfn42 · 2026-08-27 12:06:51 UTC
Yeah, that happens when you vibe code and just let the LLM be in control of everything. If you take responsibility for the architecture and instruct it to do things properly it will do them properly. You can tell it exactly how to do it or you can ask it to handle it in a way that avoids duplication, you can tell it to design a reusable abstraction for this usecase etc.
qsera · 2026-08-27 13:25:29 UTC
>If you take responsibility for the architecture and instruct it to do things properly it will do them properly.
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.
voakbasda · 2026-08-27 15:39:15 UTC
I have wondered about this. Can’t you ask the AI to find the patterns than need abstracting?
fortzi · 2026-08-27 19:24:09 UTC
Yes you can. Sometimes it’ll find them, sometimes it won’t.
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
sfn42 · 2026-08-28 07:30:44 UTC
You can do that, with varying results. Or you can just do actual software engineering like we used to do, and tell it what patterns to abstract and how.
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.
Izkata · 2026-08-28 00:45:10 UTC
My personal suspicion is that a lot of preexisting codebases are running on inertia. The abstractions exist and are used well so the generated code also uses it most of the time, with only occasional breaks to the abstraction that look like an acceptable tradeoff in isolation. But those would keep piling up to where the existing abstraction is no longer so identifiable and that's where the major spaghetti code issues start happening.
cs02rm0 · 2026-08-27 10:50:35 UTC
> So, I admit that I'm finally getting into this "let Claude help you write code" stuff, and I'm enjoying it a bit for the stuff I, honestly, just don't want to write; but ... I still read it. I still review it. I still look at the code like I'm peer-reviewing it and go, "Uh ... I don't like this area at all. That's going to be really hard to debug at 3am" and so on.
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.
menaerus · 2026-08-27 11:11:31 UTC
Exactly. That would mean going back to square one, and I also personally don't review the code anymore but I am more focused on asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests.
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.
fortzi · 2026-08-27 19:17:57 UTC
Are you working on complex systems that serve many users in production? Do you actually save time?
menaerus · 2026-08-28 07:02:26 UTC
Yes, I can't say exactly what but the backbone of cloud computing and/or infra, think databases, distributed storage, filesystems, ...
t-writescode · 2026-08-28 09:33:03 UTC
I mean, AWS did just recently go down due to a vibe-coding / agent-run-amuck incident, didn’t it?
menaerus · 2026-08-28 09:42:11 UTC
I don't know which one exactly but can we now count how many incidents there were in the pre-agent era?
rasz · 2026-08-28 09:19:07 UTC
>asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests.
LLMs are fantastic at faking those
t-writescode · 2026-08-27 11:13:13 UTC
Why? You own the pager, I assume. You own the mental hit when something you let go live (especially with your name on the PR) leaks customer data or deleted someone’s work.
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?
menaerus · 2026-08-27 11:23:49 UTC
When the combustion engine was invented, and we got the means by which we could accelerate our trip by 10x, and at the same time scale it to multiple people, we didn't tell the humans to keep pushing the vehicles by their hands, didn't we?
defrost · 2026-08-27 11:29:37 UTC
No, but the US and UK did enact Red Flag laws.
nickmonad · 2026-08-27 12:03:14 UTC
Speed doesn't mean anything if you end up driving off a cliff.
menaerus · 2026-08-27 13:02:28 UTC
Evidence so far does not suggest people driving off a cliff so while a valid concern it's not a likely one. We also acknowledged that the benefit of using a vehicle is such that it outnumbers the risks it may introduce. We never said there will be no risks attached.
t-writescode · 2026-08-27 17:01:49 UTC
We’ve only been on this train for 3-4 years, and in that period, we’ve already invented terms for this kind of vibe-coded, highly-breakable crud. We’ve also had a few, relatively high-profile in their spheres bugs come out and hurt people’s real, lived experiences.
And that’s just the stuff where the house of cards failed quickly.
menaerus · 2026-08-27 18:08:24 UTC
Software by definition has always been and will remain broken in one or another way. AI makes no difference or whatsoever. Arguably, it will help raising the quality of software.
fortzi · 2026-08-27 19:15:31 UTC
As a developer you are more akin to a car mechanic, who’s still expected to know how the engine works even a century after it was invented, rather than a driver, who is just the user in this parallel.
menaerus · 2026-08-28 07:19:19 UTC
Mechanics I've been to generally have no idea about how things actually in the car work - from what I could understand, area is full of recurring problems, and this exactly benefits mechanics to solve them through trial and error approach rather than understanding much how underlying things work. Pretty much close to what I would say SWE will turn into, there's no other choice IMO in foreseeable future.
t-writescode · 2026-08-28 09:32:07 UTC
I think you underestimate the skill of more experienced mechanics. Tractor (as in 18 wheeler) and master mechanics tend to know what’s going on under the hood in detail.
menaerus · 2026-08-28 09:41:13 UTC
Like what exactly?
Izkata · 2026-08-28 00:39:16 UTC
From what I understand for most people it isn't a conscious choice, it happens slowly over time. People naturally don't want to waste time, the code is there and if you don't look too closely it works, so they start skimming instead of going in-depth, expecting anything majorly wrong to pop out. But those things probably won't because generated code is very good at looking extremely high quality at a surface level no matter how bad it actually is. So eventually even the skimming starts feeling like a waste of time so it tapers off too.
ghoul2 · 2026-08-27 12:10:08 UTC
The problem, in my experience is:
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.
t-writescode · 2026-08-27 17:07:17 UTC
Route A seems genuinely horrifying to me - maybe not for small and/or helper scripts; but for anything substantial. For anything that bites you or someone else hard when things go bad.
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.
anon373839 · 2026-08-28 00:33:50 UTC
Route A is good for rapid, disposable prototyping. If you ever have a stray thought, “I wonder how this would work if the whole paradigm were turned sideways”, you now have a chance to preview a “working” version of your idea. If you like it, discard the code and reimplement it correctly. In this way, I think it can be a good adjunct to sketches and other lofi prototyping techniques. Just don’t outsource the creative ideation to the LLM, because all you’ll get are the same solutions as everyone else.
t-writescode · 2026-08-28 00:45:33 UTC
Have you seen many of the replies in this thread and others? They’re not doing that. They’re putting it into production code. Their company’s thought leaders are trying to say that review itself is a waste of time, etc.
That’s not “disposable prototyping” that’s whole versions of the codebase written with barely a human in sight.
anon373839 · 2026-08-28 02:45:59 UTC
Yes; my point was not related to any of that.
nektro · 2026-08-28 03:43:46 UTC
Route A is what concretely what is behind those "a select few are seeing 100x productivity increases" posts. agents bring enterprise-level engineering to the IC. your average enterprise PM has no idea how the code works either but knows who to call when it breaks or needs a new feature added. the industry split on agentic use lies in how much and to what degree you believe "but AI is different!" in this analogy
othmanosx · 2026-08-27 21:31:33 UTC
You should be the one building the gates then, but those gates should be mechanical and deterministic so the AI doesn’t wprk around them.
Lint rules, type errors, commit lint, anything that tells the AI to stop instead of allowing workarounds.
Comments
It's so hard to finish an idea that is not yours and is just suggested by AI.
AI can't read your mind, and it will read what you (or anyone else) wrote.
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.
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.
Catching code desyncing from it is a valuable place to reconsider assumptions and maybe even invariants.
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.
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 :-)
So all of that happens before the manual review and usually catches a lot of the 3-5 line comments it inevitably adds.
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.
```
## 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.
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.
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.
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?
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.
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.
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
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.
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.