How 10X Builds Software With AI Agents in Charge

Dan Zakon says he can spend four hours writing architecture documents and planning files, issue a single command, go to sleep, and wake up with the work built. The tickets moved to the right columns. The logs written back to the repository. The agent having held course through the night without a human in the loop.

Take that claim at face value and it describes something genuinely new. Treat it with the skepticism appropriate to a founder on a podcast — which is where Zakon, director of engineering at 10X, made it — and it still describes something worth understanding. Because even if the overnight build is the best-case scenario rather than the Tuesday standard, the system underneath it is concrete enough to examine.

Zakon and Alex Lieberman, co-founder of Morning Brew and 10X, laid out that system in a recent episode of the David Ondrej podcast. What they described is not so much a stack of tools as a rethinking of where software development actually lives.

The context repo is the product now

The core argument Lieberman and Zakon make is that code has become the least valuable artifact in a software project. What matters is everything that explains, constrains, and directs the code — and that lives in a separate repository they call the "meta harness."

The meta harness is a structured collection of markdown files: architecture plans, convention documents, project specifications, decision logs. When an agent starts a new session, it receives a packet of this context automatically — what Zakon calls "benevolent prompt injection" — so that it begins each session with a working picture of the project rather than from zero.

During the podcast, Zakon demonstrated the system live. He ran a command that surfaced a briefing showing the project's epics, specs, and documentation files, along with a version log of the CLI used to manage them. He also ran a validator that checks all artifacts against a rule set the team has built up over time — catching, for instance, a project spec marked "complete" whose underlying tickets are still in review. Zakon described this as "linting for your SDLC," applying the kind of automated consistency checks that developers have long run against code, now applied to the entire engineering process.

The implication is direct: if someone broke into your systems and could only take one repository, the project management repo is the one worth stealing. The code, as Lieberman put it, "is already being written by agents." Anybody could replicate it. The process, the conventions, the architecture reasoning — those are scarce.

Defining the terms

Before getting to whether any of this scales, it helps to understand the two-part framework Lieberman uses to orient companies at the start of an engagement.

Single-player AI is what most companies are doing today: a tool in front of a person. Ask a better question, get a better answer. No behavioral change, no compounding. Valuable, Lieberman says, and probably where most organizations should start — but fundamentally limited to individual leverage.

Multiplayer AI is the harder, messier, more consequential work: redesigning horizontal processes so that an improvement creates leverage for an entire function or company. A sales agent that frees every seller from administrative work. A data engineering project that makes the whole company actually ready to build agents on top of. The leverage is exponential; so is the difficulty.

10X, operating as what Lieberman calls "innovation as a service" rather than a traditional consultancy, positions itself at the multiplayer end. The pitch is that rather than delivering a deck and walking away, they stay embedded and forward-deploy — building the thing, running the change management, and actually measuring whether it worked.

That's a different model than the McKinsey slide-deck tradition, and whether it delivers differently is a question their clients will answer over the next few years, not this podcast.

Can most companies actually do this?

The meta harness and the content machine and the validator and the benevolent prompt injection — all of it, taken together, represents an enormous upfront investment in process design before a single line of code gets generated. Zakon estimates he spends four hours on planning before letting the agent execute. The content machine requires voice interviews, curated example libraries, persona-coded skills, a notion vault, a lessons file.

This is infrastructure work. It rewards organizations with the patience and institutional clarity to define their processes precisely before automating them. It punishes organizations that don't — and most large enterprises don't.

Lieberman acknowledged this directly. "Most clients come to us with an AI problem and it turns into a data problem," he said. Companies that think they're ready to build agents are often years away from being data-ready to build anything coherent on top of. That's not a knock on the approach; it's just an honest description of the gap between where most organizations are and where this system assumes they are.

Zakon's point about engineering fundamentals cuts the same way. He pushed back on the claim — made by another guest on a previous episode — that engineers will soon stop reading or writing code entirely. His view is more careful: the volume of code you read is declining, but you cannot outsource the understanding. "What you're outsourcing is the thinking and the processing over all that code, but you can't really outsource the understanding." An engineer with poor fundamentals who leans hard into AI doesn't become more capable; he said it would "amplify those bad tendencies times 100." The best outcomes go to people who understand the full stack deeply enough to push agents to their limits.

The content machine as organizational design

One part of the conversation that got less attention than it deserved was the content machine — Lieberman's system for turning 10X's engineers and strategists into regular content creators.

The architecture mirrors the meta harness in its logic: invest heavily in process and context files up front, then let the automation handle the mechanical steps while keeping humans at the origin. Lieberman's principle is that the difference between useful AI content and what he calls "an AI slop cannon" is whether the origin is human. The machine handles research, formatting, editing, and distribution. The human selects the idea, speaks their unfiltered thoughts — interviewed by simulated personas drawn from recognizable interviewers — and provides feedback at the end that updates a lessons file for the next run.

To get engineers to actually use it, Lieberman ran a $5,000 internal competition over a month. Scoring wasn't purely impressions-based; he described it as also rewarding content that "did the best job of educating an audience on a topic" or "storytelling" work done with clients. Zakon said content output at 10X increased significantly after the system rolled out internally.

It's a genuinely novel piece of organizational design: not hiring more marketing staff, but building a system that makes non-marketers capable of producing usable content in thirty minutes a day. Whether that content is good — whether it reads like something a person actually thought, or like something a system produced efficiently — is a judgment call readers will make, not a number you can validate in a demo.

What the pattern suggests

Lieberman makes an argument that trusted distribution is now one of the few remaining moats in business — that as code becomes abundant, what earns dollars is an audience's trust. The content machine is his hedge against the day when 10X's technical work is fully replicable by anyone with the same agents.

There's something honest about that framing. Lieberman isn't claiming the process itself is defensible forever. He's claiming the brand, the judgment, and the relationships that accumulate around the process are. That's a familiar argument — media companies have made it for decades — and it's right often enough to take seriously.

What the 10X setup represents, underneath all the terminology, is a bet that the work of software development has already migrated upstream. Writing the code is the easy part now. The defensible work is in knowing what to build, why to build it, and how to keep an agent coherent across the months it takes to build something real. Teams that figure that out first will move faster than teams still debating the tooling. Teams that try to skip the upstream work and go straight to the automation will generate a lot of activity and not much that lasts.

That's how these process-framework rollouts typically end: the disciplined minority extracts most of the value, the impatient majority generates a lot of cost, and the gap between them gets called a talent shortage.

---

Bob Reynolds is Senior Technology Correspondent at BuzzRAG.