Build log/2026-07-24·3 min read

How Much of AI Coding Can You Actually Hand Off to AI?

AI Agent 负责执行,开发者负责最终判断的工作流程图

Lately I've been leaning more and more on AI agents like Claude, Codex, and Hermes to write code.

At first it's genuinely exciting: they can read code, fix bugs, write tests, and fill in docs. Stuff that used to eat up half a day now moves forward in a few rounds of chat. But the longer I work on real projects, the more I think one thing needs saying clearly: AI can speed up development, but it can't take responsibility for me.

What AI is good for: execution-heavy work

AI works best on execution-heavy work like breaking down tasks, repetitive code, debugging, and organizing context

There are a few kinds of work I hand to AI most often.

  • Breaking down tasks. Which files a feature touches, which code paths it affects, what tests need adding. AI is great at producing a first-pass checklist.
  • Writing repetitive code. API adapters, form fields, data transformations, error handling. None of it is hard, but it drains your attention. AI writes the first draft, and I review it.
  • Debugging. When something throws an error, having AI dig through the logs and context for likely causes is honestly faster than me staring at it.
  • Explaining and organizing. Why some old code was written a certain way, what a function might affect, how to fill in tests. AI helps me lay all the context back out on the table.

What these have in common: the goal is fairly clear, and if something goes wrong, tests, logs, or a human review can catch it.

What AI can't own: the final call

The real danger isn't AI getting a line of code wrong. It's AI confidently pointing you in the wrong direction.

I'm especially careful with this when building a restaurant SaaS like MakanCloud. Ordering, central kitchen, delivery, staff scheduling, POS, QR-code ordering: every piece maps to how actual restaurants run day to day. Code that runs doesn't mean the business flow works.

So there are a few things I never hand off.

  • What problem users are actually hitting: I decide that.
  • Whether a flow fits the real-world scenario: I walk through it myself.
  • High-risk areas like permissions, data, config, payments, and releases: I verify them myself.
  • Whether AI's proposed approach holds up for long-term maintenance: that's my call.

My actual workflow

The developer defines the problem and boundaries first, then lets AI implement and help investigate issues

These days I think of AI as a really strong execution partner, not an "autonomous developer."

My process usually goes like this: I define the problem and its boundaries myself, then ask AI for a plan. Once I've picked a direction, it implements. After that I read the diff, run the tests, and check the business paths. If something breaks, I bring AI back in to help track it down.

It's not magic, but it's solid. It solves the most practical problem an indie developer has: you're one person with limited time and energy, and the project still has to keep moving.

AI lets me ship faster, but it also forces me to be much clearer about what I'm actually doing.

A simple rule of thumb

When I'm deciding whether to hand something to AI, I ask myself one question: if this goes wrong, who pays for it?

If it's a first draft, boilerplate, an explanation, or help with debugging, I'll use AI without hesitation.

If it touches user experience, business decisions, data security, or production stability, I always check it myself.

The core question of AI coding isn't "do humans still need to write code?" It's whether humans are still willing to own the judgment calls. For me at least, the answer is clear: AI handles the speed, I own the outcome.

If you're also using AI to build products or write code, drop a comment. What kind of task do you feel most comfortable handing off to AI right now?