# Conclusions

**Source:** https://www.youtube.com/watch?v=FU5_kpTAVDo
**Title:** Agentic Engineering, explained by a 10x developer
**Duration:** 42:33
**Speaker:** Thorsten Ball — founding engineer at AMP (Sourcegraph), author of the "Writing an Interpreter in Go" / "Writing a Compiler in Go" books
**Interviewer:** David Andre

---

## Core thesis

**The whole shape of software work has changed.** Models are now so capable that the interesting variables are no longer "which model" or "how do I read every line of code", but:
1. **Where does the information live** that the agent needs?
2. **How agent-friendly is your codebase / workflow?**
3. **What do you actually want to build** (not how to build it)?

The winners will "shed weight" — kill features, kill IDE plugins, kill local dev, kill CI-that-repeats-the-agent's-tests — anything that only made sense before agents. **99% of AMP itself is now written by AI.** Slop is a human-taste problem, not an AI problem.

> "You will get a button with which you can spawn a John Carmack that writes the code for you."

---

## AMP's operating principle: stay on the frontier, shed weight

- Bet from day one: **don't optimize for what looks safe today, optimize for the ability to move fast tomorrow.**
- Could have made a lot of money in 2025 by building "single agent in a VS Code sidebar with enterprise permission system + per-line attribution" — but the whole model would have been obsolete in a year.
- Instead: aggressive killing of own features on `ampcode.com/news`.
  - Killed VS Code extension → "who has the editor open anymore?"
  - Willing to break users out of their comfort zone; some churn, but customers who stay respect the pushing.
  - Company officially: "AMP Frontier Corporation."
- **Customer question they get most:** "guys, what's the meta? What model, what prompt?" — because customers are paying for the research decisions, not just the software.

---

## Model choice: stop tweaking, focus on getting stuff done

- Once you have Fable 5 / GPT-5.6 Sol / equivalent, **diminishing returns on which one you pick.**
- If you're mad your model doesn't use camelCase, **rethink your software engineering**, not the model.
- The dominant variable in output quality is now **the information you put in**, not the specific model or the level ("medium" vs "high" vs "ultra").
- Default recommendation: pick a good model, focus on the work. Fiddling with GLM 5.2 vs Fable in your free time is fine as a hobby but not where value comes from.

---

## Kill the backlog

**Old world:** bug reported → put in backlog → weeks later someone decides it's worth doing → estimate → maybe fix.

**New world:** *"Why don't you optimistically spawn these agents and have them parked somewhere, then go through them and look at the bug fixes?"*

You no longer need to estimate whether a bug is worth fixing if the fix is running while you sleep. Backlogs are an artifact of expensive humans.

---

## Kill CI that just re-runs what the agent already ran

- The agent is already in an isolated sandbox.
- It's already running the tests.
- Then you push and let CI run the same tests for another 10 minutes?
- **Rethink from first principles.** A lot of pre-agent process is now waste motion.

---

## Slop comes from humans

- "Most of slop comes from humans not having good product. With AI they can just build trash products faster."
- AMP internally: Thorsten polled the team on how much code they write by hand. Options were 99%+, 90-99%, and <90%. He didn't even think anyone would be under 80%. One engineer (Camden) said "I still write a bunch by hand." When pushed: "OK, probably 95%."
- Thorsten's use of AI for the orb icon: had AI generate **15 different versions in different colors** (Braille characters, different styles, 18 palettes). He picked the one he liked. That's "human taste at AI speed" — not slop.
- Same pattern for AMP news posts: him + Tim + Brad going turn-by-turn in Midjourney, reading Moby Dick, "combining Moby Dick and orb in my head."
- **Slop = lack of ideas, lack of playfulness, lack of knowing what you want to exist.** Not an AI defect.

---

## Building an AI startup today

Same question, same answer as before AI: **what's the market, who's the customer, how do you serve them, how do you sell?**

- Software as "the thing itself" is less valuable now — code is cheap, open-source contribution graphs are worth almost nothing.
- The lucky overlap of the last 20-30 years — "the guy who loves Haskell on weekends is also the guy who models the finance backend well" — is disappearing. Fable is good at that stuff now.
- What senior engineers used to hand-teach in 2-3 years (e.g. the safe multi-step column-drop migration) is now a 30-second model output.
- So the question shifts up: **what do you want to get done?**

---

## Build for the agent, not the human (a new product philosophy)

- If starting a new product on the frontier: **no human should have to fill out forms.**
- Anything a human can do on your site, they should be able to have an agent do.
- Ideally: **bring your own agent** — nobody wants to use your shitty built-in agent.

### The admin panel that dies

Thorsten built a food-ordering app in an "orb" at a local club (menu photo → working app → shared URL, 3 × 5 min iterations).

- The agent also built an admin interface to edit menu prices and spellings.
- Thorsten: *"I'm never going to open that. I'll just send another photo and say 'fix the pricing.'"*
- **A lot of admin UI existed only so no code had to change** — now it's easier to just change the code.
- Same for WordPress-style dashboards: "here's my draft, add this header image, publish, spell-check" — one sentence, no clicking.

---

## The Emacsification of software

He references a blog post about "the Emacsification of software" — Emacs users historically fork plugins, rewrite them for their config, never contribute back.

Same is happening now:
- Thorsten forked a diff viewer called **hunk**, pointed AMP at it, said: "add Gruvbox dark hard theme, add file-checkoff in sidebar, compile, drop it in `~/bin`." Two minutes of agent time.
- No reason to upstream — the change is bespoke to him.
- Prediction: much more of this. Not just individuals — teams and companies will remix mid-sized software (his example: "I want Riverside but audio-only" or "video-only").
- The blast radius will keep expanding.

---

## Explosion of internal software

- Before: internal software = one Excel file, one wiki page, one hacky script.
- Now: at his club (20 people), he encoded the ordering process in software in ~2 hours of phone-typing.
- **When people realize they can do this in companies, it replaces the Excel/wiki/hack layer.**
- Two variables that will separate winners from losers:
    1. Knowing how to use agents.
    2. Having the token budget to do it.

> "You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."

---

## First-principles thinking becomes the top skill

Anti-example from Sunday's club:

- Someone: "Can you build an app so a tablet prints a paper receipt the kitchen picks up?"
- Thorsten's push-back: *"Why do you need a printer? Why not a second tablet?"*
- The real skill: seeing the workflow underneath the request. Everyone becomes an architect; the value is **knowing solutions from other industries and having the right idea** for this problem.

---

## Don't compare yourself to the 1%

- Online debates always cite Mitchell Hashimoto (Ghostty) as "AI still isn't good enough for him."
- Yes — but Mitchell is one of the best programmers alive, working on a GPU-accelerated terminal emulator. That's not most software.
- Most software is CRUD apps, "MySQL and something-something." **Agents handle it fine.**

---

## AMP's setup — what it looks like today

- **Install:** `ampcode.com` as a PWA (Thorsten thinks the acronym PWA is what's blocking mass adoption of the install flow).
- **Model dial:** low / medium / high / ultra, each level maps to a model + sub-agent choice.
    - Sub-agent named **"Oracle"** (reviewer, gives advice).
    - Sub-agent named **"Painter"** (generates images).
    - Meta-agent named **"Puck"** (can control other agents, spawn orbs, message them, run flows).
- **Default:** medium (Sol at balanced level) — no need for Fable in the mix unless the task warrants it.
- **Multi-model:** GPT models, Anthropic models, GLM models all supported.

---

## Orbs — the multiplayer, headless-sandbox unit of work

An **orb** = a remote sandbox tied to one conversation:

- Sandbox goes to sleep when idle, wakes on typing.
- Streams to phone, laptop, TUI — same conversation, any device.
- **One URL packages: the thread + the agent + the computation + the diff.**
- Share the URL → your teammate opens the orb and takes over.
- Multiplayer is landing (agent-to-agent communication went live "last Friday").

### Why orbs kill the "cloud IDE" objections from 10 years ago

Old objections to cloud IDEs (Cloud9 etc.): latency, key bindings, "I can't SSH in," missing language servers.

Now: **who cares about latency when you're waiting for tokens/sec anyway?** Nobody uses language servers, editors, key bindings the same way. The whole objection stack collapsed.

### Async by default

- Delegate a task → orb takes 16 minutes → doesn't matter, you're doing something else.
- Live example from the interview: Twitter user asked "can orbs run Rust cross-platform desktop framework?" Thorsten prompted Puck → Puck spawned an orb → 16 minutes later, screenshot proof.
- Quinn's tweet (AMP CEO): *"You're async anyway — so ask the agent to give you proof."* Screenshots, benchmarks, dark-mode + light-mode variants, 50 tests in parallel.

---

## How Thorsten prompts

- **No custom slash commands, no skills, no MCP servers.**
- The one thing that matters: **where does the agent get its information from?**

Agents have two information sources:
1. **Training data** — a "senior engineer who's seen it all," but lossy and possibly stale.
2. **The context window** — everything you tell it, plus what the codebase and `AGENTS.md` provide.

If your prompt / codebase / AGENTS.md is thin, the model can't turn a bad prompt into a good one.

### Prompt structure Thorsten uses (paraphrased from the "port Puck to CLI" example)

- **Set the standard:** "look at how it's implemented in web UI."
- **State intent:** "I want to port this to our CLI."
- **Riff on the design:** "have a `puck open` command that uses the command palette; show up in the sidebar; maybe a `puck clear`; think about whether we need a new TUI modality."
- **Explicit process:** "research how it's implemented, research how we communicate what it does (look at the news post), document how it works, sit down and think, compile what you learned, then come up with a good idea."
- **Sub-agent economics:** "use sub-agents for implementation — Fable is expensive, it scares me. So use GPT models for the implementation. Then present the results."

Key phrase: *"This is how I would talk to a senior engineer. This is the Slack message I'd send."*

---

## Concrete velocity change at AMP

- "Shipping velocity went up" in the past 4 weeks.
- Designer Tim: "never fixed so many paper cuts as in the last two weeks" — screenshot a bug → send to AMP → orb comes back with fix → spot check → merge.
- Agent-to-agent: if the current agent says "I found another bug", Thorsten replies "launch another orb to fix it" — spawns a new checkout, new branch, new agent, in parallel.

---

## Live demo shipped during the interview

- Iterated on Puck orb variations, added them to the site, updated copy.
- Asked for a screenshot for verification.
- **Shipped to production during the podcast**, live.

---

## Predictions (his end-of-interview list)

1. **Local dev effort is going away** — orbs / remote sandboxes replace it.
2. **The distinction between models will matter less** — "John Carmack on a button."
3. **Unclear what software will survive** — remixability + custom versions per user erode the moat of general-purpose SaaS.
4. **Infra margins get eaten** — 15+ sandbox providers already racing to zero. That's not sustainable either.
5. **We are all moving up a level of abstraction** — a lot to build; nobody yet knows the shape.

---

## Cross-cutting principles

- **Optimize for shedding weight**, not for feature accumulation.
- **Information > tuning.** What's in the context window matters more than which model is picked.
- **Talk to the model like you'd Slack a senior engineer.** Standard, intent, riff, process, constraints.
- **Async by default.** Ask for proof (screenshots, benchmarks, dark/light) since you're waiting anyway.
- **Kill the human-only artifacts** — backlogs, admin panels, VS Code extensions, redundant CI.
- **Package thread + agent + computation + diff in one URL.** Sharable, multiplayer, resumable.
- **First-principles thinking > technical detail knowledge.** Everyone is an architect.
- **99% AI-written code is compatible with high taste.** Taste is human input, not human keystrokes.
- **Don't benchmark yourself against Mitchell Hashimoto.** Most software isn't Ghostty.

---

## Actionable takeaways

- [ ] Pick one good model and stop tuning between them for the rest of the week
- [ ] Delete one workflow that only made sense pre-agents (backlog triage, CI-repeat-of-agent-tests, VS Code extension you don't use)
- [ ] Try running one agent in a **remote sandbox** rather than locally — see what your objection actually was
- [ ] Instead of a form/admin panel, prompt the agent directly on the codebase (Thorsten's food-app example)
- [ ] For your next non-trivial prompt, spend 3× longer on **context / references / standards** and no time on model choice
- [ ] Ask an agent for **10-15 variations** of a design decision instead of "the answer" — pick with human taste
- [ ] Set up async parallelism: "launch another orb / branch to fix that side-bug while you continue"
- [ ] Ask agents for **screenshots, benchmarks, dark+light-mode proofs** as verification — you're async anyway
- [ ] Try one "Emacs-style" remix: fork some OSS tool → have the agent add your bespoke features → run it locally, never upstream
- [ ] Draft a company-internal doc titled "Software Is Dead — Now What?" and be honest about which of your processes only survive because humans used to be the bottleneck

---

## Who this is for

- Engineers still hand-coding at 2024-era velocity, wondering what actually changed
- Founders / EMs deciding whether to bet on agent-native tooling vs incremental IDE plugins
- Product people asking "should we build for humans or agents?" — the answer is both, but the bias should shift
- Anyone still deeply invested in local dev environments, backlogs, or IDE workflows and wondering what's next
- Anyone starting an AI product now and wondering what the actual moat becomes
