{"slug": "managing-the-hidden-overhead-of-ai-software-engineering", "title": "Managing the Hidden Overhead of AI Software Engineering", "summary": "A developer argues that AI coding agents shift the bottleneck in software engineering from writing code to understanding and verifying it, warning that parallel agents let teams start far more work than they can review or maintain. The piece notes that heavy AI adoption correlates with significantly longer PR review times, and that passing tests does not guarantee software matches the intended design, citing an example where an agent implemented a more permissive permission system than specified.", "body_md": "There is a scene that is becoming more and more common in software development right now.\n\nYou have one AI coding agent refactoring something.\n\nAnother one is writing tests.\n\nA third is handling some annoying migration you did not want to touch yourself.\n\nYou are bouncing between terminals, checking progress, answering questions, approving changes, and generally supervising a tiny army of extremely enthusiastic robot developers.\n\nAnd then the thought hits you:\n\n**I could open another terminal.**\n\nI have absolutely done this.\n\nThe problem is not that running multiple agents is automatically bad. Parallel work can be incredibly useful. The problem is that the second AI gives us more capacity, our first instinct is often to immediately fill that capacity with even more AI work.\n\nInstead of asking, “What should I do with the time this just gave me?” we ask, “How much more stuff can I cram into this workflow?”\n\nThat works for a while.\n\nThen things start getting weird.\n\nI do not think there is much point pretending otherwise.\n\nAI coding tools can make development dramatically faster, especially for certain kinds of work.\n\nBoilerplate that used to take half an hour can appear in seconds. Setting up basic project scaffolding is almost trivial. Stupid syntax mistakes disappear faster. Tests, utility functions, repetitive components, documentation, migrations, and all kinds of boring little tasks can be delegated.\n\nSo naturally, developers start doing more.\n\nThat feature you were going to put off until next week? Might as well do it now.\n\nThat weird side project idea? Fire up another agent.\n\nThat one annoying task nobody wants to do? Toss it at the AI.\n\nSuddenly the amount of work you can *start* feels almost unlimited.\n\nThe amount of work you can actually understand, review, and maintain is another story.\n\nIf you generate code five times faster, you can also lose track of what the hell is happening five times faster.\n\nOne of the strangest signs of this is when you find yourself reading an AI-generated summary of a change just to remember what your own project is doing.\n\nI have caught myself doing this.\n\nThe agent finishes some task, gives me a neat little summary, and I am reading it thinking, “Oh right. That is what we were changing.”\n\nThat is probably not a great sign.\n\nAt that point, you are no longer really engineering the system. You are managing a queue of things being engineered around you.\n\nAnd that becomes dangerous when the mistake is not obvious.\n\nImagine you ask an agent to implement a permission system.\n\nThe code looks clean.\n\nThe naming matches the rest of the project.\n\nThe tests pass.\n\nNothing immediately looks broken, so you approve it and move on.\n\nExcept maybe your prompt never clearly defined how restrictive the permissions were supposed to be. The model filled in the missing details itself and chose something more permissive than you intended.\n\nThe tests still pass because they only verify that permissions work.\n\nThey do not verify that the permissions match the security model you had in your head.\n\nThat distinction matters a lot:\n\n**Passing tests does not automatically mean the software is doing what you actually intended.**\n\nIt moved it.\n\nFor a long time, one of the slowest parts of programming was simply turning an idea into working code.\n\nYou had to write the implementation yourself, debug it, fix syntax errors, wire everything together, and slowly turn the design into something executable.\n\nAI can now blast through a lot of that work.\n\nGreat.\n\nBut now we have a different bottleneck.\n\n**Understanding and verification.**\n\nThe faster code gets generated, the more code somebody has to review.\n\nAnd generated code still needs review.\n\nHeavy AI adoption among developers correlates with significantly longer PR review times. That makes sense. If everyone suddenly starts producing dramatically more code, human review capacity does not magically increase along with it.\n\nThis gets even more interesting with experienced developers working in large, complicated codebases.\n\nAI can feel faster because you are typing less, while actually making the overall task slower because you now have to carefully inspect a bunch of generated code interacting with years of existing architecture.\n\nThat is one of the things I think gets lost in a lot of AI productivity discussions.\n\nAI is amazing at some kinds of development.\n\nSmall isolated features? Great.\n\nBoilerplate? Fantastic.\n\nA giant legacy system where changing one innocent-looking function somehow breaks seven unrelated things and awakens a forgotten service from 2014?\n\nDifferent story.\n\nAnd this creates a strange contradiction.\n\nAI is writing more and more production code, while developers still regularly report hallucinations, incorrect output, and limited trust in what the models produce.\n\nWe are delegating faster than we are learning how to verify.\n\nThat creates **verification debt**.\n\nYou save time during generation, but some of that time has not really disappeared.\n\nIt has just been moved somewhere else.\n\nMaybe into code review.\n\nMaybe into debugging.\n\nMaybe into production incidents six weeks later when somebody finally discovers the assumption the model quietly made.\n\nPart of this is technical.\n\nPart of it is also very human.\n\nThere is a weird little dopamine hit that comes from watching AI agents crank through tasks.\n\nFeature finished.\n\nAnother PR.\n\nAnother commit.\n\nAnother task crossed off the list.\n\nVisible output feels productive.\n\nMeanwhile, spending two hours understanding an architecture diagram or reading framework documentation might produce exactly zero commits.\n\nEven if it saves you ten hours later.\n\nThere is also a measurement problem.\n\nIt is easy to count closed PRs.\n\nIt is harder to measure “developer now understands the system well enough to prevent three terrible architectural decisions.”\n\nAnd then there is the career anxiety around AI.\n\nA lot of developers are understandably wondering what all of this means for their jobs.\n\nThat creates pressure to become the person running more agents, producing more code, and moving faster.\n\nAlmost like we need to prove we can keep up with the machines by becoming extremely efficient machine supervisors.\n\nThe irony is that blindly maximizing AI output may make us worse at the exact skills we are going to need most.\n\nThis is the part I think matters most.\n\nIf AI saves you two hours, you do not necessarily need to spend those two hours generating another two hours worth of code.\n\nUse some of that time for the stuff developers never had enough time for before.\n\nNot skim it looking for the one code snippet that solves your immediate problem.\n\nActually read it.\n\nUnderstand how the framework works.\n\nRead the architecture docs.\n\nLook at the edge cases.\n\nUnderstand why the API behaves the way it does.\n\nThe better your mental model of the system is, the better your prompts become too.\n\nAI works a hell of a lot better when the person steering it understands what they are steering.\n\nThis is probably one of the biggest workflow improvements you can make.\n\nBefore launching an agent, clearly define what the thing should do.\n\nAlso define what it should **not** do.\n\nWrite down important constraints.\n\nDefine security boundaries.\n\nMention the ugly edge cases.\n\nTell the model what must remain unchanged.\n\nA prompt like:\n\nAdd a permission system.\n\nleaves a massive amount of room for interpretation.\n\nA specification that explains permission scopes, forbidden wildcard access, role inheritance, failure behavior, expected tests, and review requirements leaves considerably less.\n\nModels are very good at filling gaps.\n\nUnfortunately, they do not always fill them with what you meant.\n\nWild concept, I know.\n\nSometimes the best thing you can do with your newly reclaimed development time is talk to the product person, designer, teammate, user, or whoever actually understands the requirement you are about to implement.\n\nAI can generate twenty implementations of an unclear requirement.\n\nIt cannot magically make the requirement less unclear.\n\nArchitecture decisions.\n\nImportant tradeoffs.\n\nWhy something was implemented a certain way.\n\nWhat absolutely should not be changed without understanding some weird dependency.\n\nThis stuff becomes even more valuable when AI agents are touching the codebase.\n\nGood documentation gives both humans and agents better context.\n\nAnd unlike yet another generated feature, it keeps paying off later.\n\nThe basic idea is pretty simple:\n\n**The time AI gives you is often more valuable when you spend it doing things AI cannot do well than when you immediately throw another agent at another task.**\n\nI do not think there is one perfect AI coding workflow, but there are a few principles that make a lot of sense to me.\n\nIf the requirement is fuzzy in your own head, the model is going to fill in the blanks.\n\nSometimes it will guess correctly.\n\nSometimes it absolutely will not.\n\nFigure out the boundaries first.\n\nYou do not need to memorize every line.\n\nBut if an agent gives you a giant diff and you cannot explain what it changed, why it changed it, and how the important pieces work, that is probably not ready to merge.\n\n“Tests passed” is not enough.\n\nAuthentication.\n\nAuthorization.\n\nPayments.\n\nDatabase mutations.\n\nEncryption.\n\nPermission systems.\n\nAnything where a mistake could expose data or seriously break something deserves much more careful review.\n\nThose are not great places for the old:\n\n“Looks good from here.”\n\nSometimes one agent working on one clearly defined problem is better than four agents generating four separate review queues.\n\nEvery additional task has a context cost.\n\nEventually you become the bottleneck.\n\nIf an agent writes something in four minutes and you spend forty minutes verifying it, the task did not take four minutes.\n\nIt took forty-four.\n\nThat does not make AI useless.\n\nIt just means we should stop measuring productivity by generation speed alone.\n\nDo not only ask for code.\n\nAsk why it chose that approach.\n\nAsk what alternatives it considered.\n\nAsk what assumptions it made.\n\nAsk where the implementation might fail.\n\nAsk what part it is least confident about.\n\nUsing AI as something you interrogate is very different from using it as a code vending machine.\n\nI am very pro-AI coding tools, obviously.\n\nBut I also think there is value in occasionally turning them off and actually building something yourself.\n\nYou need enough hands-on understanding to recognize when generated code is bullshit.\n\nThat skill gets harder to maintain if you never exercise it.\n\nSoftware development is basically a long history of building abstractions on top of other abstractions.\n\nAssembly languages gave way to higher-level languages.\n\nInfrastructure became cloud services.\n\nLibraries replaced mountains of custom implementation.\n\nFrameworks automated huge parts of application development.\n\nEvery time this happens, somebody announces that programmers are about to become obsolete.\n\nInstead, the job changes.\n\nDevelopers stop spending as much time on one layer and start working at another.\n\nAI looks like another massive abstraction layer.\n\nThe ability to manually type code is becoming less important than it used to be.\n\nBut knowing what code should exist, how systems fit together, what tradeoffs matter, and whether the implementation is actually correct becomes more important.\n\nThat is not less engineering.\n\nIt is engineering happening at a different level.\n\nI started noticing that when I reduced the number of parallel AI sessions I was running, I actually felt more in control of my projects.\n\nI spent more time defining what I wanted before generating it.\n\nI read more of the code afterward.\n\nI documented decisions.\n\nI caught more questionable assumptions.\n\nDid that sometimes make the first thirty minutes of a task slower?\n\nYep.\n\nBut the software usually came out better.\n\nAnd more importantly, I actually understood what I had built.\n\nAI gives developers an absurd amount of leverage.\n\nI love that.\n\nBut leverage works in both directions.\n\nIt can help you build faster, or it can help you create an enormous pile of code you barely understand at record speed.\n\nThere will always be another terminal you can open.\n\nAnother agent you can launch.\n\nAnother task you can parallelize.\n\nThe harder skill might be recognizing when you already have enough code being generated and the most productive thing you can do is stop generating for a minute and actually think.", "url": "https://wpnews.pro/news/managing-the-hidden-overhead-of-ai-software-engineering", "canonical_source": "https://dev.to/sizzlebop/managing-the-hidden-overhead-of-ai-software-engineering-179a", "published_at": "2026-09-22 04:43:03+00:00", "updated_at": "2026-09-22 04:52:32.285500+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-safety"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/managing-the-hidden-overhead-of-ai-software-engineering", "markdown": "https://wpnews.pro/news/managing-the-hidden-overhead-of-ai-software-engineering.md", "text": "https://wpnews.pro/news/managing-the-hidden-overhead-of-ai-software-engineering.txt", "jsonld": "https://wpnews.pro/news/managing-the-hidden-overhead-of-ai-software-engineering.jsonld"}}