AI in engineering companies · Coding agents
The hobby system and the professional system
Why "it works" is where the real engineering starts
Early in my career I watched IT departments switch off a knowledge management system that worked brilliantly across global businesses, and replace it with something far less capable because it was the platform everyone wanted on their CV. I tell that story in full in "AI is not my first rodeo". I come back to it here because the same pattern is repeating, faster, with AI.
Technology decisions are not always made for the business. Sometimes they are made for the people making them. The industry even has a half-joking name for it: CV-driven development. Choosing the new thing brings training, qualifications and a better story at the next interview. Continuing to run a solid, unglamorous system that works brings none of those. Nobody is promoted for leaving something alone.
AI adds a new twist. It is no longer only a choice of platform. It is now possible for almost anyone to build a working system, quickly, with very little engineering behind it.
A working system in a weekend
I use AI coding tools every day, and they are remarkable. A capable person can describe what they want and have a working application, with a database, a login and a tidy interface, in a weekend. I have written elsewhere that this is simply another level of abstraction, like the move from assembly language to high-level languages. I stand by that.
But "it works" means something different on a laptop from what it means in a business. A demonstration answers one question: does it do the thing? A business needs answers to a dozen others, and none of them show up in a demo.
This is the gap between a hobby system and a professional one. It has nothing to do with how the code was written. A hand-written system can be a hobby system, and an AI-written one can be professional. The difference is the decisions made around the code.
What separates the two
| Question | Hobby system | Professional system |
|---|---|---|
| Architecture | Whatever the tool produced first | Chosen for how the system must grow, fail and be changed |
| Where it runs | A laptop, a free tier or a personal account | Infrastructure the organisation controls, sized and paid for deliberately |
| Security | Secrets in the code, everyone an administrator, inputs trusted | Least privilege, secrets managed, inputs treated as hostile, tested |
| Data | Copied in from wherever was convenient | Known origin, known owner, lawful basis for use, retained and deleted on purpose |
| When it breaks | Someone notices, eventually | Monitored, with alerts, logs and a person responsible for responding |
| Recovery | Hope | Backups that have actually been restored, and a tested way back |
| Change | Edited live | Version control, review, tests and a way to roll back |
| Ownership | The person who built it, until they leave | A named team, documentation, and more than one person who understands it |
| Dependencies | Whatever packages and services the tool pulled in | Known, recorded, updated and checked for vulnerabilities |
| Regulation | Not considered | Data protection, and for connected products the Cyber Resilience Act, designed in |
| Cost | Free, for now | Understood at ten and a hundred times today's use |
Every row on the right is a decision, and most of them are dull. None of them makes a good demonstration. Every one of them decides whether the business can depend on the system.
Where the danger actually lies
The danger is not the weekend build. Prototypes are valuable, and AI makes them cheap. The danger is the quiet moment when a hobby system becomes something the business relies on, without anyone deciding that it should.
It usually happens like this. A useful tool is built quickly. People start using it. It gets connected to real customer data, then to another system, then to a process that matters. Nobody ever made the decision to put it into production. It simply arrived there. By the time something goes wrong, a data leak, a failure nobody can diagnose, a supplier changing its terms, the person who built it may have moved on, and the questions in the table above have never been asked.
The CV incentive makes this worse. "Built an AI system" is a strong line on a CV and in a board report. "Spent three weeks making it secure, recoverable and maintainable" is not, even though it is the part that protects the business.
Experience is about consequences, not age
This is not an argument against younger engineers. Many are fast and fluent with these tools, and teams that listen to them learn a great deal.
What experience brings is exposure to consequences. If you have been woken at three in the morning by a system nobody could diagnose, sat through a data-loss post-mortem, rebuilt a product after a supplier withdrew a component, or explained to an auditor where some data came from, you ask the questions in the table without thinking. If you have not, they are easy to miss, and AI tools will not ask them for you. They will build exactly what you asked for, confidently and quickly.
The best teams combine both: the speed of people who are fluent with the new tools, and the judgement of people who have seen what happens after the demo.
A simple gate between hobby and professional
The fix is not to ban the weekend build. It is to make the move into production a deliberate decision, with a short gate that every system passes through, however it was written.
- Name it. Keep a register of the tools and systems people have built, especially with AI. You cannot manage what you do not know exists.
- Decide when it matters. Agree the trigger that turns a prototype into a production system: real customer data, a link to another system, or a process the business depends on.
- Ask the questions. At that point, go through the table above with someone experienced who did not build it. Most of the answers can be short. None can be "we don't know".
- Give it an owner. A named team, not an individual, with the time to maintain it.
- Rebuild if needed. Sometimes the honest answer is that the prototype proved the idea and should now be rebuilt properly. That is not failure. It is what prototypes are for.
When I built my own AI readiness assessment recently, I used AI coding tools heavily, and the code came quickly. The time went on the decisions: what the AI is and is not allowed to decide, what gets sent where, how every AI-written output is checked before anyone sees it, and what happens when the model is unavailable. That is the professional system. The code was the easy part.
The question to ask
When someone proposes a new system, or a replacement for one that works, it is worth asking plainly: who benefits from this change, the business or the people making it? Often the answer is both, and that is fine. Sometimes it is not.
And when someone shows you a working AI-built system, the right response is not "that's impressive" or "that's dangerous". It is: "Good. Now let's make it professional."
For boards and owners: ask which systems the business now depends on that nobody formally decided to put into production. The answer is often surprising.
For IT and engineering leaders: judge a proposed change by what the business gains, and be honest about what the team gains. Protect the unglamorous systems that work.
For experienced engineers: your value is the questions you ask after the demo. Make them a standard gate, not a personal habit.
For anyone building with AI: build freely, and be the first to say when a prototype has become something people rely on.
I would be interested to hear how your organisation decides when a prototype becomes a production system, or whether it decides at all.
Further reading in this series
- AI is not my first rodeo. The full story of the knowledge management system, and six other hype cycles.
- Vibe coding is just another level of abstraction. Why AI-written code is a natural step, not a threat.
- Coding agents need experienced engineers. What the agent does, and what the engineer still must.
- The security of AI-written code. The typical flaws, and how to catch them.
- The AI supply chain. Knowing what your system depends on.
- Running agents in production. Monitoring, evaluation and ownership once it is live.
Catherine Ives-Yim
Chartered Engineer and independent technical adviser, with a lifetime at the bleeding edge of embedded systems, connected products, data platforms and AI-assisted engineering, who has advised clients across the UK, Europe, the Middle East, the Far East, North America and Africa. Based in Leeds.