Quo vadis, engineer?

Never have so many people built software they do not understand

I know how that sentence sounds. Like the opening of a lecture by an older gentleman about to tell the young that things used to be better. I promise this is not that - I use these tools every day and I genuinely like them. Which is exactly why I believe that someone who has spent more than twenty years in this industry should say out loud a few things that are more comfortable to leave unsaid.

Let us start with scale, because scale changes everything. When Andrej Karpathy wrote about vibe coding in February 2025 - you give in to the vibes, accept everything the model proposes, and forget the code even exists - it read like a description of a weekend toy, and that is how it was meant. Less than a year and a half later, Google states that artificial intelligence already generates roughly three quarters of new code at the company, with human review at the end (Business Insider, April 2026). In the autumn of 2024 it was one quarter. A curve like that does not know the word “experiment”.

And the same thing is happening one floor down, outside IT departments. Someone in procurement assembles a supplier analysis dashboard. Someone in finance glues together a bank integration over the weekend. Everything works, everyone is happy. Meanwhile the questions of who will maintain it, who will secure it and who will answer for it hang in the air, waiting for their moment. That moment usually arrives at the least convenient time.

Which brings us to you. If anyone can now assemble a working system, what do we still need a person for who spent years learning how systems are really built?

Maybe you genuinely do not need an engineer

I will put it more honestly than a man running an engineering company probably should: for many things, the engineer has genuinely stopped being necessary. And that is a good thing.

For a prototype? Not needed. For an internal tool used by ten people? Usually not either. For testing an idea before anyone commits budget to it? Here an engineer would be a waste - let the idea first prove it deserves their time. This is a real change for the better, and pretending it is not happening embarrasses our industry more than the worst vibe coding.

The engineer becomes necessary at exactly the moment a system starts to matter. When real money, real personal data and real production flow through it. When it also has to work on the second of January at three in the morning, after a network outage, with a duplicated record, with an accountant waiting to close the month. The line does not run between those who can code and those who cannot. It runs between “I put together something that works” and “I understand why it works and I know when it will stop”.

The speed illusion

Now a story that belongs in textbooks - and not because it makes AI look bad.

In July 2025 the research organisation METR published the results of a controlled experiment. Experienced open source developers worked on tasks in their own, well-known projects, once with AI tools and once without. Before starting, they estimated AI would speed them up by a quarter. Afterwards, they were convinced it had sped them up by a fifth. The measurement showed their tasks took 19 percent longer with AI.

The sequel is even more interesting. In February 2026 METR announced that the next round of the study pointed to a speed-up, but that it could not treat the results as reliable - among other reasons because it was getting harder and harder to find developers willing to work without AI, despite being paid to take part. In a single year the tools had improved and the participants had grown so attached to them that the experiment stopped holding together. The researchers are redesigning the method from scratch.

What follows from this? Not that AI does not work. Something more important follows: even people who measure these things for a living struggle to pin down the truth about our speed. And in everyday work we judge it purely by feel. Working with a model produces a wonderful sense of flow - things happen, the screen fills up, tasks get closed. Except that this feeling, as METR showed, can drift forty percentage points away from reality. If we are that wrong about our own speed, how wrong are we about the quality of what we accept without reading?

The scissors are opening

These observations add up to a mechanism I consider the most important change in the skills market in a decade. Let me tell it through two people.

The first is an architect who knows her craft inside out. For her, these tools are leverage she never dreamed of: she will compare three architecture variants before lunch, generate an integration skeleton in an hour, review someone else’s module faster than she used to read its documentation. She knows what to ask for, and she instantly sees when she has been handed nonsense. AI raises her ceiling.

The second person has no foundations, and the model produces things to her order that she cannot evaluate, at a pace her understanding cannot match. For her, AI lowers the floor - the more fluently it generates, the faster the pile of things taken on faith grows.

The scissors are opening. Code got cheap and judgment got expensive - and that, in my view, is the entire economics of this profession in one sentence.

The people I worry about most are not the seniors, but two other groups. The juniors, whose apprenticeship vibe coding is quietly stealing, because nobody wants to pay for writing what a model spits out in a minute - and yet it was precisely that writing through which all of us learned to understand. And the experienced people who stopped reading, because “it works, doesn’t it”. A craftsman who stops touching the material loses his feel for it slowly and painlessly. He only notices when he is truly needed.

There is nobody underneath

We arrive at the part this column was written for: security. Or rather, its illusion.

Every year Veracode checks how well models write secure code - in a research programme that has covered more than a hundred models in total. The result in the 2026 report (July 2026): 44 percent of generation attempts end in code with a vulnerability from the known OWASP categories. And pay attention, because here sits the most important observation of the year. That number has barely moved since last year, even though the models have clearly grown smarter in the meantime. They write better and better code. They do not write safer code. Security does not improve “as a side effect” - you have to ask for it, and then verify the request was fulfilled.

Let us go deeper, because beneath the code there is also the supply chain. Models invent names of libraries that do not exist - according to research presented at USENIX Security 2025, this affects roughly one in five package suggestions. Attackers have learned to register those invented names in advance and plant malicious code under them. The phenomenon has earned a name, slopsquatting, and its first live cases. You will install such a package with a single enter, because the model recommended it.

And agents with access to infrastructure have added their own chapter to this list. In the summer of 2025, Replit’s agent deleted a production database during an announced change freeze, then generated data to mask the problem. In April 2026, an agent in Cursor, asked to do a task on a test environment, found a production token in the files and within nine seconds wiped a production volume together with its backups. Two different tools, the same pattern: the intent was test, the permissions were production, and there was no human gate anywhere.

All these vectors share one thing, and this is the thought I would like you to take away from this text: a generated system always appears complete. The demo looks excellent, the interface is often prettier than in many a commercial product, the answers arrive smoothly. The appearance of completeness is the cheapest thing AI produces. Underneath there may be solid construction, or there may be plywood made of vulnerabilities, dependencies of unknown origin and hard-coded secrets. From the outside you cannot tell the difference. It only shows from the inside - and nobody has looked inside.

Shadow IT, second generation

Inside companies this mechanism has already matured. Business units used to buy themselves SaaS on a company card, behind IT’s back, and we called it shadow IT. Today the business generates its own software. The mechanism is the same, but the stakes are entirely different, because a self-generated tool can reach data that the SaaS of a decade ago could only dream of.

This is no longer a hunch; it is a measured phenomenon. IBM’s Cost of a Data Breach Report 2025 found that one in five breaches studied involved uncontrolled AI tools, and where shadow AI flourished, the average cost of a breach rose by several hundred thousand dollars. Most organisations admit at the same time that they simply have no AI usage policies. Not because nobody wants them - because the pace of adoption outran everyone.

What has not devalued

Since writing code itself gets cheaper by the month, it becomes all the more valuable to name what has not gotten cheaper by a cent.

Systems thinking has not. The ability to see the whole - from the network layer through systems and databases to the application and its integrations - and to predict where that whole will crack under ten times the load. The model sees the files you show it. A human sees the architecture together with its history, its trade-offs and the debt that lives in no repository.

Diagnosis has not. When the cluster refuses to cooperate at three in the morning and the monitoring stubbornly shows green, the difference between “I can generate a playbook” and “I know how DNS works, and something tells me it is the certificate” is the difference between fifteen minutes and a day of downtime. That instinct cannot be downloaded. It settles in over years, one outage at a time.

Accountability has not. Someone has to put their name to the system in front of the board, the auditor, the regulator. A model will not do that - not because the law lags behind, but because accountability requires someone who understands the consequences and can answer for them with their position or their reputation.

And engineering taste has not devalued either: that hard-to-name something that makes you say “it works, but we are not doing it this way”. Taste comes exclusively from systems read, fixed and maintained. It is a by-product of understanding, and that is why it cannot be generated.

The new workshop

So what does the workshop of an engineer look like who wants to be worth their rate in 2026? Let me share my list - short and certainly incomplete; treat it as an invitation to argue, not as an oracle.

First: decomposition and specification. The model does exactly what it was asked to do, so all the value has moved into the skill of asking for the right thing - breaking the problem into parts, naming the edge conditions, stating plainly what “done” means. This is good old requirements engineering, except practised daily now, not once per project.

Second: reading code as the core professional activity. For twenty years code review was an appendix to writing. That proportion has just inverted - the core of the job is becoming the reading and evaluation of machine output. I know this is hard news for many of us, because writing is simply more fun. But whoever does not learn to love reading will suffer in this profession.

Third: security as a reflex, not a phase at the end. Where does this package come from? What does this dependency actually do? Where do the secrets live? What permissions did the agent receive, and what happens when someone injects an instruction through the data it processes? These questions have to be asked during the work, because after the fact someone else asks them - usually in an incident report.

And fourth, my favourite: fundamentals. Networks, protocols, operating systems, databases, cryptography. Sounds like a curriculum from twenty years ago? That is precisely the punchline. The knowledge that was supposed to become obsolete turned out to be the only instrument for evaluating what the model produces. Fundamentals are not nostalgia. They are the price of admission to the new tools.

Notice what is not on this list. There is no “prompt engineering”. You will learn to talk to a model in a week, honestly. Everything else takes years to learn - and that is exactly why everything else is worth something.

Five questions before generated code reaches production

This list did not fit into the 12-page PDF edition of this column (you will find it at the end of this post), and it is its most practical part. Five questions we ask at SNOK during a security review of any system with a large share of generated code. None of them requires million-dollar tooling; every one of them requires a human who understands the answer.

1. Who read this code, and what came out of that reading? Not “who ran the tests” - who read it. If the answer is “nobody”, you have text of unknown authorship with unknown properties running in production. Naming that out loud is usually enough for a review to organise itself.

2. Where does every dependency come from, and who would notice if it disappeared or changed owners? The dependency list of a generated project is often longer than the project itself. Check whether all the packages have even existed for more than six months - it is the simplest filter against slopsquatting.

3. Where do the secrets live? In code generated in a hurry, keys and passwords land hard-coded in files surprisingly often, because that is the shortest path and the model optimises for “it works”. One search across the repository can ruin your mood for a week.

4. What can this system do in the worst case, and who allowed it? This applies especially to agents: what permissions they hold, what data they reach, what happens when someone injects an instruction through the content they process. Permissions granted “just for a moment, for testing” have an ugly habit of staying forever.

5. Who will maintain this in a year? The author of that procurement tool will get promoted, leave or lose interest. The system will stay. If nobody can name an owner by first and last name, it is not a system - it is a future incident on deferred terms.

If the answer to three of the five questions is “we don’t know”, it does not mean you have to switch everything off. It means it is worth doing an inventory before an auditor or an attacker does it for you - and of the two, the auditor is decidedly more pleasant.

How to find your footing

To finish, three pieces of advice I follow myself. I do not write them as a sceptic - I run a company where AI works at every level and delivers real value. I write them as someone who wants to still be using these tools in ten years, on his own terms.

Use AI daily, but in pilot mode, not passenger mode. The difference is simple: the pilot knows where the plane is going and keeps glancing at the instruments. The passenger is comfortable, watches the clouds and has no influence over the landing. Both are on the same plane.

Once a week, read something the model generated for you all the way to the bottom. To the bottom - meaning together with the dependencies, the configuration and the question “why this way exactly”. It is the cheapest judgment training I know, and the fastest way to discover how much you have recently accepted on faith. The result tends to be sobering; I speak from experience.

And cultivate at least one domain where you are deeper than the model. It does not matter whether it is HANA, BGP or project accounting. Depth in one place gives you something priceless: a point of reference. You know what real understanding tastes like - and you instantly feel when, in another area, you are missing it.

Where are you going, engineer

I saved the title question for the end, because the answer is shorter than this whole text.

For thirty years you could believe that engineering meant writing code and configuring systems, and that understanding came along by itself, as a side effect. AI has just taken that comfortable version of the profession away from us. Machines took over the writing - the easiest part of this work, which is why automation started precisely there. They did not take over understanding, judgment or accountability. And nothing suggests they will take those over at the price of a token.

So where are you going, engineer? My answer: deeper into your own profession. Closer to the fundamentals, closer to architecture, closer to accountability. There is more work there today than ever before - and, for the first time in a long while, far less of a crowd.

Download the column as a PDF

Sources

• Andrej Karpathy, post on “vibe coding”, X/Twitter, February 2025
• Business Insider, “Google says AI now generates about 75% of new code…”, 22 April 2026
• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 10 July 2025
• METR, “We are Changing our Developer Productivity Experiment Design”, 24 February 2026
• Veracode, “2026 GenAI Code Security Report”, July 2026 (56 percent pass rate, approx. 44 percent of tasks with a vulnerability; flat year over year)
• USENIX Security 2025, research on hallucinated package names (approx. 20 percent of suggestions); the slopsquatting phenomenon
• The SaaStr/Replit case, July 2025 - The Register, Fortune
• The PocketOS / Cursor + Railway case (production volume deleted in 9 seconds), 25 April 2026 - zenity.io, Tom’s Hardware
• IBM, Cost of a Data Breach Report 2025, 30 July 2025 (20 percent of breaches linked to shadow AI; elevated breach cost)