@Steve_Yegge
Post
Hear me out: Agentic TPMs (Technical Program Managers.) I had this idea in Sydney while chatting with Martha McKeen at CBA. I think this winds up being the most immediate and direct way that coding agents can make their way into the enterprise, and it will set the stage for true AI employees rolling in next year.
So. Build-side agents are great but they don't escape the SDLC. Only devs are using them. There are a handful of business people vibe coding SaaS, but for the most part, non-engineers aren't using coding agents to help with their jobs. Right? Not yet.
Autonomous 24x7 unmanned queue-based "operator" agents, like the ones that handle internal or external customer issues, are great. But they are narrowly scoped, and generally require devs involved to set them up and maintain them.
Neither builder nor operator agents are automatically going viral internally and helping run the company. They stay in their lanes. But what if their lane was to help run projects?
I was a TPM at Amazon in 1999. Bezos brought in high-powered engineers with people skills to run difficult cross-functional projects and programs. TPMs are used at Google, Uber, Netflix, and other companies, and they are always in high demand and short supply.
I have a class of agents in my Wheelhouse factory that act just like TPMs. They have external email and Slack, and talk to my accountant, lawyers, players. Each one has a project lane and drives it. They use Progress By Nagging, which... works.
A TPM owns delivery, but has no authority, and no resources. They can only ask, observe, document, and report. This is just like my TPM Wheelhouse seats, who have been helping me drive dozens of projects to completion, large and small, for months.
Agents, particularly smarter models, will go to great lengths to document the hell out of everything in the domain where they're operating. They'll capture all the tribal knowledge and unwritten rules. They can create topological maps of your project, org dependencies, and workflows. They'll bulldoze through silos and knowledge-hoarders and figure out how the company actually works, and document it all. And nag people along the way.
This kind of agent sits well in constraint-space. They're cheap: You don't need to use the fanciest models; anyone with Opus or Sol access could have a TPM agent. And TPM agents have low risk and blast radius, because they cannot act. Unlike builder agents, which create new problems (like merge-queue and code-review bottlenecks), TPM agents simply shine a light on the org, and nudge things along.
It doesn't matter what format they're recording their findings in. It could be Sanskrit and hieroglyphics. When it comes time to merge their findings with those of other TPM agents, it will all translate trivially into your company brain.
Anyone in the company can stand up a TPM agent. It's like a personal chief of staff. There's no dependency on engineers. Everyone can do it; it doesn't even have to have a paced rollout. And there's no product to buy, no tech to install, maybe just a Skill you give people. Maybe you put a company wrapper on it. But it's just an agent that's playing the TPM role.
TPM agents will wind up training human orgs on human-agent interactions. Humans start getting emails or DMs from agents, work-related, and will have to get comfortable replying and interacting. Companies can push the social side along without waiting for engineers to finish messing with the SDLC, which honestly will never finish.
Other kinds of agents struggle at enterprises because they lack context. TPM agents will build that missing context as their exhaust, no joke; they've done it for my game without me even asking. TPM agents are the jungle explorers that will map out your organization, and you'll discover all sorts of fun stuff, like that you had 3 teams doing the same thing. TPM agents are a low-risk, high-impact way to start figuring out how AI can help you run your project, or organization.
I'll write a blog post about this, but feel free to start now. Go! Just give me credit when you win big with this idea. And if you want my help, ping me on http://yegge.ai.
Explanation
Steve Yegge’s claim is that the easiest path for AI agents into large companies may not be “AI software engineers” or fully autonomous business operators, but AI versions of technical program managers: agents whose job is to keep projects moving by gathering status, finding dependencies, documenting decisions, chasing people for answers, and escalating blockers. The key insight is organizational rather than technical. A TPM typically has broad visibility but little direct authority; it coordinates rather than executes. That makes the role unusually well matched to current agents, because an agent can create value through reading, writing, remembering, mapping and persistent follow-up without being allowed to deploy code, move money, or make consequential decisions. Yegge thinks this combination—high organizational leverage, low permission requirements, low “blast radius”—could normalize human interaction with AI coworkers much faster than engineering-focused agents can.
Yegge is a longtime programmer and engineering writer who spent roughly seven years at Amazon and twelve at Google, and lately has been experimenting heavily with multi-agent software-development systems. His current private system, “Wheelhouse,” orchestrates many persistent AI roles around Wyvern, the online game he has worked on for decades. Wheelhouse is the practical evidence behind this post: he says some agents already function less like programmers and more like staff members with standing responsibilities, communicating through channels such as email, tracking work and prodding other participants. ([yegge.ai][1])
The Sydney/CBA reference is Commonwealth Bank of Australia. Martha McKeen leads AI-powered engineering and international technology-hub work there; Yegge and Gene Kim had previously run AI/vibe-coding workshops for CBA. So the idea seems to have emerged while discussing enterprise adoption with someone whose actual job involves introducing AI into a 10,000-plus-technologist organization—not merely from running coding agents at a startup. ([CommBank][2])
The distinction between his three agent types matters. A “builder” agent modifies software: useful, but trapped inside the software-development lifecycle, with code review, CI, merge queues, permissions and engineers as gatekeepers. An “operator” agent performs some persistent production function—say handling a queue of support cases—but normally has a tightly defined remit and requires engineering work to install safely. His proposed TPM agent instead operates on the organization itself: “What is blocked? Who owns this dependency? What did legal say? Has Alice replied? What changed since Monday?” It can repeatedly ask those questions without needing the ability to actually change production systems.
“Progress By Nagging” is intentionally mundane. Human TPMs often succeed through relentless coordination: noticing that team A is waiting on team B, obtaining the missing answer, writing down what everyone agreed to, scheduling another check, and making stalled work visible. An agent is potentially very good at the tedious part because sending the fifteenth follow-up costs it essentially no motivation.
His more interesting claim is that documentation becomes a by-product rather than a separate knowledge-management initiative. An agent coordinating a project has to read conversations, reconstruct ownership, learn acronyms, discover undocumented procedures and keep a model of dependencies. If you preserve that accumulated representation, you gradually get what Yegge calls a “company brain”: machine-readable institutional knowledge that normally lives diffusely in Slack threads, people’s heads, old docs and organizational folklore.
“Constraint-space” means the role is valuable precisely because you can constrain it hard. Give the agent read access plus communication/documentation abilities, but little or no unilateral action authority. If it misunderstands something, the likely failure is an annoying message or erroneous note rather than a broken deployment or financial loss. That makes the proposal substantially more plausible than “give autonomous agents employee credentials and let them run the company.”
The speculative leap comes at the end: Yegge thinks these agents could serve as organizational training wheels for genuine AI coworkers. Employees would gradually become accustomed to receiving legitimate work requests from nonhuman colleagues, while the agents simultaneously construct the contextual map future, more capable agents would need. In his framing, the TPM agent is therefore not merely an automation of a job category; it is a low-risk reconnaissance layer that maps the enterprise before more autonomous agents arrive.
[1]: https://yegge.ai/?utm_source=chatgpt.com "Steve Yegge — Programmer" [2]: https://www.commbank.com.au/articles/newsroom/2026/05/san-francisco-tech-hub.html?utm_source=chatgpt.com "Proximity and pace: CommBank embeds teams at the frontier of AI as it opens San Francisco Technology Hub"