John leads Shinetech's North American business and works with Core70 clients in the US.
The people who contact us have changed.
Three years ago a client came with a problem and asked whether we could build the solution. Today they come having already tried. They have used ChatGPT or Claude, run Copilot over a codebase, maybe stood up a working prototype over a weekend. They know that parts of software development which used to take weeks now take an afternoon.
So they ask: “If AI can write the code, why do I need developers?”
What actually got cheaper
AI has changed the economics of software development. Writing code, generating tests, producing documentation, analysing an unfamiliar system — all of it is much faster than it was. A capable engineer with good tools does in a day what used to take a week.
What didn't get cheaper is everything around the code. Architecture. Understanding what the business actually needs, as opposed to what was written in the requirements. Data modelling. Security. Integration with the systems that already run the company. Deployment, and what happens after it. Those were always the hard part.
The faster code can be produced, the more those disciplines matter. DORA's research on generative AI in software delivery found something that surprised a lot of people: greater AI adoption improved individual developer productivity, and at the same time was associated with lower delivery throughput and lower stability for the organisation as a whole. Individuals sped up. Systems didn't.
That matches what we see. AI can make one developer dramatically more productive. It does not automatically make a software organisation better.
The pattern we keep seeing
A founder or a business team uses AI to build something. They get surprisingly far — a working application, a real interface, features their customers can touch. It is impressive, and they are right to be pleased.
Then it has to become a business system.
It has to connect to the accounting platform, the CRM, the inventory database. It needs permissions — who can see what, who can change what. Someone asks where the data actually lives and how it is structured. A requirement changes, and the change ripples somewhere unexpected. Someone asks who tests it. Someone asks who maintains it. Someone asks, quietly, whether the code the AI wrote can be trusted under a real production load on a real Monday morning.
That is where the complexity arrives — not at the start. AI has lowered the barrier to creating software. It has not lowered the cost of creating software a business can rely on. Those are different things, and the gap between them is where the value now lives.
AI and the engineer
The popular version of this is that business people should build the prototype with AI and hand it to engineers afterwards. That is not the order we see working.
The idea comes from whoever runs the business — the CEO or the founder, who knows better than anyone what problem needs solving. The person who uses AI to explore it, test it and build the prototype is the engineer. They build it, show it, and if it isn't right, try again. AI has made that loop cheap: several rounds in a day.
The effect is that the engineer enters the business earlier, not later. That is how an engineer who understands the business comes to exist.
What to ask a partner now
This changes how you should evaluate anyone offering to build software for you.
“We have good developers” no longer means anything. Everyone has developers, and everyone's developers use AI. The questions that separate a partner from a supplier are more specific:
- Do you understand my business problem, or only my feature list?
- How do you use AI during development — and how do you check what it produces?
- How stable is the team? Who will still be here in two years?
- What happens after launch? Who runs it, who answers when it breaks?
- Can you help me make better business and technology decisions, or only execute the ones I've already made?
Every one of those has a checkable answer.
The role has changed. A development partner has to function as a technology advisor and an engineering partner, not as a source of hands. The hands are what got cheap.
A better question
The old question was “how much does it cost to build this software?”
The better one is “what is the fastest, safest, most economically responsible way to get the business capability I need?” — asked before the first line of code, whether that code is written by a person or generated by a model.
It is a harder question. It is also a much better conversation, for the client and for whoever they end up working with. If you have already built something with AI and you are wondering whether it can carry the business, that conversation usually starts with someone experienced reading what you have.