AI Builders: Coding Agents and Agentic Engineering

This note brings together discussions of coding agents from eleven English-language podcast sources—AI & I, Latent Space, No Priors, Training Data and Unsupervised Learning—organized by concept rather than episode. In the spring 2026 accounts collected here, Karpathy, Claude Code creator Boris Cherny, the OpenAI Codex team, Cursor, Notion and Pydantic converge on a shift from typing code toward expressing intent to agents and checking results. They disagree at several crucial junctions; those differences are retained below.

Open this note when:

You hear people say they no longer write code and want to understand what they mean.

You are choosing between Claude Code and Codex and want the reasoning of daily users.

You work in product or operations and wonder how coding agents can handle email, research or metrics.

You want explanations of skills, harnesses and MCP versus CLI.

You need to explain why coding ability alone may become less scarce, and what remains valuable.

Reading the historical material. Product comparisons, prices, model names, performance numbers and forecasts below belong to the cited accounts and their original dates. Translating this archive does not independently verify or update those claims. Later additions retain their own evidence limits.

0. A map of the shift

Think of AI-assisted coding as levels of an elevator. The speakers occupy different floors but look in the same direction:

Level 0  Humans type; AI completes code (the 2024 pattern discussed in the newtype notes).
Level 1  Vibe coding: describe what you want; keep watching and correcting (Karpathy's term).
Level 2  Agentic engineering: dispatch agents; express intent and validate deliverables (the December 2025 turning point).
Level 3  No human review: agents open issues and modify their own systems (the “dark factory” frontier).
Level 4  Automated research: supply a goal and budget; agents run and iterate on experiments (Karpathy's AutoResearch).

Why this map matters. Many people still equate AI with a chatbot, while these speakers describe work at levels 2–3. The sections below unpack individual parts of that map.

1. December 2025: from typing to orchestration

Almost all the interviewees identify December 2025 as a turning point.

Karpathy, an OpenAI cofounder and former Tesla leader, says in No Priors and Training Data that he probably has not typed a line of code since December. He describes spending sixteen hours a day expressing his will to agents: “Code” no longer feels like the right verb; “manifest” is closer.

He describes moving from writing 80% of the code himself to handing about 80% to agents, and argues that the default workflow of an ordinary software engineer changed fundamentally that December.

Boris Cherny, Claude Code's creator, gives a more extreme account in Training Data: the model writes all his code, and on one day in the preceding week he submitted 150 pull requests.

The note's interpretation. Independent speakers in the OpenAI and Anthropic ecosystems describe a similar change in the same month. Karpathy argues that anyone who assessed AI as merely a ChatGPT-style conversational toy a year earlier should reassess coherent agent workflows. These are practitioner accounts, rather than a controlled measurement of every team's productivity.

For nontechnical readers. The work moves from typing toward explaining what you want and deciding whether the result meets it. The bottleneck shifts from your fingers to your understanding and direction.

2. Vibe coding and agentic engineering are different

Karpathy repeatedly distinguishes these easily confused terms.

Question	Vibe coding	Agentic engineering
What do you do?	Ask AI to generate something that runs	Direct agents to deliver professional software
What problem does it address?	Raise the floor so more people can build	Preserve the ceiling of professional quality
Does quality remain your responsibility?	Often, running at all is sufficient	Yes: prevent vulnerabilities and remain accountable
Claimed speed ceiling	Relatively modest	Very high; speakers say beyond the old “10× engineer”

In Training Data, Karpathy frames vibe coding as raising the floor and agentic engineering as preserving professional software's quality bar while accelerating work. He says skilled practitioners can peak far above a tenfold speedup.

Product-management implication. Assembling a Cursor demo and coordinating agents to deliver a reliable production system require different skills. The original note proposes distinguishing those skills in hiring, leveling and task allocation; it does not establish that agents produce bug-free systems automatically.

3. Software 1.0, 2.0 and 3.0

Karpathy's three-part model appears across both interviews, and Cursor's Dima uses a related framing.

Generation	What you program	Plain-language description
Software 1.0	Explicit code	A programmer writes if/else logic
Software 2.0	Datasets and neural-network training	Program through data in the deep-learning era
Software 3.0	Prompts and context	Treat the language model as an interpreter and steer it with context

Dima adds a training perspective: sculpt code in 1.0, training data in 2.0, and evaluation rubrics in 3.0.

The proposed conceptual shift. Karpathy argues against treating AI only as an accelerator of existing software patterns: neural networks may directly perform jobs for which people previously built full applications.

His MenuGen example contrasts an OCR/image-generation/Vercel application for illustrated restaurant menus with simply giving Gemini a photograph and asking Nanobanana to overlay dish pictures. In that example, much of the application becomes unnecessary.

Product implication. A future model may replace a feature with a single instruction. Before building an application, ask whether direct model interaction can already do the job. Section 7 explains the accompanying argument about automating what can be verified. This is an architectural question, not proof that every application should become a prompt.

4. One person directing an agent fleet

The interviewees describe parallel agents with a person coordinating them.

Karpathy's “Peter Steinberg prototype.” His account describes a screen filled with Codex agents, each working intensely for about twenty minutes, roughly ten local repository checkouts, and a person allocating work among them. The name follows the archived note.
Cherny's phone workflow. He describes mainly using the Claude app's code tab on a phone: five to ten simultaneous conversations, hundreds of running agents and thousands tackling deeper work overnight.
Karpathy's new unit of work. Issue “macro actions” to repositories: send independent features to different agents; one researches, another codes, another plans. Orchestration becomes practiced muscle memory.

The note identifies token throughput and human attention as scarce resources. Karpathy compares unused subscription capacity to a doctoral student distressed by idle GPUs; when Codex runs out, he switches to Claude.

Ryan Lopopolo of OpenAI Frontier emphasizes the synchronous attention of his team as the fundamentally scarce resource.

Interpretation. Tokens and GPUs can support much more parallelism than a person's limited daily attention. The engineering objective becomes reducing the need for continuous human participation.

Application. Hours alone become a weak measure of output. A more relevant skill is how much concurrent agent work you can direct without losing control of results. That coordination still requires practice.

5. Skills, harnesses and loops

5.1 A skill is a Markdown file with scripts

Swyx, the Latent Space founder then at Cognition, describes skills in Unsupervised Learning as a Markdown file plus attached scripts.

His minimal agent formulation combines a tool-using model in a loop with a filesystem, retrieval and skills. The speakers present this as an emerging common foundation.

In plain terms, write down an operating procedure and provide the scripts an agent can follow. The note emphasizes how accessible the instruction-writing portion is; scripts themselves may still require engineering.

5.2 A harness is the assembly around the model

The model is the engine; the harness is the surrounding structure. Angela from Anthropic's platform team reports substantial performance differences between harness arrangements tested for agent memory in AI & I. Her point is that assembling the right surrounding components can yield large improvements.

5.3 Loops and routines support repeated work

Cherny favors /loop: schedule Claude to maintain pull requests, repair continuous integration, rebase, keep tests healthy or cluster Twitter feedback every thirty minutes. He calls loops a major future direction and encourages experimentation.

The newly discussed Routines move this pattern to a server so it can continue with the laptop closed.

Why these matter together. They change the interaction from asking and answering one question at a time toward sustained work. That is part of the transition from level 1 to levels 2–3.

6. Disagreement: Claude Code or Codex?

The same experienced users choose different tools and explain why.

Dan Shipper and Austin of Every, in AI & I's account of switching from Claude Code to Codex:

Dan describes Codex three to six months earlier as poor. Austin describes feeling unusually ineffective using it two months earlier, finding it argumentative and lacking social sensitivity.
They describe an approximately three-month turnaround from a sandbox mainly suited to senior engineers into a daily tool. Austin says he spends 80% of his work time in the Codex app. He attributes this to a faster, stronger desktop experience and stronger subagents, rather than a clear model-intelligence advantage: he considers the latest Opus and GPT at least tied for his knowledge work. His 30–40% improvement estimate is personal.
He does not argue everyone must switch: Claude's desktop app had already changed his work. He also describes low migration effort—asking Codex to transfer his Claude setup.

Karpathy's personality comparison, in No Priors: Claude feels like a teammate and gets praise approximately right; coding-oriented Codex feels dry and less invested in what the user is creating.

Samuel Colvin of Pydantic, in Latent Space, uses all three providers and compares Claude Code to Captain America, Codex to the technically minded Q from James Bond, and Gemini to the Joker: sometimes impressive but, in his account, prone to destructive mistakes. These are his colorful impressions, not measured failure rates.

How to use the disagreement:

There is no permanent winner; perceptions can reverse within six months. Swyx describes a volatile period.
Desktop engineering, speed and subagent experience may matter as much as underlying model intelligence.
Swyx characterizes Anthropic as a premium, constrained bundle and OpenAI Codex as an invitation to experiment through subsidies, an open SDK and quota resets. The archived note suggests making use of available subsidies and cites a $200 monthly exploration plan; these are dated commercial observations, not current pricing advice.

Dan Shipper argues that people who adopt new tools, paradigms and workflows can gain an advantage by default. Every holds two “Think Weeks” a year, suspending routine work to explore tools; he recommends at least one day per quarter for other teams.

7. Verifiability and jagged intelligence

Karpathy offers a general test for whether AI can help with a task: traditional software automates what can be specified in code; language models automate what can be verified. Reinforcement learning rewards verifiable domains, producing uneven or “jagged” capabilities—exceptionally strong in some math and code tasks, much weaker elsewhere.

In Training Data he contrasts the reported ability of Opus 4.7 to refactor a 100,000-line codebase or find zero-day vulnerabilities with its suggestion to walk to a car wash. The model designation and examples are retained from the account.

He attributes unevenness to what is verifiable and to what laboratories choose to put in training. His chess example describes a large GPT-3.5-to-GPT-4 improvement after adding chess material, rather than assuming a uniform increase in general intelligence. Users remain dependent on laboratories' choices.

Proposed product and startup implications:

Ask whether your application sits inside an effective RL feedback loop. Math, code and automatically scored tasks may benefit more directly than ambiguous tasks with no clear correctness test.
A verifiable domain a laboratory does not prioritize may still offer an opportunity to fine-tune.
Karpathy's optimistic view is that even subjective tasks such as writing could be made more verifiable through a council of model judges. He frames this as difficulty rather than impossibility; it remains his forecast.

He also repeats the distinction between outsourcing thought and outsourcing understanding. Humans may become the director or bottleneck, but they still need to understand enough to judge results and direct work.

8. Disagreement: MCP or CLI?

Two routes connect agents to tools and data:

MCP, the Model Context Protocol: a standard way to declare tools and delimit available actions.
CLI, the command-line interface: let the agent operate through terminal commands.

CLI-leaning views:

Ryan Lopopolo argues that loading every tool's description into context interferes with compaction and can leave agents losing track of their tools. He prefers thin command-line wrappers around what is actually needed—for example, three Playwright calls—and concise outputs containing failed tests or relevant log errors.
Simon Last of Notion favors the terminal's pagination, progressive disclosure and capacity to bootstrap new tools. His example is having an agent write roughly a hundred lines around Chromium APIs to give itself a browser.

MCP-leaning views:

Simon also acknowledges MCP's useful simplicity and permission model, particularly for narrow, lightweight agents requiring clear access boundaries.
Cherny calls MCP the simplest answer for knowledge work: the same Salesforce or Google Docs/Calendar connectors can be reused in Cowork, Claude CLI and Claude Code. Computer use can fill gaps where no MCP integration exists.

Cherny's common ground is that, to a model, MCP, CLI, APIs and computer use all become tokens. Evaluate token efficiency, permission clarity and whether the agent can debug its own interaction.

Sarah Sachs's cost argument. Using language-model inference to execute deterministic tasks can be wasteful. Under usage-based billing, code that invokes a deterministic tool can be cheaper than repeatedly spending model tokens on individual tool invocations, especially beyond a cache window. The source uses the unclear term “CLor”; it is retained here as an uncertain transcription, not expanded into a claimed product. Notion deliberately implements core search directly rather than using MCP for that path.

The note's decision heuristic: MCP for narrow, stable work with strong access boundaries; CLI for exploration, self-repair and high-volume work where tool design can reduce cost. This is a heuristic, not a universal performance result.

9. Disagreement: is the harness the hard part?

Caitlin from Anthropic's platform team argues in AI & I that teams may expect harness engineering to be the main difficulty but ultimately hit an infrastructure wall.

Her distinction is between SDK-supported work such as prompt caching and context management, and turning the agent into a product: servers staying available, starting and stopping execution, preserving conversations, safe sandboxes and fault tolerance when a sandbox dies. This motivates the team's Managed Agents work.

Angela's simultaneous claim of substantial harness gains is therefore a different layer: a harness can improve performance, while scaled production use still requires reliable infrastructure.

Angela also argues that as laboratories' approaches diverge, harnesses and models may become more tightly coupled. Rather than imagining one universal harness with interchangeable models, redundancy may need to switch the whole agent—model and harness together.

Procurement and architecture implication. Check the complete agent configuration when replacing a model. The speakers' warning challenges the assumption that a universal middleware layer makes every model swap effortless.

10. The extreme case: the “dark factory”

Ryan Lopopolo's OpenAI Frontier team describes an experiment banning handwritten code so the team must teach Codex to perform engineering work.

Reported results over about five months: around a million lines, approximately 1,500 pull requests and three people, eventually about ten times faster than hand coding. The first month and a half was reportedly ten times slower while they built the surrounding system.

Operational ideas from the account:

Move human inspection after merging. Instead of serving as a universal pre-merge gate, people sample results to find where the team struggles. A code-review agent may merge autonomously in this experiment.
Models need text. Documentation, actionable errors, technical tracking, quality scores and PR comments pass missing context between agents.
Each mistake exposes an unwritten requirement. Turn engineers' tacit quality standards into documentation, tests and review rules.
Code can be disposable. A failed PR that will not merge cleanly may lead them to discard the workspace and restart, then encode why the previous attempt failed.
Trust needs digestible evidence. Rather than watching an entire Cursor recording, Lopopolo wants an agent to attach a video showing why its change works and is ready to merge.

Swyx calls these “dark factories.” He contrasts the once-radical idea of no human-written code with the next frontier of no human review before merge. In his view, scale requires a shift toward more testing and automatic verification, using volume to improve quality.

Scope limitation emphasized by Lopopolo: this was a new, greenfield repository. It does not establish that the approach transfers to old, brownfield systems. Do not treat the experiment as a blanket promise for a legacy codebase.

11. Train your own model or use a frontier model? Cursor's “agent lab” approach

Notion rejects training its own foundation model (section 13), whereas Cursor explains a different set of conditions.

Swyx's agent-lab sequence, in Unsupervised Learning: start with the strongest frontier model, specialize the product for a domain, and only after accumulating enough high-quality real-user work train a smaller model to reduce cost or latency. He calls this a reversal of the bitter lesson: begin with a general model and distill frequent, relatively stable work into something smaller.

Cursor's account of Composer 2, in Training Data:

Treat the weights as a limited hard drive. Allocate capacity to software engineering inside Cursor, rather than programming in general.
Specialization is presented as the reason it can cost roughly an order of magnitude less than Opus.
Start from the open Kimi 2.5 base, described in the account as a one-trillion-parameter mixture-of-experts model with thirty billion active parameters. Use mid-training and reinforcement learning rather than pretraining from scratch, prioritizing a useful model quickly.
Train compression and self-summarization within the RL loop. A model with a 200,000-token window can, according to the account, perform much longer work by summarizing and restarting context.

Federico cautions that prompt engineering has an upper bound: post-training is needed to shape some product behaviors. Composer ships with a prompt, but he believes training already pushes it toward the intended behavior sufficiently to work without that prompt.

The note's conclusion for most companies: do not assume you should train your own model. Cursor has its product as an RL environment and access to tens of thousands of GPUs. Without equivalent conditions, frontier models plus careful tools, harnesses and validation may be the more practical path. Section 13 gives Notion's reasoning.

12. Monty: lightweight code execution and the conditions for a hundredfold speedup

Samuel Colvin's Monty project illustrates a tradeoff relevant to product managers.

Agents often need to write a little code to calculate something. Pure tool calls are simple and constrained but less expressive. A complete sandbox is powerful but needs additional infrastructure and may be unacceptable to some large financial institutions. Monty aims between these options: code-mode expressiveness without a full sandbox. The interview contrasts single-digit-microsecond execution overhead with about a second to start a sandbox; these are the reported project figures.

Colvin's four conditions for unusually large, rather than merely three-to-fivefold, AI engineering gains:

The model knows the internal implementation concepts, such as heaps or bytecode interpreters.
It knows the external interface very well; Python semantics are the example.
Excellent unit tests are easy to construct—compare against CPython and repeatedly iterate until they pass.
The API specification does not require negotiation: Python already defines behavior and errors.

He uses these conditions to explain why people are cloning Redis in Rust.

Application. Existing reference answers, easy tests and settled specifications make a task much more suitable for dramatic acceleration. Without objective standards, do not assume a hundredfold gain. This connects with verifiability in section 7.

Type safety. Colvin regards it as important for humans and critical for AI. He reports four Anthropic employees independently stressing type safety for chained tools and programmatic tool calls. He inferred that Anthropic was working on programmatic tool calling, which the account says was subsequently released.

13. Notion's counterpoint: not everything needs an agent or an in-house model

Sarah Sachs and Simon Last offer a counterweight to “agents eat everything” in Latent Space.

Automatic model selection is important work. Users need to trust that “Auto” means the model suited to the task, rather than the cheapest and least capable one. Sachs compares the positioning to automated investing or an index fund. She says Notion does not treat Auto as a profit-maximization device; it reduces anxiety because most tasks do not need an Opus-class model.

Her distinction from frontier laboratories is replacing processes, rather than necessarily replacing people. Notion, she says, is not incentivized to maximize token consumption. Sometimes the right tool is ordinary code and no agent at all.

Why not train a foundation model? Sachs says it is outside their core competence and budget. Fine-tuning on their own tools is also hard to sustain because the tools change every day. Simon calls training an implementation detail: most problems turn out to be tool bugs, so fix those and improve the harness, tools and validation. Retrieval and ranking are the exception they consider worth training for, particularly as agents generate more search traffic and write queries differently from people.

Lessons from rebuilding Notion's agent about five times:

Give models the representations they handle well, rather than exposing all the complexity of your own system.
Replace a proprietary, difficult JSON database-query format with SQLite because models understand SQL. Replace lossless XML with Notion-flavored Markdown because models understand Markdown.
Move from few-shot prompting to goal-oriented tool definitions. Previously, only five or six people could touch a shared prompt, creating a center-of-excellence bottleneck. Tool definitions let individual teams own their tools; this was described as the largest speed lever.
More than a hundred tools creates a progressive-disclosure problem. Even a greeting can consume thousands of tokens, and an obscure added tool can degrade the whole system. Rework the harness so agents search and select tools instead of receiving everything at once.

Simon describes coding agents as an underlying kernel that can enable much broader work. This aligns with the idea that software-building capability can support other forms of knowledge work; it remains the speakers' broader interpretation of the technology.

14. Domain knowledge, judgment and taste

This is the recurring opportunity for nontechnical readers.

Cherny's printing-press analogy. He compares software democratization with falling book prices and rising literacy after printing: the account cites roughly 10% initial European literacy, more books in fifty years than the preceding thousand, a roughly hundredfold price decline and eventual literacy around 70%. These are historical figures used in his analogy, not independently researched here. He expects the software transition to happen faster.

His product point is that a strong accountant may be best placed to specify accounting software: coding becomes easier, while knowing the domain remains hard.

Karpathy's division of responsibility. People retain taste, judgment, aesthetics, specifications, design and supervision. Agents resemble interns with excellent recall who fill in details, while people own decisions such as whether user identifiers must be unique.

Sachs's identity-crisis observation. Engineers are encountering a familiar managerial transition: delegation and context switching become more important relative to personally writing code.

For a nontechnical product manager:

Domain expertise can become a product more directly, with less dependence on first finding an engineer.
This does not mean no foundational understanding is required. Programming reasoning, judgment and acceptance testing still matter; the related newtype coding note makes a similar warning.
If AI-generated work carries your name, you remain responsible for it. Dan Shipper says he may prefer an agent-assisted document, provided the person has thought it through and can stand behind every line. Trust rests on ownership of the result.

15. Claude Code as a second brain

Noah Brier, founder of Alephic, describes his main Claude Code use in AI & I as interacting with research and notes rather than coding. It sits over an Obsidian collection of Markdown files and folders synchronized with Git.

Practices from his account:

Start at the root of the note collection, rather than an individual project folder, so it can search roughly 1,500 notes. Organize them with PARA.
Use a re-entry request such as “Can you catch me up on the last few days of research?” to recover the thread of deep work; claude --continue resumes the conversation.
Create a thinking-partner subagent whose job is to ask sharp questions and support thought, with explicit instructions not to write a finished artifact. Maintain a running account of what has been uncovered.
Expect a recurring failure: even told not to produce an outline or draft, the model may still try to generate one. Brier uses a firm opening instruction forbidding outlines, drafts or other versions. He speculates that helpfulness and incentives around producing artifacts have become part of the model's behavior.

Brier's reframing. Calling the technology “generative” makes people focus on writing and underestimate reading. People think about things far more often than they finish artifacts; reading can therefore be the more useful everyday capability.

For someone using a Markdown knowledge repository, this pattern is directly comparable. See the related Claude Code workflow note for practical details.

16. SaaS, changing moats and Jevons's paradox

Cherny uses Hamilton Helmer's Seven Powers framework. He argues AI weakens switching costs, through easier migration, and process power, through goal-directed improvement. Network effects, economies of scale and exclusive resources remain. He predicts roughly ten times as many disruptive startups over the next decade because small teams can build valuable products that compete with large firms. The model reference “Claude 4.7” belongs to the archived discussion.

Swyx's description of the coding market. The source labels the numbers as disputed industry estimates: about $2.5 billion ARR for Claude Code, $2 billion for Codex and a rumored $2 billion for Cursor. His possible outcome is two large players plus a long specialized tail. He describes capability exploration rather than efficiency optimization, with incentives to consume more tokens and a belief that overall AI use is still too low. These figures and predictions are dated claims.

Karpathy's software version of Jevons's paradox. Making formerly scarce, costly software easier to create can unlock more demand. He uses the ATM-and-bank-branch example to illustrate the argument. He sees code as increasingly ephemeral and changeable, rather than a fixed subscription purchase, and is cautiously optimistic about total demand.

Product interpretation:

Moats based mainly on switching difficulty or process complexity may be weakened.
Network effects, scale and exclusive resources may be more resilient.
Rebuilding software is only part of the challenge. Swyx compares $200,000 in annual SaaS spending with an estimated $2,000 rebuild, but the harder issue is bringing less AI-native teammates along. Uneven adoption inside a company can cause real friction. Neither estimate is a verified migration budget.

17. Disagreement: are agents the new infrastructure buyers?

Swyx and Vercel CTO Malte Ubl argue that agents increasingly select and use infrastructure. A service inaccessible through an agent-usable API can effectively be invisible to them.

The account says bots represented about 60% of Vercel application-management/configuration traffic. Sachs expects much future interface traffic to come from agents. The proposed response is to provide CLIs alongside interfaces.

Swyx also demystifies “Agent Experience,” a term associated here with Netlify: good documentation, discoverability, progressive disclosure and consistent, largely stateless APIs were already useful for people. Higher volume and more spam may be changes in degree rather than a completely new discipline.

AEO/GEO—visibility in AI recommendations. The archived Resend example claims that Claude recommended it by default in about 70% of email-provider queries despite its 2023 founding. Swyx expects memory and personalization to outweigh mention frequency in three to four years, possibly narrowing defaults to around three services rather than twenty. These are a source example and forecast, not current search measurements.

Suggested actions:

Make documentation directly usable by an agent, including text a user can hand over without rewriting it.
Complement the UI with CLI/API access.
Explore recommendation visibility without staking everything on repeated mentions; consider how a service earns ongoing, personalized selection.

18. AutoResearch, memory and world models

Karpathy's AutoResearch. Extend reduced human participation to research: give an agent a goal, measurable metric and constraints, then let it run experiments overnight. He reports that experiments on NanoChat found a forgotten weight-decay choice and an untuned Adam beta after years of manual tuning. He imagines a research organization described by Markdown roles and relationships—ProgramMD—and even optimization of that description itself.

He retains two conditions: cheap, objective feedback is needed, and the stack is still fragile enough that pushing too far ahead may be unproductive.

Swyx on memory. Context length may be the slowest-scaling part of language models and memory the largest constraint. The account notes roughly three years from 4,000-token to one-million-token windows, with Gemini's large window rarely fully used despite being available for two years. These are the discussion's temporal observations.

His next frontiers are memory/personalization and world models, the latter relevant to intelligence beyond robotics and games.

Karpathy's “animals versus ghosts” metaphor. These systems are not animals shaped by evolution, intrinsic motives and curiosity; he describes them as statistical simulation from pretraining with reinforcement-learning additions. Anger at a model is unhelpful. A better mental model helps people direct it more effectively.

19. Anti-pattern reference

Avoid	Prefer	Source
Treating AI only as a chatbot	Evaluate coordinated agents and the post-December-2025 workflow	Karpathy
Equating vibe coding with agentic engineering	Distinguish accessibility from professional quality	Karpathy
Assuming every application is a permanent product category	Ask whether a model can perform the job directly	Karpathy / MenuGen
Measuring output only in hours	Assess concurrent work and reliability	Lopopolo / Cherny
Fixing a permanent tool ranking	Reassess volatile tools and dated subsidies	Every / Swyx
Assuming universal harnesses make model swaps trivial	Evaluate switching whole model–harness combinations	Angela
Treating caching and prompts as the only hard problems	Check uptime, sandboxes and fault tolerance	Caitlin
Defaulting to training a model	First fix tool bugs; assess retrieval/ranking separately	Notion
Loading every tool into context	Use tool discovery and progressive disclosure	Notion
Repeated inference for deterministic work	Generate code for an explicit calculation or tool operation	Sachs
Exposing obscure internal formats	Use model-familiar SQL and Markdown where suitable	Simon Last
Providing instructions only for human operation	Provide agent-usable instructions and programmatic interfaces	Karpathy / Swyx
Applying greenfield autonomy claims to legacy systems	Check brownfield transfer separately	Lopopolo
Assuming outsourced thought removes the need to understand	Retain enough understanding to direct and validate	Karpathy
Treating a model as an animal with motives	Use an appropriate account of how it behaves	Karpathy

References and further reading

The original synthesis records complete reading of eleven podcast sources:

AI & I by Every: “Claude Code Can Be Your Second Brain” (Noah Brier); “Why We Switched From Claude Code to Codex” (Dan Shipper and Austin); “The Secrets of Claude's Platform” (Angela and Caitlin at Anthropic).
Latent Space: “Extreme Harness Engineering” (Ryan Lopopolo at OpenAI Frontier); “Monty” (Samuel Colvin at Pydantic); “Notion's Token Town” (Simon Last and Sarah Sachs).
No Priors / Training Data: the accounts of Karpathy on code agents and AutoResearch, the transition from vibe coding to agentic engineering, Boris Cherny's printing-press analogy, and how Cursor trained Composer with Federico and Dima.
Unsupervised Learning: episode 85, “Has AI Infra Stabilized,” with Swyx.

Related notes: the newtype AI-coding guide covers Huang Yihe's Chinese-language 2024–2026 practice. It complements these English-speaking builders' views on programming reasoning and sustained depth of thought. The Claude Code workflow note extends section 15's second-brain pattern.

History

June 5, 2026, version 1.0: created from complete follow-builders podcast digests in the coding-agents topic. Organized across episodes, highlighting four disagreements: Claude Code versus Codex, MCP versus CLI, harness difficulty and agents as infrastructure buyers.

September 26, 2026 addition: share execution infrastructure; design review and maintainer permissions separately

Evidence scope: locally archived, truncated interviews with Logan Kilpatrick (June 11 feed, through 07:18) and GitHub COO Kyle Daigle (June 17, through 08:01). This section is partial. Product details reflect statements made at interview time.

A harness can be shared across products to reduce development cost, while the final experience needs task-specific optimization. Logan estimates the common foundation at about 80%, distinguishing AI Studio coding from a persistent personal assistant. That is a spoken estimate, not an architecture acceptance threshold; the episode title alone does not establish that models will absorb every framework.

As generation becomes easier, review and contribution governance can become the bottleneck. Kyle describes GitHub legal and finance staff building small applications. More entry points bring submissions without automatically increasing maintainers' capacity. His sequence involves agent-assisted review, changes in response to comments, and merging only within permitted boundaries after CI and policy checks. Generated code, successful review and permission to merge are separate states.

Open source adds another layer: companies can constrain staff, whereas maintainers cannot necessarily control all outside contributors. Platforms need admission rules, contribution evidence and permissions that let communities choose their own arrangements rather than imposing one universal sponsorship system.

Questions for product managers: Which execution capabilities are shared? Which tasks need special treatment? Who can initiate, review and approve? How are failure and pending checks displayed? PR volume is not code quality. The interview's seventeen-million figure referred to agent-created PRs in March 2026; fourteen billion annual submissions was a forecast, not a result independently checked here.

September 26, 2026 full-text addition: design agents should support divergence, refinement and review

Evidence scope: the complete Matt Colyer/Figma interview, 00:00–33:52, read in full. The host disclosed owning Figma shares. Future user scale and proactive-agent designs are opinions or plans.

Chat is useful for initial intent but not necessarily for comparing alternatives side by side or positioning elements precisely. Matt uses divergence and convergence to explain the canvas: preserve alternatives, explore style, layout and accessibility, then cluster and choose. Divergent agents should create distinct directions, convergent agents support comparison, and direct manipulation lets designers refine. Some of this remains exploratory; a vision is not a shipped-feature list.

Built-in agents and external agents can be complementary. Design systems supply team components and standards; external agents connect with users' existing code environments. The interview's round trip is code page → editable canvas → design context → implementation branch and PR screenshots → human review. A reviewable implementation is a candidate deliverable, not automatic merge authorization.

Existing workflow context is valuable. The PMOS example combines organizational charts, Slack and project tools into onboarding information, making a manager's tacit relationships readable. Accessibility still needs task-appropriate authorization; it does not permit unrestricted use of all information.

As generation increases, review becomes harder. Screenshots, recordings and a second agent are possible interfaces, but people must understand what changed, why it meets the standard and what remains uncertain. Cheaper generation can make maintenance and acceptance more important. The guest bought more software after experiencing the maintenance burden of his own email agent. Scheduled summaries reduce checking effort, while email drafts still require approval one at a time. Proactivity does not imply unrestricted authority.

Check whether a design product preserves exploratory branches, obeys the design system, supports precise changes, shows implementation differences and separates generation from approval. Taste and curiosity help users challenge outputs rather than accept the first attractive answer.

September 26, 2026 full-text addition: remeasure review and maintenance as code generation accelerates

The AI Vibe Check panel discusses a migrating bottleneck: faster generation can leave teams constrained by understanding, review and upkeep. Measure total cost and elapsed time from requirement to stable delivery. Compare model-plus-environment results, rather than bare-model scores or lines of code.

At the same advertised price, output length, reasoning and retries can change the bill. Compare routing, smaller models and fallbacks on real tasks; rehearse which features degrade first under capacity constraints. The panel's API-outage, closed-model, acquisition and corporate-direction discussions are scenarios or unverified reports, not confirmed announcements. Convert forecasts into dependency exercises before using them to justify migration. Panel source.

September 26, 2026 full-text addition: data-cooperation boundaries; evaluate models and execution environments separately

An AI Vibe Check discussion archived on August 4, 2026 distinguishes ordinary API calls, domain customization, expert samples and shared failure evaluations. Each reveals different information to a supplier. The panel includes unverified company events and policy speculation. This section retains product-analysis questions rather than treating those stories as news facts.

Different depths of cooperation reveal different things. One call is not the same as an editing history, the version a user finally accepts or an expert evaluation dataset. Specify what enters the service, its permitted uses and which domain knowledge creates your advantage. This analysis does not assert that any supplier trains on customer data by default; actual terms need checking.

Value comes from additional information. User revisions, refusals and rare failures may add more information than repeated common successes. The speakers' argument for more data assumes equal quality. Quantity does not replace coverage or feedback quality.

Model selection. Test weights separately from tools, permissions, execution loops and evaluation. A model's results may change with its environment. Open weights do not establish license rights, deployment fitness or safety. A speaker explicitly says there was no evidence for a hypothesized covert supply-chain action; a risk discussion must not become a finding that a model class has a backdoor. Selection still depends on task correctness, actual cost, license text and required controls. Source discussion.

October 8, 2026 addition: track cloud reasoning and local execution separately

Based on remarks by Thariq and Boris Cherny in the October 6–7 Builders digests. This addition uses the captured digest text; it does not claim a fresh review of the original posts or complete podcast transcripts.

A cloud brain with local hands still needs an available device. Thariq separated cloud reasoning from local operations and noted unresolved boundaries around offline devices and synchronization. A completed cloud plan does not prove that the local action ran. Task interfaces should distinguish plan readiness, device reachability, execution and result verification. After reconnecting, establish what happened to the previous action before retrying it.

Editorial recommendation: disconnection is neither proof of success nor necessarily failure. An agent exporting a report locally may have created the file before the network failed, or may have downloaded only part of it. Checking the destination file, task identifier and completion record after recovery can prevent duplicate exports and false completion claims. For messages or changes to external records, query the receipt before retrying an action with an unknown result. This is a product design recommendation derived from the remarks, not a claim that a particular agent implements these capabilities.

Specify three things when delegating. Boris Cherny's October 7 remarks emphasized the goal, effort and verification method. “Compile this month's settled orders, use only the supplied material, and check each amount against the original table” gives clearer stopping and completion criteria than “analyze this carefully.” Verification must match the real objective: creating a file is an intermediate step; complete fields, consistent values and a usable result establish completion.

Scope and limits. Tasks involving local files, browsers or devices need these distinctions. Cloud-only tasks should also check external dependencies; cloud execution alone does not establish continuous availability. A low-risk, one-off draft does not require a complex scheduling system, but it still needs a clear completion criterion.

Sources for this addition

October 15, 2026 update: Validate a source-control migration together with review and operational dependencies

Evidence scope: Anthropic's public engineering post about Scion, read in full. Performance and staffing figures describe the vendor's internal experience, not benefits that ordinary teams can necessarily reproduce. This section focuses on migration and review boundaries.

Why generating more code changes infrastructure needs. Scion serves a very large monorepo, moving work such as history queries and merges to the server while clients fetch file and directory objects on demand. The migration also depends on the Antique review tool, search, and continuous integration (CI: automated build and code-checking workflows). Retrieving code with the new tool is therefore only one part of success. A complete task must also let people find relevant implementations, understand changes, run checks, and complete a controlled merge.

What engineers still need to protect. As the post explains, engineers remain valuable while the nature of their work changes. When agents can produce implementations quickly, engineers still need to define system constraints that must hold, explain tradeoffs, and identify unnecessary complexity. Review should check whether the implementation matches the original intent and whether it shifts costs or failures to downstream systems, as well as whether the code runs.

Editorial application: Validate the migration with a complete task. Choose a real task that includes searching, editing, review, automated checks, and merging; identify the dependencies and owners at each step. Faster code retrieval does not mean the migration is complete if reviewers lose access to history or automated checks stop working. Test against your own repository size and workload before deciding whether to migrate. Do not redesign an ordinary team's toolchain solely because of a vendor's internal performance multiples. See enterprise AI delivery responsibilities for the related discussion.

Source: Anthropic: Redesigning source control.

Case: Use AI-generated tools to support learning and acceptance testing

This case draws on the October 2 Builders accounts of posts by Thariq and Guillermo Rauch. The prototypes were not independently tested and the demonstrations were not watched in this review. Personal experiences are not efficiency guarantees.

To improve a game's jumping animation, Thariq asked Claude to teach concepts, find references and generate an animation editor for repeated adjustment. Rauch experimented with having an application explain the implementation behind its features step by step. These examples extend the existing discussion of human judgment and taste: ask AI to create a small tool that makes comparisons and experiments easier, so that the object of judgment becomes concrete.

An editorial application is to choose one observable quality problem, fix the reference and comparison conditions, and adjust only a few parameters at a time. Record which version is closer to the goal and why. For code, ask for the key implementation choices and constraints, then check the explanation against tests and actual execution. A fluent explanation does not prove correctness, and a working animation editor does not establish that the whole game experience is good. This approach suits local problems requiring repeated comparison; a simple one-off change does not require a complex new tool.

October 21, 2026 addition: separate planning, isolated execution and independent challenge

Peter Steinberger reports a concrete division of work: Astra plans and runs Codex CLI in separate worktrees, Sol 6.1 codes, and another agent supervises and challenges the planner. This differs from having the same agent read a goal text to review itself. He wrote an OC plugin for this “smart goal” arrangement. The post provides one author’s experience, without complete plugin code, a comparison task set or performance data. It does not establish that subagents are generally inferior.

The transferable idea is a boundary between responsibilities. The planner explains the goal and current approach; the executor delivers actual files in an isolated directory; the reviewer checks whether the deliverables answer the goal, whether the evidence is sufficient and whether the work has drifted. Separate directories can reduce overwrites without eliminating errors. A second agent’s objections still need checking against file changes and execution results. This arrangement is most relevant when deliverables can be defined clearly and justify coordination costs; small changes do not automatically need another supervisory layer.

Source links and related public notes

October 22, 2026: Match Code Understanding and Accountability to Consequences

AI lowers the cost of generating code without removing the consequences of maintenance, data leakage or incorrect deployment. A useful distinction in Shensi’s account of Guillermo Rauch’s remarks is between personal experimental tools and systems carrying other people’s data or critical operations. They require different depths of understanding and acceptance. The point is not that every user must rewrite all the code. Someone responsible for the consequences must be able to explain critical data flows, permission boundaries and failure behavior.

A practical project can list its worst plausible outcomes before choosing review depth. A prototype restricted to disposable test data in an isolated environment can use a lighter feedback loop. Once real user data, persistent writes or external services are involved, the team should identify critical paths, recovery behavior, permissions and an accountable handoff owner. This is the site’s suggested application; calling a project a small tool does not reduce its actual impact.

Deployment shares, migration times and forecasts of provably correct code have not been checked against the original interview in this batch. They are not treated as measured improvements or safety guarantees. Sandboxes, tests and proofs cover different properties, and passing a check supports only the conditions it covers. This complements independent challenger review by asking who bears the consequences and which parts must be explainable.

Source: Shensi’s Chinese account of an interview with Guillermo Rauch.