I think a lot of people still imagine AI coding as opening ChatGPT, asking for code, and copy-pasting the result. That's not really how I work anymore.

The biggest shift for me is that planning matters far more than coding.

Earlier, execution was expensive, so most of the effort went into writing code. Now execution is cheap. I can have an agent implement something in minutes. The hard part is making sure the plan is correct.

Most of my effort goes into thinking through the architecture, edge cases, failure modes, test strategy, and how the change fits into the broader system. If the plan is vague, the agent will confidently implement the wrong thing. The quality of the result is mostly determined by the quality of the plan.

Once I have a plan, I break it into small independent pieces. Each piece should be executable without additional clarification. If an agent needs to stop and ask questions, the task probably isn't broken down enough.

Those pieces become tickets.

Then an agent picks up a ticket and implements it.

The important thing is that the agent isn't operating in a vacuum. I try to give it a good environment to work in:

• Clear architectural rules
• Reusable skills and workflows
• Guardrails
• Hooks for things that must always happen

One lesson that really stuck with me is that instructions are guidance, not guarantees.

At one point I had "always use a git worktree" written in AGENTS.md. The model still ignored it occasionally. When I dug into it, the answer was simple: models can drift from instructions.

So if something absolutely must happen, don't rely on instructions. Enforce it. Put it in a hook, script, validation step, CI check, or some other deterministic mechanism.

If it is important, make it impossible to skip.

Once the implementation is done, the agent opens a PR.

This is where another useful pattern comes in: don't let the same model review the code it wrote.

I usually have one model implement and another model review.

Different models catch different things. They have different strengths, weaknesses, and blind spots. The disagreements between them are often where the real issues are hiding.

A surprising amount of feedback can be handled at this stage before a human ever looks at the PR.

After that, human review depends on what changed.

If the change touches critical infrastructure, security, core architecture, data correctness, or anything with a large blast radius, I want human eyes on it.

For lower-risk changes, I care about two things:

• Does it work?
• Does it follow the architectural rules?

If both are true, I don't think every change needs a mandatory human line-by-line review.

The other thing that has become important is having a written constitution for the codebase.

For me this is usually an architecture document that defines the rules of the system.

For example, if the architecture says inner layers cannot depend on outer layers, then that rule should be written down explicitly. Not tribal knowledge. Not something that only senior engineers know.

When the rules are documented, every agent can follow them consistently.

The workflow ends up looking something like:

Plan → Break into small tasks → Create tickets → Agent implements → Different model reviews → Human reviews critical changes → Merge

What's interesting is how little of my time is spent writing implementation code.

Most of my time goes into:

• Planning
• Architecture
• Reviewing critical decisions
• Improving the harness

And that's probably the biggest change.

The real leverage isn't getting AI to write code.

The real leverage is continuously improving the system around the AI:

• Better plans
• Better skills
• Better guardrails
• Better hooks
• Better architectural rules
• Better review workflows

The better the harness becomes, the better every future task becomes.

That's where most of the compounding value comes from.