// AI Coding
ARTICLE ID: AIC-MHE-AI
The Many Hats Engineer
AI does not need to replace an engineer's expertise to be useful. The real advantage is using it deliberately to cover the other hats involved in building a product while keeping control of the engineering decisions you understand best.
I know how I want the database designed. I know how I want the application architected. I know where I want the boundaries to sit and which parts of the stack I actually trust.
So why would I hand all of that over to AI?
That is where I think the conversation around AI-assisted engineering gets a little confused. There is a difference between using AI everywhere and using AI deliberately. I am not interested in handing over the parts of engineering I already understand just because an agent can generate something quickly. What I am interested in is using AI to cover the parts of a project where I either need acceleration or where I simply do not have the same depth of expertise.
That is less “vibe coding” and more like wearing several hats without pretending I suddenly became an expert in all of them.
The Parts I Want to Own
When I start building an application, there are areas where I already have strong opinions.
If I know how I want the data model to work, I do not need an agent inventing the database for me. If I already know I want Cloudflare involved in the architecture, or I have a clear idea of where APIs, workers, queues or storage should sit, I am not asking AI to make those architectural decisions on my behalf.
That does not mean AI is useless in those areas. Quite the opposite.
I can still use it to generate boilerplate, investigate implementation details, compare options, write migrations, build repetitive pieces of code, or sanity check an assumption. I might ask it to compare Firebase and Supabase for a particular requirement even if I already understand the broader architecture. The important part is that the agent is accelerating a decision process I still own.
That distinction matters.
The Hats I Do Not Normally Wear
The interesting bit starts when the project moves outside my strongest areas.
A real application does not only need an engineer. It needs architecture, database design, APIs, frontend work, UX, product thinking, copy, marketing, documentation and a dozen other things depending on what you are building.
I can do some of those things well. I can do some of them badly. And there are definitely some where I know enough to be dangerous but not enough to pretend I am the subject matter expert.
UX is a good example. I can recognise a terrible user experience, but that does not make me a UX designer. The same is true for visual design, marketing, positioning and a lot of frontend decision making.
That is where AI becomes genuinely useful to me.
Instead of staring at a blank page pretending I suddenly have ten years of UX experience, I can get an agent to explore flows, produce alternatives, question assumptions, draft copy or identify common interface patterns. I can then interrogate those outputs, test them, throw away the bad ideas and keep moving.
AI gives me breadth without requiring me to pretend that breadth is the same thing as expertise.
This Is Not About Giving Up Control
There is an important difference between delegation and abdication.
If I ask an agent to explore a UX flow, I still need to decide whether that flow makes sense. If I ask it to investigate a technology, I still need to check whether the assumptions are valid. If it writes frontend code, I still need to understand enough about the system to recognise when it has created something fragile, inaccessible or unnecessarily complicated.
The agent can wear the hat for a while. I am still responsible for deciding whether the hat fits.
That is probably the biggest difference between deliberate AI-assisted engineering and vibe coding. Vibe coding tends to reward momentum first and understanding later. I would rather decide which parts of the project deserve my direct expertise, then use AI aggressively everywhere else where it gives me leverage.
AI as a Breadth Multiplier
The biggest value AI gives me is not that it writes code faster than I do.
It is that I can stay focused on the parts of the project where my judgment matters most while still making progress in areas that would otherwise block me.
I can be thinking about the architecture while an agent investigates a frontend library. I can be reviewing a schema while another task explores onboarding flows. I can ask for copy, research or implementation options without constantly switching my own mental context.
That makes one person capable of moving across far more of a project than before.
It does not make me a designer, marketer, product manager and frontend specialist overnight. It just means I can work with those disciplines without every one of them becoming a hard stop.
Retrospective
I do not think the useful question is, “How much AI should an engineer use?”
The better question is, “Where does my own expertise matter most?”
Keep direct ownership of the areas where your experience gives you an advantage. Use AI to accelerate the boring parts, investigate the uncertain parts and provide breadth where you do not have the same depth.
Let the agent wear the extra hats.
Just do not forget which ones are actually yours.