Tech is moving faster than any of us imagined. Blockchain, digital currencies, AI, quantum computing, security threats like never before: it's all arriving at once. Anyone who says it isn't overwhelming isn't being truthful.
So I'll stick to one thing here: AI adoption.
Large corporates that demand AI adoption without understanding the pitfalls are digging themselves a small grave in quality, governance, security and cost. They also forget to ask where their engineers stand. I've spent the past year on the other side of that question, and it changed how I think about all of it.
The boss who vibe-coded
For the past year I've been experimenting with vibe-coding apps, building tools the business needed but we simply didn't have the resource or capacity to deliver.
I've led engineering and product for most of my career, which puts me in a good spot. I know exactly what I want and can articulate it, covering the same ground I'd cover with a whole team of DevOps, engineers, data analysts, designers, BAs and QAs.
My team were not best pleased that the boss was building apps for fun outside the scope of work we'd agreed with the business. Or maybe it was the kudos I was getting from departments whose working lives I was changing overnight, single-handedly.
Single-handedly is its own problem. Who fixes a complicated app built by one person and a bot, when nobody else was involved? How supportable is it? Those trade-offs are real. In practice, though, AI can quickly help you understand an app without knowing the whole thing. And, instructed properly, it documents far better than any engineer, without complaining about it.
What the code reviews taught me
Tools like Lovable are amazing at taking a brief and producing a decent proof of concept, both a design and a working demo. What they don't bring is deep engineering know-how. They leave a lot of questions open on security and DevOps standards, and they keep you fairly tied to the platform.
Every tool I built went through a code review by my team. That turned out to be essential: the engineers always found questionable decisions the AI had made, and they often looked fine on the surface.
Those reviews taught me how to change the way I build with agents. I now use Claude Code in the terminal for about 90% of my work, and Lovable only for early design ideas. The bigger change wasn't the tool, though. It was setting the rules before writing a line of code.
The setup: rules before code
These days every project starts with the same groundwork, before the AI builds a single feature:
- A rulebook the AI reads every session. One file in the repository sets out how we work, what's off limits and what "done" means. The AI starts every session fresh, so anything not written down doesn't exist.
- Separate environments. Local, staging and production are kept fully apart, each with its own secrets. Every change is built and tested locally first, and nothing reaches production without going through staging.
- Pipelines from day one. Deployment, pull requests and checks are set up first, not bolted on later. Every change goes through a pull request.
- Tests the AI must pass, not just write. Unit tests, linting, a local build, security tests, and smoke tests on the sensitive areas such as payments and permissions. Nothing is promoted until they pass.
- A human hand on production. The AI prepares a release; I open, review and merge it myself.
- A review every two weeks, without exception. Each one focuses on a named area, gets logged, and feeds new rules back into the rulebook.
- A memory that survives the session. A short script at the start of each session shows where things were left: open work, open pull requests, the last review date. Decisions go into the docs and get committed, because chat history isn't recoverable.
Now that I'm working solo again, I've had to adapt. I still need a senior engineer in the mix, but I don't have one. So I asked the AI to be one, and gave it the freedom to question my decisions.
The job description
This is the core of the rulebook my AI works to. It's written to the AI, which is why it refers to me in the third person.
- The AI acts as senior engineer; I own the product. It flags problems even when they're outside the task: security holes, data risks, deployment gaps, code that will cause trouble later. Product decisions stay with me, but it gives an opinion when one is worth having.
- Question decisions before acting on them, including mine. If an instruction looks wrong, risky or inconsistent with an earlier decision, it says so before doing the work. If I still want it my way, it does it and writes the decision down.
- Answer before acting. When I ask a question, it stops, answers plainly and waits. No batches of changes while a design question is still open. Work goes in small, reviewable steps.
- Be honest about limits. It says when it's unsure, hasn't checked something, or a test failed. For anything touching money, personal data or production, "how do you know?" must be answered with code, a test or a check, not say-so.
- Know your blind spots. It only sees the files it opens, starts each session fresh and can be confidently wrong. The rest of the rulebook exists to cover those gaps.
- Pushing is not deploying. It checks the live behaviour, not just that the code went up.
- Don't trust what another tool did. Check the history before rebuilding or "fixing" anything.
Almost every one of these rules exists because something went wrong, or nearly did. They're written in blood.
Adopt the guardrails first
So where does that leave the corporates rushing to "adopt AI"?
The AI was never the hard part. It's quick, tireless and surprisingly good. The hard part is everything around it: the reviews, the pipelines, the rules, and the discipline to keep asking "how do you know that works?" Most of my rules came from engineers picking apart code that looked fine on the surface.
That's what leaders miss. Telling a team to "use AI" without changing how work is reviewed, tested and deployed just gets you mistakes faster. Engineers aren't the obstacle to adoption; they're the reason it works. Their job shifts from writing every line to setting the standards, reviewing what the AI produces and catching what it gets confidently wrong.
And my advice to any engineer who's holding back on AI, or who says "I can do it better"? Many engineers love writing code. It's like a musician playing their instrument: it gives them joy. But technology evolves, and we're constantly being given new tools to improve what we do.
See AI as one more instrument to play. It doesn't have to stop you doing what you love most. Keep the parts you enjoy and let it handle the parts you don't. For research and examples it's become invaluable, and for testing and deployment it's a must in my book. Wherever you choose to use it, it can help.
If you're solo like me, you still need that senior voice in the room. Write it down, give the AI the job, and give it permission to tell you you're wrong.
Adopt AI, by all means. Just adopt the guardrails first.