Software Planet Group has spent nearly three decades building bespoke software products, SaaS platforms, enterprise systems and complex digital products for organisations ranging from early-stage start-ups to international enterprises. Throughout that time, one thing has remained constant: we have never believed that technology itself is the differentiator. Engineering thinking is.
In that time, we have watched many technologies announced as transformative arrive with great fanfare and depart quietly, having changed far less than promised. So we developed a habit of asking, whenever some new tool emerged: Is this real yet?
For most of the past few years, our answer to AI coding tools was a cautious Not yet. Impressive in demos. Inconsistent in production. Useful at the margins, but not something that fundamentally changed how a professional engineering team operated day to day.
At some point in the past twelve months, that answer changed. We did not make a formal decision. There was no meeting, no announcement, no company-wide memo declaring that AI had arrived. We simply began to notice that we were trusting it with real work — not experimental side projects, not throwaway scripts, but production code in live systems. And it was holding up.
Perhaps that happened naturally because our engineering organisation has never been organised around specific programming languages or frameworks. Throughout our history we have moved from Delphi and FoxPro to Java, .NET, JavaScript, cloud platforms and now AI-assisted engineering. Technologies changed. The engineering process remained remarkably consistent.
We are not entirely sure when the shift happened. That uncertainty is itself worth noting. The threshold was crossed quietly.
This Is Not Another Productivity Improvement
The first instinct, when people hear that AI coding tools have become genuinely capable, is to reach for a familiar frame: So it’s like a faster autocomplete. A smarter linter. A search engine that writes code.
We understand the impulse. It is easier to integrate a new tool if it fits into a category you already have. But we think this framing is wrong in a way that matters.
Consider the difference between an excavator that digs 20% faster and an excavator that can independently plan, execute, and verify an entire site preparation without human intervention on each step. Both are improvements. But only one changes the structure of how you build a team, plan a project, or think about who you hire.
What has changed is not that AI writes code faster. It is that AI can now independently execute entire categories of engineering work — the kind of work that used to require an engineer’s sustained attention. Generating data models. Scaffolding API endpoints. Writing test suites. Translating requirements into working interfaces. Handling the boilerplate that every project accumulates.
This is not a productivity improvement layered on top of existing software development. It is a change in what software development consists of.
Kent Beck Said It Better Than We Could
A few months ago, Kent Beck — one of the people most responsible for how the software industry thinks about engineering practice — wrote something that we found ourselves returning to repeatedly. He said that AI had made roughly 90% of his skills less valuable while making the remaining 10% dramatically more valuable.
We have thought about that sentence a great deal.
The obvious reading is pessimistic: 90% of what you know is now worth less. But we think the more accurate reading is structural. Beck is not describing a loss. He is describing a redistribution.
The work that made up that 90% — the mechanical execution of well-understood patterns, the translation of clear specifications into working code — that work still exists. It still needs to happen. But AI can now do a great deal of it, which means the economic value of a human doing it has declined sharply.
What remains — and what has become more valuable — is everything that AI cannot do. Understanding what a system actually needs to accomplish. Making architectural decisions that will still be sound two years from now. Recognising when AI-generated code is technically correct but strategically wrong. Owning the consequences of technical choices.
The 10% was always the harder part. It has simply become more visible now that the 90% is no longer obscuring it.
Code Is Becoming Cheaper. Engineering Is Becoming More Expensive.
We believe the software industry is beginning to separate coding from engineering.
These two things have been bundled together for so long that most people treat them as synonymous. But they describe different activities. Coding is the act of producing code. Engineering is the act of solving problems well, at scale, over time, under uncertainty. Coding is a means to that end. It has never been the end itself.
What is happening now is that the cost of coding — the raw production of working code — is falling rapidly. Dramatically, in some categories of work. And as it falls, the cost of engineering in the deeper sense is rising. Not because engineers are becoming scarcer, but because the distance between having code and having a good system is becoming more visible.
A system built quickly on AI-generated code can look complete. It can pass basic tests. It can demo successfully. And then, six months later, it can become an unmaintainable tangle that costs far more to fix than it would have cost to build correctly in the first place.
This is not a new problem. But AI has made it easier to get to that point faster. Which means the value of the engineer who prevents that outcome — the person who thinks about architecture, maintainability, and long-term consequences — has never been higher.
The Role of a Software Engineer Is Changing
There is something uncomfortable in this shift that we think deserves to be said plainly.
Software Planet Group was founded by engineers rather than entrepreneurs. We were never interested in selling technologies. We wanted to build products and solve difficult problems. Looking back, that mindset prepared us surprisingly well for the AI era, because technologies come and go, while engineering judgement compounds over decades.
One of our oldest internal stories is about a client who expected an expensive document management system. The actual problem was solved with coloured envelopes. The story became part of our engineering culture. Our responsibility is not to maximise development hours. It is to solve the client’s problem — even if software turns out not to be the answer.
That orientation matters now more than ever, because the shift happening in our industry runs deeper than tooling.
Many people entered software development because it offered something rare: work that rewarded deep technical focus and allowed a certain distance from the messier parts of human interaction. You received a well-defined problem. You solved it. The quality of your solution could be evaluated relatively objectively. The feedback loop was mostly between you and the machine.
AI is particularly good at exactly that kind of work. Well-defined problems with clear success criteria, executed without ambiguity, evaluated by whether the code runs correctly — that is the territory where AI coding tools perform most reliably.
What remains for the human engineer is disproportionately the work that involves ambiguity. Talking with a client who does not know what they want. Making architectural decisions where several options are reasonable and the right choice depends on context that no specification will fully capture. Pushing back when a requirement is technically possible but strategically unwise. Taking responsibility when something goes wrong.
We are watching soft skills become, in a real sense, engineering skills. Not because technical depth matters less — it matters more, as we argued above — but because the situations that require human judgment are increasingly the situations that involve other humans.
Communication, ownership, systems thinking, the ability to hold a client’s real problem in mind while making technical decisions — these are becoming core competencies of software engineering, not supplementary ones.
Customers Are Changing Just as Quickly
Something else is happening that we did not fully anticipate.
Clients are arriving with prototypes.
Not always. Not universally. But with increasing frequency, we are beginning a project not from a blank page or a written specification, but from a working application — something built quickly, often with significant AI assistance, that demonstrates a concept and sometimes even has early users.
The client rarely frames it this way. They often describe it as a rough draft, a starting point, something that needs to be rebuilt properly. But what they are really saying is: We got ourselves to here. Now we need you to take us somewhere we cannot reach on our own.
Many organisations approach us after discovering that building software is no longer their biggest challenge. AI can generate impressive prototypes remarkably quickly. Turning those prototypes into maintainable, scalable, secure products is an entirely different engineering problem. Increasingly, this is where Software Planet Group becomes involved.
The conversation is different when the client has built something. They have more intuitions about what the system needs to do. They have also sometimes made early decisions that will need to be revisited carefully — decisions that made sense for a quick prototype but that create real constraints for a production system.
What this means, practically, is that the ability to read a codebase quickly, understand its implicit assumptions, and have an honest conversation about what needs to change has become more valuable than it used to be. The client who arrives with a prototype is not asking us to build from scratch. They are asking us to see what they have built and tell them the truth about it.
AI May Reshape a Market That Has Been Selling Speed
We want to offer a hypothesis here — not a prediction, and not a conclusion, but something we are beginning to wonder about.
For the past fifteen years or so, the low-code and no-code market has been built on a specific promise: you can build software faster, without needing developers, by working within our platform. It was a compelling proposition, and it attracted genuine adoption. But it came with constraints — vendor lock-in, limited customisability, ceilings that became visible exactly when a product started to grow.
What AI coding tools now offer is speed without those constraints. A skilled engineering team using AI can move at a pace that, until recently, only low-code platforms could offer — while retaining full control over the underlying architecture.
We think this could put meaningful pressure on the low-code market. The core proposition — speed — is no longer exclusive. And the tradeoffs that came with it — flexibility, ownership, scalability — now look different when the alternative is no longer “hire a large team and wait six months.”
We hold this hypothesis loosely. There are strong network effects and real switching costs in the platforms that have built large user bases. But we would be surprised if the next five years did not produce significant disruption in that segment of the market.
Software Engineering Is Becoming More Like Traditional Engineering
Here is the shift that we find most interesting, and that we think is least discussed.
For most of the history of the software industry, a software developer was valued primarily for their ability to produce code. The analogy to other skilled trades was reasonable: you hired someone who could do the work with their hands, and the quality of the output correlated with the quality of those hands.
What is happening now is that software engineering is beginning to resemble classical engineering disciplines — civil, mechanical, structural — in a way it has not before.
A structural engineer is not primarily valued for their ability to perform calculations by hand. They are valued for their understanding of how forces move through materials, how systems fail, what tolerances are acceptable, and what decisions will still be sound when conditions change. The calculations are a means to that understanding, not the understanding itself.
We are watching something similar begin to happen in software. The ability to write code is becoming table stakes — the baseline, not the differentiator. What matters increasingly is whether you understand the system: how components interact, where failure modes live, what scale will break, how security assumptions hold under pressure, what the architecture will cost to maintain in three years.
This is not a loss for the profession. If anything, it is a maturation. Software engineering is old enough now to have accumulated the kinds of lessons — about what fails, what scales, what holds up under real conditions — that make a discipline into a real engineering discipline. AI is, in a sense, forcing that maturation to accelerate.
Conclusion: A Line That No One Announced
For nearly three decades, software development has evolved through a continuous series of higher-level abstractions. Assembly gave way to compiled languages. Manual memory management gave way to managed runtimes. Raw SQL gave way to ORMs. Physical servers gave way to cloud platforms. Each abstraction raised the floor of what a capable engineering team could accomplish and changed what it meant to be capable.
AI is the next abstraction layer. And like the ones before it, it does not eliminate the need for engineering judgment. It raises the level at which that judgment operates.
What we notice — and we want to be precise about the word notice, because this is observation, not prediction — is that something has shifted. We are building differently than we were two years ago. Our engineers are spending less time on mechanical execution and more time on decisions that actually require thinking. The ratio has changed.
We crossed a threshold. We are not entirely sure when. No one announced it.
But the profession on the other side of that threshold is not smaller or simpler than the one before it. It is, if anything, more demanding — and more interesting. The engineers who will thrive are not those who resist the change or those who believe AI makes engineering unnecessary. They are the ones who understand systems deeply enough to know what AI is getting wrong, and who can take responsibility for the consequences of code they did not write by hand.
That has always been the job. It is simply more visible now.
Software Planet Group is a UK-based software engineering consultancy with nearly three decades of experience designing SaaS platforms, enterprise systems and bespoke digital products. We combine engineering depth, product thinking and technical consultancy to help organisations solve complex problems, reduce delivery risk and build software that remains valuable long after the first release. The observations in this article come from day-to-day engineering practice rather than theory.
