My experience is the more things you add to the list, the worse agents perform (I'm not exactly the first person to notice this)

I actually have a pretty simple set of instructions right now and Claude still regularly messes them up. Like, my first instructions are:

    - Never commit to git without permission.
    - Never sign commit messages

Then it gets even more fun, because if I politely correct it in the session, it will understand, but then there's a decent chance it will be completely unable to commit anything in the session going forward. Phd level intelligence!

Anyway, my point is, if you're asking it to review a list of 200 items I guarantee it's quietly messing up on a lot of that list.

> Any time I notice something in code review and have to get the agent to fix it.. I throw it on the list! My list is like 200 items now.

This is a gripe I've had with AI tools for a while now. Though it's gotten somewhat better in time, but we don't really know what to expect from the tool in terms of quality. Ex. I'd expect a human engineer to probably not use a brand new assertion library for a new test when there are 200 tests using an existing one. But Claude has done this to me multiple times. So I have to add yet another item to the list, like you have, and tell it to look for testing conventions before writing. But, there is plenty we don't have to tell it, like what a function is or a test should probably cover the change in the diff. But we don't really have a list of what things are on each side so we're just left to sort of hunt and peck to build a viable solution.

Can you share your list?

I am curious what does it contain, for me a lot of times its a back and forth with agent until it "looks good to my eyes and taste", but haven't written any such list yet, because it is context dependant, in some projects I forgive minor issues, or allow magical numbers, but in other projects I force agent to use constants with meaningful names `SECONDS_IN_A_DAY = 24 * 60 * 60`

I have good experience with using open-code-review:

* https://github.com/alibaba/open-code-review

** https://layandreas.github.io/personal-blog/posts/beyond-vide...

I have my own review skill (I think it predates when Claude added theirs) and one thing I'd add to your description is tell it to examine all the code and then, based on the changes, do a multi-role review of the code again using the most appropriate N of the following roles based on the changes: ... (where ... is a long list I have like Senior Engineer, Security Engineer, WCAG specialist, etc). Claude will spawn those reviews in parallel and then consolidate the feedback. I do spec based development so I just have my skill append the issues to the spec so I have a trail of issues and decisions.

You should do an experiment of splitting that up to multiple reviews that are logically together. My hypothesis is that you may be losing signal due to the amount of text expected back.

A couple of notes for anyone reading this comment and thinking of implementing something similar:

- You should use skills instead of commands (commands still work, but they've been rolled into skills) https://code.claude.com/docs/en/skills

- Hardcoding git diff against main isn't always ideal (depending on your git workflow). If you branch off of branches, the agent will figure it out, but it often has to go through a few hops to determine what to actually diff. You're better to ask it to diff 'the commits on this branch' or similar.

- You might not necessarily want to enter plan mode for a review. I don't personally as I don't see any benefit to it writing a markdown plan file for a review.

Why wouldn't it already just do this though?

Given all the hype that LLMs have got and the valuations these AI companies are getting, I am disappointed at how even the "best" coding agents degrade over time.

WTF - I need to implement a review command to guide to do its job properly.

Can you imagine any other industry charging people money for a product like this ?

When you are charging people money - scratching the surface cannot be an excuse.

Nice. I had a file with code samples (old code I wrote), including formatting and I asked to use it as a reference.

Will try your approach to distill the code to bullet points.

> My list is like 200 items now

Do human developers check for 200 items when they do code review? How long would that take? It's quite clear that AI code review could be better even with some error.

What's easy for human to review is also easy for AI (small code base, small PRs). What's hard for AI is also hard for human, if not more. But the time cost is so different that it's almost a nobrainer to choose AI to code and review, especially considering most software out there is not so critical :)

Just one thing

A model might be able to follow 200 different instructions at the same time, while another model will choke on it

I've been finding that they can write surprisingly elegant code, you just have to ask them to. It seems to be kind of like the old generative AI art days where you still had to add "+quality -bad" to the prompt.

Failing that they default to the most common style they were trained on. Which, at this point, is mostly code they wrote...

> My list is like 200 items now. Know what? Agents don’t care that they just got a wall of generic feedback, they happily look into all the bullet points.

Yes, yes, there has been a library of information on HN by now about how to use agents effectively. (And I'm grateful for that, because I can keep current and in the loop without feeling enslaved to the new style of development.)

None of that is a reason not to do what the title of TFA says. If your review process is doing the right thing, you should observe that it results in your agent moving the code in the "human-maintainable" direction. If you, for whatever reason, actually directly make commits yourself any more (read this ironically; I genuinely can't understand why anyone would want to give up on that, no matter how good the generated code gets, because "the LLM could do better" is not the point), then of course you should write it to be human-maintainable.

The reason humans find "human-maintainable" code to be maintainable is because maintainability is one of the precious few worthwhile at-least-vaguely-objective metrics of code quality we have.

Every time I see someone try to make a point about the fact that some code actually is just better than other code, only to be met with more of this sort of advice, I start to wonder whether I was alone in ever actually enjoying programming.

This sounds like gold to me, thanks. I'm going to try it.

[dead]

> I write the code myself. I find it hard to believe why so many engineers try to avoid it.

Gradually over its recent booming years, software work went from one of several practical engineering refuges for curious tinkers and puzzle-addicts to a career path for financially ambitious bright people akin to finance, law, or medicine.

Many people carrying a "software engineer" title now never really enjoyed that part of the work at all but were suitably clever and responsible to accomplish what modest ends they were tasked to by their very generous employers. Mostly (but not entirely), those people are the ones most eager to have AI agents shield them from rigorous design and puzzle work and enable them to leverage their innate cleverness more lazily. They never really internalized the coding and engineering principles of the industry and so can't foresee what might be down the road for them with this technique, especially when they're surrounded by peers with the same mindset.

> AI isn’t always faster.

It is when coding was an extremely frustrating and high friction experience for you in the first place, as is the case for many who work among us now.

This is exactly why I advocate people write code, even in a world where agents code “better”

It’s not enough to read code. You don’t internalize it. You need to experience it painfully :)

Also agents frequently defensively wrap old code instead of questioning whether legacy paths should exist. You get this nested doll layering effect of extremely large amounts of defensive code.

https://softwaredoug.com/blog/2026/07/09/write-code

>> AI isn’t always faster

It is always faster if you don't care about quality and need to churn out code as fast as possible to close tickets.

Exactly. I follow a similar workflow. I am still writing code by hand. Not all code. Parts are generated by Opus.

have been doing "racing to debug" things with AI for quite some time too. Have to say, before Opus 4.8, there wasn't even a comparison for anything slightly complex.

Opus 4.8 has been the turning point though. I am not winning many races compared to Opus 4.8, especially if it is something more complex.

I think if everyone was using Opus 4.8 (or better) for every single task/question/etc, you would have much different overall sentiment. I don't think you would have many AI disbelievers left.

> I use LLMs for exploration and for review, but I write the code myself. I find it hard to believe why so many engineers try to avoid it. It’s not consuming much of my time. And it’s actually the most enjoyable part.

At my workplace, there is more work to be done than there is engineers, and approximately 2 engineers per service. I can spin off multiple Claude Code instances on unrelated work, steering them occasionally, and then finally reviewing the output. After I have reviewed it, I post it for team review.

You're absolutely right that my depth of familiarity is lesser with this code, but we are absolutely shipping more as a result of increased parallelization.

The bottleneck now is typically reviews - both pre-push and team reviews.

> To solve this you can regular refactor, but it’s not a nice experienc.

Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better.

I agree with you about the joy of writing things directly, overall. But being able to get a few hundred lines of new approximately-what-I-wanted-to-type code (which I generally can read and fix much faster than I would have written it from scratch) definitely improves the experience, when my brain is racing ahead of my fingers. Certainly it gets me more motivated to actually start on a new feature. Similarly for all the not-exactly-exact find-and-replace tasks.

(I'm not a slow typist, but I slow myself down when I write the code, by thinking too much about details that won't be important until after the tests run.)

>Sometimes I race AI i give it a prompt /bug to fix and at the sametime im greping/symboling through the codebase and tryto fix it myself. AI isn’t always faster.

+1 - this is also my experience. I also "race" the AI on some tasks, especially when it's simple and the AI is taking forever to return a result - so it even has a head start, and I often complete it faster or around the same time.

For some things maybe it is faster, but it isn't really returning a better result. It often turns into spaghetti, doing things I didn't ask it to do.

It’s not crazy. I always add a simple message to my prompts: “leave 20% solutions empty and I’ll implement them myself”.

It work wonders for me.

I usually just say “make sure this code is professional and ready to deliver as a senior engineer” and it usually infers all that stuff you said plus more things as well. I try to give it the goal and let it decide what to do.

One thing I usually keep having to point out directly is to remove all “progress tracking” code comments and make sure all comments are appropriate for long term maintenance in the code base. Claude tends to leave comments like “button click causes save now, no longer uses onBlur” when the code really never used onBlur, that was just a thing Claude wanted to do earlier in the same task/branch and I redirected it at some point.

Just pull the slot machine lever

I like to also compliment the model on its very fashionable shoes as well, they love the flattery.

good, but this is just a verbose "make no mistakes"; it'd probably make more sense to just setup a nightly cron job that loops through the prior days' work and writes some morning tasks of the same character.

The models will interpret this willynilly; but nonetheless, it's often a better than doing nothing.

This is a good example of AI native thinking. Teach AI everything and ask it if it has learnt throughly learnt. The results are surprisingly good.

I am following similar steps from this article https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...

“ There have been many cases where I've started a piece of work by laying down very rigid abstractions and a few examples of using them, and I explicitly prompt to not only exclusively use the specific abstraction API but also copy the way I've used it. And the (frontier) LLM does neither, it just steams ahead re-implementing things from scratch from bottom up basic structures”

Yup, this is the sad state of affairs that we’re currently in, and the only way to avoid this is to specifically instruct the model on how exactly to implement things.

From my point of view, I think this is fine, to be able to use these LLMs as fast implementation engines. The challenge is to make it surface these types of implementation decisions before it goes off doing it the wrong way.

Right now the comments that upset me the most are LLM TMI-style comments that break encapsulation by talking about the behavior of specific current callers of a function right above the function definition.

I recently reacted angrily in a PR review comment after encountering one for the umpteenth time... that caught me off guard. I didn't know I was capable of that.

Used to work with a guy who would frequently say "a comment is an apology" i.e. the comment is there because the code itself is not clear. That can be the case, but I generally find more comments better than fewer, especially if they relate the code to actual business or functional requirements and don't just restate what the code is doing.

Years ago I would often write comments first. I.e. start with describing the overall goals. Then break it down into routines and order of operations, all still in plain english. Once I was happy with that, I'd break up the comments with blocks of code. I guess this is sort of like "literate programming" though I was doing it long before I ever heard that term and I still have never read much about it. It's almost more like I was prompting myself towards the end goal. The downside of this approach is that the comments do end up more or less just explaining in english what the code is doing, so maybe aren't quite as useful to future maintainers.

The comments that drive the most homicidal behavior are outdated or inaccurate comments rather than no comments.

sounds like a recipe for over-commenting. The code should be self-documenting. Comments are for the places where there are dragons.

I've seen a lot of human-written tests that wind up testing the testing framework and not the actual code.

My workflow is: - Write the test first, confirm it fails - Write the minimum code to make that test pass - Confirm it is green

Do you think it matters that it's a different model?

Or is it more about the review process and a context reset?

What do you think of traditional AST-based static analyzers (like SonarQube, Rubocop, etc.) that catch cyclomatic complexity and code duplication deterministically?

You can even put them on the build pipeline, even. No tokens spent at all!

This. Before LLMs there was copilot which repeated a lot. Then before that we had copy paste and stack overflow.

No one is stopping you. It's only if you want someone to pay you for hand writing code that you might feel a certain competitive pressure that makes it economically difficult, let's say.

Cat is out of the bag. Other than recreational programming I doubt many will write code without any form of LLM.

We're addicted to LLMs.

Will it? Okay, first we need to ask "which humans" - there are many humans who don't see a point in the things we call best practices. I've work with programmers who are faster than me to getting low bug count code out the door, despite writing 70,000 line functions - he didn't understand why nobody else wanted to add new features to his code.

The standards most "good developer" humans demand were learned from many decades of painful experience about what happens when you do it the other way. These are not only compromises for human convenience, they often are things that we have learned will come back to bite you later even though they just add more work today for no gain.

Aren't LLMs trained on and optimized for human code? In general, anything that is concise is more effective as context for the LLM, whether it be your CLAUDE.md or code, since LLMs are meant to model human language.

However, an argument can be made that such Literate Programming code can be easier/better for an LLM to work with:

https://news.ycombinator.com/item?id=47300747

How did you know you're not stuck at a local optimum where the AI could iterate even faster if you enforced higher quality on what it produced?

To make up some hypothetical numbers in order to illustrate with math: if you ship bugfixes 10x faster but then have 11x more bugs you need to fix, that's not a net improvement. Even if it's only 5x more bugs, maybe you could reduce that to 2x if you changed how you worked to only be 8x as fast in a way that produced higher quality code. Similarly, maybe you could cut the time it needed to produce a new feature by 50% if your code were higher quality by moving 20% slower.

My point in all of this isn't that you literally need to work the same way you did before you had these tools, but that framing it as either "move fast and ignore the code" and "use the same exact heuristics you would in the pre-LLM days for what code is acceptable" is a false dichotomy. If you aren't thinking about how effectively you're using these tools and whether there are changes you could make to move even faster because "AI go brrr", I think you've lost the plot in the same way you probably think that other people in this thread have.

Are you my colleague? It's fine if it's your own personal app, but please don't do this in a large complex codebase in a team. It's entirely depressing. You can use AI and still write good code. I think it's actually probably easier to write maintainable code with AI.

> That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better.

This work great until you reach a certain size, then good (or even "not bad") code is required otherwise the model spins its wheel trying to ensure the change is correct.

The way I've measured how good/bad the code is (for AI) is to have one "baseline fixed change" that I measure how long time it takes to implement. Always in the beginning (less than 10K LOC, as just some measurement), this baseline change will take 2-3 minutes. As you add more code, the same change starts to take 5-6 minutes, and once you hit 1 million LOC, it can take as long as 10 minutes, even though the change is the same.

It's when this baseline task starts to take longer time, that you need to update the design/architecture/layout/whatever, to better fit the task/domain, and to actually make it easy to maintain and still possible to add changes without spending 10 minutes. So its at this point you refactor, and once done, the baseline task will again be easy for the model to do.

So yeah, if all you do is smaller projects, then "shipping 10x as many features" is easy and doable, for the lifetime of the projects. But once the projects start to accumulate technical debt, the model will have a harder time making sure the changes are correct, and suddenly "shipping 2x as many features" is maybe doable, but you could still have had 10x if you just spend slightly more time on the actual design and architecture of the program.

Man, I bet Jia Tan is simultaneously kicking themselves and having a field day. All those years of wasted effort gaining trust and making good contributions to try to land a sophisticated backdoor into a tool via layers of indirection, and then not long after we have devs just going “I don’t need to read this code, or prioritise, or think about what makes sense, just prompt for fractals of kitchen sinks and ship it”.

Anthropic themselves have admitted you don’t need much to poison LLMs¹. I can’t wait for us to discover the backdoors that are being introduced. I hope it happens soon so people get to their senses. Bah, what am I saying, when (not if) that happens, the response will just be to throw more LLMs at it.

¹ https://www.anthropic.com/research/small-samples-poison

> shipping 10x as many features and bugfixes sounds better

I understand you're excited about the tool, but for the sake of earnest discussion here, maybe commenters like yourself can tone the hype down to plausibility?

Claims like this are just nonsense. It's not how product development works.

How do you even have so many bugs left to fix if the tool is so fast and productive? Surely, you didn't have a backlog of tens of thousands of bugs that you're still chewing through? And of course, the volume of new bugs much be minimal since the AI-composed additions introduce "no problems so far". If it works like you say, which we'll accept in good faith per HN guidelines, you must have exhausted your backlog long ago.

And if you've indeed exhausted your bug backlog long ago (incredible!), you're left to talking about shipping "10x as many features". Yet no product has a limitless capacity for features. Nobody would want to use software so bloated and churning that was gaining features at such a pace. And who is designing and specifying them so quickly anyway? If it works like you say, which we again accept in good faith, you must have stalled out on your feature list long ago.

If the AI indeed allows you to "[ship] 10x as many features and bugfixes", and we take what you say in good faith, then one of the following seems to be implied:

* you've fixed all your bugs and blew through your mature feature designs already, leaving your AI agents sitting idle for all but a few hours a week, while you're bottlenecked on feature design and your software product is bloated beyond imagination

* your coding productivity before AI was absolutely glacial by industry standards such that "10x" productivity for you is actually much closer to "0.5-2x" for others

Any insight into which of those it might be?

How long has "so far" been?

Yeah, the flip side of the article is that Fable level models can fix the majority of codebases created from the past 3 years and one shot it to a fixable state that is "human maintainable"

That sounds like a good idea but how do you know what you’re shipping?

Nobody is reviewing this, right?

One does not exclude the other

I find myself doing this but then I worry that the slop will just compound and 3, 6, 12 months from now as my services scale I'll have a harder time operating them. Maybe I'm wrong.

Similarly, I try to follow an “around 400 lines per MR” (violations can exist for test code if something is particularly gnarly).

I’ll build whole features and then break them apart into several MRs that chain off each other.

Everyone who has seen this style has been really grateful for it and finds my code much more readable. I encourage and embody the pattern everywhere I go.

Exception: For mass find/replace or auto-linter changes, that’s all one MR, and is usually pair programmed so the other person can confirm that’s all I did, still easing cognitive load.

but then you end up with a clusterfuck of classes?

I have been impressed with them as a “on this line” or “the next couple lines” autocomplete, though.

My first real use with them as that was during an interview with Jetbrains’ assistant enabled and I repeatedly went “oh! Huh!”, so … in that form, it seems very good but that’s first impressions and everything feels like magic at first

I’m not so sure this matters. My team manages a couple pretty new projects and I still see LLM tools doing this. I’m starting to suspect that vendors are building in these behaviors to ensure the output compiles (never throw an exception, null check every variable no matter what, never change a function or method but copy or inline its code and change that, etc.)

I think I would prefer code that is clear, understandable and simple even if it doesn’t compile and needs some straightforward polishing.

What you want is to guard at the outset of each API call is the same thing -- whether the user is not suspended, active, any other number of things (including more things as you add more functionality), so you want to shift the entire validation logic to its own module.

We therefore want to encapsulate the logic of all users being "qualified". I think the best way to realize this is to try to say in as few words as possible what we want. We want the user.toBe.qualified, but we can write that even more efficiently, user.isQualified(), so we can ASK at the top of each API `if !user.isQualified()` and then fail loudly and quickly if so, and then go do something afterwards otherwise. We presumably expect multiple users that will have a property of being qualified, so let's use a class:

```js

class User { constructor(data) { this.isAuthenticated = data.isAuthenticated; this.hasActiveLicense = data.hasActiveLicense; \\ many more details... }

// Now encapsulate the boolean property of being qualified, for all Users, in one place

isQualified() { return (this.isAuthorized && this.hasActiveLicense && this.hasPaidInFull && this.hasAdminPermissions); } }

// Now, we can use our isQualified() property at each of our API guard clause by checking if the user is NOT qualified:

if (!user.isQualified()) { return res.status(403).json({ "error": "Unauthorized access requested."}); }

// Critically, the API guard clause remains identical even if we change the criteria for validation and what it means to be "qualified"

```

There are of course many other ways to solve this problem beyond this approach. For instance, you could export a function called isUserQualified(user) (or more likely userId) then call it somewhat similarly:

```js

if (!isUserQualified(user)) { return res.status(403).send("Error: Unauthorized access requested"); }

```

The other approach I like is to use a factory pattern to build a userSession with function arrow notation. That's really helpful when you are getting raw data back from a database call, say as a JSON object. That would look like this:

```js

const createUserSession = (userData) => { return { ...userData, // here we use the ...notation for convenience but don't trust this as secure) isQualified() { return ( this.isAuthorized && !this.isSuspended ); } }; };

// Then you instantiate a user session from the request like this:

const user = createUserSession(res.session.user); if (!user.isQualified()) { return res.status(403).send("Error: Unauthorized"); }

```

There are actually loads other approaches too, like using class inheritance (define a parent User class and child QualifiedUser class, for instance), or types. I would say that readability here is less a concern than the issue that you have multiple APIs and if you refactor or change the logic for qualified users, now you have to refactor your most sensitive attack surface at multiple points. It's just safer to have that rewrite only happening once, wherever you put it, in my view.

CLAUDE.md (or AGENTS.md) is not good place to put all code change rules, because these rules would dillute the context and "distract" the agent e.g. during bugs triage or business analysis.

Instead modularize the knowledge with skills and specialized MD files. Agent should lazy load what is needed to do focused work.

Skills have usage description metadata, but with free files you can simply instruct agent with CLAUDE.md to load them, e.g.: "Before you attempt to change any frontend code first load and follow `docs/{JS|HTML|CSS}_coding_rules.md`".

[flagged]

My threshold is three. The third time I duplicate code/behavior is when I start to think about DRYing said code/behavior.

No, you've created a generic condition checker, which is where all of your complexity comes from. Further, you've left the actual check to be duped in all callers.

I argue that is the case in my experience: https://javiergonzalez.io/blog/on-clean-code-2026/

Humans will do this as well, especially inexperienced junior SWEs. Adding a new boolean parameter and some if statements here and there. After a while a seemingly simple function takes four boolean parameters that each control a little bit of what the function does.

The benefit is that a human who is a junior might need at least a few weeks to months of guidance to have a good taste of when to duplicate and when to DRY. An LLM likely already has good judgment, and your prompt merely needs to be activate this judgment.

But LLMs can do it much faster and more consistently.

Code structure still matters for cost effectiveness and performance over time

https://arxiv.org/abs/2605.20049 https://arxiv.org/abs/2605.13280

Counterpoint: as long as context don't rot or it's less effective that starts maintaining repetitions only slightly different. Also

> we are not going back to hand-writing these functions

do you really think there isn't a good chunk, if not the majority outside some bubbles, of developers that still hand code? Crazy to hear, I bet you're not a programmer

Just this morning I was trying to scrape nitter, for funsies. One hour and neither gemini nor kimi were able to write something working, despite trying selenium (or playwright), beautiful soup, and a specific library that can be used to scrape it.

I eventually read the library docs and managed to build a scraper for what I wanted in a few mins. Llms are great for a lot of things, but sometimes you stumble in something that's just outside of what they know/can do and you're sol. And of all the thinks, I didn't expect they would fail at this, to be honest the opposite

It's unlikely that AI will get to the point where it makes handwritten coders redundant, and then not immediately be at the point where vibe coders are redundant too. So if you earnestly take the position that handwriting code is a "ngmi" type activity, you also need to take the position that the vibe coder (or agent- assisted-developer/loop-architect, or whatever its nom de guerre is this week) is "ngmi".

People are so desperate for this to be true. Maybe it comes from a subconscious recognition that their own self-imposed deskilling will inevitably catch up with them.

AI is trained on a various range of code quality, including very low one.

I'm paid to provide good quality code and not flood my company with more average code than it should.

In my previous job, I could regularly reduce a PR code down to 10-20%% of its size because someone overlooked something or was just "overengineer" a feature.

AI are such "bullshiters" that they produce more text than necessary.

Code bloat was already real, but from my personal experience it becomes realer with AI. The outcome of this will likely be apparent when no one can dive into any code base because of the amount of fluff in it (and you will obviously need more AI to deal with this).

Why stop there? If you _use_ handwritten products you’re ngmi. I only use vibe coded operating systems, JavaScript sandboxes, compilers, TLS libraries, databases, rendering engines..

It’s bizarre to me that so many people feel the need to keep parroting this corporate talking point. What do you care? If you think people who eschew LLMs for coding “are not going to make it” or “are going to get left behind”¹, then let them. More opportunities for you, right? Go do your own thing.

¹ As if “moving forward” or “progress” were always a positive. It’s not. Just look at how many regulations we have to forbid or curtail uses of stuff we found to be harmful.

If you don't understand the software you're creating (handwritten or not) you are ngmi.

None of us are "going to make it"

Gotta touch grass.

if your skillset is tied to corporate bullshit, yourre better off buying lottery tickets