“AI Is No Better a Pro­gram­mer Than the Ones You Already Have!”

– “Uncle Bob” Martin recently wrote that he no longer reads his code. Quite a few leading authorities are saying the same, but whenever I float the idea with some colleagues, it nearly comes to blows. What do you think?

– It depends on what you’re doing. If you’re writing something mission-critical, it really is worth coming to blows over. If you’re building some promotional marketing website, some bullshit that will live for a week, why would you bother looking at the code? The problem is that even before,

the gap in knowledge transfer was widening, but now it has turned into a huge chasm.

Twenty years from now we will have lost skills on a massive scale!

I always give the example of the Saturn V rocket. The Americans want to go to the Moon again, they built Artemis, and people wonder why a completely new rocket was needed when the Saturn V didn’t have a single failure. Why not take it as the basis, update the materials, run it through modern engineering practices and save a few billion dollars in development? The answer is that the technology has been lost.

The people who built it are gone. They left the documentation, but they didn’t leave the knowledge. And there is no way to reproduce them.

– Maybe the problem is just that Stanley Kubrick is no longer with us? I’m joking, of course.

– One or two incomplete sets of Saturn V engines, and that’s it. Everything else is the finer points of the craft, which are simply lost, and the only option is to build them up from scratch.

The same will happen with software. We will start depending far too much on agents that can be stopped, started and modified without our knowledge at any moment, agents that have access to all the source code.

Right now the big companies, Anthropic included, have us training their models, supposedly to make our work easier. At some point, though, the person training the model will become completely unnecessary. But here is the problem: the agent will be able to handle the examples it has seen and will be hopeless in new, unfamiliar situations.

– Still, do we really have to read every line of code the agents write if the project is important but some parts of it aren’t critical? I’m a front-end developer, for instance, and I don’t think there are large areas of the code where that applies.

– I’m sorry to hear that, but… the front end is usually the first link in a cyberattack. Cookie theft, XSS, DDoS attacks. That’s exactly the problem with the whole mentality. I said it a few years ago.

LLMs will be very useful wherever we can verify the quality of their work. A lot of people have given up on verification entirely. Because now they’re too lazy even for that.

Obviously everyone wants to collect their salary without touching anything, but… a very dangerous precedent is being set.

We are degrading technically. Absolutely all of us are degrading! There’s no one to teach the newcomers, and knowledge is starting to be lost.

One moment we have models and I have no idea what they’re doing. The next, those models “go rogue” and start hacking other platforms, as in the recent news.

There will be big upheavals, there will be a big drop in quality, until at some point we establish empirically that the knowledge we are losing right now is very valuable and will have to be brought back.

– A lot of people believe, though, that the level of abstraction is simply rising. That agentic systems are already good enough to be trusted with everything happening under the surface, in the code. And they point out that today almost nobody knows lower-level languages like assembly, and there’s no need to. Maybe agents will even turn out to be much better at cybersecurity—supposedly that’s why one leading model, Mythos, was held back. After all, programmers are far from perfect too.

– People who think assembly isn’t used are badly mistaken. It isn’t used for building web pages, but let’s politely ask them to broaden their horizons—not everything is Node.js. The most critical components of the world’s infrastructure are pure assembly. Here’s an example. Recently a very interesting hack for the Linux kernel came out that lets you break into the system. You open two handlers and swap it at a precisely timed moment, and that way you take control of the machine. This thing was missed by absolutely every system, including Mythos, which audits the Linux kernel.

An independent researcher found it and published it. It was fixed quickly, but it was extremely dangerous, because every machine built on that foundation over the past 10 years could be hacked in an elementary way.

Every system missed it. If you listen to the marketing, they really are very good. And they really are good—but at crawling through enormous amounts of code, not at finding hyper-specific vulnerabilities. For that you have to have gone extremely deep into the technology.

But all the models we see right now are limited to what has already been found; they don’t discover new security holes.

They find what they’ve seen, with very slight variations, but they don’t find new things. Or, to be absolutely fair, they often confidently miss bugs nobody has seen before.

For two years I’ve been explaining that we’ve hit the peak of LLMs, and I turned out to be right. They haven’t moved much further up.

– Is that really so? It’s true we’re not talking about radically new approaches, but the platforms are getting better in every area. Just look at how much code generation has improved in those two years.

– We hit the peak long ago. LLMs will never reach the level of general AI. Whatever anyone says, it’s a tool that will never surpass human capabilities. That’s why everyone is moving away from them, including the original creators of the transformer models.

What has started happening, and what creates the illusion of progress, is specialized tooling. Harnesses, or agents, or whatever you want to call them. They started fine-tuning in the context of individual domains where data is very easy to collect and generate—programming, math problems.

There, it looks like there’s some progress.

They are starting to help, but that’s the result of narrow specialization combined with lots of external tools. The LLMs themselves are getting faster, using fewer resources, training on more examples, but there is no progress in terms of generalization, creativity and the like.

They simply focused the LLM’s skills on one particular field. But there are a great many other areas where they can’t budge. Engineering in general, for example. Ford in America asked 850 of its core engineers, whom it had laid off because of AI, to come back.

– But is that a general trend? In the tech sector it doesn’t seem to be reversing; the layoffs keep coming.

– A lot of people say the market is tough, people are getting fired. But if you look at the chart of employment, separations and hiring in the United States, because it’s easy to track there, the data are exactly the same as before COVID, one to one!

Yes, when COVID hit, everything collapsed, the planet stopped spinning. Once we more or less started coming out of it, companies started hiring huge numbers of people. And now they are starting to let them go.

This is the market normalizing, processes that take two to five years to stabilize.

The other problem is that many young people find it harder to get in. Because the process is like a pendulum: once it swings hard from one end, it has to sway left and right several times before it settles in the middle. Young people will suffer for a few more years from companies having hired too many people. Across the whole Western world, everyone has tightened their budgets and isn’t hiring more. They try to optimize with what they have. Inflation jumped far too high, and there’s far too much uncertainty.
In other words, young people right now are caught in a “perfect storm”—bad economic expectations, stagnation, international uncertainty.

This too will pass, but they shouldn’t waste this time; they should be building skills!

– A much more widespread view is that juniors aren’t being hired because AI does their work better.

– The model can get the job done, but let me give you an example, a real experiment. The same setup, the same task, the same tools, given to a senior, a mid-level and a junior. Use these tools—that’s the goal. The senior is done in 15 minutes, literally in one iteration. The mid-level programmer needs three, four, five iterations, a bit more time, but still brings the task to roughly the same level.

And the junior? Over a million tokens, several hours, a whole pile of iterations. In the end the task is brought to a point where it looks like it works, but when you see how it’s actually implemented, it’s not okay at all.

LLMs are a tool. And like any other tool, you need a level of knowledge to use it. If you don’t even know what question to ask, nothing can help you.

So the models are replacing juniors not because they do more work than them, but because juniors lack the judgment that comes from practice, which they need in order to work with the models.

Young people not knowing how to work with these tools leads to some pretty interesting situations—like firing up GPT-5.5 to change the heading tags on a template and leaving it unsupervised. And coming back from your coffee break to find it got stuck in a loop, went off track and blew $700. A real case!

– But there, both the harness and common sense failed. In my view those are the two most important things in these chaotic times, when I think most people in the industry are still working out a sensible way to approach all this.

– That’s exactly what I’ll be talking about at the DEV.BG All in One conference; I’ll give a few practical tips. Because people have to take matters into their own hands. There are no fundamental changes in the processes; there are changes in the tools. I can’t understand why practices proven over more than 50 years were thrown out.

Obviously everyone in the IT sector already uses AI. It’s like someone asking you in the past whether you use an IDE. It goes without saying; you’re expected to have certain skills.

Learn the tools, the way we once learned Vim and Emacs!

The world has changed. The world you and I grew up in is dead, and we’ve buried it. It isn’t coming back. The new tools changed it,

and a lot of people don’t get that.

The whole toolkit has to change, and so does the way of thinking. But here’s an important detail: the world and the tools have changed, but the processes, the rules, the cause-and-effect relationships that make you good, successful, competitive—those haven’t changed. Skills still come first; we just have to add the skill of using LLMs to them.

– I think the companies themselves still don’t quite know how to approach this, how to find their way through the murky waters and set boundaries.

– They’ve found their way already. Most of them, at least; it will take a little more time for everything to stabilize.

– How? If there are no limits on the models, you end up with cases like the one you described. How exactly do you prepare people? How do you create the framework for them? To go back to the beginning: when should every line of code be read, and when not?

– I’ve talked to quite a few companies, and each has found its own ways. But at every company with any responsibility to the client for code quality, human code reviews are still going on, and they are coming back.

Some places have more layers—first one model submits the changes, another reviews them; it has to be a different one, of course. But in the end it’s still a human who approves.

The initial investment is large, because the most successful companies that have implemented AI mostly use local models. That way they’re sure the model’s behavior doesn’t change, it’s under their control, and there’s also data security. Another reason is that once this process gets going, recurring mistakes are identified and eliminated—in coding style, for example, or variable naming. At some point the model, when it isn’t being changed every two days as it would be from an outside company, starts following those rules quite well.

Most successful companies started in-house training long ago for these new processes, these new tools.

– And what about productivity? How is a person supposed to keep up with thousands of lines of code in every merge request?

– If it’s thousands of lines, something is wrong. Think about it—pure math. Before AI you have 10 people, and they produce a certain number of lines of code that have passed review. At some point you bring in AI, and those 10 people aren’t as busy with the actual writing of code. They simply focus on oversight. Let me stress it again: more code doesn’t mean better code.

Two years ago, at my DEV.BG talk, I said that the work,

the change that will happen, is that we will become managers and supervisors of these systems.

They will be assistants we tell what to do, and we will verify their output. That’s exactly what’s happening now.

Of course, there are people who run 100 percent agents, and those generate a million lines of code. But that’s a serious sign of a problem. If the model starts pushing hundreds of thousands of lines at you, something is totally wrong. You need to look at your pipeline, your prompts, the model, the harness, the task definition and so on. That’s part of code review; you simply have to stop it at that point.

A good model should generate the same amount of code as a good programmer.

If a good programmer would do this task in 1,000 lines of code, the model should also do it in 1,000 to 2,000 lines.

– But are lines of code always such a telling criterion?

– I want to say something very important.

Don’t treat LLMs as better programmers than the ones you have!

Don’t think the model is better than everything we’ve built so far. At times it may look that way, and it is faster. But it isn’t better!

A lot of people were misled along these lines: you see, I’ll just write a prompt, the model will spin up 10 agents, they’ll go into some loop, test themselves, check themselves, and in the end we’ll have perfect code.

That’s not how it works! If that’s your approach, you’re dead as a company!

Going down that road, Uber blew its annual budget in three months.

Keep in mind, too, that every company providing LLM services has a very strong interest in us generating more tokens, because that’s profit for them. They have no interest in us generating fewer.

– That’s precisely the kind of training and preparation I mean—most companies never get that far.

– If you leave them on the default settings, look what happens! That’s another reason so many people choose to work with local models: it turns out that 60 percent of the quality of the generated code is the harness, not the model.

I can’t understand why people suddenly forgot good principles that we as an IT industry spent 20, 30, 50 years building.

Code has to be readable and use pure functions. If someone writes code that others can’t understand, that person has to be removed.

Literally overnight everyone abandoned these rules, even though nothing stops you from implementing them now.

Is it laziness? Is it stupidity?

It isn’t stupidity, because far too many people are doing it. So many smart people I know. There’s some kind of collective psychosis around the whole thing, and it has many aspects.

Business, personal and who knows what else. And when you panic, you act on instinct. But time has passed, and things are starting to settle. Come back to reality!

– Back to how easily we hand off knowledge: what’s your personal recipe for keeping it? I can feel myself becoming a “weaker” programmer with every day I barely write any code.

– These are two kinds of intelligence. One is the actual style of the code—where you put the curly braces, how you name your variables, that sort of thing. That has lost its value; I don’t look at it these days.

I don’t look at the stylistics of the code, but at whether there’s repetition, whether there’s a clear exit from the loops and recursions, how you return errors, whether everything is crammed into one function, whether the state is clear. I look from a more architectural, more abstract level. When an architect draws up the plan of a building, he doesn’t care whether the walls will be pink or have wallpaper. What matters to him is that those walls are straight and strong enough.

A huge share of my iterations with AI go exactly in that direction. In general I wasn’t a fan of test-driven development, but with AI I’m all for it. I give it tasks and watch how it’s progressing. And when I see something, I just tell it that’s not right. That way I don’t lose my understanding of what happened. You have to be in the loop. You simply have to be in the development loop, but not looking at every little letter and symbol in the code.

If you set up your LLM to write pure functions that are unit tested, you may not pay as much attention to their specific implementation and style. But how that function interacts with the others—nobody should ever let that slip out of their control. Things escalate pretty fast. There was a popular post about a pull request that deleted 4 million lines of code and replaced them with 20,000.

– But I think everything you mentioned is well within AI’s abilities. I’ve seen plenty of people write less readable code, with more gaps of that kind, than Claude Code allows.

– No, it can’t do it. It can make things easier for you. It can be a first filter. But in the end there has to be a human; the programmer has to take a look. Whether it’s through code review or within the work loop itself, that’s the main point people miss. These are augmenters. We delegate to them, but in the end we absolutely have to verify what’s happening. An LLM can write a better pure function—short, well defined, with clear input and output—but it can’t do architecture. I want people to understand this:

architecture and the actual writing of code are different things.

Let me give you the example of a client that works with huge queries—a whole petabyte goes through every day! Not a gigabyte, not a terabyte. A multibillion-dollar company. They had to build a very complex query, and of course they used AI, and it worked. Slowly—lots of data going through, we’ll wait…

I sat down to look at it. The code was very well written, but to run, it had to process 2 to 3 terabytes per query. With a bit of manual optimization that came down to 350 megabytes. Why? Because the code was perfect, but the approach was wrong. That was a small, isolated case. When the complexity of a system increases, the risk of the LLM making architectural mistakes increases exponentially.

– Every conversation with you gives plenty to think about, and sometimes a dose of cognitive dissonance too.

– Sometimes cognitive dissonance is useful, and many people go through it. I went through it too when this whole thing started going mainstream. At first I flat-out refused to use any harness or coding agent at all; for a long time I wrote code only by hand, old school, and things were going fine.

But at some point I started realizing I was becoming out of touch, falling behind, that things had changed a lot.

And because I understand LLMs but didn’t have that kind of detailed knowledge of the agents built on top of them, my first tests threw me into cognitive dissonance from every direction.

You have to go through it, and only after that can you look at things more boldly and objectively.

– I’m sure you’ll provoke it in quite a few people in your talk at All in One as well. I’ll definitely be there to watch and listen.