Three Workshop Habits That Actually Fixed My AI Coding Workflow

I didn’t leave Miki’s Ardan Labs workshop with a new tool to install. I left with a different way to work.

I’d already been using AI coding agents in my day-to-day work. The code showed up faster. So did the surprises: extra flags nobody asked for, design choices buried in a diff I skimmed, and long threads where the agent seemed to forget what we’d agreed on twenty messages ago. Speed wasn’t the problem. Rework was.

After two days building a small ride-hailing service with agents, I changed three habits. Miki kept stopping to read the plan, challenge the output, and ask why the agent made a decision. That rubbed off. Three things I actually do now, most days, that made the experience feel less like shouting at a very fast intern and more like working with a capable tool I still own.

Key Takeaways

• Plan before code: context, constraints, and passing criteria beat a fast first draft.
• Repo as memory: fresh session per feature plus a lean CLAUDE.md or AGENTS.md beats a bloated chat thread.
• Verify before trust: automated checks, CI, and a real diff review. If it ships, you own it.

1. Plan before the agent touches code

I don’t let the agent write code until context, constraints, and passing criteria are spelled out. I resisted that the longest. It was also the most annoying habit at first.

I used to open an agent, describe the feature, and accept almost whatever it generated. Planning mode felt like overhead. Then Miki mentioned an example from NASA’s defect-cost research in the workshop: catching a mistake in design is dramatically cheaper than catching it in live tests. It gets far more expensive still once it reaches production. Miki wasn’t asking for endless upfront design. Agents amplify whatever clarity you give them. Vague intent becomes vague code, fast.

Now I start in planning mode, or the equivalent in whatever client I use, and structure the prompt around four things from the workshop:

• Context: greenfield handler, refactor, bug fix; what system is this part of?
• Constraints: what not to touch, which libraries, deployment limits
• Non-goals: “auth is out of scope,” “do not edit integration tests”
• Passing criteria: tests that must pass, use cases with expected outcomes

Filling in the four boxes isn’t the finish line. Miki never took the agent’s first plan at face value. I read it, push back on vague passing criteria or scope that crept in, and iterate in planning mode until the plan is tight. Only then do I let anything touch code.

In Miki’s ride-hailing demo, the agent asked sensible questions before coding: where does the timestamp come from, which database, how to handle duplicate IDs. That only happened because planning came first. When I skip that step, I get the same over-engineering Miki called out live, like adding CLI flags for configuration nobody requested.

The place this landed for me was a large set of changes to a long-running pipeline I maintain in a custom agent harness: subagents and skills that pass work through staged steps. On a system like that, a vague plan doesn’t produce a small bug. It produces a broken workflow. I couldn’t afford to discover mid-build that two subagents disagreed on handoff format or that a skill fired in the wrong order. Before anyone touched code, I had the agent map the pipeline in Excalidraw: what would change, how logic would flow, where the risky seams were. When the diagram looked right, we turned it into a phased plan with explicit completion markers and tests at the end of each phase. That felt slow for the first hour. It was nothing compared to unwinding a bad orchestration change across a dozen moving parts.

Planning doesn’t slow me down. It prevents the “wait, why did you do that?” loop that burns an hour.

2. Treat the repo as the agent’s memory, not the chat thread

I start a fresh session per feature and keep a short CLAUDE.md or AGENTS.md in the repo. The thread is temporary. The repo is what the next session actually reads.

I used to pile everything into one conversation. New feature, bug fix, refactor, all in the same chat. Every message sent the whole history back to the model. That’s the context window: the conversation plus whatever files you attached. It gets noisy fast. By day two of the workshop, Miki was also pushing decisions into the repo instead of letting them live in chat logs and random markdown files nobody would open again.

These days I do two things:

• Fresh session per feature. When I finish a design pass or ship a slice, I start a new thread for the next task. Same repo, empty chat. It feels wasteful at first. Then the agent stops reopening arguments from three features back.
• A lean CLAUDE.md or AGENTS.md. How we build, how we test, the libraries and patterns I’d rather stick to, what’s out of scope. If I’m typing the same instruction in every new chat, it belongs in that file instead. Miki said to keep it around five hundred words because it loads on every request. When I change how the project works, I tell the agent to update the file so I’m not re-explaining the same rules tomorrow.

One rule I put in there myself: drop parenthetical asides in generated code and comments. Fine for a human reader. Often a mess for an agent parsing a long file. I like short sentences better than nested qualifiers.

On that pipeline refactor, I quit trying to drag the whole project through one thread. At each phase boundary I’d open a fresh chat with the phased plan and a handoff from the previous agent. Same repo, none of the old fights about naming we’d already settled.

The agent wakes up with no memory. The repo doesn’t have to.

3. Verify before you trust, and own the merge

I put the bar in automated tests and CI, not in prompts, and I review the diff for decisions, not just syntax. If it ships with my name on it, I own it.

The workshop opened with a line from an old IBM training manual: computers cannot be held accountable, so they must not make management decisions. Substitute “language model” and the point holds.

Automation over politeness. Miki was blunt: agents usually follow instructions in markdown and skills, but every so often they ignore them completely. Not maliciously. Probabilistically. I used to nudge the agent in chat to run the linter or clean up failing tests. Sometimes it listened. Often it didn’t, or it got it right once and drifted the next time. Now the checks live in the repo: a test command, CI, whatever actually gates a merge. I run that before I spend much time reading the diff. If something fails, I’m not arguing about style. I fix it or ask for another pass.

Miki’s hierarchy went further. Hooks and permission settings enforce what markdown can’t. A PreToolUse hook or a “don’t ask again for make test” permission survives when the model drifts. I lean on CI first because it’s portable across clients, but the lesson is the same. Enforcement beats politeness.

That same lesson pushed me to treat skill files like budget, not decoration. Skills load into context on every request, and Miki warned that long rules plus skills plus MCPs blow up the window fast. I wrote a small skill whose only job is to strip marker comments from my other skills: the human-readable section headers and callouts I used to sprinkle through for my own sanity. They cost tokens every turn and I couldn’t count on the model weighing them reliably. Leaner skills, fewer tokens, less noise. Deterministic checks still beat polite markdown when the stakes are high.

Review for decisions, not just syntax. I’d been handing over small changes because the diff looked fine. “It’s just logging.” “We can fix flags later.” Then in the workshop we watched the agent tie API types to storage types in ways that would hurt the next feature, or leak raw errors to HTTP clients. Now I ask: did it add configuration I didn’t ask for? Is this a vertical slice I can run end-to-end? I’m not doing full manual rewrites. I’m doing the review I’d expect on my own PR before anyone else sees it.

On that same pipeline work, the phase markers were the guardrail. I didn’t merge a phase because the agent said it was done. I ran the tests we’d agreed on at that boundary, read the diff, and only then opened the next session with an updated handoff. Same discipline as a small handler in the workshop, just stretched across a pipeline that runs longer.

Try it for a week

The workshop didn’t teach me to type better prompts. It taught me to run agents the way I already build software: plan with constraints, persist decisions in the repo, verify before merge.

If you’re a Go developer already using agents and feeling the same friction (fast output, slow trust), try one week of:

• Plan first: context, constraints, non-goals, passing criteria
• Repo as memory: fresh session per feature, short AGENTS.md/CLAUDE.md you maintain
• Verify before trust: run your checks and CI, then read the diff like you own it

You might not need more AI. You might need less chaos.

Based on Miki’s Ardan Labs workshop, Practical Go Development with AI Agents.

Bridging the Gap

Featured · 2-Day · Online Workshop

Practical Go Development with AI Agents

with Miki Tebeka

September 16th & 17th, 2026 2 sessions · 4 hours each

Reserve Your Seat View Workshop

These habits aren’t clever prompt tricks. They’re the same engineering discipline you already use for production Go, applied to agents: clear constraints, durable decisions, and verification before merge.

That is exactly what Miki’s workshop is built around.

Over two days, engineers build a real service with AI agents while practicing planning, context engineering, project rules, skills, MCPs, and review habits that keep you in control of what ships.