The robot can type, but I’m still the driver

The robot can type, but I’m still the driver

Embracing AI as a UI engineer without letting it drive


Let's get this out of the way: I use AI every day as a UI engineer (it's been a slippery slope), and I'm not embarrassed about it. Claude, ChatGPT, whichever one happens to be open. I've found them fairly interchangeable for my Vue work, whether I'm using the desktop apps, the CLI or a VS Code plugin. They're all good. Genuinely, properly good. That said, I barely use it in my personal life, unless you count a certain popular search engine shoving its AI's opinion at me before I've even asked.

But "good" and "in charge" are two very different things, and the trick is keeping them apart.


Where it absolutely shines

Having a mess about. That's what I call it, anyway. If you've ever wanted to try a new tech stack but couldn't face an evening of setup, config files and that one dependency that refuses to cooperate, AI is a revelation. Proofs of concept that would have taken me a few days now take an afternoon, sometimes with time left for a cuppa. For prototyping it's brilliant: you get something on screen quickly, have a mess about, poke at it, throw it away, and try again. Nobody's precious about throwaway code, least of all the robot.

It's been great across a surprisingly wide range of UI work, and it's a handy debugging buddy too: the robo-rubber-duck. Sometimes just explaining the problem to something that answers back is half the battle. The other half is it spotting the typo you've stared past fourteen times.

Performance work? It's... fine. It gets there in the end. It'll suggest sensible things for page load speed, like lazy loading and splitting bundles, but it doesn't know your app, your users or that one ancient component nobody dares touch. Treat its suggestions as a starting point, not a diagnosis.


Production is a different beast

Here's where I get cautious. A prototype can be held together with tape and optimism. Production code can't. It has to be readable by your colleagues, maintainable by future you (who will be grumpy and short on context), and it has to actually work, not just look like it works.

AI is very good at producing code that looks right. That's the danger. It'll confidently hand you something plausible, and if you're tired or rushing, plausible slides straight through review. So production use becomes a balancing act. You read every line. You understand every line. If you couldn't explain it to someone else, it isn't going in.


There's no single rule

The honest answer to "how much AI code should I use?" is: it depends. Annoying, I know. But every project, feature, bug and function deserves a slightly different approach. A quick internal tool? Let it do the heavy lifting. A gnarly accessibility issue in a core component? Maybe use it to talk through ideas, then write the fix yourself. Like most good things (chocolate, coffee, Bake Off), it's best in moderation.

For anyone still levelling up (which is all of us, really)

This bit's for the engineers on my team, and honestly anyone who's still learning (so, everyone). AI is a fantastic tool for getting unblocked and for learning. Ask it why something works, not just how to make it work. Use it to explore an unfamiliar API or untangle a confusing error message.

But be honest with yourself about the trade-off. Every time it solves a problem for you, you've skipped a chance to solve it yourself. Sometimes that's exactly the right call, because the deadline's real and the project needs to ship. Other times, the struggle is the point, because that's where the knowledge sticks. The goal is to deliver work to a good standard and keep growing as an engineer, not to trade one for the other.


The bottom line

AI is the best pair programmer I've ever had who doesn't need biscuits. The downside? You don't get the random side chats about video games and music etc. But it's a pair programmer, not the lead. Let it type, let it suggest, let it rescue you at 4pm on a Friday. Just make sure you're the one who decides what ships.

You're still the engineer, and the work is still yours. You are responsible for it. 



← Back to blog listings

© 2026 olly shenton's portfolio