> Who cares about DRY? You don't have to be the one updating the same long conditional in four different files - the AI will just do it for you! Right?
One pattern I've really been enjoying lately has to do with a language called haxe. It's designed to be compiled into other languages (java, python, others). There's this extension called reflaxe which lets you make mini compilers for compiling haxe into pretty much anything.
So if I have anything with duplicate structure... like maybe I want the CLI subcommands to resemble the http API. $ foo bar --baz 6 # equivalent to HTTP GET /foo/bar?baz=6 or something like that. Then I have the LLM maintain a haxe source of truth and then have it compile that source of truth to the other stuff.
Previously I was using OpenAPI spec's and generators for this, but they wound up feeling like a black box that I ended up debugging all the time. The reflaxe setup is much more generic. So you end up with this mountain of generated code, but unlike LLM-generated code it's obviously generated (in .../generated/thingy.py or whatever) and a comment at the top of the file says where to look to learn how it's generated). I'm generating docs this way.
So even though the repo is large, the parts of it that are authoritative remain small. I find LLM's manage this boundary much better because it's so crisp an in their face. But they have to be told to do this, otherwise they'll just create context-size problems that they'll later struggle with.
cadamsdotcom 2 hours ago [-]
Write yourself a /review command. That is an empty markdown file at `.claude/commands/review.md`. In it, put a checklist of things the agent should look for. When you’re ready to have your agent review the code, type `/review`. The checklist will be examined and it’ll plan out some findings to ask you if you want them fixed.
Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider: ...” and proceeds to a bullet list of things.
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. Know what? Agents don’t care that they just got a wall of generic feedback, they happily look into all the bullet points.
I added “ensure the new things aren’t duplicating code that already exists elsewhere” and it gave me such a surprise - it really truly started planning cleanups!
We are just scratching the surface. We have to give tools to our tools so they can use them to be better tools for us.
wismwasm 30 minutes ago [-]
I have good experience with using open-code-review:
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`
dugmartin 22 minutes ago [-]
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.
soperj 3 minutes ago [-]
Why wouldn't it already just do this though?
notatoad 10 seconds ago [-]
It does. Claude has a built in review and it’s pretty good. But it doesn’t know exactly what you want. This is a way to tell it.
ebiester 1 hours ago [-]
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.
Espressosaurus 22 minutes ago [-]
Yeah. I have a set of 5 review prompts attacking different problems, an adversarial review, and then a final synthesis, with the best results gotten by multiple passes using multiple models (the adversarial review stage combining all passes into one review per model and the synthesis picking the best of the two or three adversarial reviews). Expensive but it actually finds real problems that the single pass reviews rarely seem to find.
conception 1 hours ago [-]
Or a dynamic workflow. $$$ but lots of coverage.
1 hours ago [-]
is_true 1 hours ago [-]
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.
planb 59 minutes ago [-]
I have good results with this prompt after every larger change: Now do a final code check. Is everything tidy and do the components adhere to the principle of separations-of-concerns. Is everything in an understandable and maintainable state? Do we make any assumptions that may not be true anymore? Is any code left over from previous edits or experiments that does not belong into the codebase? Is the documentation still representing the current state of code?
Benjammer 27 minutes ago [-]
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.
mnicky 3 minutes ago [-]
For things the agent forgets to obey often, at least in Claude Code, there are also "output styles" that are more deeply embedded - into a system prompt - and agent is also periodically reminded of them during the session: https://code.claude.com/docs/en/output-styles
I haven't used them so far but maybe these would work better than basic instructions for such cases.
Ancalagon 23 minutes ago [-]
Just pull the slot machine lever
cyanydeez 37 minutes ago [-]
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.
weitendorf 18 minutes ago [-]
It means the same thing to you, but not to the whole spectrum of people using AI. You literally see it on Reddit all the time where people are complaining about the same model either over-engineering or doing too much, vs it being requiring too much steering or not being autonomous or capable enough to hand off tasks to on its own.
The reason prompting it to review its own work for loose ends, record any new undocumented or noteworthy behavior, suggest changes to tests/processes to make it go more smoothly the next time, etc is that it’s prescriptive and process-oriented (and thus easily verifiable/done in-context) rather than descriptive and outcome oriented (which to do properly could require way more context than the model has, because it doesn’t know what it doesn’t know about your particular work, only what it’s seen so far).
Even promoting it to do these after-the-fact vs as an upfront requirement can have a big impact IMO. If you make “maintainability” part of the task before it’s seen the real work it will focus on general “best practices” crap rather than the real work, so either way if this is something you care about it doing you have to give it guidance for how you want it done.
If you were to review the logs of a model after the fact, you’d also not really save on input tokens unless you compressed the context or sharded it out, which can easily miss the small details that constitute the difference between “what actually happened” vs “how the LLM models this general class of problems” unless the first pass involves the entire context anyway. That said I do think there’s a lot of value in building some kind of pipeline for validating and aggregating these “learnings” across sessions.
chopete3 47 minutes ago [-]
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.
We still need to discuss this things for real? Aren't they already taken for granted after all this "experimenting" with LLMs? I'm wondering when we will discuss hand coding again without treating it like a taboo anymore. LLMs can be useful in so many ways it's tiring knowing people are delegating the entire source code typing to agents, to me it's like hearing from people that the web is good and we should be happy with it
hakunin 4 minutes ago [-]
I have been on a quest to get AI to code like me, using pi harness, and any model that it can support. I'm mostly a Ruby programmer, so here's my journey so far.
1. Created a "coding" skill with every practice I posted on my blog website, as well as a bunch I had in the queue to blog about but never got a chance, summarized into "do this" kind of language. This is more or less good for any PL, but a bit Ruby-slanted.
2. Created a "rails" skill because that's my framework, where similarly I explained my approach to architecting Rails apps.
3. Created a "writing" skill where I literally fed it my entire blog, and tried to get it to write more like me (mixed success, weaker models did better for some reason, but I haven't tried the GPT-5.6 series yet).
4. Next, I really wanted it to format code exactly like I would, even things like "let's make this `if` into a ternary, let's split these assignment groups with a line break, let's vertically align here, but not there", but with GPT-5.5 (my primary driver up until yesterday) there's almost no way to make a skill of reasonable size that will be consistently applied. So instead I instructed the agent to write me a Rubocop cop for every single situation I ever encounter where I would've formatted code slightly differently. This was quite powerful, because I usually thought of linters as enforcers of objective consistency decisions in the codebase, but this was me going full format nazi on the agent. And the nice part is that these cops can contain some non-autocorrectable feedback, which AI will follow.
5. I'm working on a review loop where the most easily missed parts above get double checked. This is the first thing I'm doing with pi subagents. (I feel like I'm getting better results if I don't use subagents for code exploration, other tool calls). The idea here is that I want reviews to be in the implementation loop. I always read/review code in the end, but so want it to have gone through the review loop before it gets to me. Since implementation is already context-heavy, I want to be able to orchestrate this loop without adding to the implementation context.
6. I'm also adjusting all of the above for GPT-5.6, because it requires less guidance, so I'm carefully trimming the verbiage to save tokens.
So far the results have been surprisingly good. I want to experiment with GLM-5.2 running under these constraints.
One invariant in all of this: I read the code. My end product is not working software, it's good code (which also incidentally produces working software).
illuminator83 6 minutes ago [-]
I've seen lots of code that people have maintained for 20 years and its full of these duplication and worse.
In fact I'm sad to say that majority of code I've seen people write and maintain is worse than what LLMs produce today.
Often it is inexperience, sometimes it is willful negligence, but most often it is just tight deadlines and pressure to do finish whatever is being done right now. People know how to do it better, but nobody got the time and budget to actually do it.
LLMs also learned from that.
egonschiele 28 minutes ago [-]
In a similar vein, here's my favorite prompt: "Please review the tests you've written. Will the tests actually test what they're meant to? If the code breaks, will the test fail?" It's amazing how often LLMs will write tests that don't test anything.
alexpotato 2 hours ago [-]
There is an old quote:
"Add comments to your code under the assumption that the next person to maintain it is a homicidal maniac who knows where you live"
TimTheTinker 52 minutes ago [-]
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.
fphilipe 24 minutes ago [-]
This is what has been frustrating me most lately. Even though I have a rule in my global CLAUDE.md that says:
> Only write comments to explain the why when it is not obvious from the code (rationale, gotchas, constraints). Do not comment on the what — well-named code already says it. Do not comment on how a framework works.
It still keeps adding these bad comments. When I then ask it to review the comments based on my preferences it then deletes most of them or improves them.
Today I asked Claude why it disrespects my preference and it said that the surrounding code was like that and it followed that style. It suggested I add this line to my global CLAUDE.md file:
> The comment rule above beats the style of the surrounding code: neighboring files with what-style comments are not license to write more of them, and comments carried along when porting or copying code must be re-judged against the rule, not kept for consistency.
Let's see if that improves things.
mnicky 5 minutes ago [-]
In Claude Code there are also "output styles" that are more deeply embedded - into a system prompt - and agent is also periodically reminded of them during the session: https://code.claude.com/docs/en/output-styles
Maybe these would work better for such cases.
jawilson2 31 minutes ago [-]
Yeah, agreed. These have started popping up a lot more recently, where I get a 5 sentence paragraph explaining how function overloading works in c++.
boredtofears 15 minutes ago [-]
I have tried prompting it out and providing strong guidelines in my AGENTS.md against it, but I still get _way_ too many useless "explain the code" style comments no matter how much I try. I usually have to do something like "Look at all commits in the past X days and remove (DO NOT TRIM) all comments that are not truly exceptional"
Normally when I can't get claude to follow a prompt I try a lint hook, but it's tough to lint something that subjective.
hansonkd 2 hours ago [-]
The comments that drive the most homicidal behavior are outdated or inaccurate comments rather than no comments.
saghm 2 hours ago [-]
Sure, but the proportion of code that drives homicidal behavior is heavily weighted towards non-comments. You're a lot more likely to piss off whoever inherits your code with the code that actually does something being bad or a lack of documentation than with comments.
jraph 1 hours ago [-]
I'm quite fine with no comments but correctly named variables and functions. This can't become out of sync contrarily to "out of band" comments. I take this over commented code with poorly named stuff any day.
I've also seen a lot of comments that restate what the code already says and that's just noise, more work to keep in sync, an additional thing that can fail, and more cognitive load because you have to read twice the same thing (best case, if code and comment are still in sync). That's the result you risk when you think you must comment your code.
I appreciate the occasional comment that explains why something seems overly tricky or weird or not immediately intuitive. Once, I had left such a comment that saved myself years later from making a mistake. Of course, this should be kept at a minimal level. It leads to me liking clear code with few comments the most. (Some guidelines, even if it's not perfect, to limit complexity and spaghetti code help a lot).
Function, class, module documentation is also useful so you don't have to read the whole thing and you know what it's intended to provide (which is slightly different than simply what it provides, and this differences is important).
AnimalMuppet 60 minutes ago [-]
I worked with this guy. He'd write the code, and comment where needed, and then he would ask "How can I make this comment unnecessary?" The answer was usually to rename something, so that what he was doing was obvious.
jraph 57 minutes ago [-]
Nice, I love this. That's pretty satisfying.
mekoka 40 minutes ago [-]
Ignorance will always be a better starting point for discovery than wrong assumptions. If you leave comments, they must reflect what the code is actually doing. If during edit it's no longer the case, at least mark them as stale. The next best thing is indeed to remove them.
minraws 2 hours ago [-]
Both can be true at the same time, we can be equal opportunity murderers who treat lazy verbosity and hippester terse code.
gowld 2 hours ago [-]
Put your home address in the comments. Problem solved.
sejje 51 minutes ago [-]
I moved after I wrote the comment. It's hard to keep everything up to date.
SoftTalker 25 minutes ago [-]
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.
dionian 27 seconds ago [-]
sounds like a recipe for over-commenting. The code should be self-documenting. Comments are for the places where there are dragons.
40 minutes ago [-]
snarfy 9 minutes ago [-]
## HARD RULE - design scope must always be maintained and no function should ever be longer than XXX lines and no class should have more than Y methods. Create new classes and subclasses and refactor until the criteria are met.
You'd be surprised how readable this makes the code when XXX is about the size of your vertical screen and Y is relatively small.
alexsmirnov 13 minutes ago [-]
The problem of duplicated code described in the article, goes in a different way in reality: AI does not update 4 places in the same way, but implement them a slightly different. I found diverged business logic all the time. For example, file upload dialog for a document with the same meaning: in one place, it accepts pdf only. Another allows to upload pdf or docx. The last accepts pdf, doc, docx, and txt.
dofm 6 minutes ago [-]
Do you think the steel birds with the food in will come back if we light torches in long lines on the plateau again?
carimura 2 hours ago [-]
I continually run codebases through different models to have them look for bad code smells like repeated code. That's been pretty effective. You do have to maintain over time or else you end up with a sloppy mess which I can only imagine compounds.
sejje 50 minutes ago [-]
Do you think it matters that it's a different model?
Or is it more about the review process and a context reset?
bluGill 3 minutes ago [-]
I have personally not found value in a different model. The review itself often is good.
2 hours ago [-]
MattyRad 21 minutes ago [-]
This is an agreeable article, sure, but the idea that an LLM fueled group or team will collectively have this discipline is... idk... bemusing and saddening at the same time.
baptou12 15 minutes ago [-]
I agree, but “write code like a human will maintain it” can also be limiting: if LLMs reduce the cost of maintaining more explicit or verbose code, we should use that to raise the standard, not preserve compromises made for human convenience.
bluGill 4 minutes ago [-]
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.
godshatter 31 minutes ago [-]
Could someone show me what a shared helper would look like in this case? This code looks easily readable to me and I fear abstracting it will just make it harder to reason about. Is it just variable_with_a_better_name = that conditional?
Snoopfrogg 48 minutes ago [-]
Or we start writing code without LLMs.
danielbln 32 minutes ago [-]
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.
el_io 34 minutes ago [-]
Cat is out of the bag. Other than recreational programming I doubt many will write code without any form of LLM.
schnebbau 2 hours ago [-]
That sounds like a good idea, but shipping 10x as many features and bugfixes sounds better.
I started using AI with the best intentions. Checking everything before committing. Improving output by hand if it didn't quite follow the existing code style guidelines or variables were not named as well as they should be. Or if it did something sloppy or hacky.
Now, AI GOES BURRRRRRRRRRRR! If the tests pass it's good to ship. AI can deal with the problems it may create. No problems so far.
saghm 1 hours ago [-]
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.
geraldwhen 22 minutes ago [-]
It’s a new form of development. The thing that the author didn’t state is that to work the code base at all, you must also use these tools and workflows.
Manual edits literally aren’t possible. You can’t grok the code growth and the new patterns fast enough to be productive.
This does work. I’ve seen it in real products. Nobody has a real mental model of the code flows. But with enough money in Claude credits it doesn’t matter.
The spend to support this development model is something like $50/day/developer.
thevillagechief 47 minutes ago [-]
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.
swatcoder 1 hours ago [-]
> 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?
javier123454321 56 minutes ago [-]
OP is making toys, not enterprise software
embedding-shape 2 hours ago [-]
> 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.
schnebbau 1 hours ago [-]
Yes, this resonates. I have noticed things slow down over time. But fortunately my app will never grow that big so I don't think it will be an issue.
The solution, as you say, is probably to break it down into isolated sub-components that are only aware of each other's APIs and nothing more.
javier123454321 57 minutes ago [-]
Yeah, for personal software, enterprise practices don't make sense.
matt_kantor 2 hours ago [-]
How long has "so far" been?
pauletienney 2 hours ago [-]
I second that question
schnebbau 1 hours ago [-]
Since November.
AnimalMuppet 38 minutes ago [-]
Yeah... in at least some circumstances, "maintainable" means, like, 20 years. 8 months is not an adequate test.
hansonkd 2 hours ago [-]
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"
geraneum 1 hours ago [-]
That sounds like a good idea but how do you know what you’re shipping?
exabrial 1 hours ago [-]
One does not exclude the other
latexr 1 hours ago [-]
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.
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.
cmrdporcupine 2 hours ago [-]
The bigger problem is the number of things you don't understand will grow substantially from under your feet, and then you'll slip on it.
jaredcwhite 8 minutes ago [-]
Write code like an agent will never touch it, that's my motto.
(Because it's true.)
luciana1u 26 minutes ago [-]
Write code like a human will maintain it — and that human is you at 3am six months from now, fueled by regret and cold coffee.
rconti 20 minutes ago [-]
I have very mixed results with LLMs, but I actually find they're really GOOD at, unprompted, pointing out existing code that is redundant and could be simplified and so on.
Where it really, really struggles for me is in existing complex infra codebases.
dionian 1 minutes ago [-]
my LLM does this pretty well with my coaching. i use a good model and i encourage it to make such improvements. and since the llm is trained on human maintainers it works fine.
internet101010 24 minutes ago [-]
No. I will generate code in a way that makes it easier for clankers to maintain it, because they will actually be doing the maintaining. In practice, this means that most of my time is dedicated to improving the repo harness because the state of the repo harness directly determines the quality of the codebase as a whole.
At a minimum, there should be precommit checks and CI workflows that cause PRs to fail if the documentation is not up-to-date and synced with the other docs.
Then regular codebase analysis for improvement. This is where you find the bug sources, make new modules for consolidation, and get those +5000/-4000 PRs that people stuck in the world of manual code review hate.
ramshorst 26 minutes ago [-]
So the new prompt is "Write code like a human will maintain it" ?
uhhhd 30 minutes ago [-]
Counterpoint: This no longer matters because we are not going back to hand-writing these functions. These patterns were designed to make code easier for humans to read and write, but that is no longer the primary way software is built.
iecheruo 16 minutes ago [-]
Code structure still matters for cost effectiveness and performance over time
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
geraldwhen 19 minutes ago [-]
The change is exponential and happening daily. The future is smaller teams spending a lot of money on AI credits.
hollowturtle 15 minutes ago [-]
If it really is exponential intelligence should have already exploded. Go give away your certainties on a seer's forum
exabrial 1 hours ago [-]
What I'm seeing is the organizations that had written code standards:
* define the software layers, their function, and the max depth allowed
* establish a corp code formatter for each language, along with a process to PR it
* establish a business vocabulary and what the terms mean
* establish a data dictionary, make it part of the database schema/table/col comments
Are far more successful with LLMs. You _should_ have been doing this years ago, but with LLMs its a super power.
dsagent 2 hours ago [-]
Very much this. LLMs are not producing code humans can maintain unless you take your time with them and still care about the quality of the output.
Maybe someone has the perfect claude.md that solves this problem but I have not seen it.
imhoguy 1 hours ago [-]
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`".
phaser 1 hours ago [-]
The first line of my AGENTS.md is: You are an engineer who writes code for *human brains, not machines*.
The key idea here is that your codebase is context that will be used for future changes. And context determines the model’s output, so it’s still worth having a well-designed codebase.
Easier said than done to be honest, especially if there are many people (and their agents) pushing code. It’s hard to keep up these days.
cmiles74 15 minutes ago [-]
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.
imilev 18 minutes ago [-]
What happens when shit hits the fan in my exp is that I have to crack open the codebase and debug some portion of it, so I can explain it to myself in order to be able to explain what is wrong to the LLM.
Otherwise what I have found is that the LLM will add a new if statement which will handle the newly discovered issue and you start stacking them ifs. As the article mentions LLM's unlike humans aren't lazy, they will copy, paste add patches for every issue, why bother think and understand root cause :d.
So as part of our review we have a rule against that as well.
kccqzy 16 minutes ago [-]
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.
ge96 57 minutes ago [-]
Been getting these vibe coded PRs ugh code PR submitter can't even explain
francisofascii 1 hours ago [-]
Before LLMs we didn't have time for code quality. LLMs make our jobs faster, so now we have time to dedicate to code quality, right?
It's interesting that the author didn't mention considering updating their agentic code review prompt to keep an eye out for repetitive/duplicate code.
k4200 48 minutes ago [-]
I'm not sure this guy is using the same LLMs as we do. A small AGENTS.md or CLAUDE.md easily prevents issues like that.
trjordan 1 hours ago [-]
AI is so miserable for this. It's so focused on doing what you ask, it forgets that there's stuff worth doing that you didn't ask for, like defining reasonable abstractions.
Getting away from stuff like this is exactly why I want to use AI. When I say "implement this for idle but active users," I _want_it to define isUserActiveIdle() and stuff these 4 conditionals in it. Having to check the generated code for stuff like this undoes, like .... all the benefit of using AI.
AI makes all these little decisions for us. I can about some of these decisions. I just want to notice when it's doing this without having to make my eyes bleed reading 10k lines of generated code a day.
Forgeties79 1 hours ago [-]
[flagged]
DCKing 1 hours ago [-]
I run various forms of workflows to run dedicated QA, code review (of various flavors) simplification and text simplification agents. Especially the simplification goes a long way to remove dumb padding, duplication and efficiency. Dedicated docs/comment simplification is also becoming more and more necessary on recent models. For things like feature development in my workflow, the majority of time the agents run and tokens spent is critiquing the code from various perspectives and it's not close.
Of course, this doesn't solve the overall issue that agents don't write code like you and still requires a lot of human attention in planning and code review out to clean up leftover issues, and e.g. challenge bad assumptions about architecture and real-world context. A human is still very much needed to cull the slop (or, more gratuitously: align the agent). But IME it does help avoid a lot of pitfalls and makes the code high quality a lot more quickly.
bdcravens 2 hours ago [-]
Humans have been writing unmaintainable code well before LLMs came along.
BadBadJellyBean 2 hours ago [-]
But LLMs can do it much faster and more consistently.
bdcravens 2 hours ago [-]
They had good teachers. :-)
andrewjneumann 2 hours ago [-]
Have a bit of a contrarian view on this tl;dr don’t write code for human consumption if you use AI; BUT you have to accept AI coding lock in and change how you work.
Just run weekly cron job to assess code quality and highlight candidates for refactoring. In addition to doing the same in each PR, of course, but things can get through.
jasonlotito 46 minutes ago [-]
linting tools, static analysis, CPD, etc. These are all old things you can continue to use and are much more robust than anything you can prompt. These should be standard when using LLMs. In fact, you can tighten the rules even more enforcing more restrictions so you ONLY get the output you want. put this behind a pre-commit hook and a CI job that runs on a PR, and it will work wonders.
You can have all the prompts you want on top of this, but if you don't have this automated stuff running behind the scenes, you aren't serious about these issues.
Looking through some of these comments here, I see lots of people rewriting concrete rules in markdown willing to spend tokens on the hope AI won't miss it where an actual program won't.
deadbabe 2 hours ago [-]
I absolutely will not write corporate code like humans are maintaining it anymore, because I don’t have any confidence actual humans will be maintaining it.
For personal projects, I can trust that I myself will be maintaining things so I still write things like it matters, but I do not extend the trust to others.
jdw64 2 hours ago [-]
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.
— John F. Woods (1991)
cyanydeez 2 hours ago [-]
AI isnt taking my job. my company is supporting local AI for development. who ever comes after me will have the same hardware and models or better. unless a MBA is put in charge, my boss and predecessors can maintain and build out as needed.
bottom up AI use seems a godsend compared to the corporate AI rat race.
i setup some slop reporting systems and ensured my boss knows theyre great starting points but serious use requires real time investment.
Black_Triangle 32 minutes ago [-]
[flagged]
amaze_28 19 minutes ago [-]
[dead]
ing33k 2 hours ago [-]
And hope it works?
I’m pretty sure many people who use AI to write emails or blog posts add "make it sound like a human wrote it" to their prompts. We all know what the result usually looks like.
If AI is writing my code, I'd rather have it focus purely on correctness and efficiency than on making the code easy to read.
heck! I might even ask it to imitate Arthur Whitney’s style.
/s
Invictus0 2 hours ago [-]
[flagged]
kreco 55 minutes ago [-]
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).
Invictus0 38 minutes ago [-]
blah blah blah YOU ARE GOING TO BE REPLACED
kreco 16 minutes ago [-]
Yes. But definitely not this year.
cliglot 37 minutes ago [-]
[flagged]
amarcheschi 1 hours ago [-]
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
Invictus0 37 minutes ago [-]
gemini is a terrible model... my cat also can't scrape nitter, try using something with actual intelligence
gdulli 2 hours ago [-]
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.
sejje 12 minutes ago [-]
People are so desperate for [GP post] to not be true. Maybe it comes from a subconscious recognition that their own hard-earned skillset will inevitably become obsolete.
[More seriously, the comment you replied to doesn't put out any desperation. It's stated like a fact. It could easily be based on logic & reason, not emotional desperation.]
Invictus0 37 minutes ago [-]
i havent written a line of code in months
OtherShrezzing 2 hours ago [-]
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".
Invictus0 35 minutes ago [-]
you are very smart
theultdev 2 hours ago [-]
He just means the development pace has picked up with AI.
I've been doing this for 15 years, I love coding manually.
However, with AI-assistance I can do projects in 3 days what would take 6 months.
It's not vibe coding, everything is controlled, reviewed, understood, refined by me in the end.
But still the dev time is magnitudes faster. I would not hire anyone that is adverse to AI.
I'm actually happier. With age and a family I was getting a bit slower.
Now I have more time to spend with them AND I'm getting more done. Including personal projects I never had the bandwidth for.
latexr 1 hours ago [-]
> I can do projects in 3 days what would take 6 months.
The hyperbole on this keeps growing every time I see it. Soon we’ll be having people claiming they can do in 12 seconds what used to take them 17 years. What is never presented is proof. People (and programmers are no exception) are notoriously bad at estimating. We already did studies where people thought they were being faster with LLMs when they were in fact being slower.
As companies begin to rehire to fix the mess made by LLMs, it’s clear that just getting something out the door isn’t enough. It never was. Maintenance is an important part of any long-standing system.
theultdev 19 minutes ago [-]
It's not a hyperbole. I know how long it takes me to do something.
And the last project truly would have taken me 6 months.
It was done in 3 days after fable 1:1 the design, setup the infrastructure, and turned all tasks and specs into code.
Everything was done day 1, but it took 2 days to manually clean it, test, and correct small issues.
--
But that does make sense you're seeing "hyperboles" grow, AI is getting better very quickly, so you'll see the time saved estimations grow.
Less than a year ago I'd say it was saving me about a month of work, mainly because it sucked at UI.
klabb3 2 hours ago [-]
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..
tjwebbnorfolk 2 hours ago [-]
This is cute reductio ad absurdum, but it does nothing to refute the basic point made
discreteevent 20 minutes ago [-]
There was no point made. You couldn't find a shallower comment. Why are you even bothered to defend it?
2 hours ago [-]
latexr 1 hours ago [-]
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.
matt_kantor 2 hours ago [-]
If you don't understand the software you're creating (handwritten or not) you are ngmi.
cmrdporcupine 2 hours ago [-]
None of us are "going to make it"
Gotta touch grass.
cyanydeez 2 hours ago [-]
if your skillset is tied to corporate bullshit, yourre better off buying lottery tickets
tristan666 2 hours ago [-]
u right
Rendered at 15:47:00 GMT+0000 (Coordinated Universal Time) with Vercel.
One pattern I've really been enjoying lately has to do with a language called haxe. It's designed to be compiled into other languages (java, python, others). There's this extension called reflaxe which lets you make mini compilers for compiling haxe into pretty much anything.
So if I have anything with duplicate structure... like maybe I want the CLI subcommands to resemble the http API. $ foo bar --baz 6 # equivalent to HTTP GET /foo/bar?baz=6 or something like that. Then I have the LLM maintain a haxe source of truth and then have it compile that source of truth to the other stuff.
Previously I was using OpenAPI spec's and generators for this, but they wound up feeling like a black box that I ended up debugging all the time. The reflaxe setup is much more generic. So you end up with this mountain of generated code, but unlike LLM-generated code it's obviously generated (in .../generated/thingy.py or whatever) and a comment at the top of the file says where to look to learn how it's generated). I'm generating docs this way.
So even though the repo is large, the parts of it that are authoritative remain small. I find LLM's manage this boundary much better because it's so crisp an in their face. But they have to be told to do this, otherwise they'll just create context-size problems that they'll later struggle with.
Mine starts with “Enter plan mode. Examine the differences on this branch vs. main. Consider: ...” and proceeds to a bullet list of things.
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. Know what? Agents don’t care that they just got a wall of generic feedback, they happily look into all the bullet points.
I added “ensure the new things aren’t duplicating code that already exists elsewhere” and it gave me such a surprise - it really truly started planning cleanups!
We are just scratching the surface. We have to give tools to our tools so they can use them to be better tools for us.
* https://github.com/alibaba/open-code-review
** https://layandreas.github.io/personal-blog/posts/beyond-vide...
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`
Will try your approach to distill the code to bullet points.
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.
I haven't used them so far but maybe these would work better than basic instructions for such cases.
The models will interpret this willynilly; but nonetheless, it's often a better than doing nothing.
The reason prompting it to review its own work for loose ends, record any new undocumented or noteworthy behavior, suggest changes to tests/processes to make it go more smoothly the next time, etc is that it’s prescriptive and process-oriented (and thus easily verifiable/done in-context) rather than descriptive and outcome oriented (which to do properly could require way more context than the model has, because it doesn’t know what it doesn’t know about your particular work, only what it’s seen so far).
Even promoting it to do these after-the-fact vs as an upfront requirement can have a big impact IMO. If you make “maintainability” part of the task before it’s seen the real work it will focus on general “best practices” crap rather than the real work, so either way if this is something you care about it doing you have to give it guidance for how you want it done.
If you were to review the logs of a model after the fact, you’d also not really save on input tokens unless you compressed the context or sharded it out, which can easily miss the small details that constitute the difference between “what actually happened” vs “how the LLM models this general class of problems” unless the first pass involves the entire context anyway. That said I do think there’s a lot of value in building some kind of pipeline for validating and aggregating these “learnings” across sessions.
I am following similar steps from this article https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...
1. Created a "coding" skill with every practice I posted on my blog website, as well as a bunch I had in the queue to blog about but never got a chance, summarized into "do this" kind of language. This is more or less good for any PL, but a bit Ruby-slanted.
2. Created a "rails" skill because that's my framework, where similarly I explained my approach to architecting Rails apps.
3. Created a "writing" skill where I literally fed it my entire blog, and tried to get it to write more like me (mixed success, weaker models did better for some reason, but I haven't tried the GPT-5.6 series yet).
4. Next, I really wanted it to format code exactly like I would, even things like "let's make this `if` into a ternary, let's split these assignment groups with a line break, let's vertically align here, but not there", but with GPT-5.5 (my primary driver up until yesterday) there's almost no way to make a skill of reasonable size that will be consistently applied. So instead I instructed the agent to write me a Rubocop cop for every single situation I ever encounter where I would've formatted code slightly differently. This was quite powerful, because I usually thought of linters as enforcers of objective consistency decisions in the codebase, but this was me going full format nazi on the agent. And the nice part is that these cops can contain some non-autocorrectable feedback, which AI will follow.
5. I'm working on a review loop where the most easily missed parts above get double checked. This is the first thing I'm doing with pi subagents. (I feel like I'm getting better results if I don't use subagents for code exploration, other tool calls). The idea here is that I want reviews to be in the implementation loop. I always read/review code in the end, but so want it to have gone through the review loop before it gets to me. Since implementation is already context-heavy, I want to be able to orchestrate this loop without adding to the implementation context.
6. I'm also adjusting all of the above for GPT-5.6, because it requires less guidance, so I'm carefully trimming the verbiage to save tokens.
So far the results have been surprisingly good. I want to experiment with GLM-5.2 running under these constraints.
One invariant in all of this: I read the code. My end product is not working software, it's good code (which also incidentally produces working software).
"Add comments to your code under the assumption that the next person to maintain it is a homicidal maniac who knows where you live"
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.
> Only write comments to explain the why when it is not obvious from the code (rationale, gotchas, constraints). Do not comment on the what — well-named code already says it. Do not comment on how a framework works.
It still keeps adding these bad comments. When I then ask it to review the comments based on my preferences it then deletes most of them or improves them.
Today I asked Claude why it disrespects my preference and it said that the surrounding code was like that and it followed that style. It suggested I add this line to my global CLAUDE.md file:
> The comment rule above beats the style of the surrounding code: neighboring files with what-style comments are not license to write more of them, and comments carried along when porting or copying code must be re-judged against the rule, not kept for consistency.
Let's see if that improves things.
Maybe these would work better for such cases.
Normally when I can't get claude to follow a prompt I try a lint hook, but it's tough to lint something that subjective.
I've also seen a lot of comments that restate what the code already says and that's just noise, more work to keep in sync, an additional thing that can fail, and more cognitive load because you have to read twice the same thing (best case, if code and comment are still in sync). That's the result you risk when you think you must comment your code.
I appreciate the occasional comment that explains why something seems overly tricky or weird or not immediately intuitive. Once, I had left such a comment that saved myself years later from making a mistake. Of course, this should be kept at a minimal level. It leads to me liking clear code with few comments the most. (Some guidelines, even if it's not perfect, to limit complexity and spaghetti code help a lot).
Function, class, module documentation is also useful so you don't have to read the whole thing and you know what it's intended to provide (which is slightly different than simply what it provides, and this differences is important).
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.
You'd be surprised how readable this makes the code when XXX is about the size of your vertical screen and Y is relatively small.
Or is it more about the review process and a context reset?
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.
I started using AI with the best intentions. Checking everything before committing. Improving output by hand if it didn't quite follow the existing code style guidelines or variables were not named as well as they should be. Or if it did something sloppy or hacky.
Now, AI GOES BURRRRRRRRRRRR! If the tests pass it's good to ship. AI can deal with the problems it may create. No problems so far.
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.
Manual edits literally aren’t possible. You can’t grok the code growth and the new patterns fast enough to be productive.
This does work. I’ve seen it in real products. Nobody has a real mental model of the code flows. But with enough money in Claude credits it doesn’t matter.
The spend to support this development model is something like $50/day/developer.
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?
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.
The solution, as you say, is probably to break it down into isolated sub-components that are only aware of each other's APIs and nothing more.
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
(Because it's true.)
Where it really, really struggles for me is in existing complex infra codebases.
At a minimum, there should be precommit checks and CI workflows that cause PRs to fail if the documentation is not up-to-date and synced with the other docs.
Then regular codebase analysis for improvement. This is where you find the bug sources, make new modules for consolidation, and get those +5000/-4000 PRs that people stuck in the world of manual code review hate.
https://arxiv.org/abs/2605.20049 https://arxiv.org/abs/2605.13280
> 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
* define the software layers, their function, and the max depth allowed
* establish a corp code formatter for each language, along with a process to PR it
* establish a business vocabulary and what the terms mean
* establish a data dictionary, make it part of the database schema/table/col comments
Are far more successful with LLMs. You _should_ have been doing this years ago, but with LLMs its a super power.
Maybe someone has the perfect claude.md that solves this problem but I have not seen it.
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`".
Taken from: https://github.com/zakirullin/cognitive-load/blob/main/READM...
Easier said than done to be honest, especially if there are many people (and their agents) pushing code. It’s hard to keep up these days.
I think I would prefer code that is clear, understandable and simple even if it doesn’t compile and needs some straightforward polishing.
Otherwise what I have found is that the LLM will add a new if statement which will handle the newly discovered issue and you start stacking them ifs. As the article mentions LLM's unlike humans aren't lazy, they will copy, paste add patches for every issue, why bother think and understand root cause :d.
So as part of our review we have a rule against that as well.
Getting away from stuff like this is exactly why I want to use AI. When I say "implement this for idle but active users," I _want_it to define isUserActiveIdle() and stuff these 4 conditionals in it. Having to check the generated code for stuff like this undoes, like .... all the benefit of using AI.
AI makes all these little decisions for us. I can about some of these decisions. I just want to notice when it's doing this without having to make my eyes bleed reading 10k lines of generated code a day.
Of course, this doesn't solve the overall issue that agents don't write code like you and still requires a lot of human attention in planning and code review out to clean up leftover issues, and e.g. challenge bad assumptions about architecture and real-world context. A human is still very much needed to cull the slop (or, more gratuitously: align the agent). But IME it does help avoid a lot of pitfalls and makes the code high quality a lot more quickly.
Funny enough, discussed this yesterday
Stop Optimizing Code for Humans https://youtube.com/live/eLn4-XA-KdQ?feature=share
You can have all the prompts you want on top of this, but if you don't have this automated stuff running behind the scenes, you aren't serious about these issues.
Looking through some of these comments here, I see lots of people rewriting concrete rules in markdown willing to spend tokens on the hope AI won't miss it where an actual program won't.
For personal projects, I can trust that I myself will be maintaining things so I still write things like it matters, but I do not extend the trust to others.
— John F. Woods (1991)
bottom up AI use seems a godsend compared to the corporate AI rat race.
i setup some slop reporting systems and ensured my boss knows theyre great starting points but serious use requires real time investment.
I’m pretty sure many people who use AI to write emails or blog posts add "make it sound like a human wrote it" to their prompts. We all know what the result usually looks like.
If AI is writing my code, I'd rather have it focus purely on correctness and efficiency than on making the code easy to read.
heck! I might even ask it to imitate Arthur Whitney’s style.
/s
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).
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
[More seriously, the comment you replied to doesn't put out any desperation. It's stated like a fact. It could easily be based on logic & reason, not emotional desperation.]
I've been doing this for 15 years, I love coding manually.
However, with AI-assistance I can do projects in 3 days what would take 6 months.
It's not vibe coding, everything is controlled, reviewed, understood, refined by me in the end.
But still the dev time is magnitudes faster. I would not hire anyone that is adverse to AI.
I'm actually happier. With age and a family I was getting a bit slower.
Now I have more time to spend with them AND I'm getting more done. Including personal projects I never had the bandwidth for.
The hyperbole on this keeps growing every time I see it. Soon we’ll be having people claiming they can do in 12 seconds what used to take them 17 years. What is never presented is proof. People (and programmers are no exception) are notoriously bad at estimating. We already did studies where people thought they were being faster with LLMs when they were in fact being slower.
As companies begin to rehire to fix the mess made by LLMs, it’s clear that just getting something out the door isn’t enough. It never was. Maintenance is an important part of any long-standing system.
And the last project truly would have taken me 6 months.
It was done in 3 days after fable 1:1 the design, setup the infrastructure, and turned all tasks and specs into code.
Everything was done day 1, but it took 2 days to manually clean it, test, and correct small issues.
--
But that does make sense you're seeing "hyperboles" grow, AI is getting better very quickly, so you'll see the time saved estimations grow.
Less than a year ago I'd say it was saving me about a month of work, mainly because it sucked at UI.
¹ 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.
Gotta touch grass.