The price of speed, or programming yesterday and today
Things used to be different
I remember the days when all you needed to start programming was “some” computer, “some” text editor and a bit of free time. There were no smart assistants, AI agents or language models that could generate half an application from a few sentences.
What we had instead was code. Documentation. Trial and error. And a lot of patience.
My journey started with plain Notepad. Then came Notepad++, and its syntax highlighting and file type detection were a real leap in quality.
Next came Eclipse. The pain of installing Java and picking the right plugins was quickly rewarded with a working debugger and with SimpleTest, and later PHPUnit, tests you could run straight from the IDE. Not everything worked right away. Sometimes just setting up the environment took half a day. But that was exactly how you started to understand things and feel like a professional.
Over time, more and more advanced IDEs appeared. IntelliJ IDEA, PhpStorm, Visual Studio Code. Autocompletion, refactoring, integration with version control, tests and debuggers. More and more things worked almost out of the box.
What did most of these tools have in common?
You could use them for free. Not all of them, of course, and not always with every feature, but it was doable, and not having a credit card was no barrier to entry at all.
You bought a computer once
The first computer I programmed on had a Pentium 166 MMX and 8 MB of RAM. It was a beast. Then came new generations of processors, more and more RAM, faster drives and bigger monitors. Eventually, computers with Core i5 processors and later generations of ever faster chips.
The requirements grew too. A simple editor gave way to a full IDE. A single application turned into several services, a database, a cache, queues and Docker containers.
But the financial model stayed much the same. You bought a computer once. You used it for a few years. If the hardware got too slow, you upgraded it or bought a new one. It was a one-off expense. You didn’t have to wonder every month whether to pay for yet another subscription just to keep working at the same pace.
Today a computer is basically a terminal, and the cloud is the natural place to run, and even test, things. We build, test and run code on servers, and more and more often the code itself is written by models running somewhere in a data center. Computing power that you once paid for once, when you bought a computer, is now rented by the hour or on a monthly plan.
Time was the biggest investment
Of course, programming was never completely free. The computer cost money, and so did electricity and the internet, but the most important investment was time. Hours spent reading documentation, analysing errors, experimenting and trying to understand why something didn’t work.
Sometimes solving a problem took a whole evening, but that evening wasn’t wasted. Along the way you learned how a library, a language, a framework or an operating system worked, so the next time you solved a similar problem faster. After a few years you had a pretty solid mental model of how software works, and that knowledge stayed with you.
All it took was motivation, a computer and a bit of free time to keep investing in yourself, with practically no extra financial cost.
No card, no go
Let’s jump to the present.
We have tools we could only dream of a dozen or so years ago. Language models can write code, generate tests, analyse errors, prepare documentation and even carry out multi-step tasks on their own. We can set up a whole agent system on a virtual server in the cloud and manage it all from a tablet.
In theory, it has never been easier to start programming. But is that really so?
Today a completely different cost shows up more and more often, a subscription for productivity.
One model for everyday coding. Another for harder problems. An AI-integrated editor. An agent running in the terminal. Yet another automation tool.
Not all of them are paid, and not everyone needs them. But the more intensively you use AI, the sooner you start to notice the limits, the differences in quality between models and the need to move to more expensive plans.
You used to be limited mainly by your computer’s performance and your own skills.
Today you can have a great computer and still wonder whether your token limit will be enough to finish the task.
What’s more, the payments don’t necessarily end with one subscription. Tools evolve, new models appear, new integrations and more promises of higher productivity.
One server is no longer enough, so you get another one, and a sub for that second model. Oh, and you hit the limit on GitHub, and actually you also have to pay for email and the office suite, because the plan came with that nice big drive, which is already half full of photos and videos from trips. You never have time to clean them up anyway, and the last time you looked at them was about 18 months ago.
Instead of a one-off hardware cost, we have a growing number of recurring costs.
We do more. But do we understand more?
This is probably the most interesting change.
Thanks to AI, we can get much more done in the same amount of time.
Code gets written faster. Tests generate themselves. A refactoring that used to take a few hours can be done in fifteen minutes or so.
The problem is that the speed of writing code is not the same as the speed of gaining knowledge.
When you implemented a solution yourself, you had to understand how it worked, at least to some extent. Today you can accept a few hundred lines of code you haven’t even skimmed.
And the application will work.
At least for a while.
Speed isn’t that simple either. In a METR study from July 2025 [1], 16 experienced open-source developers worked 19% slower with AI, yet they were convinced AI had sped them up by 20%. METR itself now says these results are out of date, and in a follow-up study from February 2026 [2] it believes AI most likely does speed up work now. Still, the gap between how fast we think we work and how fast we actually work is worth remembering.
Then there is the problem of knowledge retention. If you complete several times more tasks every day but delegate most of the details to AI, how much of it actually stays in your head?
Anthropic tested this [3] on 52 programmers, mostly juniors, who had to write two features using a Python library they didn’t know. Afterwards, the group using AI scored 50% on average in a knowledge test, and the group coding by hand scored 67%. On top of that, the AI group finished only about two minutes faster, and that difference wasn’t even statistically significant.
That’s interesting, because you can ask yourself the same question, whether a month later you can explain the architecture of a solution you approved yourself, or change something without using a model. I think that may be a problem. More and more often you are just the operator of a process whose details you don’t understand. You can already see it today, and it will only get worse.
I’m not saying every programmer should write every line of code by hand. I use automation myself and see huge value in it. But I wonder whether we are starting to confuse productivity with competence.
Tons of documentation nobody reads
There is one more paradox.
AI tools were supposed to reduce the work of writing and reading documentation. Meanwhile, we are starting to produce huge amounts of extra text.
Instruction files for agents, architecture descriptions, design rules, contexts, implementation plans, session summaries, documents defining how models should behave.
AGENTS.md, CLAUDE.md and dozens of other files.
More and more documentation written by AI, intended mainly to be consumed by other AI. Some of it is genuinely useful. The problem starts when we document everything without thinking, or agents start recording too much information. Keeping all of it consistent will soon account for a good share of all the tokens we burn.
On top of that, there are no settled ways of working yet.
Some people use agents in the IDE, others in the terminal. Some build elaborate systems of rules and agent skills, others prefer simple prompts. Every month there is another tool that is supposed to change how software gets made. Building a truly effective work environment is not nearly as easy as the big companies’ promotional materials make it sound. And that means that without solid technical foundations, it’s easy to mistake a complicated environment for a good one.
One bad day and the project goes off course
In classic programming, being tired usually meant working more slowly.
When working with AI agents, being tired doesn’t have to slow you down at all, but it can mean something much worse.
Imagine a day when you are distracted, tired or simply don’t feel like analysing yet another implementation.
The agent proposes a solution. It looks reasonable. You accept it.
Then another one. And the next.
Everything passes the tests. The code compiles. The feature seems to work.
Except that somewhere along the way an unnecessary abstraction, a wrong architectural decision or a dependency nobody consciously planned has crept in. Suddenly the agent is protecting an ordinary form on a website in case a single user submits it 100 times a second. It adds handling for concurrent writes and more connections to Redis. In theory such a problem could happen, but let’s be honest, with a form it will practically never happen.
Because each task builds on the previous ones, this bulletproof code soon gets wrapped in several more layers. A few days later it turns out the project has gone in a completely different direction and is solving unrealistic problems, which is not quite what we intended, and a simple class has turned into an overcomplicated library handling cases that don’t exist.
AI can develop a good solution very quickly. But it can just as quickly overcomplicate it and wrap it in unnecessary code.
And that is exactly why the human role doesn’t disappear. Its nature changes.
We spend less and less time writing the code itself, and we should spend more and more time evaluating decisions, architecture and the consequences of the proposed solutions.
But where do you get the ability to judge them if you never learned to create them yourself?
Should a beginner programmer start with AI?
IT systems are very complex today. If you start “programming” by delegating everything to AI without understanding the basic concepts, you won’t be able to judge the solution the AI proposes, and the number of pieces it generates can quickly become overwhelming. Maybe that’s fine for a simple website, maybe even for a simple mobile app you build as a hobby, or for some demo. But will you take responsibility for it in production if you want to build a product for someone else?
You don’t have to ignore modern tools or make life artificially hard for yourself. The order matters. First it’s worth learning the basics, that is the language, data structures, debugging, testing, HTTP, databases, the basics of architecture and how applications work. Write a few things on your own, make mistakes and understand why one solution works and another doesn’t. Only then gradually hand repetitive tasks over to automation.
AI can be an excellent teacher along the way, because it can explain complex topics, point out mistakes and help you learn. It gets worse when it replaces the learning process itself. If you know the basics, AI expands what you can do. If you don’t, you can become completely dependent on its answers.
Yesterday we invested time. Today we buy speed.
I wouldn’t want to go back to the days when configuring a debugger could take half a day and finding a bug meant digging through dozens of pages of documentation. Today’s tools are objectively more powerful and let a single programmer build things that used to require a whole team.
But this change comes at a price, and it’s not just about subscriptions. Gaining knowledge used to be a natural by-product of building software, and today nobody guarantees it. You can build more, faster and cheaper per unit of work, while understanding less and less of what you are building.
That’s why I think what matters more than how fast you can generate code is the ability to judge what code should be written at all, and understanding the consequences of your own decisions. That still takes knowledge, and knowledge is not something you can simply get with a monthly subscription.
Sources