How Kenn is doing Agentic Engineering in August 2026 – Wes McKinney

We have had our heads down building and working toward launching Kenn Software’s product offerings later this year, but in the meantime, I wanted to give some insight into how our agentic engineering process and culture have evolved since the beginning of the year, and what a work day for us looks like. We merge hundreds of pull requests per week into our projects with a team of three people, and yet have an empirically low bug rate across millions of lines of production code.

A couple weeks ago, after being drowned in posts about “loop engineering” and “graph engineering” on X/Twitter and LinkedIn, I posted on my X account:

I think loops are bullshit

Wes McKinney (@wesmckinn) July 22, 2026

I stand by this. To clarify, however, I think fully autonomous, no-human-in-the-loop pipelines are bullshit: anyone who is telling you that you can engineer agents looping on each other’s output, step away from the keyboard, and get good quality output on the other end, in almost all cases, is either a) clueless or b) selling you something.

That being said: I burn a lot of tokens. I am regularly at the top of one prominent token leaderboard. As of this writing, at API rates I would be paying $56,836 (as reported by AgentsView) for my last 30 days of consumption if not for subsidy provided by coding agent subscriptions. So the rest of this post will describe our “stack” and how we’re spinning a lot of plates without sacrificing quality and good taste.

“Planning, Architecture, and… Caring about the Output”

Jesse Vincent, creator of the megapopular Superpowers framework, described the difference between “vibe coding” and “agentic engineering” as “planning, architecture, and… caring about the output”. On the Kenn team, we put it bluntly: “Vibe coding is not caring at scale. ”

The workflow, in brief:

Start with the right tools. For us, that is Superpowers and roborev, our continuous local review and verification system.

Design together. The human stays involved in every important brainstorm decision and design section. Design and taste are not delegated to an agent.

Ask for a second opinion when the decision is unclear. A separate agent session, ideally from a different model family, should challenge the choice or design before it hardens.

Write the spec for the implementers. Once the design is settled, Superpowers turns the design into a precise specification. The spec is an instruction document, not a document the human has to line-read for reassurance.

Review the spec adversarially. A separate agent reviews the specification, findings are fixed, and the review repeats until it converges.

Plan, implement in small pieces, let roborev verify the work. Superpowers turns the reviewed spec into an implementation plan, which we implement either with subagent-driven development (mostly with Claude) or inline execution (mostly with Codex, because Codex’s subagents are… not great). Superpowers commits frequently after validating spec conformance, and roborev asynchronously does adversarial verification. All roborev reviews are closed out (by invoking the roborev-fix skill) after the plan is implemented.

Use roborev branch reviews to fix bugs in the whole implementation. The work produced by the latest frontier models (5.6-Sol and Fable) is extremely sloppy and almost never suitable for production without substantial hardening. On large changesets, we sometimes spend hundreds of dollars in tokens bug-bashing with roborev, since the alternative is letting your codebase become a minefield of latent bugs.

Make the work durable. We do not retain Superpowers spec and plan documents in our repositories or refer to them in production code: all documents must be converted into “living architecture documents” both for human-facing documentation and future context for agents who need to understand how a system works.

Explain the change, open the pull request, and own the merge. Agents can do the typing and checking, but the human remains accountable for the result. Pull request descriptions need to use plain language and lead with outcomes, and not be a wall of text of “robospeak” which seems to be the default behavior nowadays especially with Claude Fable.

We even made an internal diagram of this workflow:

The How Kenn Builds workflow

The process isn’t foolproof. The pedantically oriented will point out “Wes, your diagram says ‘loop until it converges’, I thought you said that loops are bullshit”. This is true, but remember these are human-operator loops . The clankers (what we call the coding agents, since “agent” gives them too much credit) are not in charge, we are.

The Clanker Constitution

On top of this engineering process, we have also been developing a set of operating principles for our coding agents, since their out of the box behavior (presumably the harnesses are largely to blame for this) is rather poor these days. They are bad at...