Put Me In, Coach!

In my last post I wrote about the history of what we now call "agentic" coding... basically going back over the 25 years of my personal experience with trying to get the computer to take the drudgery out of natural language programming, which itself was an attempt to get the computer to take the drudgery out of machine language programming. But that's another story for another time.

In that post, I went from "vibe" coding... the idea that you surrender the work of writing actual code to the LLM (Claude, Codex, etc.) and just feel your way to whatever final result you like... to "loop" and "graph" coding, which you could either define as "vibe coding with more steps" or as a more "human-in-the-middle" process where the developer remains an active participant in the design, architecture and decision-making.

But there's something related to these methodologies... maybe it's better to say related to them but on a different axis... that I wanted to mention in this post. This is how I explain what good agentic coding looks like to lay people (and occasionally, without realizing it, to people who know a lot more about the process than I do!)

Shall We Play a Game?

Imagine you're the coach of a Little League baseball team. If you're not familiar with Little League baseball, imagine a bunch of nine-year-olds who want to look cool and have fun but who really don't know anything about the history, rules or subtle playing techniques of baseball... but they do know if they make it to the end of the game somehow without too much embarrassment and crying, they'll get sno-cones. Do you kind of see where I'm going here?

As the coach, you can absolutely pick twelve or fifteen kids of roughly the same age and size, fit them with caps and uniforms, give them bats, gloves, helmets and a few baseballs, then set them loose on a perfectly groomed baseball diamond and they will play a game. It won't be baseball... though it might look like it at first... but they will have fun. They'll toss the ball around, run this way and that, yell and laugh a lot and throw themselves into the grass and dirt just for the sake of making a mess. It's a near certainty that at least one of them will hit another one in the head with a bat... hopefully the one wearing the helmet.

If you choose to do this, you may have some amused parents, likely a few very upset ones, and definitely a scorekeeper who isn't sure what numbers to put up on the board. And when the kids are all tired out and you end up declaring the game a wash, they're definitely going to expect to get those sno-cones. And probably a pizza party too, if you make them do it more than a few times over the course of the summer.

The other extreme alternative, of course, is for you as the coach to be so strict with the kids about what they're supposed to be doing that no game gets played at all or, worse, you go out onto the field to "show them how it's done" and end up doing all the "playing" yourself... and likely getting into a fight with one of the parents who has invested real money in sponsoring the team and a lot of emotion in seeing his kid get into the major leagues.

Neither of these approaches is in any way ideal, and neither will produce outcomes that are likely to get your Little League baseball team funded for another season. So as a good coach, you take the middle approach... you identify which kids best represent which skill (hitting, pitching, fielding, etc.), practice those skills with the kids, teach them the rules (simple ones at first, of course) and, most importantly, instill in them the values of sportsmanship, teamwork, and resilience in the face of defeat. And maybe, over time, they learn the game... and if you're lucky, you might find yourself a star who really does have a chance to go to the majors.

Coach Coding

Sure, you can sit at your desk with a nice cup of coffee and watch the chaos unfold in your IDE, hoping somehow it will turn into a shippable app if your LLM just keeps trying to one-shot your single-paragraph requirements doc for long enough, or you fan out enough agents and spend enough tokens checking and cross-checking each other's work. And sure, you could also rage-quit your Claude Max account and commit to going back to coding C++ yourself by hand. But there is a better way... you don't have to depend on the "get the LLM to do all the work" approach with vibes, token maxing with loops and graphs, or waiting until the models learn how to code correctly to get good work done.

If you're doing it right (and yes, that's my opinion), what you should be doing is entrusting the playing of the game to the LLMs... clueless, hopeful and sometimes apparently happy to lie to you about what they're actually doing... while you spend your considerable skill and brain power guiding them to the results you seek.

This is Coach Coding... and the trick is that it asks more of you than simple baseball skills. It's no longer enough to be able to properly authenticate to API endpoints or to manage database migrations or hand-write a CORS config or IAM policy in perfectly formatted JSON. Now you have to be able to envision the entire project... work with the client or potential end users to decide what needs to be built, write meaningful requirements docs, forge contracts between builders and testers, review and verify functionality, be aware of and recognize security concerns, configure a deploy pipeline and manage environment changes... all the stuff in between the code where LLMs either aren't technically capable enough yet, or their capabilities simply don't apply at all.

An Example from My Own Work

I am just now in the process of putting the finishing touches on a project named Eero, my custom internal tool for adversarial agentic coding which may best be called a "contract engine." The objectives of the tool are pretty clear... two separate LLMs working on the same project, one building, the other testing, with me as the architect sitting in the middle, deciding what is to be built and what it's to look like when it's completed, and managing the flow of information between the two sides to maintain the appropriate level of opacity between them so that they both have to work from the contract, not from what the other is producing.

Now I suppose I could have told Claude Fable 5 to "fan out a bunch of agents to build me a tool that does adversarial agentic coding and keep looping until it works and there are no errors," but I can't imagine how many tokens that would have consumed or what I would have gotten at the end.

What I did instead was immediately connect the concept with an experience from my own childhood... visiting the St. Louis Gateway Arch and seeing how it was built. Using this mental framework, I worked together with Claude to map out the core principles of adversarial agentic programming "on paper" and then tested them against real project work by writing out the steps, adjusting them as the realities of the work came to light, holding onto what made sense, throwing out the parts that didn't, and finalizing the experience as a set of discovery documents.

From this I crafted a language for how I wanted to talk about the process and then, again with Claude's help, built out 62 kanban cards across nine milestones to define the project using my own kanban tool "Tanzaku." Each card contained its own workable contract with its workability readiness... a score for how well defined and ready to build and test the work is, measurable against my own contract model. Then I set Claude to work building the tool using the process the tool would ultimately encode... including a visual metaphor for the construction of the "arch" that was each workable card.

The Extra Matters

Is this the most efficient way to build an app? No, it is not. Each card's build took what felt like 3 to 5 times longer than it would have taken to vibe code... but the adversarial pairings landed clean a surprisingly high percentage of the time, with most issues being related not to the code itself but rather to environmental variables outside of the scope of the specific cards being worked (which was itself a useful finding).

And then when the mechanics of the work were done, there was still the visual styling and program flow, which I am going over with a fine-toothed comb now to make sure Eero communicates properly with my kanban board, looks and feels consistent with the rest of my tool fleet, and captures the workflow in a way that makes sense to me and the way I work.

No amount of vibe could accomplish either the concepting portion or the finishing portion of the work. Not at this point in history, at least.

The Big Show

So will Eero make it to the majors? I don't know. I'll use it in my own work and maybe I'll demo it to someone somewhere, ideally before we move on entirely to Ephemeral Code (where machines just create whatever software tools we need in real time and then delete them when we're done), but it's already proven its value... not only in the quality of work it's produced on its own, but also... and this is the key for Coach Coding... in the learning and understanding I've gained from helping to build it.

If coding has gotten boring for you because "LLMs can do it all / LLMs are garbage," then I invite you not to rethink the role of LLM-based coding tools in your work, but rather to rethink your own role. More about that in my next post.