Every company should have a Brain — Garry Tan, Y Combinator

Actionable Insights

• Build a small company brain before trying to automate the company. Start with a repo such as company-brain/ containing README.md, skills/, refs/, evals/, and scripts/. Put only high-leverage institutional knowledge into it: how to ship, how to handle support escalations, how to run finance/reporting, and how to prepare customer artifacts. The first milestone is not 400X productivity; it is one repeatable workflow that a new teammate or agent can execute from written procedure. Evaluate by time-to-complete, rework rate, and whether a second person can run it without tribal knowledge.

• Use resolver tables as routing infrastructure. Garry’s most concrete pattern is a resolver table: when the task mentions tests, load tests.md; when it touches pricing, load pricing.md; when it changes a customer email, load support-tone.md. Implement RESOLVER.md with columns trigger, load, owner, last_eval, and do_not_use_when. Test it with prompts that should and should not route to each file. Caution: resolver sprawl becomes a second undocumented system unless it has owners and trigger evals.

• Separate nondeterministic judgment from deterministic execution. Around 9:12, Garry distinguishes model space from deterministic space. Put fuzzy interpretation, summarization, and prioritization in the LLM; put accounting math, database migrations, billing, tests, and policy checks in code. First step: for every agent workflow, mark each step LLM or code. Move anything that needs reproducibility into scripts or typed services. Evaluate by rerunning the same workflow and checking output variance.

• Add performance reviews for skills, not just more skills. The talk maps trigger evals to performance reviews. Create eval cases that ask: did the agent load the right skill, avoid unrelated skills, produce the expected artifact, and pass deterministic checks? Run these on every model upgrade. This directly addresses the strongest commenter critique: verification is the missing bridge between “vibes” and engineering.

• Treat productivity multipliers as hypotheses, not planning constants. Garry’s 400X rhetoric is motivating but risky. For your team, instrument baselines: cycle time, PR review defects, customer-response time, escaped bugs, and revenue per employee. Run a 2–4 week pilot on one workflow and compare assisted vs unassisted throughput. Do not use generated lines of code as the primary metric; it rewards verbosity and can hide maintenance cost.

• Make non-engineer automations safe through templates and approvals. The finance example is compelling: non-programmers can collapse spreadsheet work into apps or cron jobs. Provide templates for safe automations: read-only data connectors first, dry-run mode, audit logs, owner approval, and rollback. Evaluate whether the automation reduces manual work without increasing compliance or data-quality incidents.

Core thesis

Garry argues that AI-native companies gain leverage not mainly from better models but from how they wire work: skill files as employees, resolver tables as org charts, process files as operating procedures, and evals as performance reviews. Every company, in this frame, needs a “brain” that agents can use as institutional memory and routing logic.

Big ideas / key insights

• The same model can produce radically different results depending on workflow design.
• Markdown files, references, and routing tables become a lightweight management layer for agents.
• AI-native organizations shift employees toward managing agents and maintaining procedures.
• Deterministic code and nondeterministic model calls should be separated deliberately.
• Huge productivity claims need real verification; generated LOC is a weak proxy for value.

Best timestamped moments with interpretation

• 0:31–2:33 — Garry introduces the productivity claim, then partially deflates it from 400X to a claimed floor/middle range. This is rhetorically strong but methodologically thin.
• 3:03–3:35 — The key claim: people with the same Claude achieve different leverage because the wiring differs, not because the model differs.
• 4:06–5:39 — The organization analogy becomes concrete: skill file = employee, resolver table = org chart, filing rules = process, trigger evals = performance reviews.
• 6:10–7:10 — YC company examples are used to argue that revenue per head is changing. These examples are hard to verify from transcript alone and should be treated as claims.
• 7:40–8:11 — Non-engineers at YC are described as building skill files and cron jobs, broadening the thesis beyond software teams.
• 9:12–10:14 — The nondeterministic/deterministic split is the most operationally important engineering advice in the talk.

Practical takeaways / recommended workflow

1. Choose one painful recurring workflow and encode it as a skill plus references.
2. Add a resolver table with explicit triggers and anti-triggers.
3. Put deterministic checks in code, not prose.
4. Add trigger/output evals before expanding to more workflows.
5. Measure value with cycle time, error rate, and handoff quality rather than generated LOC.
6. Give every skill an owner and review cadence.

Comment insights

The comments are sharply polarized. Supporters argue that Garry explicitly caveats his 400X number and that even an 8X floor would be meaningful. Skeptics object to the guru-like tone, lack of detailed verification, and perceived AI-generated delivery. The most valuable technical pushback says no one explains what verification looks like in detail; that critique is valid and should shape implementation. Several comments focus on social signaling around San Francisco/YC rather than the workflow mechanics.

Deep research on the creator’s main claims

• AI coding productivity is real but variable. Public studies and industry reports disagree on magnitude. Some controlled studies show speedups for certain tasks, while METR’s 2025 study on experienced open-source developers reported AI tools made participants slower on selected issues despite users believing they were faster. This contradicts treating 400X as generalizable.
• Lines of code per day is a weak productivity measure. Software engineering research has long warned that LOC rewards verbosity and ignores correctness, maintainability, review load, and product value. Garry partially acknowledges this by discounting scaffolding, but the metric remains fragile.
• Agent skills and evals are becoming real infrastructure. Related talks and SkillsBench-style work support the idea that procedural knowledge plus evaluation can improve agent performance. That supports the company-brain pattern more than the extreme multiplier claim.
• High revenue per employee exists but causality is hard. YC’s internal company metrics may be true, but the transcript itself admits AI-generated code cannot be proven to have caused growth. Market timing, product-market fit, pricing, and team quality are confounders.

My verdicts on major claims

• Claim: leverage is in workflow wiring, not only model weights. Verdict: agree, high confidence. Tooling, context routing, deterministic checks, and process design strongly affect agent usefulness.
• Claim: 400X individual productivity is achievable as a general expectation. Verdict: disagree/mixed, low confidence. It may describe an anecdotal or metric-specific case, but it is unsafe as a planning assumption.
• Claim: every company should maintain a brain-like operational knowledge repo. Verdict: agree, medium-high confidence. The idea is practical if scoped, owned, and evaluated; it becomes dangerous if treated as magic automation.
• Claim: non-engineers can manage agents and cron jobs. Verdict: agree with cautions, medium confidence. This works when templates, permissions, dry runs, and approval gates are in place.
• Claim: AI-native startups can support much higher revenue per head. Verdict: mixed, medium confidence. There are credible anecdotes, but causality and survivorship bias remain unresolved.

Screen-level insights

• 0:31 and 1:01 frames — Garry is onstage without slides while setting the revolutionary framing. The lack of visual detail makes the transcript evidence more important than screen artifacts here.
• 1:32 and 2:03 frames — The productivity-number section is delivered as a personal comparison between 2013 and today. It matters because the claim is anecdotal and metric-dependent.
• 3:03 frame — The transcript context says same Claude, different outcomes; this is where the talk shifts from model capability to work design.
• 4:38 frame — Resolver tables are explained as an org chart for context loading, the most actionable visual/conceptual element.
• 6:10 frame — YC company examples appear; treat them as claims unless independently verified.
• 7:10 and 8:11 frames — The batch-room and finance-staff examples show the thesis extending outside engineering.
• 9:12 and 10:14 frames — The deterministic/nondeterministic split is connected to concrete work allocation: let the model infer human intent, but let code handle exact computation.

My read / why it matters

The talk is best read as an organizational design pattern, not a proof of 400X productivity. The useful part is surprisingly mundane: write down procedures, route context, add evals, and keep deterministic work deterministic. That is enough to be worth doing even if the multiplier rhetoric is inflated.

Verification notes

Four passes completed: source/evidence audit, transcript/comment/frame fidelity audit, hallucination/overclaim audit, and Actionable Insights audit. The top section was checked for concrete workflows, files, evals, metrics, and cautions. I explicitly downgraded unsupported claims about YC company performance and 400X productivity, incorporated commenter concerns about verification, and cited broader external evidence that AI productivity effects vary. Residual uncertainty: YC-specific revenue/head and batch statistics require primary YC data for firm verification.