Why do you use AI? That is the question I am currently asked most often.
And the next statement that usually follows right after that question is: I would not even know what to use AI for.
The answer “for everything” is obviously too broad, even though it is true. But let me break it down in more detail. The answer falls into three areas:
1. Daily work: reading and processing Jira tickets, answering emails, and writing letters.
2. Project maintenance: programming new features, fixing bugs, or improving existing parts of the software.
3. New projects: either a helpful tool or a completely new project.
Of course, I can read my emails by hand, and perhaps my spam filter is good enough. But how do I separate customer bug reports from the hundreds of other emails that land in my inbox every day?
But first, let me look at the industry from this perspective.
I assume that you have been programming for quite some time and have managed perfectly well without AI until now. So why should you bother with AI?
The industry and the role of a software developer are changing. And I am not talking about new projects being written in FMX instead of VCL so they become cross-platform. I am also not talking about finally migrating your old database routines to FireDAC.
I am talking about the biggest shift since the move from DOS to Windows. This time, however, it is not a technical software shift. It is a shift in what people expect from you.
I hardly believe that anyone will still program without AI in the future. And even if you do, the company you apply to will expect you to know how to use AI.
I can already hear the comments: “I am my own boss!”
Yes, but the company you have been competing with for years — sure, their software was never as good as yours — is now hiring developers whose entire day consists of sending clever prompts to Codex, Claude, and others. And they will use those tools to turn the software that used to lag behind yours into a product that is superior to yours in every respect.
One or two years ago, that would have been unthinkable. It would have required a lot of money and many developers. Today, it costs only a fraction in token costs.
And that is exactly where the problem lies.
As developers, we are no longer competing only with other developers. If we write code by hand today or search for a bug manually, it simply takes much longer than having an AI generate 1,000 lines of code and a new unit in one go — naturally including the corresponding unit tests for which we supposedly never had time.
We no longer have to spend three hours googling a Windows API call or searching through three different forums. We describe the problem, maybe add a hint about where it should be used, press Return, answer two more questions, and go to lunch.
When we come back, the call has been implemented, the unit test is green, the changelog has been written, and the update has been committed. And this time with a truly detailed explanation — not just the usual “API call done.”
Last year, people said: AI replaces a junior programmer, but costs per year what a junior costs per month.
I think that statement is already outdated — just like last year’s model versions.
But what about code reviews or bug fixes? Should I really review the code written by Claude and others? Even if the unit tests are green?
Everyone has to answer that question for themselves. If the new method controls a nuclear power plant or autonomous driving, then perhaps yes.
Personally, I tend to look more closely at the unit tests to make sure the AI did not simply write the test in such a way that it turns green. I think this is where the wheat is separated from the chaff. Only if the unit tests are good can I trust the code. TDD — test-driven development — is practically mandatory.
And then we arrive at an important point.
The unit tests are green and verified. The commit also looks good. But what if I do not actually understand the code?
Maybe I ask the AI to explain the code to me or add comments. Or maybe I do not care.
But what happens when the AI services are currently unavailable? What if the code contains a bug that the agent does not find?
When Claude was unavailable for several hours, I felt a disturbance in the Force, even though I was not at my PC. Thousands of developers were staring at a screen with an error message and suddenly no longer knew what to do.
So it is not all that simple, and we need to be aware of where we are heading.
I call it the Titanic problem.
Sure, this route is faster. But what happens if an iceberg suddenly appears?
What happens when an entire industry becomes addicted and then the drugs — AI — simply become more and more expensive?
Who will still be able to afford the tokens if the costs multiply?
A good current example — current meaning for about four weeks — is the new Opus 4.7 model. The token prices may have stayed the same, but the model needs 1.3 times more tokens per query than before.
And, of course, the thinking tokens, which conveniently are not shown in the output, have also multiplied by several factors.
The price has not increased yet. But with the same budget, I do not even get half as far as before.
So not everything that glitters is gold.
But hey, it is fun. And you can finally have the things programmed that you never had time for — or simply did not know how to build.
Happy Vibe Coding.
