10 ms·

Be intentional about how AI changes your codebase

• ares623 7mo ago
  What if it's not _my_ codebase?
• rsmtjohn 7mo ago
  [flagged]
• benswerd 7mo ago
  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.
  • Heer_J 7mo ago
    [dead]
  • tabwidth 7mo ago
    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 7mo ago
      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.
      • skydhash 7mo ago
        Code review should be a transmission of ideas and helping spotting errors that can slip in due to excessive familiarity with the changes (which are often glaring to anyone other than the author). If you're not familiar with the patch enough to answer any question about it, you shouldn't submit it for review.
  • peacebeard 7mo ago
    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.
    • deleted 7mo ago
      [deleted]
    • newAccount2025 7mo ago
      I think this is mostly right. In a blameless postmortem style process, you would look at not just the mistake itself but the factors influencing the mistake and how to mitigate them. E.g., doctor was tired AND the hospital demanded long hours AND the industry has normalized this. So yes, the programmers need to hold the line AND ALSO the velocity of the tool makes it easy to get tired AND and its confidence and often-good results promote laziness or maybe folks just don’t know better AND it can thrash your context and bounce you around the code base making it hard to remember the subtleties AND on and on. Anyway, strong agree on “dude, review better” as a key part of the answer. Also work on all this other stuff and understand the cost of VeLOciTy…
  • ChimpWithHat 7mo ago
    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.
  • lukaslalinsky 7mo ago
    Fully agree. AI or not, it's still the human developer's responsibility to make sure the code is correct and integrates well into the codebase. AI just made it easier to be sloppy about it, but that doesn't mean that's the only way to use these tools.
• mika-el 7mo ago
  [flagged]
  • p1necone 7mo ago
    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.
  • w29UiIm2Xz 7mo ago
    Shouldn't all of this be implicit from the codebase? Why do I have to write a file telling it these things?
    • cjonas 7mo ago
      For any sufficiently large codebase, the agent only ever has a very % of the code loaded into context. Context engineering strategies like "skills" allow the agent to more efficiently discover the key information required to produce consistent code.
    • cyanydeez 7mo ago
      mostly because reading the code base fills up the context window; as you aggregate context, you then need to synthesize the basics; these things arnt intelligence; they dont know whats useless and whats useful. They're as accurate as the structureyou surround them with.
  • keeganpoppen 7mo ago
    it’s not that shorter rules are intrinsically better, it’s that longer rules tend to have irrelevant junk in them. ceteris paribus, longer rules are better. it’s just most of the time the longer rules fall under the Blaise Pascal-ian “i regret i didn’t have time to make this shorter”.
• mrbluecoat 7mo ago
  ..but unintentional AI (aka Modern Chaos Monkey) is so much more fun!
  • benswerd 7mo ago
    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 7mo ago
  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 7mo ago
    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 7mo ago
      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/ https://littlegreenviper.com/testing-harness-vs-unit/
      • cindyllm 7mo ago
        [dead]
    • butILoveLife 7mo ago
      [dead]
    • stpedgwdgfhgdd 7mo ago
      You can ask it to /simplify Related, it seems to me that there are two types of tests, the ones created in a TDD style and can be modified and the ones that come from acceptance criteria and should only be changed very carefully.
    • theshrike79 7mo ago
• clbrmbr 7mo ago
  Page not rendering well on iPhone Safari. Good content tho!
  • butILoveLife 7mo ago
    [dead]
• deleted 7mo ago
  [deleted]
• gravitronic 7mo ago
  *adds "be intentional" to the prompt* Got it, good idea.
• abcde666777 7mo ago
  My intentionality is that I'll never let it make the changes. I make the changes. I might make changes it suggests, but only upon review and only written with my hands.
  • benswerd 7mo ago
    I think this style of work will go away. I was skeptical but I now write the majority of my code through agents.
    • thepukingcat 7mo ago
      +1 for this, once you have a solid plan with the AI and prompt it to make one small changes at a time and review as you go, you could still be in control of your code without writing a single line
    • dougg 7mo ago
      I see this a lot in research as well, unfortunately including myself. I do miss college where I would hand write a few thousand lines of code in a month, but i’m just so much more productive now.
    • abcde666777 7mo ago
      I don't think it will go away, I think there will remain a niche for code where we care about precision. Maybe that niche will get smaller over time, but I think it will be a hold out for quite a while. A loose analogy I've found myself using of late is comparing it to bespoke vs off the shelf suits. For instance, two things I'm currently working on: - A reasonably complicated indie game project I've been doing solo for four years. - A basic web API exposing data from a legacy database for work. I can see how the API could be developed mostly by agents - it's a pretty cookie cutter affair and my main value in the equation is just my knowledge of the legacy database in question. But for the game... man, there's a lot of stuff in there that's very particular when it comes to performance and the logic flow. An example: entities interacting with each other. You have to worry about stuff like the ordering of events within a frame, what assumptions each entity can make about the other's state, when and how they talk to each other given there's job based multi-threading, and a lot of performance constraints to boot (thousands of active entities at once). And that's just a small example from a much bigger iceberg. I'm pretty confident that if I leaned into using agents on the game I'd spend more time re-explaining things to them than I do just writing the code myself.
• fhouser 7mo ago
  [dead]
• mattacular 7mo ago
  Code cannot and should not be self documenting at scale. You cannot document "the why" with code. In my experience, that is only ever used as an excuse not to write actual documentation or use comments thoughtfully in the codebase by lazy developers.
  • bdangubic 7mo ago
    this always starts out right but over the years the code changes and its documentation seldom does, even on the best of teams. the amount of code documentation that I have seen that is just plain wrong (it was right at some point) far outnumbers the amount of code documentation that was actually in-sync with the code. 30 years in the industry so large sample size. now I prefer no code documentation in general
    • derrak 7mo ago
      Are there any good systems that somehow enforce consistency between documentation and code? Maybe the problem is fundamentally ill-posed.
      • sgc 7mo ago
        I am not saying it doesn't matter because it does, but how much does it matter now since we can get documentation on the fly? I started working on something today I hadn't touched in a couple years. I asked for a summary of code structure, choices I made, why I made them, required inputs and expected outputs. Of course it wasn't perfect, but it was a very fast way to get back up to speed. Faster than picking through my old code to re-familiarize myself for sure.
        • codingdave 7mo ago
          We cannot get full documentation on the fly, though. We can get "what this does" level of documentation for the system that AI is looking at. And if all you are doing is writing some code, maybe that is enough. But AI cannot offer the bigger picture of where it fits in the overall infrastructure, nor the business strategy. It cannot tell you why technical debt was chosen on some feature 5-10 years ago. And those types of documentation are far more important these days, as people write less of the code by hand. This is the same discussion that goes round ad nauseum about comments. Nobody needs comments to tell us what the code does. We need comments to explain why choices were made.
• Sense_101856 7mo ago
  [dead]
• openclaw01 7mo ago
  [dead]
• AgentOrange1234 7mo ago
  "Every optional field is a question the rest of the codebase has to answer every time it touches that data," This is a beautiful articulation of a major pet peeve when using these coding tools. One of my first review steps is just looking for all the extra optional arguments it's added instead of designing something good.
  • shepherdjerred 7mo ago
    There's nothing specific to AI about this. Humans make the same mistake. To solve this permanently, use a linter and apply a "ratchet" in CI so that the LLM cannot use ignore comments
    • oblio 7mo ago
      Is there a Python linter that does this?
      • datsci_est_2015 7mo ago
        Not that I’m aware of (writing Python 10+ years). Suppose you could vibecode one yourself though.
      • KronisLV 7mo ago
        I've been writing my own linter that's supposed to check projects regardless of the technology (e.g. something that focuses on architecture and conventions, alongside something like Oxlint/Oxfmt and Ruff and so on), with Go and goja: https://github.com/dop251/goja https://github.com/dop251/goja Basically just a bunch of .js rules that are executed like: projectlint run --rules-at ./projectlint-rules ./src Which in practice works really well and can be in the loop during AI coding. For example, I can disallow stuff like eslint-disable for entire files and demand a reason comment to be added when disabling individual lines (that can then be critiqued in review afterwards), with even the error messages giving clear guidelines on what to do: var WHAT_TO_DO = "If you absolutely need to disable an ESLint rule, you must follow the EXACT format:\n\n" + "// prebuild-ignore-disallow-eslint-disable reason for disabling the rule below: [Your detailed justification here, at least 32 characters]\n" + "// eslint-disable-next-line specific-rule-name\n\n" + "Requirements:\n" + "- Must be at least 32 characters long, to enforce someone doesn't leave just a ticket number\n" + "- Must specify which rule(s) are being disabled (no blanket disables for ALL rules)\n" + "- File-wide eslint-disable is not allowed\n\n" + "This is done for long term maintainability of the codebase and to ensure conscious decisions about rule violations."; The downside is that such an approach does mean that your rules files will need to try to parse what's in the code based on whatever lines of text there are (hasn't been a blocker yet), but the upside is that with slightly different rules I can support Java, .NET, Python, or anything else (and it's very easy to check when a rule works). And since the rules are there to prevent AI (or me) from doing stupid shit, they don't have to be super complex or perfect either, just usable for me. Furthermore, since it's Go, the executable ends up being a 10 MB tool I can put in CI container images, or on my local machine, and for example add pre-run checks for my app, so that when I try to launch it in a JetBrains IDE, it can also check for example whether my application configuration is actually correct for development. Currently I have plenty in regards to disabling code checks, that reusable components should show up in a showcase page in the app, checking specific configuration for the back end for specific Git branches, how to use Pinia stores on the front end, that an API abstraction must be used instead of direct Axios or fetch, how Celery tasks must be handled, how the code has to be documented (and what code needs comments, what format) and so on. Obviously the codebase is more or less slop so I don't have anything publish worthy atm, but anyone can make something like that in a weekend, to supplement already existing language-specific linters. Tbh ECMAScript is probably not the best choice, but hey, it's just code with some imports like: // Standalone eslint-disable-next-line without prebuild-ignore if (trimmed.indexOf("// eslint-disable-next-line") === 0) { projectlint.error(file, "eslint-disable-next-line must be preceded by: " + IGNORE_MARKER, { line: lineNum, whatToDo: WHAT_TO_DO }); continue; } Can personally recommend the general approach, maybe someone could even turn it into real software (not just slop for personal use that I have), maybe with a more sane scripting language for writing those rules.
• xiaolu627 7mo ago
  What changed for me isn’t that AI writes bad code by default, but that it lowers the friction to adding code faster than the team can properly absorb it. The dangerous part is not obvious bugs, it’s subtle erosion of consistency.
  • vinnymac 7mo ago
    Well said. I have to review PRs of non-software developers nowadays. The “what is this trying to do?” has never been harder to answer than before. It creates scenarios where 99% is correct, but the most important area is subtly broken. I prefer it to be human, where 60-80% will be correct, and the problematic areas begin to smell more and more gradually. In my experience LLMs, at times, may hide the truth from you in a haystack made of needles.
    • thienannguyencv 7mo ago
      This very matches my observation. The error isn't due to incorrect code—it's code that looks specific to your system but is actually generic patterns applied from the training process. The structure is correct, the logic is sound, it just doesn't interact with what your source code actually does. Harder to catch because nothing is factually wrong. You have to ask: could this output have been produced without actually reading my codebase?
  • riteshkew1001 7mo ago
    [flagged]
  • mrvinhpro 7mo ago
    [dead]
• earljwagner 7mo ago
  The concepts of Semantic Functions and Pragmatic Functions seem to be analogous to a Functional Core and Imperative shell (FCIS): https://testing.googleblog.com/2025/10/simplify-your-code-functional-core.html https://testing.googleblog.com/2025/10/simplify-your-code-fu... The key insight of FCIS is that complicated logic with large dependencies leads to a large test suite that runs slowly. The solution is to isolate the complicated logic in the functional core. Test that separately from the simpler, more sequential tests of the imperative shell.
  • bcjdjsndon 7mo ago
    I think it's much better put in your link. Op is too vague on what constitutes pragmatic v semantic... when what he should just say is make it pure functional because then you don't have to simulate a database in your test suite.
• lucas36666 7mo ago
  [dead]
• WWilliam 7mo ago
  [flagged]
• ueda_keisuke 7mo ago
  AI feels less like an autonomous programmer and more like a very capable junior engineer. The useful part is not just asking it to write code, but giving it context: how the codebase got here, what constraints are intentional, where the sharp edges are, and what direction we want to take. With that guidance, it can be excellent. Without it, it tends to produce changes that make sense in isolation but not in the system.
  • slopinthebag 7mo ago
    Fuck off bot
    • thienannguyencv 7mo ago
      Yes, it scored 84% in GPTZero's AI test, but it was still "good enough" to pass HN's anti-AI test.
• divyanshu_dev 7mo ago
  The velocity problem is real. AI makes it easy to add things faster than you can understand what you added. The intentionality has to come before you prompt, not after you review.
  • theshrike79 7mo ago
    Why? You can ask the agent to make 10 different solutions in the time it takes you to make 0.5. Then you review them based on whatever criteria you feel is right and either throw them all away and do it yourself (maybe with inspiration from the other solutions) or pick one to progress further.
    • diatone 7mo ago
      If 9 of those solutions are crummy and reviewing them takes longer than just doing it right once…
    • divyanshu_dev 7mo ago
      Depends on the system for boilerplate yes, reviewing 10 solutions is faster. But when the code is deeply interconnected, reviewing solutions you don't fully understand just moves the problem downstream you end up with passing tests and broken assumptions.
• bobokaytop 7mo ago
  [dead]
• c3z_ 7mo ago
  [dead]
• microbuilderco 7mo ago
  [flagged]
• xmcqdpt2 7mo ago
  This could have been html instead of whatever awful moving pattern it is.
  • christophilus 7mo ago
    Wow. You weren’t joking.
  • abdusco 7mo ago
    God forbid people use CSS to build something cool
    • sph 7mo ago
      Cool? It’s broken on my iPhone, text appears beneath other text for no discernible reason. The result of AI coding ‘cool’ websites instead of learning how to use CSS properly.
  • benswerd 7mo ago
    Made it with Vite+. Highly recommend trying it, rolldown HMR and build times are freakishly fast.
• heliumtera 7mo ago
  Dog, be intentional with you web page. Holy fuck Batman
• amavashev 7mo ago
  Agree, you need to your own code review, although as AI gets better, this problem will most likely be solved.
• deadlypointer 7mo ago
  site is totally broken on mobile, just because cursor can vibe code a nice rolling scrolling shithole, chances are it will break on some platform/browser
• maciejj 7mo ago
  I've noticed the cleaner the codebase, the better AI agents perform on it. They pick up on existing patterns and follow them. Throw them at a messy repo and they'll invent a new pattern every time. It's basically like hiring a new developer for one task and letting them go right after. They don't know your conventions, your history, or why things are the way they are. The only thing they have is what they can see in the code. Your code quality is basically the prompt now.
• theogravity 7mo ago
  Site renders extremely poorly on mobile safari that it is completely unreadable.