A couple of years ago, I decided to build a simple application for cleaning up unnecessary folders in C# projects.
As every programmer is apparently required to write their own logger, DI container, and ORM at least once, I decided to write my own utility.
It did one fairly simple thing: found temporary bin and obj directories in .NET projects and deleted them.
AI 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.
Then Codex arrived.
Or, more accurately, I started using it seriously.
I handed it the repository and asked it to turn the application into a proper extension.
GPT-5.2 was still a bit green and didn’t quite get there.
Not that it failed completely. It produced something. Code appeared.
But I couldn’t turn what it produced into a solid working solution, so I abandoned the idea again.
Some time later, GPT-5.4 came out. After some ritual troubleshooting, I finally managed to port the application.
The actual task, meanwhile, had barely changed.
It still deleted bin and obj.
From that point on, I started using the same prompt — remember prompt engineering? Very 2025 — and the same instruction with every new model: Do a code review of the project.
Every new model, at the same effort level, found a fresh list of problems.
And not just cosmetic ones.
Another P0.
P1s and P2s were never far behind.
After each review, I asked the model to fix everything.
The fix would turn into hundreds of lines of changed and newly added code.
The project became “better.”
Then the next model came out.
And found critical problems again.
And so the cycle continued.
I can think of several explanations for this:
The 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.
New models really are getting so much better at code review that they see things previous models simply missed. Questionable, but fine. Some of the new problems are introduced by the previous fixes.
Models are simply getting more inventive at finding the next P0 in places where nobody saw one yesterday.
And if that is the case, the problem is no longer just the code.
It is also the process.
If you ask an AI to perform a review, it is almost required to find something worth fixing. Preferably something “critical.”
There is also no obvious stopping condition for this loop:
review → fix → review → fix
At what point is the project good enough?
When does the next fix add less value than the complexity it introduces?
The funniest part is that the actual task has not changed this entire time.
The program still just deletes bin and obj.
The project, however, gets larger after every new review.
By now, this small project has grown noticeably.
There is much more code, even though the actual task is still the same.
It still deletes temporary folders from C# projects.
And the issue is not just the number of lines.
The issue is me.
I still roughly know how the project works.
I know which patterns different classes follow. I roughly know where things live.
But if I had to make a substantial change manually, I would probably need to learn large parts of the repository almost from scratch.
In the past, a significant part of my mental model of a project formed naturally while I was writing it.
When you write a class yourself, you usually remember why it exists.
You remember why you implemented it that way.
You remember the alternatives you tried and discarded.
You remember where you made a compromise, and what other code is quietly holding that workaround together.
With an agent, that connection breaks.
It can produce a finished implementation in minutes.
The code already exists.
My understanding of that code does not.
And 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:
The agent can produce code faster than I can verify it well enough to justify accepting it.
Which raises another question:
Do I even need to understand all of it?
We never understood every line of our systems before AI either.
I don’t know the internal implementation of the entire .NET runtime.
I don’t read the source code of every NuGet dependency.
I don’t go line by line through everything another developer writes.
We constantly work through abstractions, contracts, tests, and trust in code written by other people.
So what changes with AI?
This is where it gets more complicated.
With code written by another developer, I can at least try to recover the intent.
I can ask why they chose that particular solution, what alternatives they considered, and where they deliberately accepted a trade-off.
More importantly, I can usually try to understand their line of reasoning.
We are both human.
We have roughly similar constraints, ways of reasoning, and professional experience.
Even when I disagree with a decision, I can often reconstruct why another developer arrived at it.
With an agent, it is different.
Its internal process is fundamentally not a human line of thought that I can reconstruct from my own experience.
I can analyze the result, the prompt, the context, and the changes it made.
But I cannot treat them exactly like another developer’s decision and simply “understand what they were thinking.”
That context is also much easier to lose.
The diff stays in the repository.
The reasons why that diff ended up looking exactly the way it does may remain somewhere in the history of an agent session.
Or disappear with it.
On 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.
While I carefully read several hundred lines of the latest diff, someone else will already have their agent building the next feature. And then another one.
In the job market, they will look much faster and more productive.
But 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.
So the question of whether a developer needs to understand every line has probably become rhetorical.
AI can already produce code faster than I can properly read it.
So how well does a developer need to understand a repository to still genuinely own it?
Is understanding the architecture enough?
The main contracts?
The invariants?
The failure modes?
Or 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”?
In the past, authorship of code and understanding of code tended to develop together.
Now they are starting to separate.
You can get the code almost immediately.
Trust still has to be built.
And the developer is still responsible for the code the agent generates.
So perhaps the real constraint on agentic development will not be how quickly AI can write code.
It will be how quickly a human can determine what, exactly, they have enough reason to trust in that code.
New models will keep coming. They will keep getting smarter.
And 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.