The developer's dilemma - mastering the transition to AI engineering

Dear software developer, please choose one of the following options for 2026 and beyond:

a) finding yourself with obsolete skills, and eventually, unemployed.
b) salary increases lower than inflation, whilst expectations of your output continually increase.

Sound unpleasant? At the height of the CD era, the music industry had a similar choice. They were making a profit of something like $6 per CD when the opportunity arrived to sell MP3s and make only 10c to 20c per song - that is, option (b). Which sensible manager would promote the move to MP3?

Likewise, software developers are wary of the move to AI engineering. It's unfamiliar, this way of working doesn't align with their craft, it's stressful and employers will expect more and more output. Our exclusive skills, our scarcity, are under threat from tools which open coding to the masses, and this will push the price of those skills down.

You could stick with option (a): put your head in the sand and hope the hype passes. That's effectively what the major music studios did. History shows that the market moved to MP3 anyway and through their inaction, these companies not only lost profits but also lost the distribution channels to digital companies like Apple, and later, Spotify. Unfortunately, you can't stop the market.

Alright, so now you're thinking: is there an option (c)? Maybe. To answer that, we need to understand where options (a) and (b) come from. The disruption that is AI engineering has thrown software engineers into "The Innovator's Dilemma", a term coined in the book of the same name by Clayton Christenson.

The innovator's dilemma - why history tells us to ignore AI engineering at our peril

The innovator's dilemma is that disruptive technologies tend to either serve new customers, or pick off the least attractive customers with a cheaper, inferior offering. When confronted with such a disruption, industry leaders are naturally motivated to stick to the premium segment instead of defending the new or existing low-end markets which the innovators find attractive. This allows the disruptive technology to gain a foothold, from where it can grow and win market share from the incumbents.

I've heard plenty of developers say things like "AI-generated code is low quality", "I stopped using AI after repeatedly being lied to" and "it often slows me down more than helping me". And they are right. AI does often produce problematic code. Vibe-coded applications may produce hard-to-maintain tech debt.

Yet here is the catch: lack of quality is not the problem. Because it doesn't actually matter what the premium customers think if you sell to a different market.

The sony Mavica, an early digital camera, stored images - slowly - on floppy disks. Photo by Lëa-Kim Châteauneuf / CC BY-SA 4.0.

When digital cameras came along, they were also low quality. Initially 100x100 pixels, what serious photographer would want such a toy? The experts at Leica wrote them off. Leica had an amazing brand and customer service, strongly associated with quality. These people were real photographers, and they had no trouble spotting rubbish. Similarly, competent software developers today can see the quality disaster that vibe coding creates. Yet there were a few photography customers, like studios who valued the ability to take unlimited photos for free, who were willing to make the quality compromise. Once digital cameras found a market, they began improving, and you know how that played out. Leica eventually survived - but only after a painful transition, including changing CEO 3 times in 4 years.

The 1968 Toyota Corolla. Uncomfortable. Uncool narrow tyres. Unquestionably better than nothing. Photo by D.Bellwood / CC BY-SA 3.0. 

Or take Toyota's first mass-market success in the USA: the 1968 Toyota Corolla. It wasn't better than US cars. It was smaller, less performant and actually quite uncomfortable. But it was cost-efficient and it reliably got you to where you needed to go. They found a partially new market amongst first-time buyers, students and immigrants. Once they had their foot in the market, they gradually improved quality to target "the next-highest niche". Today they are the world's largest car maker.

For a long time, producing steel required a large investment in costly machinery. Creating flat sheets of steel for tin cans is far more difficult than creating the low-quality steel which is used to reinforce cement (rebar). The chart shows this for four different uses of steel, based on data in The Innovator's Dilemma.

When the "Minimill" was introduced, it was able to produce steel with less upfront investment and more cheaply, but the quality was so low that it was only useful for producing rebar. Rebar customers tend only to care about price (hey, you can't verify the quality of steel once it's in the cement anyway) so the bottom of the market is a price war. Traditional steel producers couldn't compete with the minimill, so they made the conventionally smart management decision: they retreated to the other types of steel, where they could operate with higher margins. Rebar is only 4% of the steel market anyway.

But once the minimill had a market, the technology improved. By 1980 it was able to produce angle steel, and again the conventional producers were forced to retreat to the higher margins of construction steel. Now industry experts widely believed that minimills had hit a wall. Their process simply made it technically impossible to achieve the next quality level. Does this ring a bell when you think of AI and vibe coding?

But the minimill producers were determined. Extraordinary innovations, which no-one had thought could be done, eventually allowed the minimills to produce all kinds of steel. Meanwhile, the conventional producers were still stuck with their old process which produces steel at 20% higher cost.

What if vibe coding follows the same trend? In this second chart, I switched some labels to represent this symbolically. The dates are not necessarily meant literally, but the principle is. In the examples given above, the existing players didn't see profit potential or value for their customers. They didn't realise that the customers are partially new (people that wouldn't have used the existing technology). So they ignored the new technology and ended up playing catch-up once the new technology starts eating into their market.

Once you have money flowing into the new, low-quality solution via paying customers, a vicious investment and improvement cycle starts. And AI-engineering, as incomplete as it is, certainly has paying customers. Get ready for revolution.

New coders are vibe coders

Last week I chatted with Harald. He takes care of information security issues and processes, and in contrast to most of us at codecentric, he doesn't actually write code. Well, that is until recently, when he vibe-coded his first Apps Script to help him migrate assets between Google Sheets.

Harald brings the vibe to ISMS

An IT-friend of mine named Timo has a 15-year-old son who collects coins. He can't code, but he vibe-coded an application which allows him to categorise and classify his coins according to details like where he found them. It's deployed on AWS with DynamoDB. When it doesn't work, he checks the source code and tries to figure out what's going on - so he's implicitly learning to code.

When I tell this story, people often pipe up, "my 12-year-old vibe-codes minecraft mods!" It seems to me that there are a lot of teen-vibe-coders out there. It's a new market. A lot of these people would never have coded. They are not so concerned about our generation's theoretical quality metrics, they are worried about producing value. Initially it's value for themselves, but useful things spread. My colleague Ralf doesn't code anymore, except for his vibe-coded iOS drumming app. As a drummer myself, I installed it the other day.

That's me, before I had Ralf's app. Imagine what I can do now! :-)

This is how the next generation is coding. The new way of learning to code will be vibe coding, reading the code and trying to make sense of it when strictly necessary. This generation lets ChatGPT write their school assignments; they are certainly not going to write any code by hand that they don't have to - whether or not that suits your preferences.

As early as March 2025, Y Combinator CEO Garry Tan said that for a quarter of their startups, 95% of the code was written by AI.

But it's not just the new market. With every improved LLM release, more existing developers are finding that coding with AI, despite its problems, is too helpful to ignore.

Extinction-level event for coding companies?

This move away from directly writing code sounds highly problematic for a company that hires out developers as a business model. In our case, even the business name centres on code.

Yet, this change is a fantastic opportunity for codecentric. Yes, we do hire out developers, but the real value-add we provide is that we improve people and companies as we do it. We teach people to develop software better, we coach product people to create more value for customers. We sit in the sweet spot between theoretically telling people what to do and just taking orders to develop software: our daily business is hands-on doing, learning and teaching. I quite like that the German word for employee, "Mitarbeiter", translates literally to "with-worker".

This is exactly what our customers need over the next couple of years. Basically every company out there is going to need to transition to AI-engineering. It's going to be more wide-ranging than just how we develop code. Yes, a few slide decks will be created, but what companies really need is engineers, product people and organisation (agile) coaches who get their hands dirty to help the customers set up ways of working that will power them into market-beating value generation over the upcoming years. Psychologically bringing employees on board, and helping them to improve the entire software development lifecycle. As early adopters, we've been running AI development training for a couple of years already and we continue to develop that offering. Yet it's the medium-term, hands-on learning engagements which are really accelerating our customers.

Early adopters: Daniel Hartung and I began enabling people with AI-powered-development talks and workshops a couple of years ago

On the internal side, we are ensuring that all our developers are skilled, not just to develop with AI, but to show others how to do it. We are strongly investing in internal AI upskilling, and you see this reflected outwards - our knowledge sharing and our conference presence with AI-engineering talks and workshops will step up further in 2026.

Disruptive or sustaining innovation?

In his follow-up book The Innovator's Solution, Christenson clarifies that disruptive innovation generally targets new or low-end markets. If an innovation can be used to better serve existing customers, then it may simply be adopted by the the incumbents rather than disrupting them.

To avoid being disrupted, companies like codecentric should aim to successfully apply AI engineering for their customers. If their existing structures prohibit this, the most promising strategy is to create an autonomous organisation. Incidentally, codecentric has successfully started a number of spinoffs including Instana, Steadybit and Centerdevice.

Option (c) - continual high-value creation

Where does all this put the humble software developer? The market trajectory is taking us to a place where traditional software development skills are less scarce or valued than they were. But traditional coding won't disappear overnight. Some of us may even be able to retire on traditional coding with limited AI support (option a). If that's what you love, you can stick with it for now. However, that part of the market will become smaller and smaller, and you may have to make other compromises (location, industry, salary).

Alternatively, you can do what I see most developers (at least here in Germany) doing - be pulled along by the flow, tinker a bit with AI and integrate it slowly into your normal process, without disrupting the good old day-to-day workflow too much (option b). This strategy might work fine. But it may also cause you to get somewhat left behind by the fast rate of change and brilliant younger colleagues. It's really hard for me to say.

My advice, my option (c), is to implement what I described above for codecentric, but on a personal level. Become the person creating massive value by pioneering the new AI workflows, teaching others to use the technology effectively, improving the business. People that create value are always in demand. If you have a technical background, have some helpful skills like a desire to learn, proactivity and business-consciousness and then apply all this to AI-engineering, you are going to beat "some dude with a vibe coding tool" any day.

The difference between option (b) and (c) is attitude and energy level. Option (b) developers don't feel any real push to change. They are not against AI, but they are comfortable. They expect that they'll be able to use AI just fine once it is expected of them. Option (c) developers are practicing as much as possible and trying out crazy new ideas. They are talking to business guys about how they could collaborate on something exciting together. They are asking their legal department whether they will personally go to prison if they use unauthorised AI tools.

No-one knows what the future holds, so independent of which way you go, aim to maintain a flexible viewpoint about AI engineering. Express your current opinion, but be ready to change it in two months in the light of new facts. The worst thing you can do is let pride cause you to get stuck defending a viewpoint that has lost merit. Being proven wrong is a fantastic learning experience!