[HN Gopher] Be intentional about how AI changes your codebase
___________________________________________________________________
Be intentional about how AI changes your codebase
Author : benswerd
Score : 27 points
Date : 2026-03-19 21:23 UTC (1 hours ago)
(HTM) web link (aicode.swerdlow.dev)
(TXT) w3m dump (aicode.swerdlow.dev)
| benswerd wrote:
| I've seen a lot of people talking about how AI is making
| codebases worse. I reject that, people are making codebases worse
| by not being intentional about how their AI writes code.
|
| This is my take on how to not write slop.
| tabwidth wrote:
| The intention part is right but the bottleneck is review. AI is
| really good at turning your clean semantic functions into
| pragmatic ones without you noticing. You ask for a feature, it
| slips a side effect into something that was pure, tests still
| pass. By the time you catch it you've got three more PRs built
| on top.
| peacebeard wrote:
| In my experience trying to push the onus of filtering out
| slop onto reviewers is both ineffective and unfair to the
| reviewer. When you submit code for review you are saying "I
| believe to the best of my ability that this code is high
| quality and adequate but it's best to have another person
| verify that." If the AI has done things without you noticing,
| you haven't reviewed its output well enough yet and shouldn't
| be submitting it to another person yet.
| peacebeard wrote:
| Agreed. When you submit code you must take responsibility for
| its quality. Blaming AI for low quality code is like blaming
| hammers for giant holes in the drywall. If you don't know how
| to use AI tools without confidence that your code is high
| quality, you need to re-assess how you use those tools. I'm not
| saying AI tools are bad. They're great. But the prevalence of
| people pushing the tools beyond their limits is not a failure
| of the tools. Vibe coding may be fun but tight-leash high-
| oversight AI usage is underrated in my opinion.
| hosh wrote:
| I have a take-home assignment for a hiring process.
|
| Of the 12 or so I have reviewed, 4 looks clearly AI
| generated. 3 of those 4 were clearly slop: they ended up with
| a Frankenstein, mixing three different approaches and doing
| none of them well.
|
| The submission that was not slop was careful and explicit
| about scope. Crucially, it also defined what -not- to
| generate.
|
| You'd also have to know the constraints to add it into the
| specs.
|
| Myself, vibe coding is not fun. Coding is fun. I grew up in
| the generation before the internet and learned programming by
| going through books. Researching approaches with AI have been
| surprisingly useful for me. Tight-leash, high oversight --
| or, for me, more like a surgically precise AI powered "sed"
| is my current sweet spot. Another is if I already have a
| sufficiently commented template file that I can include my
| spec and the template file.
|
| I have friends exploring fully automated systems. I know the
| block is at orchestration systems. I know of a soon-to-be-
| published work that would take this to the next level. I
| would not trust the code generated from any of the current
| attempts at orchestration.
| systemsweird wrote:
| I think there's just a lot of people who would love to push
| lower quality code for a variety of legitimate and illegitimate
| reasons (time pressure, cost, laziness, skill issues, bad
| management, etc). AI becomes a perfect scapegoat for lowered
| code quality.
|
| And you're completely right, humans are still the ones in
| control here. It's entirely possible to use AI without lowering
| your standards.
| mika-el wrote:
| We did something similar -- wrote markdown skill files that teach
| agents our coding patterns. Naming conventions, which libraries
| to use, how we structure components. Basically onboarding docs
| but for agents.
|
| One thing we learned the hard way: shorter rules work better. We
| started with a 600-line comprehensive guide and the agent
| actually got worse. Every token in the skill competes for context
| window space with your actual conversation. Once we cut to under
| 200 lines per skill, consistency went up significantly.
|
| The semantic vs pragmatic function split in this post is a good
| frame. I am not sure agents need that level of abstraction
| explained to them though -- what they actually need is concrete
| examples. "Use pdfplumber not PyPDF2" beats "prefer minimal
| semantic functions" every time.
| p1necone wrote:
| I haven't really extensively evaluated this, but my instinct is
| to _really aggressively_ trim any 'instructions' files. I try
| to keep mine at a mid-double-digit linecount and leave out
| anything that's not critically important. You should also be
| skeptical of any instructions that basically boil down to
| "please follow this guideline that's generally accepted to be
| best practice" - most current models are probably already aware
| - stick to things that are unique to your project, or value
| decisions that _aren 't_ universally agreed upon.
| mrbluecoat wrote:
| ..but unintentional AI (aka Modern Chaos Monkey) is so much more
| fun!
| benswerd wrote:
| LOL fr. I've been talking with some friends about RL on chaos
| monkeying the codebase to benchmark on feature isolation for
| measuring good code.
| ChrisMarshallNY wrote:
| Because of the way that I use AI, I am constantly looking at the
| code. I usually leave it alone, if I can; even if I don't really
| like it.
|
| I will, often go back, after the fact, and ask for refactors and
| documentation.
|
| It works. Probably a lot slower than using agents, but I test
| every step, and it is a _lot_ faster than I would do it,
| unassisted.
| benswerd wrote:
| I don't think testing the product alone is good enough, because
| when you give it tests it has to pass it prioritizes passing
| them at the expense of everything else -- including code
| quality. I've seen it pull in random variables, break semantic
| functions, etc.
| ChrisMarshallNY wrote:
| Oh, no. I test. Each. and. Every. Step.
|
| I use a test harness, and step through the code, look at
| debug logs, and abuse the code, as much as possible.
|
| Kind of a pain, but I find unit tests are a bit of a "false
| hope" kind of thing: https://littlegreenviper.com/testing-
| harness-vs-unit/
| clbrmbr wrote:
| Page not rendering well on iPhone Safari.
|
| Good content tho!
___________________________________________________________________
(page generated 2026-03-19 23:00 UTC)