Featured · 2-Day · Online Workshop
Practical Development with AI Agents
with Miki Tebeka
September 16th & 17th, 2026
2 sessions · 4 hours each
## 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 Development with AI Agents](/workshops/practical-go-development-with-ai-agents/).
---
## Bridging the Gap
Featured · 2-Day · Online Workshop
with Miki Tebeka
Preview the workshop
This webinar is a preview of the hands-on Go and AI agent work you will do across both sessions. This includes planning, context engineering, skills, MCPs, and building real services with solid engineering practices.
Agents amplify whatever clarity you give them. Spelling out context, constraints, non-goals, and passing criteria before implementation reduces rework, over-engineering, and the "why did you do that?" loop that burns hours later.
Keep it lean: how you build and test, preferred libraries and patterns, and what is out of scope. If you repeat the same instruction in every new chat, it belongs in that file. Aim for roughly five hundred words so it stays useful when loaded on every request.
Long chat threads fill the context window with old decisions, unrelated files, and settled arguments. A fresh session per feature keeps the agent focused, while the repo and project rules carry the durable memory forward.
Agents usually follow markdown instructions, but they ignore them probabilistically. Checks that live in the repo—tests, CI, hooks, and permission settings—enforce standards when polite reminders in chat do not.
Run automated checks and CI first, then review the diff for decisions—not just syntax. Ask whether the agent added unrequested configuration, whether the change is a vertical slice you can run end to end, and whether you would merge it under your own name.
Go developers already using coding agents who want less rework and more control. The workshop focuses on planning, context engineering, project rules, skills, MCPs, and verification habits—not just better prompts.
Over two live online days, you build a real Go service with AI agents while practicing planning mode, context engineering, AGENTS.md/CLAUDE.md rules, skills, MCPs, TDD, and code review practices that keep engineering judgment in charge of what ships.