{"slug": "ai-can-write-code-faster-than-i-can-trust-it", "title": "AI Can Write Code Faster Than I Can Trust It", "summary": "A developer describes how repeatedly running AI code reviews on a small C# utility that deletes bin and obj folders caused the project to grow with each new model generation, as successive models found fresh critical issues and fixes introduced new complexity. The developer notes that while agents can produce implementations in minutes, the natural mental model formed by writing code manually is lost, leaving them unable to make substantial manual changes without relearning the repository.", "body_md": "A couple of years ago, I decided to build a simple application for cleaning up unnecessary folders in C# projects.\n\nAs every programmer is apparently required to write their own logger, DI container, and ORM at least once, I decided to write my own utility.\n\nIt did one fairly simple thing: found temporary bin and obj directories in .NET projects and deleted them.\n\nAI wasn’t quite the cool kid yet, so eventually I abandoned the WinForms application. Mostly because I couldn’t be bothered to figure out how to turn it into a proper Visual Studio extension.\n\nThen Codex arrived.\n\nOr, more accurately, I started using it seriously.\n\nI handed it the repository and asked it to turn the application into a proper extension.\n\nGPT-5.2 was still a bit green and didn’t quite get there.\n\nNot that it failed completely. It produced something. Code appeared.\n\nBut I couldn’t turn what it produced into a solid working solution, so I abandoned the idea again.\n\nSome time later, GPT-5.4 came out. After some ritual troubleshooting, I finally managed to port the application.\n\nThe actual task, meanwhile, had barely changed.\n\nIt still deleted bin and obj.\n\nFrom that point on, I started using the same prompt — remember prompt engineering? Very 2025 — and the same instruction with every new model:\n\nDo a code review of the project.\n\nEvery new model, at the same effort level, found a fresh list of problems.\n\nAnd not just cosmetic ones.\n\nAnother P0.\n\nP1s and P2s were never far behind.\n\nAfter each review, I asked the model to fix everything.\n\nThe fix would turn into hundreds of lines of changed and newly added code.\n\nThe project became “better.”\n\nThen the next model came out.\n\nAnd found critical problems again.\n\nAnd so the cycle continued.\n\nI can think of several explanations for this:\n\nThe original code genuinely had some code smells, and several generations of models have simply been finding more and more problems in it. I don’t write bugs, obviously.\n\nNew models really are getting so much better at code review that they see things previous models simply missed. Questionable, but fine.\n\nSome of the new problems are introduced by the previous fixes.\n\nModels are simply getting more inventive at finding the next P0 in places where nobody saw one yesterday.\n\nAnd if that is the case, the problem is no longer just the code.\n\nIt is also the process.\n\nIf you ask an AI to perform a review, it is almost required to find something worth fixing.\n\nPreferably something “critical.”\n\nThere is also no obvious stopping condition for this loop:\n\n*review → fix → review → fix*\n\nAt what point is the project good enough?\n\nWhen does the next fix add less value than the complexity it introduces?\n\nThe funniest part is that the actual task has not changed this entire time.\n\nThe program still just deletes bin and obj.\n\nThe project, however, gets larger after every new review.\n\nBy now, this small project has grown noticeably.\n\nThere is much more code, even though the actual task is still the same.\n\nIt still deletes temporary folders from C# projects.\n\nAnd the issue is not just the number of lines.\n\nThe issue is me.\n\nI still roughly know how the project works.\n\nI know which patterns different classes follow. I roughly know where things live.\n\nBut if I had to make a substantial change manually, I would probably need to learn large parts of the repository almost from scratch.\n\nIn the past, a significant part of my mental model of a project formed naturally while I was writing it.\n\nWhen you write a class yourself, you usually remember why it exists.\n\nYou remember why you implemented it that way.\n\nYou remember the alternatives you tried and discarded.\n\nYou remember where you made a compromise, and what other code is quietly holding that workaround together.\n\nWith an agent, that connection breaks.\n\nIt can produce a finished implementation in minutes.\n\nThe code already exists.\n\nMy understanding of that code does not.\n\nAnd if AI really does remove the constraint on implementation speed, then in my own tiny project I have run into what is increasingly called the verification bottleneck:\n\nThe agent can produce code faster than I can verify it well enough to justify accepting it.\n\nWhich raises another question:\n\nDo I even need to understand all of it?\n\nWe never understood every line of our systems before AI either.\n\nI don’t know the internal implementation of the entire .NET runtime.\n\nI don’t read the source code of every NuGet dependency.\n\nI don’t go line by line through everything another developer writes.\n\nWe constantly work through abstractions, contracts, tests, and trust in code written by other people.\n\nSo what changes with AI?\n\nThis is where it gets more complicated.\n\nWith code written by another developer, I can at least try to recover the intent.\n\nI can ask why they chose that particular solution, what alternatives they considered, and where they deliberately accepted a trade-off.\n\nMore importantly, I can usually try to understand their line of reasoning.\n\nWe are both human.\n\nWe have roughly similar constraints, ways of reasoning, and professional experience.\n\nEven when I disagree with a decision, I can often reconstruct why another developer arrived at it.\n\nWith an agent, it is different.\n\nIts internal process is fundamentally not a human line of thought that I can reconstruct from my own experience.\n\nI can analyze the result, the prompt, the context, and the changes it made.\n\nBut I cannot treat them exactly like another developer’s decision and simply “understand what they were thinking.”\n\nThat context is also much easier to lose.\n\nThe diff stays in the repository.\n\nThe reasons why that diff ended up looking exactly the way it does may remain somewhere in the history of an agent session.\n\nOr disappear with it.\n\nOn the other hand, if I try to understand every line of generated code, I lose a significant part of the productivity gain AI gives me.\n\nWhile I carefully read several hundred lines of the latest diff, someone else will already have their agent building the next feature.\n\nAnd then another one.\n\nIn the job market, they will look much faster and more productive.\n\nBut if I stop understanding generated code altogether, sooner or later I will end up owning a system that I am formally responsible for but do not actually know.\n\nSo the question of whether a developer needs to understand every line has probably become rhetorical.\n\nAI can already produce code faster than I can properly read it.\n\nSo how well does a developer need to understand a repository to still genuinely own it?\n\nIs understanding the architecture enough?\n\nThe main contracts?\n\nThe invariants?\n\nThe failure modes?\n\nOr will there come a point when saying, “I built this feature,” means roughly the same thing as saying, “I used a library whose internals I have never read”?\n\nIn the past, authorship of code and understanding of code tended to develop together.\n\nNow they are starting to separate.\n\nYou can get the code almost immediately.\n\nTrust still has to be built.\n\nAnd the developer is still responsible for the code the agent generates.\n\nSo perhaps the real constraint on agentic development will not be how quickly AI can write code.\n\nIt will be how quickly a human can determine what, exactly, they have enough reason to trust in that code.\n\nNew models will keep coming.\n\nThey will keep getting smarter.\n\nAnd I am quite sure the next generation of AI will once again find a critical P0 in my little project that still just deletes bin and obj.", "url": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-trust-it", "canonical_source": "https://dev.to/dmitry-truhanovich/ai-can-write-code-faster-than-i-can-trust-it-1olf", "published_at": "2026-09-16 12:00:00+00:00", "updated_at": "2026-09-16 12:12:40.729530+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models", "ai-products"], "entities": ["Codex", "GPT-5.2", "GPT-5.4", "C#", ".NET", "Visual Studio", "WinForms"], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-trust-it", "markdown": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-trust-it.md", "text": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-trust-it.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-code-faster-than-i-can-trust-it.jsonld"}}