Hello, my AI friends...
If you did not read Part I and Part 2, here they are first!
So after the money talk, the tool talk, and the "I only wrote 500 lines myself" confession, there is still one question left:
Can you really trust an AI agent in day-to-day development?
The short answer is: No. And yes.
No, you must not trust the agent the way you trust a compiler. And yes, you can trust it the way you trust a junior developer who works incredibly fast, never gets tired, and is brave enough to touch every file in your repository.
That is exactly the point: the agent is not magic. It is not a senior architect. It is not a legal department. It is not a compiler. It is not your final QA. But it is a surprisingly productive team member if you build the right rails around it.
For me, the real productivity boost did not come from simply saying "implement feature XY". The real boost started when I forced the agent into a workflow that looks more like a disciplined development process.
That means:
- clear coding rules
- small, testable tasks
- build scripts it must use
- a fixed format for commit messages
- a habit of writing tests before touching bug fixes
- and a strong preference for asking questions before changing too much
If you let the agent work without these rails, it will still produce output. Sometimes impressive output. But sometimes it will "improve" things that were not broken, rewrite working code because it found a prettier abstraction, or confidently explain nonsense in a very professional tone.
That part is new for many developers: you are no longer mainly writing code, you are designing the behavior of your digital coworker.
I spend a lot of time defining process now. (And because of that, I had an idea, but more about that in the next blog post.)
Which compiler must be used?
Which config?
Are comments wanted or not?
Must interfaces live in separate units?
Must a bug fix come with a test?
May it edit old ANSI source files directly?
Should it stop and ask before changing public APIs?
All these rules sound boring. But boring rules are exactly what make AI coding useful in production.
Without rules, the agent is creative. With rules, it becomes productive.
And there is another thing I had to learn: context is everything.
If I start a fresh session and just throw a task at the tool, the result may be okay. But if the agent already knows the repository, the coding style, the current branch, the open bug, and the surrounding units, the quality jumps massively.
So a large part of my work now is not coding itself, but feeding the right context and cutting work into chunks that the model can solve safely.
This also changes debugging.
Sometimes I no longer start with the debugger. I start with a question like:
Find the most likely reason why this value can become nil although the constructor should have initialized it. Check all call sites and the lifetime management around the interface references.
And very often the answer is not the final truth, but it gives me three strong places to inspect immediately. That alone saves a lot of time.
Of course, there are still complete failures.
Sometimes the agent overlooks the obvious.
Sometimes it introduces a regression in a totally different area.
Sometimes it uses modern Delphi syntax where Delphi 2007 would simply laugh and die.
Sometimes it writes a beautiful helper class that nobody asked for.
And sometimes it keeps pushing forward, although it should have stopped and asked a question twenty minutes earlier.
That is why reviews matter more, not less.
In the old world, I reviewed code mostly because humans are inconsistent. In the AI world, I review code because the agent is fast enough to create a lot of very convincing mistakes in a very short time.
So my confidence does not come from "AI is so smart." It comes from this combination:
- strict rules
- repeatable build steps
- automatic tests
- small commits
- and fast review loops
If all of that is in place, then working with an AI agent feels less like gambling and more like scaling.
And there is something else that changed for me: documentation.
I used to postpone documentation because it always felt like the part of the work that steals time from the "real" work. Now I often let the agent draft it immediately while the implementation is still fresh. README files, release notes, migration hints, installation steps, and even ticket summaries. Suddenly, all the annoying but necessary text around the code is no longer such a burden.
That alone removes a lot of friction from finishing projects properly.
So, where is this heading?
I think the next big step is not that AI writes even more code. The next big step is that it will understand workflows better: tickets, logs, build pipelines, documentation, dependencies, and all the little conventions that make up real software engineering.
We are moving from "generate me a function" to "help me run software development as a system."
And that is why I do not see AI agents as a gimmick anymore.
They are already becoming infrastructure.
Not perfect infrastructure. Not cheap infrastructure. Not trustworthy without supervision.
But infrastructure nevertheless.
So yes, I still read a lot. I still review a lot. I still stop the agent when it goes in the wrong direction. But I also get more done, across more projects, with less context switching pain than ever before.
That trade is worth a lot.
Maybe you are not using AI agents yet. Maybe you are worried that AI might cost you your job in the near future. But of one thing I am absolutely sure: if you do not engage with this topic today, you will be sidelined within the next three years at the latest.
Stay tuned—and have fun with AI.
