When AI removes the translation layer between thinking and building

For most of my career, my work stopped just before the code began.

I would design the system, write the architecture, explain the awkward edge cases, and then hand it to capable people to build. Embedded systems, IoT platforms, connected devices, real-time control architectures: the pattern was broadly the same. Usually it worked well. But it rarely came out quite as I had pictured it.

Somewhere between the model in my head and the implementation in front of me, small things changed. Sometimes harmlessly. Sometimes in exactly the places that later mattered most.

This past year I led the build of a production platform for a client, with AI in place of a conventional development team. Not a prototype: a live, multi-region, GDPR-compliant, security-tested connected vehicle platform covering more than 18 regulatory zones, eight languages, four user surfaces and nine vehicle lifecycle stages.

AI made that possible. That sentence is easy to misunderstand, so I want to be precise about what changed, and what did not.

---

The problem was never the developers

Every architect who has worked with a development team knows the feeling. The whole system is there in the architect’s head: the data flows, the dependencies, the edge cases, the security implications, and the few decisions that look minor on paper but are not minor at all.

Then it gets written down.

However carefully that is done, the team is still building from a partial representation of a living model. Developers make reasonable interpretations. The design moves on. Questions get answered in different rooms at different times. Most of the drift is understandable. Some of it only reveals itself under load, after release, or when the system meets a case nobody thought to mention in the spec.

This is not a complaint about developers. It is a structural problem in the way complex systems are usually built. Better documentation helps. Pair programming helps. Embedded architects help. Daily communication helps. None of them removes the gap completely. They manage it.

---

What building Fienti involved

Fienti is a connected vehicle platform for e-mobility OEMs and fleet operators. I built it for a client launching a new business.

It covers nine vehicle lifecycle stages, from factory QA to end-of-life. It includes OTA firmware with cryptographic integrity verification and rollback, thousands of automated security tests including Bluetooth-specific work, per-customer data sovereignty through separate database instances, more than 18 regulatory zones, and right-to-left layout support.

It is not a small system.

There are two production cross-platform mobile apps: one for consumers, one for engineers and workshops. Both are location-aware. On launch, the detected region sets the language, regulations, terms, distributor configuration and vehicle model profile automatically. Beyond region, the cloud configures the consumer app at an individual user level, right down to per-user beta features. It is not simply a settings screen. The whole app experience is assembled for that person in that context.

The consumer app relays continuous telemetry back to the OEM for error analysis and sends proactive notifications for things such as battery health, maintenance reminders and fault alerts. Customers can control their own screen layout through widgets. If a fault is hard to reproduce, customer service can switch the app into high-sample-rate telemetry during a live ride, moving from background monitoring to near-real-time diagnostic data without asking the customer to perform a complicated ritual. Agents can also see the customer’s live app view directly for remote support. The engineering app sits behind tighter access controls and handles maintenance, diagnostics and vehicle history that should never appear on the consumer surface.

I was the architect, and I guided every part of it closely: design, development, testing and security.

Most people ask how long it took. About six months. The more interesting question is why that was possible at all.

---

What AI changed, and what it did not

AI did not build Fienti.

It cannot decide that a connected vehicle platform needs per-customer data sovereignty. It does not know, by instinct, which automotive BLE attack surfaces deserve special attention. It cannot look at a half-formed product idea and decide what matters commercially, what is merely clever, and what will become expensive later if handled casually now.

Those decisions were mine. The judgement calls were mine. Thirty-five years of pattern recognition mattered throughout.

What AI changed was the time and friction between a decision and a working implementation.

When I knew how the OTA update mechanism needed to behave, I could describe it precisely and get to working code in minutes rather than days. When I needed a user interaction, I could iterate on the component myself instead of first turning the idea into a brief for someone else. When I wanted to test an algorithm, I could build a simulation of the operating environment before committing the production implementation. When I was uncertain about a security approach, I would run the same question through two or three different systems and compare the answers.

Cross-model validation. That last habit is worth naming. It is not magic, and it is not a replacement for expertise. But different systems make different mistakes. Comparing them catches some of the errors that any one model can state with great confidence.

Testing alongside the code. The other large change was in testing. As the code moved forward, I could keep highly effective specialist tools running around it: penetration testing, scalability testing, regression testing and other automated checks. The coverage was excellent. More importantly, I could use their output immediately, while the relevant design decisions were still fresh in my mind. That saved weeks of effort that would otherwise have gone into organising, handing over, reviewing, and then re-entering the problem later.

Continuity of thought. What changed for me was not simply speed. I no longer had to explain the whole system to someone else before I could find out whether an idea worked. I could carry the architectural model directly into implementation, test it, correct it, and keep moving while the whole shape of the system was still present in my mind.

What surprised me most was not that AI made me faster. It was how much of my own imagination and experience it released. I could build the thing I actually wanted to build, rather than a slightly compromised version shaped by how much complexity would be reasonable to explain, divide up and supervise through other people.

AI did not replace architecture decisions, judgement about what to build and why, regulatory knowledge, security instincts, or the ability to notice when a plausible answer is wrong.

---

The uncomfortable implication

I am wary of turning one substantial project into a universal rule. Teams building complex systems at scale are not going away, and they should not. A well-run team with deep shared context can still do things one person cannot.

But I do think the category of “architect who does not implement” is now worth questioning more seriously than it was even a few years ago.

For a certain kind of experienced technical person, AI changes the shape of the work. A junior developer with AI tools may become a more productive junior developer. A senior architect with AI tools can sometimes collapse roles that previously had to be separated. The six or eight people I might once have needed to build Fienti were not replaced by cheaper labour. In this case, much of the handoff itself disappeared.

That is uncomfortable territory. It is also real territory.

The roles most exposed are not necessarily the most junior ones. They are the roles whose value lies mainly in translating someone else’s decisions into output: code from a spec, screens from a brief, tests from a script. The people who remain hardest to replace are the ones who can own the problem: decide what needs building, understand why it matters, and recognise what good looks like when the answer is not already written down.

AI can implement a great deal. It still cannot say, unaided, what is worth implementing.

---

On the ethics of it

People have asked whether this model is morally questionable: whether one person using AI instead of a team is somehow wrong.

The honest answer is that it depends on the comparison.

If the alternative is an understaffed team, poorly briefed and constantly reconstructing intent from partial information, one experienced person with AI may produce a better outcome for the people who eventually use the system. If the alternative is a well-resourced team with strong technical leadership, good embedded practice and enough time to think, that team will still outperform one person at scale.

The concern I take more seriously is different. Organisations may use AI as an excuse to stop investing in technical talent rather than to move that talent towards higher-leverage work. That risk is real. The answer is not to pretend the capability shift is not happening. It is to be much clearer about where human judgement, creativity and ownership still matter, and to invest there deliberately.

---

Four things worth taking seriously

For architects and senior technical people: the claim that a team is necessary to build something now needs to be made consciously, not assumed. It may still be the right answer. It is no longer the only answer.

For leaders building technical organisations: the most valuable AI deployments may not be the ones that summarise email or tidy meeting notes. They may be the ones that put AI in the hands of the most experienced people and remove the friction between their thinking and execution.

For people in translation roles: the move from “I implement to spec” to “I own the problem” matters more each year. Not everyone will want to make it, and not every organisation will make room for it. The people who can will be increasingly valuable. The people who cannot may find the ground shifting faster than they expected.

For organisations adopting AI: use it to move technical talent towards higher-leverage work, not as a reason to stop investing in that talent. Be explicit about where human judgement, creativity and ownership still matter, and put money there.

---

Fienti exists because, for the first time in my career, I could think and build almost in the same movement. I am still working out how far that generalises. I am certain it changes something important. I would be interested to hear where, in your own organisation, the handoff between deciding and building costs the most.