6 ms·

I've set a few rules for working with coding agents: 1. If I use a coding agent to generate code, it should be something I am absolutely confident I can code c

• dathanb82 5mo ago
  I’ve also heard it being called “comprehension debt,” which I like a little more because I think it’s more precise: the specific debt being accrued is exactly a lack of comprehension of the code.
  • baddash 5mo ago
    Yeah I like that better too, gonna start using that
  • cassianoleal 5mo ago
    I think it’s both in fact. Comprehension debt just sounds like there are things you don’t (yet) understand. Cognition debt means your lack of understanding compounds and the cognition “space” required to clear it increases accordingly. An increasing comprehension debt that can be paid off one bit at a time within reasonable cognition space takes linear time to clear. Cognition debt takes exponential time to clear the more of it you have. If it reaches a point where you simply don’t have the space for the cognition overhead required to understand the problem, you probably need to start over from your specifications.
    • baddash 5mo ago
      Woah, didn't expect a cognition debt researcher to be in the comment section jk :D your points make a lot of sense though!
      • cassianoleal 5mo ago
        lol no. Just an opinionated grey bearded software engineer with sleep deprivation. :D
  • layer8 5mo ago
    I like that too. However, “cognitive debt” points to the possibility of cognitive overload, that the code can become so complex and inscrutable that it may become impossible to comprehend. “Comprehension debt” sounds a bit weaker in that respect, that it’s just a matter of catching up with one’s comprehension.
  • kortilla 5mo ago
    “You can outsource your thinking, but not your understanding.”
• TranquilMarmot 5mo ago
  This is great until the "gun to your head" is your skip-level manager demanding that a feature be implemented by the end of the week, and they know you can just "generate it with AI" so that timeline is actually realistic now whereas two years ago it would have required careful planning, testing, and execution.
  • nertirs3 5mo ago
    I hate this current trend of managers deciding, what tools developers have to use. Hopefully it ends soon.
    • nikau 5mo ago
      Time will tell if outages and defect resolution sky rocket or if ai can deal with it
      • adrianN 5mo ago
        Does that matter that much in practice? I bet lots of costumers are okay with software that crashes 10x as much if it costs 10x less. There already is a ton of shitty software that still sells.
        • drchickensalad 5mo ago
          > if it costs 10x less This will not happen. Nobody desires to give that up. Also AI does not deliver even remotely that much true value multiplier
  • fransje26 5mo ago
    Well, that's nice. Your manager is unknowingly helping you create a form of job security for yourself, with all the technical debt and bugs being accumulated. He might not understand it, and it might not be the type of work you want to do, but someone is going to have to fix those issues. And the longer they wait, the bigger the task gets.
• jimsojim 5mo ago
  While this is a legitimate set of rules to follow for maintaining code sanity and a solid mental model of how a codebase may grow, it’s always challenging to stick to them in a workplace where expectations around delivery speed have changed drastically with the onset of AI. The sweet spot lies in striking a balance between staying connected to the codebase and not becoming a limiting factor for the team at the same time.
  • baddash 5mo ago
    That's kind of what I figured, sadly. I haven't experienced it personally yet since I got let go from my last job about 14 months ago, but it makes so much sense given how management is so willing to sacrifice quality for speed.
    • jimsojim 5mo ago
      Another frustrating thing that has emerged from this is where managers “vibe code” half-baked ideas for a couple of hours and then hand it off as if they’ve meaningfully contributed to the implementation. Suddenly you’re expected to reverse engineer incoherent prompts, inconsistent code, and random abstractions that nobody fully understands. In their mind they’ve already done the “architectural heavy lifting” and accelerated the team. More often than not it just adds cognitive overhead where you spend more time deciphering and cleaning up garbage than actually building the thing properly from scratch.
      • 6LLvveMx2koXfwn 5mo ago
        I am lucky to have never worked in a team where my manager wouldn't expect strong push back in this scenario. Many of the corporate environments described on here seem dystopian, this included.
      • KronisLV 5mo ago
        Vouching for this comment because my friend confided in me a week ago that her manager also does this and is like “oh yeah, here’s 80% done, you just do the rest so we can ship it” when a large part of it is slop that needs to be rewritten, due to not enough guidance and pushback during generation.
• bmitc 5mo ago
  This is about how I use it. I initially use it to carve out an architecture and iterate through various options. That saves a lot of time for me having to iterate through different language features and approaches. Once I get that, I have it scaffold out, and I go in and tidy things up to my personal liking and standards. From there, I start iterating through implementations. I generally have been implementing stuff myself, but I've gotten better at scaffolding out functions/methods through code instead of text. Then I ask it to finish things off. That falls into your first category of letting it implement stuff that I already know I could do. Not sure if it's faster. But it's lower cognitive load for me, since I can start thinking about the next steps without being concerned about straightforward code. This all works pretty great. Where it starts going off the rails is if I let it use a library I'm not >=90% comfortable with. That's a good use of these tools, but if I let it plow through feature requests, I end up accumulating debt, as you pointed out. For my uses, I'm still finding the right balance. I'm not terribly sure it makes me faster. What I do think it helps with is longer focused sections because my cognitive load is being reduced. So I can get more done but not necessarily faster in the traditional sense. It's more that I can keep up momentum easier, which does deliver more over time. I'm interested in multi agent systems, but I'm still not sure of the right orchestration pattern. These AI tools still can go off the rails real quick.
• brabel 5mo ago
  I was trying to follow similar rules, until one day I had to solve a hard mathematical problem. Claude is a phd level mathematician, I am not. I, however, know exactly the properties of the desired solution and how to test it’s correct. So I decided to keep Claude’s solution over my basic, naive one. I mentioned that in the pull request and everyone agreed that was the right call. Would you open exceptions like that in your rules? What if AI becomes so much better at coding than you , not just at doing advanced mathematics? Would you then stop to write code by hand completely since that would be the less optimal option, despite you losing your ability to judge the code directly at that point (and as in my example, you can still judge tests, hopefully)? I think these are the more interesting questions right now.
  • Jweb_Guru 5mo ago
    > Claude is a phd level mathematician Unfortunately, it is not, and many of its attempts at mathematical proofs have major flaws. You shouldn't trust its proofs unless you are already able to evaluate them--which I think is pretty much all the OP is saying.
    • adrianN 5mo ago
      To be fair, many of the proof attempts that mathematicians do also have major flaws. Most get caught before getting published.
      • seba_dos1 5mo ago
        But that's the actually important difference. Mathematicians have the toolset and processes to catch the flaws, random people using Claude don't.
    • IanCal 5mo ago
      Trust isn’t a binary, and I can trust things I don’t understand enough that I can use them. OP was talking about needing to understand, which is quite a bit above the level of being able to validate enough to use for a task.
  • 5mo ago
• gritzko 5mo ago
  I just had a Claude episode. Instead of trying to fix the bug, it edited the data to hide the bug in the sample run. This kind of BS behavior is not rare. Absolutely, if you do not understand every bit of what's going on, you end up with a pile of BS.
  • dzhiurgis 5mo ago
    That’s why I love gemini - none of this bullshit ever happen.
    • gritzko 5mo ago
      I do not think Gemini can relieve a developer from knowing what he is doing.
      • 2ndorderthought 5mo ago
        There's some really weird and unusual posts glazing Google in here today. Bot accounts out in force!
        • dzhiurgis 5mo ago
          Says 27 day old account
          • 2ndorderthought 5mo ago
            Believe it or not I am only 27 days old.
      • dzhiurgis 5mo ago
        No but it can actually go a fix a bug instead of disabling unit test..?
• whitefang 5mo ago
  I agree to this though it also depends on the nature of project. Had a project idea which I coded with the help of AI and it became quite large to a point I was starting to have uncharted areas in the code. Mostly because I reviewed it too shallow or moved fast. It was a good thing as that project never floated but if I were to do such a thing on my breadwinning project I would lose the joy.
• IanCal 5mo ago
  This is fine if it’s more enjoyable for you, that’s what’s important in personal projects most of the time. But we don’t follow the same things for dependencies, work of colleagues, external services, all the layers down to the silicon when trying to work. Why is AI suddenly different? We just have to do this by risk and reward. What’s the downside if it’s wrong, and how likely is an error to be found in testing and review? What is the benefit gained if it’s all fine? This is the same for libraries and external services. A complex financial set of rules in a non-updatable crypto contract with no testing? A viewer for your internal log data to visualise something?
  • marginalia_nu 5mo ago
    It is and has always been immensely helpful to understand what you are doing in any context. There are some programmers who treat the job as just plumbing together what is to them completely incomprehensible black boxes, who treat the computer as a mystery machine that just does things "somehow", but these programmers will almost always be hacks that spend their entire career producing mediocre code. There are things such a programmer can build, but they are very limited by their lack of in depth understanding, and it is only a tiny fraction of what a more competent programmer can put together. To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth. You don't have to be an expert at these things by any means, but you do need to understand them and be comfortable treating them as transparent boxes that you may have to go in and fiddle with at some point to get where you need to go. Sometimes you need to vendor a dependency and change it. Sometimes you need to drop it entirely and replace it with something more fit for purpose you built yourself.
    • lo_zamoyski 5mo ago
      That's a little simplistic and lacking in nuance. > To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth. I think maybe you overestimate your own knowledge here. It's one thing to understand general principles and design or to understand a contextually-relevant vertical or whatever. It's another to demand comprehensive (even if not expert) familiarity in non-trivial projects, especially those created by many developers over long time spans. It's not just a question of intelligence or dedication or even just time spend working on a project. The amount of software even your typical piece of code relies on is staggering and shifting, and it's only getting more complicated. A good chunk of software engineering and programming language research has been focused on making it practical to operate in such an complex environment - an environment that nobody fully understands - which is a major part of why modularity exists. Making software like "plumbing together [...] black boxes" is exactly what such research aspired to accomplish, because it allows different developers to focus on different scopes and focus on the domain they're working on. Software engineering is a practical field, and any system that requires full knowledge to operate, modify, and extend is either relatively small (maybe greenfield and written by a sole developer) or impractical to work with. So I would say there's a wide gap between "lazy guy who doesn't give a shit" and "guy who thinks he can understand everything". Both lack the humility and wisdom needed to know the limits of their knowledge, to circumscribe what he needs to understand, and to operate within the space these afford. (Both extremes remind me of cocky junior devs. On the one hand, you have the junior dev who carelessly churns out "hot shit" garbage code by plumbing things together with no grasp or appreciation of sound design; on the other you have the dev who makes a big show about "rigor" completely detached from the actual realities and needs of the project. In each case, the dev is failing to engage intelligently with the subject matter.)
• throwaway2027 5mo ago
  I already followed those rules mostly with StackOverflow and before AI.
• i_love_retros 5mo ago
  It's not worth fighting it at work. If the idiots you work for want everything vibe coded and delivered at 5 * 2025 speed then just vibe code and try to leave the company ASAP. That's where I am right now. Of course I might end up somewhere just as ridiculous or maybe not be able to even find another job. Shitty times we live in right now.
  • duskdozer 5mo ago
    I'm hoping I'll manage to skate by long enough that by the time something like that comes to pass I can just retire
• seba_dos1 5mo ago
  I had a similar approach, but in the end I don't think it's feasible to actually sufficiently follow the rule 2. It sounds good in theory, but in practice you'll always take some mental shortcuts that you may not even be aware of. Try digging into an unknown codebase to fix some issue and compare how much will stay in your head a week after if you do it yourself or if you "completely understand" what an agent did for you. When I do it myself, it contributes to my general knowledge and I mostly retain the important parts in my head even if I lose the details over time; when I try to own what an agent did as if it was mine, it feels like I understand it well at the time after putting some effort into it but then I forget it all very fast. Ultimately I decided that having an LLM help me there is actually detrimental to my goals most of the time, and that's without even considering some other concerns raised by sibling comments here such as time and business pressures.
• dyauspitr 5mo ago
  You’re going to be the least productive developer in any work setting from this point on. There are people checking in 50k lines of solid TDD verified, non bloat, instrument performance checked feature code per day. Your 200 lines isn’t going to cut it for very long.
  • pydry 5mo ago
    I dont believe this for one second. There ought to be entire sets of teams of devs replaced by one guy if this the case. There ought to be popular open source projects suddenly being improved at 10x previous speed if it were true. Im seeing plenty of evidence of slop being churned out fast, often creating work for others in the process. I keep reading all over social media about these "hypercharged 10x AI devs". But, I see literally zero evidence of their existence beyond a series of comments on internet forums of "trust me bro".
  • abalashov 5mo ago
    That may indeed look like quite the speed-up. But the accumulated errors and entropy in such an enterprise will eventually cause a cave-in, at which point the productivity metrics don't look so good.
  • badc0ffee 5mo ago
    50k lines per day, or at least 1 million lines a month, per team member. How many months can you keep that up, and keep calling it "non bloat"?
    • dyauspitr 5mo ago
      Well you stop when you have what you want. It doesn’t have to go the whole month. Over the last couple of months I’ve had to ride product and my business analysts hard because they can’t seem to come up with new features fast enough.
• ventana 5mo ago
  I often break these rules for one specific aspect of my personal projects: if it has a web frontend, I don't want to know what kind of CSS magic the agent used to make it look as it looks. I'll happily accept whatever unmaintainable AI slop it produces, because I don't want to spend any time figuring out if my understanding of flexbox (or anything else related) is wrong again, and why.
• CapsAdmin 5mo ago
  While this is all good practice in theory, I wonder how much discipline plays a role here? I am not very disciplined, and find it too convenient to reach for an agent these days. This may sound ridiculous, but I am addicted to nicotine. I used to have some sort of rule around how I am allowed to use nicotine pouches to manage my addiction. For example after I finish writing a feature, I could have one pouch. It was obviously a dumb idea that didn't last very long.. But in that specific aspect, coding agents feel similar. I tried setting up rules on how I should use them, but it's not easy to follow them. Maybe the biggest problem is just guilt?