anukamithara.com

How I Use AI Coding Agents Without Outsourcing the Engineering

How vibe coding fits into my workflow without giving up architecture, judgment, testing, or ownership

By

AI coding agents are part of my development workflow.

Some of the implementation work in personal projects such as Kapuru and Office Escape was accelerated through what people now casually call vibe coding.

I am comfortable saying that because I do not think the useful distinction is "hand-written code" versus "AI-written code" anymore.

The distinction I care about is:

Who understands the system, makes the decisions, validates the result, and owns what happens when it breaks?

For me, AI is part of the development workflow. It is not a replacement for engineering ownership.

What vibe coding means in my workflow

The phrase can mean very different things.

At one extreme, it can mean describing an idea, accepting whatever the model generates, and stopping when the UI looks correct.

That is not how I use it.

My normal workflow looks closer to this:

problem / requirement
        ↓
clarify constraints
        ↓
choose architecture
        ↓
use an AI coding agent where it helps
        ↓
review behavior and assumptions
        ↓
test real flows
        ↓
inspect failures
        ↓
iterate
        ↓
preview deployment
        ↓
production verification

A coding agent can produce substantial implementation code for a task, but I still own the sequence above.

That changes the skill from "prompting" into something much closer to software orchestration.

Requirements matter more when code becomes cheap

A coding agent can implement a vague idea very quickly — including the wrong interpretation of that idea.

So I spend more time making requirements explicit before asking for implementation.

I try to define things such as:

  • what the user should be able to do
  • what should happen at boundary conditions
  • which state is authoritative
  • what should happen after reload or reconnect
  • what must work offline
  • what security boundary must not be crossed
  • what "done" means in tests

The faster code can be produced, the more expensive ambiguity becomes.

That was very visible while building Office Escape. A feature like "show the remaining work time in the browser tab" sounds tiny until the tab is backgrounded, the browser throttles timers, the PWA is installed, the extension popup opens independently, and an overnight shift crosses midnight.

A coding agent can help implement those cases. It cannot decide which behavior is correct unless I first define the contract.

I delegate implementation, not responsibility

There are tasks where AI assistance can save a lot of time:

  • repetitive component implementation
  • CRUD plumbing
  • refactors with a clear target shape
  • test generation
  • type fixes
  • UI iteration
  • repetitive API integration work
  • documentation updates

Then there are decisions I do not want to delegate blindly:

  • data ownership
  • authentication boundaries
  • authorization rules
  • multi-tenant isolation
  • irreversible operations
  • service boundaries
  • synchronization semantics
  • failure behavior
  • migration strategy

An AI agent can propose all of those. I often ask it to.

But a proposal is different from authority.

The most valuable skill is catching a plausible wrong solution

AI-generated code often fails in a dangerous way: it looks reasonable.

A syntax error is easy to catch.

A route transition that checks the old DOM, a React effect that quietly creates an API loop, or a retry path that can duplicate a write is harder because each individual piece can look correct.

I have run into exactly those kinds of issues.

That is where engineering experience becomes more valuable, not less.

I ask questions such as:

What assumption is this code making?
Who owns this state?
What happens if this runs twice?
What happens when the request times out?
Can the old page satisfy this condition before the new page renders?
Is this operation idempotent?
What happens if the process restarts halfway through?

Those questions are usually more important than who typed the final code.

I use the agent as a collaborator during debugging

When something breaks, I do not simply ask the agent to "fix it" repeatedly.

I try to narrow the failure first.

A useful debugging loop for me is:

observe symptom
    ↓
collect evidence
    ↓
form a hypothesis
    ↓
ask the agent to inspect the relevant path
    ↓
compare its explanation with runtime behavior
    ↓
change one boundary
    ↓
re-test

A coding agent can be useful for reading a large amount of code quickly and proposing connections between files.

But runtime evidence still wins.

If the implementation says a flow should work and the browser says it does not, the browser is right.

Preview deployments are part of the workflow

I prefer:

branch
→ pull request
→ preview build
→ validation
→ merge
→ production deployment
→ production verification

This gives AI-assisted changes a real gate.

A successful code-generation session is not the same as a successful deployment.

Build systems catch type problems. End-to-end tests catch integration problems. Preview environments catch UI and environment differences. Production verification catches assumptions that survived everything else.

Vibe coding without those gates is fast.

Vibe coding with those gates is useful.

Kapuru was a good example

Kapuru combined several systems that are easy to demo independently and harder to make reliable together:

  • multilingual conversation
  • real-time voice
  • product-search tools
  • memory
  • cart state
  • checkout preparation
  • image input
  • authentication
  • Supabase data access

AI-assisted development helped speed up implementation and iteration.

But the hard questions were architectural:

  • how much conversation history should the model receive?
  • when should durable memory become visible?
  • how large can tool results become?
  • what happens when a tool hangs?
  • where does authorization live?
  • what requires explicit user confirmation?

Those are system-design questions, not just code-generation questions.

Office Escape was another example

Office Escape began as a small countdown and became a web app, PWA, and browser extension with shared user state.

AI-assisted development made it possible to iterate quickly.

That speed also exposed problems faster:

  • timer drift under browser throttling
  • extension and web state disagreement
  • cloud-sync request loops
  • service-worker lifecycle issues
  • shortcut behavior
  • mobile UI problems
  • overnight and overtime transitions

The workflow became repetitive in a good way:

implement
→ test
→ find an edge case
→ clarify expected behavior
→ redesign the boundary
→ implement again

The code was not the scarce resource. Clear reasoning was.

I do not measure skill by percentage of code typed manually

If a coding agent can save time on an implementation task, I will use it where that makes sense.

I would rather spend the saved time on:

  • architecture
  • edge cases
  • performance
  • security
  • tests
  • product decisions
  • observability
  • another useful feature

The metric I care about is not:

How many lines did I personally type?

It is:

Can I explain the system, change it safely, debug it under failure, and take responsibility for the outcome?

The skill I am developing is AI-native engineering

I still use the term vibe coding because it is recognizable and because sometimes the workflow really does feel like rapidly steering an implementation through conversation.

But the capability I want to get better at is broader:

AI-native software development.

That includes:

  • decomposing work for coding agents
  • giving them enough context without drowning them
  • defining implementation boundaries
  • evaluating generated architecture
  • reviewing assumptions rather than only syntax
  • building validation loops
  • using tests and deployment gates
  • knowing when to take control manually

Coding agents are getting better at producing code.

That makes the engineer's responsibility move upward: from typing every implementation detail toward defining systems, constraints, verification, and direction.

I do not see that as less engineering.

I see it as another engineering skill I intend to keep improving.

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

© 2026 Anuka Mithara. All rights reserved.

GitHubLinkedInanukamithara.com
Close Menu