AI prototype works: why hire engineers?

Next year, a client may send a robot to the meeting instead of coming in person. It rolls into the room, puts a laptop on the table and shows me a working prototype built over the weekend with AI agents.

“Here it is. It works. Why would we need your engineers?” the robot asks on the client’s behalf.

Maybe the robot is a little early. The question is right on time.

The scene is speculative. The shift in buying is already visible. In McKinsey’s 2026 global survey, 32% of respondents said their organisations had decided against buying at least one software product or feature because they believed they could build it internally with agentic coding. That is a survey result, not a forecast of the share of the whole software market. Still, it points to a change in the starting point: some clients already expect to build the first version themselves.

If AI creates the prototype, what will a client pay an engineering company to do?

My route to this question is practical. My background is in the humanities and company leadership. For more than a year, I have used AI agents to turn ideas into working applications. I have seen how quickly a first version can appear, and how much work remains after that.

The telling moment often comes with the second serious change. Replace the model. Connect a corporate system. Change the data structure. Add access controls. Hand the project to another engineer while keeping critical functions reliable.

That is when you find out whether the prototype has an architecture people can understand and develop.

Documentation matters here too. A new engineer needs to know why components exist, how decisions were made and what must keep working. AI can create architecture records, component maps, tests, release notes and handover instructions alongside the code.

That opens the possibility of better documented projects. It depends on keeping those materials connected to the actual system, its decisions and acceptance criteria, then checking them during handover. Otherwise, AI can produce outdated documents faster.

Faster generation does not mean faster product development

AI already speeds up parts of software work. The evidence does not show that this automatically speeds up the entire journey from idea to dependable product.

In a McKinsey survey of 334 product and engineering respondents, 25% of those in director-and-above roles (n=173) reported meaningful AI acceleration, while 30% said their teams’ productivity had fallen. The survey captures different outcomes across teams.

DORA’s qualitative analysis of 1,110 open-ended responses from Google engineers describes a similar tension: AI can speed up the initial output while increasing the effort required to verify it, and it can amplify weaknesses in an engineering system. This is a qualitative study, not a universal measure of every team.

METR also cautions against turning agent results on well-specified, automatically scored tasks into predictions about entire occupations. Real projects involve ambiguity, legacy systems, physical constraints, negotiation and consequences that no single automated test can capture. METR draws that distinction explicitly.

A demo shows that an idea can work. Engineering has to show that the product can live in the real world. Reality brings old databases, component lead times, auditors, safety requirements and users who click twice.

Clients will buy five different things

Discussions about the future of engineering often mix several business models together. AI will affect each one differently.

Software engineering services

The greatest price pressure will fall on work measured mainly by lines of code or tickets closed. Boilerplate, simple CRUD applications, standard dashboards and first drafts of tests or documentation are becoming cheaper to produce.

Clients will still need custom engineering. They will pay for architecture, integration with real systems, domain logic, security, verification, change management and support.

The boundary between probabilistic and deterministic logic will matter more. A model can suggest a classification, text or possible action. When an action affects money, safety, production or compliance, someone has to define the exact rules, acceptable failure modes and how the result will be checked.

Code is becoming cheaper. The judgement about where a system must not fail is not.

SaaS

Clients will be able to recreate individual SaaS features more quickly. A simple interface over a model, another dashboard or a narrow automation is easier to reproduce than before.

SaaS value sits in a reliable operating process: availability, security, updates, access control, integrations, data integrity, predictable quality and support.

The most exposed products are thin wrappers without a deep workflow, valuable operational knowledge, meaningful integrations or responsibility for an outcome. Strong SaaS sells work that is completed reliably.

Hardware engineering

The physical world sets its own limits on software’s speed.

AI can help draft a specification, suggest an architecture or produce an initial schematic or embedded code. The product still has to meet electromagnetic compatibility, thermal and signal integrity requirements, FPGA constraints, component availability, laboratory testing, certification and production preparation.

In my own hardware-related work, specialist FPGA expertise mattered at a point where another generated draft could not replace it.

Clients will pay for hardware and software co-design, physical verification, bring-up, lab work, component risk management, production preparation and lifecycle support. AI can speed up a design draft. The device still has to work in the physical world.

Hardware-as-a-Service

Under Hardware-as-a-Service, the client pays for equipment availability or the outcome it produces over time. The provider may take on responsibility for telemetry, maintenance, replacement, upgrades, spare parts, financing and residual risk.

This fits a broader move in industrial services towards ongoing outcomes and service models. IFS and Accenture’s 2025 research examines this trend among manufacturing leaders.

The value comes from keeping a physical system useful over time. That requires operations, field support and lifecycle decisions alongside the original design.

AI-as-a-Service

A model API is one component of AI-as-a-Service. The client pays for a managed capability that performs useful work with defined data and permissions, quality checks, cost controls, logging, security and human escalation.

NIST distinguishes agent tools by their access levels, from read-only through constrained-write to full write access. Whether an agent operates in a trusted or untrusted environment matters too. NIST’s tool-use taxonomy helps explain why these details shape whether an agent can be used in a real business process.

A strong AI service should keep its value when the underlying model changes. Its value comes from the domain workflow, integration, controls and demonstrated quality.

What gets cheaper, and what becomes more valuable

The work most likely to face price pressure includes:

• Boilerplate and simple interfaces
• First drafts of requirements, tests and documentation
• Manual handovers between disconnected roles
• Staff augmentation sold mainly by the hour
• Products whose advantage is an easily reproduced feature

The work likely to gain value includes:

• Architecture and changeability
• Deep domain knowledge
• Integration with legacy and critical systems
• Deterministic business logic
• Security, verification and evidence
• Hardware and software co-design
• Physical prototyping and production preparation
• Lifecycle management and accountable support

This is a hypothesis about where value moves: from producing an artefact towards managing its consequences.

The sale starts after the demo

A client who arrives with a prototype is not necessarily a lost client. The conversation can begin at a higher level.

Instead of asking, “What would you like us to build?”, an engineering company can ask:

• What must never happen in this system?
• Which decisions must remain deterministic?
• What data and actions can the agent access?
• What evidence is needed before launch?
• Which real systems must the product connect to?
• How will each significant change be checked?
• Who owns the response when something fails?
• Who will support the system over time?

The sale shifts towards defining risk and responsibility together.

An engineering company can offer a managed transition from prototype to production: architecture assessment, hardening, integration, security review, physical validation, documentation recovery and lifecycle planning.

The client brings the starting point. The engineering company helps make the route to a dependable product understandable and manageable.

Where I see the opportunity

My personal hypothesis, not an official company strategy, is that engineering companies will move closer to the most demanding transitions:

• From prototype to product
• From software to a physical device
• From a discovered vulnerability to a verified fix
• From first delivery to a supported lifecycle

In my own work, finding a vulnerability and choosing a safe, verified fix have proved to be different tasks. Finding can be automated. A fix still requires product context, dependency analysis, risk decisions, regulatory understanding, testing and a person who owns the decision.

AI shortens the distance to the first version. The path from that version to a dependable result remains an engineering challenge.

The robot may deliver the prototype next year. The client will still ask who understands it, who can change it and who will own the outcome when the demo meets the real world.

That is the question engineering companies need to answer now: if your client’s AI built the first version, what are they hiring you to own next?