Skip to content
AI6 min read

Using AI as a Build Tool, Not a Shortcut

The useful divide isn't 'AI or no AI' — it's which parts of the work are mechanical and which parts need judgement. Getting that line right is most of the skill.

Muhammad Fajar Ariandi

Designer, Developer & IoT Engineer

There's a version of the AI conversation that's about whether to use it at all. That framing is a dead end. The question that actually changes your output is narrower: which parts of this work are mechanical, and which parts need judgement?

Mechanical work is anything with a verifiable answer

Configuring a router has a correct answer. So does a regex, a Dockerfile, or the twentieth variant of a card component. These tasks share a property: you can tell whether the result is right without much argument.

That's exactly the work worth handing over. Not because it's easy — some of it is fiddly — but because the cost of being wrong is low and the feedback loop is fast.

Judgement work is where the value is

The opposite end: deciding what the product should do, choosing what to leave out, working out why a user is confused. There's no verifiable answer, which means there's nothing for a model to check itself against.

This is where attention pays. And the practical benefit of handing off the mechanical work is that it frees exactly that attention.

The failure mode

The failure I see most often isn't bad generated code. It's generated code accepted without reading, in a domain the person doesn't understand well enough to evaluate.

The rule I use: don't delegate work you can't review. If I couldn't spot a subtly wrong answer, I'm not delegating the task — I'm outsourcing the understanding. That's the difference between moving faster and accumulating debt.

Speed you can't verify isn't speed. It's just debt with a shorter feedback loop.

What this looks like in practice

A concrete example from a recent project. I needed a set of components with consistent spacing and accessible states across a fairly large surface.

  • Delegated: the repetitive variants, the boilerplate, the first pass at edge-case states.
  • Kept: the token decisions, the component API, what the states should be, and every review.
  • Result: roughly a day of work compressed into a few hours, with the design decisions still made deliberately rather than by default.

The output quality was the same or slightly better — mostly because the mechanical parts got consistent attention instead of whatever was left at the end of a long day.

The honest caveat

None of this makes hard problems easy. It makes tedious problems fast. If the bottleneck is thinking, no tool removes it — and treating AI as a way to skip thinking is the fastest way to ship something you don't understand.

Working on something like this?

I'm available for freelance projects and full-time roles.

Get in touch

Related articles