AI-assisted delivery, without the hype

There are two stories about AI in software delivery and both of them are wrong. The first says it changes nothing: a faster autocomplete, a better search engine, the same team doing the same work. The second says it changes everything: the engineers go away and the machine ships the product. We have spent the last two years rebuilding how a small senior team delivers connected products, and the truth sits in a more useful place. AI has removed a large share of the repetitive work from our days. It has not removed a single decision. Knowing which is which is the whole craft.

Most firms bolted it on. We rebuilt around it.

The common approach is to give engineers an AI tool and carry on as before. That gets you a modest speed-up and a lot of unreviewed code. We took the other route. We looked at every step from a client's brief to a device in the field and asked, for each one, two questions: is this step repetitive, and does it carry a decision? Steps that were repetitive and carried no decision went to AI, with a human check on the output. Steps that carried a decision stayed with a senior engineer, who now has more time for them because the repetitive work has gone.

The result is a team that is still small and still senior, shipping in weeks what used to take months, with more review rather than less. That last part matters more than the speed.

Where AI speeds us up

Scaffolding. The first version of a firmware project, a cloud service or an app has a great deal of structure that is the same every time: project layout, configuration, the plumbing between a sensor driver and the code that reads it, the boilerplate of an API. AI drafts this well, and an engineer who has written it fifty times before is glad to review it rather than type it again.

Tests. Unit tests, integration tests and the hardware-in-the-loop tests that check firmware against a real board are tedious to write and essential to have. We now write them alongside the code, with AI drafting the cases from the code's own contracts and an engineer deciding which cases matter. Coverage used to lag behind the code by weeks. Now it keeps up.

Documentation. Architecture notes, API references and runbooks are the first thing to rot on any project, because they are written last and updated never. Generating them from the code and regenerating them as the code changes means the documentation a client receives at handover describes the system they actually have. This is the single change clients notice most.

Release checks. The checklist before a firmware release or a cloud deployment is long and unforgiving, and humans skip steps when they are tired. Automating the pipeline and the checks, with people approving the gates, has made our releases more boring, which in a fleet of devices is exactly what you want.

Where people stay in charge

Architecture. How the device talks to the cloud, what happens when it is offline, how data is modelled, where the state lives. These decisions shape everything built on top of them and are expensive to reverse. They are made by a senior engineer, argued over, and written down.

Hardware. AI can draft a driver; it cannot tell you that the sensor you have chosen drifts in heat, that the enclosure will trap it, or that the battery you budgeted for will not last a winter. Those judgements come from people who have put devices in the field and gone back to fix them.

Review. Nothing ships unreviewed. Every change, whether a person or a tool drafted it, is read by an engineer who is accountable for it. That rule has not relaxed as the tools improved. If anything we review more, because we produce more.

The hard calls. Which feature to cut to make the date. Whether a client's requirement is a good idea. When to tell someone that the product they want is not the product they need. No tool makes those calls, and no client should want one to.

Why hardware makes the line sharper

In pure software a bad decision is usually a bad deploy, reversed in an hour. In a connected product a bad decision can be a thousand devices on walls in five hundred stores running firmware that cannot be fixed without a technician and a ladder. The cost of being wrong is physical, and it arrives late. That is why the split above is so firm for us. The repetitive work is where speed pays; the decisions are where care pays; and a fleet in the field punishes anyone who confuses the two.

What this means if you hire us

Three things. Your prototype arrives in days, because the scaffolding that used to take the first fortnight no longer does. Your defects surface early, because tests and reviews run in short loops rather than at the end. And your documentation keeps up with the code, so the handover you receive describes the product you own, and you are never locked in by the only person who understood it.

What it does not mean is a cheaper team of junior people supervising a machine. The team is senior and it is accountable for everything it ships. The AI has given it back the hours that used to go on the parts of the job nobody should still be doing by hand.