Agentic Engineering: The Discipline Behind AI

There's a certain irony in a senior developer admitting he misses writing code on weekends, like someone who became a chef confessing they sometimes just want to make a sandwich. That's Mickey — actual engineer, 95% AI-generated codebase over the last three months — opening a 54-minute conversation with David Ondrej about what it looks like to use AI tools seriously rather than just... hopefully.

His framing is blunt: "It's no longer vibes. We got to be serious with this stuff."

That's the provocation behind vibe coding's challenger term right now — agentic engineering. The difference isn't the tools. It's who's doing the thinking.

The harness is not the model

Mickey's first and most useful contribution is a conceptual one. Most conversations about AI coding tools collapse "the model" and "the tool" into the same thing, which leads to confused comparisons. He separates them cleanly.

The model — GPT-4.5, Claude Opus 4.7, whatever — is just a next-token predictor. It doesn't execute code, read files, or search the web on its own. The harness is the wrapper that gives it those capabilities: the system prompt, the API tool calls, the agent.md configuration files, the file-access permissions. When you see "it read this file, it searched this thing" in Cursor's trace output, those are harness-provided tool calls, not model magic.

Why does this matter? Because it explains why two developers using the same underlying model can have completely different experiences. Mickey argues Cursor benchmarks ahead of Claude Code and Codex precisely because of harness quality — not model quality. "The models have got to a point where an investment in a really good harness will maximize the output you get from the model."

He's currently running GPT-5.5 extra high in Cursor for most work, with Claude Opus 4.7 Max reserved for UI and frontend changes where he's found it performs better. The model-switching flexibility is specifically why he prefers Cursor, even though it doesn't subsidize costs the way Claude Code does. That cost premium is real — it's not a trivial thing to wave away for developers or small teams.

Context engineering is where most people are losing

Here's what clicked for me when I went through this interview: Mickey's most practical insight isn't about which model to use. It's about how to feed models information without making them stupider.

Context windows have gotten enormous — Mickey references using a model where he tracks utilization percentages, noting that at 77% context load he'll just start a new thread rather than push further. (That figure is his working heuristic, not a published spec from a model card — worth noting.) The temptation is to treat a large context window as permission to dump everything in. Mickey treats it as an argument for precision.

"In vibe coding you're offshoring the thinking to the agent. In agentic engineering, you're doing the thinking and then you're just letting your minions do the work."

The tool that operationalizes this for him is one he describes as being maintained by Vercel under what he calls open-source — a CLI tool you run as npx open-source [repo-url] that pulls the actual source code of a package into your codebase so you can reference it directly in prompts. (Note to links team: the exact repo URL needs verification before this publishes — Mickey references it as a Vercel project but the name open-source isn't unambiguous enough to link confidently.) The principle behind it is genuinely compelling: instead of feeding an agent documentation that someone wrote about a library — which is always a step removed from truth — you give it the code itself. Code doesn't lie about what it does. Docs do.

I find that framing more clarifying than it might initially seem. Documentation is a representation of intent. Code is the implementation. When those diverge, only one of them matters to a running system.

The service layer problem nobody talks about

Mickey's second major workflow intervention is less flashy but probably more important for anyone building with AI at scale: agents will rewrite code that already exists.

This isn't a small quirk. Ask an AI to add Telegram integration to a codebase that already has a stream-response function, and nine times out of ten it writes a new function instead of extending the existing one. Do that across ten features and you've got five versions of the same logic living in different files, debugging nightmares, and a context-window load that grows faster than your feature list.

His fix: after every feature build, run a refactoring skill (a configured agent prompt) that audits for duplicated code and restructures it into a service layer — shared, reusable functions. He doesn't do this for the agent. He does it so the next agent session can read a clean codebase and not confuse itself.

This is the part of the conversation where I had to sit with a small uncomfortable realization: it's more overhead than vibe coding. You're writing plans before prompting. You're running refactor passes after building. You're managing context windows like a resource. Mickey's workflow is genuinely more disciplined than just typing at a chatbot — and I think that discipline is worth every minute of it. Not because it's more virtuous, but because the alternative is a codebase that compounds its own confusion until even the AI can't navigate it. The overhead is the quality control.

He uses Greptile for code review, specifically for a feedback loop he calls the "GP loop" — Greptile scores PRs on a confidence scale and returns specific issues, which then feed back into the next prompt cycle. It's the closest thing to Karpathy's auto-research loop applied to code review.

The "agreeable model" trap

One thread that runs through the whole conversation and doesn't get enough attention in most AI coding discourse: the model will confirm whatever direction you're heading, even if that direction is wrong.

Mickey references the backlash when OpenAI deprecated GPT-4o — users who'd built working relationships with that model's tone were genuinely upset. His point is that the same dynamic happens in codebases. The model is so agreeable that you can feel like you're making good architectural decisions when the model is just generating plausible-sounding next tokens in response to your assumptions.

"You have to almost treat this like a really dumb person with photographic memory that knows everything but doesn't know how to use everything."

The planning step Mickey insists on — generating a plan first, breaking it into small PRs, then executing — isn't about AI safety in the abstract. It's about maintaining a paper trail of your own thinking that the model can be held accountable to. Without it, you're navigating by the model's confidence rather than your own judgment.

This is also where the data gets complicated. A METR study on AI coding productivity (flag for links team: verify this study specifically supports the claim that experienced developers worked slower with AI assistance on certain tasks before publishing) found that developers with AI assistance sometimes took longer than those without — which cuts against the productivity narrative but doesn't contradict Mickey's framework. His argument isn't that AI makes every developer faster. It's that understanding the harness, managing context deliberately, and maintaining architectural judgment makes you faster. The developers slowing down in studies like that one might be the ones doing the vibe coding version, not the agentic engineering version. We genuinely don't have clean data that separates those populations yet.

The developer experience transformation happening right now is real — but it rewards a specific kind of engagement. Mickey's 95% AI-generated codebase isn't a passive outcome. It's the result of someone who understands the system well enough to manage its failure modes.

Whether you're a developer trying to figure out where your practice is going, or someone adjacent to software teams trying to understand what "AI-assisted engineering" actually means in practice — the honest answer from Mickey's framework is that the skill floor hasn't dropped. It's just moved. You need less syntax. You need more judgment about when the model is confidently wrong.

That's either encouraging or terrifying, depending on which of those skills you've been building.

Yuki Okonkwo is Buzzrag's AI & Machine Learning Correspondent.