AI-Assisted Development With Engineering Discipline

AI coding agents can now read a repository, plan a change, edit dozens of files, and run the tests. Used carelessly, they produce confident code that nobody on the team fully understands. Used with discipline, they let one engineer deliver what used to take a small team — without lowering the bar.

This is the workflow I use with Claude Code on client projects: ERP modules, HR systems, e-commerce, and React Native apps. The tools will change. The discipline is what makes the output trustworthy.

Give the agent a constitution

Every repository gets a project instruction file — CLAUDE.md — that the agent reads at the start of every session. Mine always answer the same questions:

• What is this product, and who uses it? One paragraph is enough.
• What is the source of truth? For example, "the web app defines behavior; mobile mirrors it, but never copies a bug."
• What must never happen? No secrets in code, no deploys, no destructive database commands, no new libraries without asking.
• How do we communicate? I talk with the agent in Indonesian, but everything inside the codebase — names, comments, commit messages — is professional English.
• What counts as done? Type check, lint, build, and the specific tests for the change.

Short, specific rules beat long essays. If a rule matters, write it as an instruction the agent can follow, not a value it should "keep in mind."

Write the spec before the code

For anything bigger than a one-line fix, the agent first writes or receives a spec: the goal, the scope, what is explicitly out of scope, the data model changes, and acceptance criteria. I review the spec, not the first draft of code. Fixing a wrong assumption in a paragraph takes a minute; fixing it across fifteen files takes an afternoon.

Specs also become reusable skills. Instead of re-explaining "how we build an admin CRUD page" in every session, a skill file captures the conventions once — layout, validation, empty states, permissions — and the agent loads it when the task matches.

Keep tasks small and scoped

Agents are strongest on well-bounded tasks: "add a paid flag to invoices with a summary on the list page," not "improve the invoicing module." Small tasks keep diffs reviewable, make failures cheap, and let me choose the right level of model effort for each piece of work.

Verify everything, trust nothing

"It compiles" is not done. Every change goes through gates before I accept it:

1. Static checks — tsc --noEmit and ESLint with zero warnings in the touched files.
2. Production build — some errors only appear in the optimized build.
3. Behavior — unit tests where logic lives, and an end-to-end run in an isolated environment: a separate database and separate ports, so tests never touch a developer's running servers or real data.
4. Reading the diff — every line, the same way I would review a colleague's pull request.

When the agent claims something works, I want to see the command and its output. When a check fails, the fix is part of the task, not a follow-up.

Make memory explicit

Long tasks outlive a single session. Context windows fill up, sessions restart, and sometimes the work moves to a different account or a teammate. Instead of hoping the agent remembers, I make memory a file:

• docs/PROGRESS.md — phases and checkboxes, updated after every task.
• docs/DECISIONS.md — decisions with the reason and the date.
• docs/HANDOVER.md — what was just done, commit hashes, what is pushed, and the exact next step.

The rule is simple: update these after every completed task, and stop for a full handover when the session's token usage reaches roughly 92–95%. A new session then starts with "read CLAUDE.md and HANDOVER.md, continue with the next step" and loses nothing.

Connect the tools the team already uses

Through MCP (the Model Context Protocol), an agent can work with the same tools as the team. I connect Notion so the agent creates or updates a task when work starts, and writes a structured report when it finishes: what changed, how it was verified, and what is left. The project manager sees progress where they already look, without asking for status updates.

Keep humans on the irreversible decisions

Some actions stay human, always:

• Committing and pushing code, and especially deploying.
• Anything destructive: dropping data, force-pushing, deleting files outside the task.
• Product decisions: what to build, what to cut, what "good enough" means for this client.

The agent proposes; I decide. That is also why credentials never go into prompts or config files the agent writes. If a task needs a secret, the human runs that step.

What changes for the team

With this workflow, my role shifts from typing to designing, reviewing, and deciding. Delivery gets faster because research, scaffolding, refactors, and regression checks run in parallel with my thinking — not instead of it.

AI does not replace engineering judgment. It multiplies whatever judgment you bring. Bring specs, checks, and clear boundaries, and it multiplies quality. Bring none, and it multiplies the mess.