This commit is contained in:
EugeneTes
2026-07-30 11:13:27 +02:00
parent 2685fc9ba2
commit 62d0f06a2d
40 changed files with 1502 additions and 47 deletions

View File

@@ -0,0 +1,40 @@
# Async by Default (Orbs and Proof)
#concept
## Summary
If agent work takes sixteen minutes and you are doing something else, latency stops being a cost. [[thorsten-ball]]'s working mode: delegate into a **remote sandbox**, walk away, run several in parallel, and — since you are waiting anyway — **ask the agent for proof** rather than a claim of success.
## Current Understanding
**The orb.** [[amp]]'s unit of work is a remote sandbox tied to one conversation. It sleeps when idle and wakes on typing; it streams to phone, laptop and TUI as the same conversation; and **one URL packages the thread + the agent + the computation + the diff**. Share the URL and a teammate opens the orb and takes over. Agent-to-agent messaging turns this multiplayer: "I found another bug" → "launch another orb to fix it" → new checkout, new branch, new agent, in parallel.
**The old objections collapsed.** Cloud IDEs (Cloud9 and friends) died on latency, key bindings, "I can't SSH in," and missing language servers. Thorsten's rebuttal: *who cares about latency when you're waiting for tokens per second anyway?* — and nobody uses editors, key bindings or language servers the way they did when those objections were formed. The objection stack was about a workflow that no longer exists.
**Ask for proof.** Quinn (AMP's CEO): *"You're async anyway — so ask the agent to give you proof."* Screenshots, benchmarks, dark-mode *and* light-mode variants, fifty tests in parallel. This is the delegation-side counterpart to [[make-more-cheap-code]]: cheap generated artifacts exist to make a claim checkable, and asking for three of them costs you nothing when you are not sitting there watching. In practice at AMP: screenshot a bug → send it → an orb returns a fix → spot check → merge; the designer "never fixed so many paper cuts."
**The prediction.** Local dev effort goes away, replaced by remote sandboxes — with the caveat that 15+ sandbox providers are already racing margins to zero, which Thorsten himself calls unsustainable.
## Evidence
- Orbs, sleep/wake, one-URL packaging, multiplayer handoff, the 16-minute live demo, the collapsed cloud-IDE objections, Quinn's proof line, paper-cut velocity, local-dev prediction, infra-margin prediction — [[2026-07-28-agentic-engineering-10x-developer]].
- Fire-and-forget as a native harness mode; completion notifications as what makes background agents usable — [[2026-07-14-skills-based-on-git]], [[harness]].
- Scheduled agents producing while you sleep (the non-engineer version) — [[personal-ai-operating-system]].
## Related Pages
- Concepts: [[harness]] (async is one of its two modes), [[agentic-loops]], [[make-more-cheap-code]] (proof artifacts are throwaway code with a job), [[shedding-weight]] (async is what makes killing the backlog possible — parked agents replace queued tickets), [[personal-ai-operating-system]], [[context-as-scarce-resource]]
- Entities: [[thorsten-ball]], [[amp]], [[claude-code]]
## Contradictions / Uncertainty
- **Attention, not latency, is the real budget.** Five parallel orbs produce five diffs that a human must still review; [[make-more-cheap-code]] argues reading is the scarce resource. Async multiplies generation without multiplying review capacity, and the source does not address the pile-up. Status: tentative — this is the same open question logged on [[make-more-cheap-code]] about reviewing *agent behaviour* becoming the new attention sink.
- **Proof is produced by the thing being checked.** A screenshot from the agent that made the change is evidence, not verification; the failure mode where an agent produces a convincing artifact of work it did not do is unaddressed.
- **Remote sandboxes vs compliance.** Code and conversation in a vendor's cloud is exactly what [[enterprise-ai-reality|locked-down enterprises]] forbid. Also sits against [[eugene]]'s consolidated *local* workspace pitch ([[harness]]) — though the two are compatible if the consolidation point is the interface rather than the compute.
- "Local dev is going away" comes from a company selling remote sandboxes. Status: tentative.
## Next Questions
- What is the non-engineer's orb? The corpus has scheduled workflows (Allie) and completion notifications (Eugene) but nothing that packages a resumable, shareable unit of work for a non-technical user.
- Which proofs actually catch drift? If [[leave-less-room-for-imagination|the damage is what you don't notice]], a screenshot proves the happy path and nothing else — the proof list needs a design, not just a habit.

View File

@@ -0,0 +1,37 @@
# Build for the Agent, Not the Human
#concept
## Summary
A product philosophy from [[thorsten-ball]]: if you start something on the frontier today, **no human should have to fill out a form.** Anything a human can do on your site, they should be able to have an agent do — and ideally they should **bring their own agent**, because "nobody wants to use your shitty built-in agent."
## Current Understanding
- **The admin panel that dies.** Building a food-ordering app from a photo of a menu, the agent also produced an admin UI for editing prices and spellings. Thorsten's reaction: *"I'm never going to open that. I'll just send another photo and say 'fix the pricing.'"* The insight underneath it is general: **a lot of admin UI existed only so that no code had to change.** Once changing code is cheap, the UI layer built to avoid changing code is pure [[shedding-weight|weight]].
- **The same for content dashboards.** WordPress-style admin: "here's my draft, add this header image, publish, spell-check" — one sentence instead of a session of clicking.
- **Bring your own agent** is the sharp part, and it cuts against most 2026 product roadmaps: the differentiator stops being *your* assistant and becomes whether your surface is drivable by *the user's* assistant. That makes agent-accessibility a product feature rather than an integration checkbox.
- **Consequence for moats.** If every surface is agent-drivable and every agent can remix software ([[emacsification-of-software]]), general-purpose SaaS loses the lock-in that UI familiarity used to provide. Thorsten's own prediction list says it plainly: it is unclear what software survives.
**Read carefully, this is not "no UI."** The claim is that UI built as a *substitute for changing the system* dies, and UI built as a genuinely better interface survives. The distinction matters for the webinar's [[personal-ai-operating-system|OS framing]], where the endpoint is a *smaller* interface (a button that already knows what the email said) rather than no interface — arrived at from the opposite direction: Thorsten deletes UI so he can prompt, the OS framing builds tiny UI so you need not prompt. Both are the same underlying claim that the generic chat box and the generic admin panel are the two things being squeezed out.
## Evidence
- "No human should have to fill out forms," bring-your-own-agent, the food-app admin panel, the WordPress example — [[2026-07-28-agentic-engineering-10x-developer]].
- Erosion of software moats via remixability (prediction 3 in the same source).
## Related Pages
- Concepts: [[shedding-weight]] (the parent move), [[emacsification-of-software]], [[explosion-of-internal-software]], [[personal-ai-operating-system]] (the interface question from the user's side), [[async-by-default]]
- Entities: [[thorsten-ball]], [[amp]]
## Contradictions / Uncertainty
- **Who operates the software if forms die?** Thorsten's answer is "prompt the agent" — which assumes exactly the prompting competence the corpus's HR interviews identify as the real bottleneck ([[levels-of-ai-usage]], and Nina/Yulia's *friction, not resistance* finding). An admin panel is a poor interface for an expert and a good one for a beginner. Status: tentative.
- "Bring your own agent" is asserted by someone who sells an agent; the business model that survives universal BYOA is not addressed.
- No account of authorization: an agent-drivable surface is also an agent-*abusable* surface, and the source says nothing about permissions, rate limits, or attribution.
## Next Questions
- What is the minimum an existing product must expose to be genuinely agent-drivable — an API, an `AGENTS.md`, structured error messages, or something else?
- Does the webinar audience want fewer forms or *better* forms? Worth asking directly, since it decides whether the OS pitch lands as liberation or as loss of a familiar surface.

View File

@@ -16,6 +16,11 @@ When the cost of writing code trends to zero, code stops being a precious asset.
- **The trust carve-out.** Eugene puts a date and a boundary on it: "Code isn't something elite anymore. From 4.6 on, the code is safe enough — though **authorization and payments** I still wouldn't trust to Claude." Cheap code does not mean uniformly trusted code; the exceptions are where a silent error is unrecoverable rather than merely wrong. Consistent with the safety-critical exception noted below.
- **The production datapoint.** [[thorsten-ball]] reports **99% of [[amp]]'s code is written by AI** — the corpus's only figure from inside a shipping company rather than an individual workflow, and the strongest available answer to "does this survive contact with a real product?" He polled his team offering 99%+, 9099% and <90%; the one engineer who said he still wrote "a bunch" by hand landed at ~95% when pushed. Self-reported, and from a company that sells an agent — but specific.
- **Slop is a human problem.** "Most of slop comes from humans not having good product. With AI they can just build trash products faster." Slop = lack of ideas, lack of playfulness, not knowing what you want to exist — *not* an AI defect. His counter-demonstration is taste at AI speed: 15 generated icon variants across styles and 18 palettes, one picked by hand. This converges with Theo's anti-slop stance from a different direction — Theo defends cheap code with *verification discipline*, Thorsten with *taste* — and both reject the vibe-coder reading of this page.
- **The lifetime boundary.** [[2026-07-29-what-if-we-vibe-code-it]] adds the third cost besides writing and verifying: **maintenance**. Throwaway code is safe *because it is never maintained* — the trap begins at the first user, which converts code into a service ([[maintenance-is-the-real-cost]]). "I can write it in a week ≠ it's worth writing" is Theo's ship/no-ship line restated over the artifact's lifetime rather than at review time.
Caveat: legacy/hobby niches persist (COBOL in banks — no training data; coding "for the love of it, like an old-timer car") — but not where time, quality, and money matter.
## Evidence
@@ -24,15 +29,18 @@ Caveat: legacy/hobby niches persist (COBOL in banks — no training data; coding
- Kill code without guilt, guilt-merging, G-brain markdown tier — [[2026-07-14-everything-we-knew-about-software-has-changed]].
- "Code isn't elite anymore" from 4.6 on; authorization and payments withheld; browser-over-emulator testing note — [[2026-07-21-larysa-interview]].
- Ship/no-ship line, four tiers, 100-lines-of-slop-per-shipped-line, "make more cheap code" — [[2026-07-24-youre-reading-way-too-much-code]].
- 99% AI-written at AMP; the hand-coding poll; "slop comes from humans"; the 15-icon-variant workflow — [[2026-07-28-agentic-engineering-10x-developer]].
- Writing was never the bottleneck; cost of software = maintenance; "can write in a week ≠ worth writing" — [[2026-07-29-what-if-we-vibe-code-it]].
## Related Pages
- Concepts: [[make-more-cheap-code]], [[product-ownership]], [[think-wider-not-bigger]], [[skills-as-memory]], [[decoupling-identity-from-profession]], [[leave-less-room-for-imagination]]
- Entities: [[theo-browne]], [[sebastian]], [[eugene]]
- Concepts: [[make-more-cheap-code]], [[maintenance-is-the-real-cost]] (the lifetime boundary), [[product-ownership]], [[think-wider-not-bigger]], [[skills-as-memory]], [[decoupling-identity-from-profession]], [[leave-less-room-for-imagination]], [[emacsification-of-software]] (cheap code makes the bespoke fork rational), [[explosion-of-internal-software]], [[shedding-weight]]
- Entities: [[theo-browne]], [[sebastian]], [[eugene]], [[thorsten-ball]]
## Contradictions / Uncertainty
- "Most code isn't high-value" is a generalization; safety-critical/regulated code is a clear exception (see [[enterprise-ai-reality]]).
- The 99% figure is self-reported by a founding engineer at the company selling the agent, and describes a codebase whose authors are all expert users of that agent. It bounds what is *possible*, not what is typical. Status: tentative.
## Next Questions

View File

@@ -18,6 +18,10 @@ Context pressure explains several otherwise-separate design choices:
The human role has climbed prompt-engineer → **context-engineer** → harness-builder → loop-engineer, tracking exactly this concern.
**Information beats tuning** ([[2026-07-28-agentic-engineering-10x-developer]]). [[thorsten-ball]] states the strongest version: once you have a frontier model, **the dominant variable in output quality is the information you put in** — not which model, and not the effort level (medium vs high vs ultra). "If you're mad your model doesn't use camelCase, rethink your software engineering, not the model." He names the agent's only two information sources — **training data** (a senior engineer who's seen it all, but lossy and possibly stale) and **the context window** (your prompt, plus whatever the codebase and `AGENTS.md` supply) — and the operative asymmetry: a model cannot turn a thin prompt into a good one. Note what he does *not* conclude: the fix is a better-tended codebase and a longer prompt, not [[skills-as-memory|skills]] (contested there).
**Context now has a price — at fleet scale.** The same source names **token budget** as one of two variables separating winners from losers, alongside knowing how to use agents. Context has always been scarce per-request; this is the corpus's first claim that it is also scarce per-*wallet*. Scope, corrected 2026-07-28: the claim comes from **metered** usage (parallel remote sandboxes), and under a flat consumer subscription the corpus's own heavy users report no ceiling — so per-request scarcity remains the binding constraint for individuals, and per-wallet scarcity is a fleet and enterprise concern. See [[enterprise-ai-reality]] and [[explosion-of-internal-software]].
**The supply-side facet** ([[2026-07-22-ai-is-stupid]]): before context is *scarce* it is usually *absent*. "Intelligence without context loses to context without intelligence" — ten Nobel laureates asked about your sales month can only cite industry averages, while your rank-and-file employee answers better because they see your funnel, clients, and deals. The default "stupid AI" experience is a strong model given neither business context nor a [[harness]]; the fix is investing in context infrastructure (data, memory, integrations) before reaching for a bigger model.
## Evidence
@@ -25,11 +29,13 @@ The human role has climbed prompt-engineer → **context-engineer** → harness-
- Smart zone, summarization decay, "context is the most valuable resource," tool/skill loading mechanics — [[2026-07-14-skills-based-on-git]].
- Context engineering vs prompt engineering; foundation docs as durable context — [[2026-07-14-gap-between-ai-users-irreversible]].
- "Intelligence without context loses"; Nobel-vs-employee analogy; invest in context before model upgrades — [[2026-07-22-ai-is-stupid]].
- Information > model choice > effort level; the two information sources; token budget as a winner/loser variable — [[2026-07-28-agentic-engineering-10x-developer]].
- Reading costs attention — the human-side analog of the same scarcity — [[make-more-cheap-code]], [[2026-07-24-youre-reading-way-too-much-code]].
## Related Pages
- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[personal-ai-operating-system]]
- Entities: [[konstantin]], [[allie-miller]]
- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[personal-ai-operating-system]], [[make-more-cheap-code]], [[explosion-of-internal-software]], [[enterprise-ai-reality]]
- Entities: [[konstantin]], [[allie-miller]], [[thorsten-ball]]
## Contradictions / Uncertainty

View File

@@ -0,0 +1,38 @@
# The Emacsification of Software
#concept
## Summary
Emacs users have always forked plugins, rewritten them for their own config, and never contributed back. [[thorsten-ball]] (citing a blog post of this name) argues **that behaviour is now becoming the default for all software**: when an agent can bend someone else's program to your exact needs in two minutes, the bespoke fork beats the upstream contribution.
## Current Understanding
- **The worked example:** he forked a diff viewer called **hunk**, pointed [[amp]] at it, and said "add Gruvbox dark hard theme, add file-checkoff in the sidebar, compile, drop it in `~/bin`." Two minutes of agent time. **No reason to upstream** — the change is bespoke to him, and the cost of maintaining a personal fork has collapsed along with the cost of writing the patch.
- **The blast radius expands.** Not just individuals with small tools: he expects teams and companies to remix mid-sized software. His examples: "I want Riverside but audio-only," or video-only.
- **Why it matters commercially:** general-purpose SaaS has historically been defended by the gap between "close enough" and "exactly what I want." Agents close that gap for free, which is why his prediction list includes *it is unclear what software survives* — remixability plus per-user custom versions erode the moat.
- **The OSS side effect:** contributions dry up where the incentive to upstream was mostly "so I don't have to maintain a fork." This compounds a claim already in the corpus — that open-source contribution graphs are worth almost nothing now, and giving away near-free code costs little ([[code-as-throwaway]], via [[sebastian]]).
**Relationship to the sibling concept.** [[explosion-of-internal-software]] is about building tools that never existed; this page is about *remixing tools that do*. Same shift — software becoming personal rather than general — from opposite starting points, and both feed the webinar's "little tools you make for yourself" thesis.
## Evidence
- The Emacsification framing, the hunk fork, the Riverside remix prediction, expanding blast radius — [[2026-07-28-agentic-engineering-10x-developer]].
- OSS growth as low-cost giveaway, contribution graphs devalued — [[2026-07-14-sebastian-eugene-interview]].
- Cost-of-code → zero as the enabling condition — [[code-as-throwaway]].
## Related Pages
- Concepts: [[explosion-of-internal-software]] (sibling mechanism), [[maintenance-is-the-real-cost]] (the bounding counterweight), [[code-as-throwaway]] (the enabling economics), [[build-for-the-agent-not-the-human]] (what happens to the products being remixed), [[shedding-weight]], [[make-more-cheap-code]] (a fork nobody else sees is tier-A/B code with a long life)
- Entities: [[thorsten-ball]], [[amp]], [[sebastian]]
## Contradictions / Uncertainty
- **Maintenance is assumed away.** A two-minute fork is cheap; a fork carried across three years of upstream security patches is not. The source does not address rebasing, CVEs in the parent project, or what happens when the agent that built the fork can no longer reconstruct it. *(Sourced 2026-07-29:* [[2026-07-29-what-if-we-vibe-code-it]] *makes exactly this objection — [[maintenance-is-the-real-cost]] — and its pendulum case (in-house Jira clone abandoned for Linear within four months) is the mid-size "Riverside but audio-only" prediction failing in the wild. The personal `~/bin` fork still passes that source's checklist; the team/company remix he predicts does not.)*
- **Who maintains the upstream** if the people capable of patching it now all fork silently? The prediction is stated as an observation, with no answer for the commons problem it describes.
- Untested against [[enterprise-ai-reality]]: a bespoke unaudited fork in `~/bin` is precisely what locked-down corporate environments forbid.
## Next Questions
- Does a personal fork count as a durable artifact, or is it disposable in the [[code-as-throwaway]] sense — regenerated from a prompt against a fresh upstream each time you need it? The second reading is more consistent with the rest of the corpus and would dissolve the maintenance objection.
- Is there a non-engineer version of this — remixing a tool you use rather than one you can compile?

View File

@@ -12,22 +12,28 @@ The indie/practitioner world and the regulated-enterprise world diverge sharply.
- **The business opportunity:** *scalable, manageable, company-standard harnesses for larger engineering teams.* The gap between what individuals can do (custom [[harness]]) and what enterprises can allow **is** the product.
- **Governance vs leverage tension:** individuals get maximum leverage from personal harnesses ([[eugene]]); enterprises must standardize and control ([[sebastian]]). Unresolved — and monetizable.
- **Adjacent constraints:** the [[seniority-and-the-junior-squeeze|"read what you approve"]] security concern is amplified at scale; safety-critical/regulated code is the clear exception to [[code-as-throwaway|"most code isn't high-value"]].
- **A second divide: the token budget** (added 2026-07-28; **scope corrected 2026-07-28** — see below). [[thorsten-ball]] names two variables separating winners from losers — knowing how to use agents, and **having the token budget to do it**. It cuts both ways for this page: an enterprise can buy budget an individual cannot, while a locked-down enterprise may withhold it from the people who would use it best. Whoever controls the budget controls how far [[explosion-of-internal-software|internal software]] spreads. Thorsten names the variable and says nothing about who pays.
- **Scoping correction.** This was first written here as "the divide is also a *spending* gap," which overstates it. Thorsten's pricing regime is **metered**: [[amp]] sells usage, and his working pattern is parallel remote sandboxes and parked orbs ([[async-by-default]]) — a fleet cost, not a seat cost. Under a **flat consumer subscription** the corpus's own evidence points the other way: [[eugene]] runs 7 project-agents in parallel on a $200 plan, [[allie-miller]] runs ~100 agents and 36 workflows, and neither reports hitting a cost ceiling — while [[2026-07-14-sebastian-eugene-interview]] frames levelling as "a 20-year veteran and a fresh grad **on the same subscription**." For individual and small-team use the budget is one subscription; the token-budget variable bites at fleet scale and under metered pricing, which is where Thorsten sits and where enterprises will land.
- **The frontier's advice does not transfer.** [[shedding-weight]] — kill the backlog, kill CI that repeats the agent's tests, kill local dev in favour of remote sandboxes ([[async-by-default]]) — describes a startup that owns its own process. In a regulated shop the pipeline, the audit trail and the ticket history frequently *are* the deliverable to a regulator, and code sitting in a vendor's remote sandbox is precisely what Sebastian's clients forbid. The gap between what the frontier recommends and what compliance permits is the same gap this page calls the market.
## Evidence
- Managed VMs / zero self-install, Roche ~1,200 engineers, banks banned→adopting, "company-managed resource," "the interesting market" — [[2026-07-14-sebastian-eugene-interview]].
- Token budget as a winner/loser variable; the frontier playbook (kill backlog/CI/local dev, remote sandboxes) that compliance cannot follow — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[harness]], [[seniority-and-the-junior-squeeze]], [[code-as-throwaway]]
- Entities: [[sebastian]], [[virtido]], [[eugene]]
- Tools: [[claude-code]]
- Concepts: [[harness]], [[seniority-and-the-junior-squeeze]], [[code-as-throwaway]], [[shedding-weight]], [[async-by-default]], [[explosion-of-internal-software]], [[context-as-scarce-resource]]
- Entities: [[sebastian]], [[virtido]], [[eugene]], [[thorsten-ball]]
- Tools: [[claude-code]], [[amp]]
## Contradictions / Uncertainty
- How AI transforms *huge* (~1,200-engineer, multi-year) programs is explicitly unknown even to Sebastian.
- Whether [[virtido|Virtido]] itself is building the company-managed harness, or just naming the market, is unstated.
- [[amp]]'s orb model (code, conversation and diff living in a vendor's remote sandbox) is a direct test case for this page and the source never addresses it. Whether the frontier's unit of work is adoptable at all under compliance is open. Status: tentative.
## Next Questions
- What is the minimal compliant feature set for a centrally-managed enterprise harness?
- Who controls the token budget in a large organisation, and is it allocated by role, by team, or by request? The corpus has no evidence either way, and it decides who actually gets to use the tools.

View File

@@ -16,21 +16,25 @@ Konstantin's three-generation map of how agents get capabilities: **Tools (2022
**When to use which:** Skills when tasks are unknown/diverse or tool count is ~550; MCP when the agent is narrow, tasks are uniform, and the same small toolset applies every time. The line blurs — Claude Code converts MCP servers *into* skills (file laid down, functions not all injected), erasing most MCP downsides. Konstantin doesn't hate MCP; its problems are largely solved.
**A fourth position: skip the progression.** [[thorsten-ball]] uses none of the three generations as user-authored artifacts — no skills, no MCP servers, no slash commands — and locates capability instead in the *codebase* plus `AGENTS.md` plus a rich prompt ([[2026-07-28-agentic-engineering-10x-developer]]). [[amp]] does ship structure (Oracle/Painter/Puck sub-agents, a model/effort dial), but the vendor curates it, not the user. Read against this table, his claim is that the progression's real axis was never tools → MCP → skills but **who supplies the context and where it lives** — and that for someone working in one well-tended repo, the repo wins. See the three competing readings logged on [[skills-as-memory]].
## Evidence
- Three generations, per-generation problems, skills-vs-MCP decision table, Claude-Code-turns-MCP-into-skills caveat — [[2026-07-14-skills-based-on-git]].
- Skills as portable markdown folders across Claude/Perplexity/Gemini — [[2026-07-14-gap-between-ai-users-irreversible]].
- The skip-it-all position; vendor-curated sub-agents in place of user-authored skills — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[skills-as-memory]], [[harness]], [[context-as-scarce-resource]]
- Tools: [[claude-code]], [[hermes]]
- Entity: [[konstantin]]
- Tools: [[claude-code]], [[hermes]], [[amp]]
- Entity: [[konstantin]], [[thorsten-ball]]
## Contradictions / Uncertainty
- "Everything changes every 6 months" — MCP was just ratified and A2A is already wanted; this map may shift quickly. Status: tentative.
- The map assumes each generation *supersedes* the last. Thorsten's practice suggests a parallel track that never enters the table at all (repo + `AGENTS.md`), which would make the progression a history of *one* branch rather than of agent capability as such. Status: tentative.
## Next Questions
- Where does agent-to-agent (A2A) sit in this progression?
- Where does agent-to-agent (A2A) sit in this progression? *(Partial datapoint 2026-07-28: [[amp]] shipped agent-to-agent messaging and a meta-agent that spawns and controls other agents — see [[async-by-default]]. It arrived as a harness feature, not as a fourth generation of capability-delivery, which the table would not have predicted.)*

View File

@@ -0,0 +1,38 @@
# Explosion of Internal Software
#concept
## Summary
The layer of organisational life that used to be **one Excel file, one wiki page, and one hacky script** is about to be replaced by actual software, because building it now costs an evening instead of a quarter. [[thorsten-ball]] encoded his 20-person club's ordering process in **~2 hours of typing on his phone**. This is the corpus's strongest external validation of the webinar's thesis — *little tools you make for yourself*.
## Current Understanding
- **The before/after.** Before, internal software was whatever survived the cost-benefit test against a spreadsheet — which almost nothing did. Now the test is trivially passed, so the Excel/wiki/hack layer gets replaced by real, purpose-built tools.
- **Two variables separate winners from losers**, per Thorsten: (1) knowing how to use agents, and (2) **having the token budget to do it.** Scope matters on the second, and was corrected here 2026-07-28: he is describing **metered** fleet work (parallel orbs, parked agents), not a subscription. At individual scale the corpus's own practitioners run large agent setups on flat consumer plans without reporting a ceiling — so for a non-engineer this is a skill divide, and the budget is one subscription. See the scoping note on [[enterprise-ai-reality]].
- **The velocity claim:** *"You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."* Stated about programmers, but the internal-software argument extends it to any role that has ever maintained a spreadsheet.
- **The hard part is not building.** His printer anecdote is the whole skill in one exchange: asked to build an app so a tablet prints a paper receipt for the kitchen, he answered *"Why do you need a printer? Why not a second tablet?"* Seeing the workflow underneath the request is the surviving competence — see [[product-ownership]] and the first-principles section there.
**Why this matters for the webinar.** It is the outside evidence for thesis T5 in [[2026-07-28-webinar-theses]] — the claim that had been the talk's least provable. [[eugene]]'s arc (chat box → your own OS) lands on exactly this: "It dissolved — into the operating system. Into little tools you make for yourself… You don't buy it. You build it — one small tool at a time." Thorsten reaches the same endpoint from a frontier-engineering starting point and with a non-technical audience (a 20-person social club, a menu photo, a phone). That convergence is usable evidence: the pitch is not an engineer's fantasy about non-engineers, it is what happens when someone with the skill applies it to an ordinary group of people.
## Evidence
- Excel/wiki/hack replacement, the club ordering app in ~2 hours of phone typing, the token-budget variable, "crushed by a mediocre programmer with AI," the printer anti-example — [[2026-07-28-agentic-engineering-10x-developer]].
- The webinar's convergent framing — "little tools you make for yourself," the OS arc — `raw/notes/Webinar script.md` (raw, not yet ingested).
- Non-engineer capability ceiling and the same build-it-yourself instinct — [[levels-of-ai-usage]], [[personal-ai-operating-system]].
## Related Pages
- Concepts: [[emacsification-of-software]] (sibling mechanism — remixing rather than building), [[maintenance-is-the-real-cost]] (the bounding counterweight), [[personal-ai-operating-system]], [[levels-of-ai-usage]], [[product-ownership]], [[shedding-weight]], [[enterprise-ai-reality]] (token budget as access), [[solve-first-then-skillify]]
- Entities: [[thorsten-ball]], [[eugene]], [[allie-miller]], [[virtido]]
## Contradictions / Uncertainty
- **Survivorship.** Thorsten is a founding engineer at an agent company building for a club he belongs to. The corpus's actual non-engineers ([[nina]], [[yulia]], [[larysa]]) hit friction, [[integration-dead-ends|integration dead-ends]] and memory loss well before "2 hours on a phone." His datapoint proves the ceiling is high, not that the floor is low. Status: tentative.
- **Nobody owns the result.** Internal software built in an evening still needs to survive its author leaving, a schema change, or an incorrect order going out. The source treats creation cost as the only cost — the same gap [[emacsification-of-software]] has around maintenance. *(Upgraded 2026-07-29 from self-criticism to a sourced contradiction:* [[2026-07-29-what-if-we-vibe-code-it]] *makes this objection its whole thesis — [[maintenance-is-the-real-cost|the cost of software is maintenance, not writing]] — and supplies the corpus's only observed outcome of this pattern in the wild: a company that built its own Jira clone in March 2026 and returned to a bought tracker by July. Partial reconciliation: the club app passes that source's own build-vs-buy checklist — tiny, no SLA, no external users — so the disagreement is about where the threshold sits, not whether one exists.)*
- **The token-budget variable is named and then dropped.** Who pays, how much, and what happens to people or teams without the budget is unaddressed in the source. Partly resolved by scope (see above): under flat-rate consumer pricing it appears not to bind at individual scale, and the corpus has two practitioners running large setups to show it. It remains open for metered pricing and fleet scale — and [[eugene]]'s prediction that prices *rise* ("what I now buy for 200 will cost about 1,000") would reopen it for everyone if it holds. Status: tentative.
## Next Questions
- What is the realistic first internal tool for the webinar's HR audience — and does it survive contact with the friction Nina and Yulia describe?
- Is there a threshold above which internal software must graduate to being owned like a product (an on-call rota, a schema, a backup), and where is it? *(Sharpened 2026-07-29: [[maintenance-is-the-real-cost]] supplies a checklist for the question — size, ongoing support, operational load, second-business willingness — but not the line itself.)*

View File

@@ -16,6 +16,8 @@ The harness is the de-facto unit of agentic work in 2026. A good one has: a **sh
**The business-facing formula.** An anonymous Russian business short ([[2026-07-22-ai-is-stupid]]) independently restates the concept for non-engineers: the harness is an "engineering wrapper" — what the model must verify, which tools to trust, how to shape the answer, what is forbidden — and **strong model + your business context + harness = employee-level answer**. Remove any component and you get "smart but generic," "specific but undisciplined," or "stupid AI." Useful as webinar language: it names what the audience already feels (generic answers) without requiring the engineering vocabulary.
**A second reference harness: [[amp]].** Where [[claude-code]] is local-first and user-extended, AMP is sandbox-first and vendor-curated ([[2026-07-28-agentic-engineering-10x-developer]]): a PWA install, a low/medium/high/ultra dial that maps each level to a model *and* a sub-agent set, named sub-agents (**Oracle** the reviewer, **Painter** the image generator), a meta-agent (**Puck**) that spawns and messages other agents, and **orbs** — remote sandboxes where one URL carries thread + agent + computation + diff (see [[async-by-default]]). Two things it demonstrates about the concept: the harness is now the *product* (AMP's most-asked customer question is "what's the meta — what model, what prompt?", i.e. customers pay for research decisions), and a harness can be strong with **no user-authored skills layer at all** — the structure exists, but the vendor supplies it. That is the design axis [[hermes]] and Claude Code put in the user's hands.
**The governance fault line:** [[eugene]] argues every developer should **build their own** harness (deep knowledge → more effective). [[sebastian]] counters that "bring your own harness" cannot survive enterprise compliance — it must be a company-managed resource, and *that gap is the business*. See [[enterprise-ai-reality]].
## Evidence
@@ -26,16 +28,18 @@ The harness is the de-facto unit of agentic work in 2026. A good one has: a **sh
- Claude Code as the reference harness across surfaces — [[2026-07-14-gap-between-ai-users-irreversible]].
- Consolidated multi-project workspace, inter-agent messaging, completion signals, "before and after" claim — [[2026-07-21-larysa-interview]].
- Harness as "engineering wrapper"; model + context + harness formula; "stupid AI" as the harness-less default — [[2026-07-22-ai-is-stupid]].
- AMP's dial/sub-agents/meta-agent/orbs; "what's the meta?" as the customers' recurring question — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Tools: [[claude-code]], [[hermes]]
- Concepts: [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[context-as-scarce-resource]], [[enterprise-ai-reality]], [[personal-ai-operating-system]], [[leave-less-room-for-imagination]]
- Entities: [[eugene]], [[sebastian]], [[konstantin]], [[larysa]]
- Tools: [[claude-code]], [[hermes]], [[amp]]
- Concepts: [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[context-as-scarce-resource]], [[enterprise-ai-reality]], [[personal-ai-operating-system]], [[leave-less-room-for-imagination]], [[async-by-default]], [[shedding-weight]]
- Entities: [[eugene]], [[sebastian]], [[konstantin]], [[larysa]], [[thorsten-ball]]
## Contradictions / Uncertainty
- Personal vs company-managed harness is an unresolved tension (Eugene vs Sebastian), not a settled answer.
- Personal vs company-managed harness is an unresolved tension (Eugene vs Sebastian), not a settled answer. [[amp]] adds a third option neither of them argues for: a **vendor-managed** harness, where the research decisions are the purchase and the user tunes almost nothing.
- **Local vs remote.** Eugene's consolidation pitch assumes one place *on your machine*; Thorsten predicts local dev disappears into remote sandboxes. Compatible only if the thing being consolidated is the interface rather than the compute. Status: tentative.
- The "life split into before and after" consolidation payoff is self-reported by its builder and never measured; Larysa, the practitioner it was pitched to, does not yet run one. Status: tentative.
## Next Questions

View File

@@ -17,6 +17,8 @@ This is Eugene's explicit critique of demo culture: asking Claude to build a who
**Model-choice corollary.** Eugene runs **Claude 4.7** rather than 4.8, calling 4.8 "too proactive" — "without the flights of fancy 4.8 has." He treats over-eagerness as a property to select against in the model, not only in the prompt. (Whether that is really a model trait or an unspecified-prompt symptom is unresolved — see below.)
**A worked example of the constructive form.** [[thorsten-ball]]'s prompt for porting a feature to the CLI ([[2026-07-28-agentic-engineering-10x-developer]]) shows what "less room" looks like without a skill: **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** (name the commands, guess at the modality, invite disagreement) → **specify process** ("research how it's implemented, research how we communicate it, document how it works, sit down and think, compile what you learned, *then* come up with a good idea") → **set constraints and economics** ("Fable is expensive — use GPT models for the implementation, then present the results"). His summary: *"This is how I would talk to a senior engineer. This is the Slack message I'd send."* Note that the *process* step is doing most of the work here — it removes imagination about **how to proceed**, not only about what to build. Worth holding against this page's remedy: Eugene freezes procedure into a [[skills-as-memory|skill]]; Thorsten retypes it, and rejects skills outright (see that page's contradictions).
Tension worth holding: [[think-wider-not-bigger]] argues for giving models *more* latitude across a wider surface. These are compatible only if read as breadth-of-attempts vs. tightness-of-each-spec — many cheap wide attempts, each individually well-constrained.
## Evidence
@@ -24,17 +26,19 @@ Tension worth holding: [[think-wider-not-bigger]] argues for giving models *more
- "The more room for imagination, the more it will exploit it"; the collateral-damage-you-won't-notice framing; the one-or-two-requests demo critique; 4.7 vs 4.8 — [[2026-07-21-larysa-interview]].
- "Narrow the variability of interpretation when prompting" as a plateau practice — [[2026-07-14-yulia-interview]].
- Skills as frozen, proven procedure — [[2026-07-14-skills-based-on-git]].
- The five-part prompt structure (standard / intent / riff / process / economics); "the Slack message I'd send to a senior engineer"; stop tuning model choice — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[skills-as-memory]], [[solve-first-then-skillify]], [[levels-of-ai-usage]], [[integration-dead-ends]] (the capability-side mirror), [[think-wider-not-bigger]] (tension), [[product-ownership]]
- Entities: [[eugene]], [[larysa]], [[claude-code]]
- Concepts: [[skills-as-memory]], [[solve-first-then-skillify]], [[levels-of-ai-usage]], [[integration-dead-ends]] (the capability-side mirror), [[think-wider-not-bigger]] (tension), [[product-ownership]], [[context-as-scarce-resource]]
- Entities: [[eugene]], [[larysa]], [[claude-code]], [[thorsten-ball]]
## Contradictions / Uncertainty
- Sits in tension with [[think-wider-not-bigger]]; reconciled above as breadth vs. per-task tightness, but neither source addresses the other. Status: tentative.
- **Diff summaries vs invisible drift** (added 2026-07-24): Theo/Dax recommend routing big diffs through agent per-file summaries instead of line-by-line reads — "anything weird will stick out" ([[2026-07-24-youre-reading-way-too-much-code]]). Eugene's claim here is the opposite: the damage is what you *don't* notice, and a summary is exactly where drift hides. Theo's tier framework partially reconciles it (summaries are a tier-B/C practice; tier-D still reads every line, and slop verification catches what reading misses — see [[make-more-cheap-code]]), but neither source addresses the other. Status: tentative.
- "4.8 is too proactive" is one practitioner's preference from production use, not a benchmark. Status: tentative.
- **Model choice as a lever, or a distraction?** (added 2026-07-28.) Eugene selects *against* over-proactivity at the model level (4.7 over 4.8). [[thorsten-ball]] says the opposite about the whole activity: past a frontier model there are diminishing returns on which one you pick and even on the effort level, and "if you're mad your model doesn't use camelCase, rethink your software engineering, not the model" — put the effort into the information you supply ([[context-as-scarce-resource]]). They are reconcilable if Eugene's complaint is about *behaviour under an underspecified prompt* rather than capability, which is exactly what Thorsten would say the prompt should fix. Neither addresses the other. Status: tentative.
## Next Questions

View File

@@ -33,5 +33,7 @@ Supporting practices at the plateau: keep CLAUDE.md self-maintaining ("always ke
## Next Questions
- Does the final webinar script keep this exact rung order? (`raw/sources/Webinar script.md` is not yet ingested.)
- **Is the top rung the right ceiling?** (Raised 2026-07-28 by lint.) This ladder's non-programmer ceiling is *CLAUDE.md + skills*, and [[thorsten-ball]] reaches the frontier with neither — no skills, no MCP, no slash commands, context in the codebase and `AGENTS.md` ([[2026-07-28-agentic-engineering-10x-developer]]). If his practice generalises, the ladder's top two rungs are a detour rather than a summit; if it doesn't, the reason is that he has a codebase to encode context into and this ladder's audience does not — which would be worth stating *as* the rung's precondition. See [[skills-as-memory]] for the three competing readings.
- Does the final webinar script keep this exact rung order? (`raw/notes/Webinar script.md` — an authored deliverable, not an ingest candidate.)
- Where do agents/processes (the harness's outer loops) sit for a non-programmer — above skills, or out of reach?

View File

@@ -0,0 +1,37 @@
# Maintenance Is the Real Cost
#concept
## Summary
The cost of software was never in writing it — it is in **running it after the first user arrives**. AI collapsed the writing cost, which was always the small part, and left the real cost untouched. The trap of the vibe-coding era: "assemble in two weeks — easy; carry it forward — impossible." An internal service is an internal business.
## Current Understanding
- **The misconception being corrected:** "we couldn't build our own Jira before, and now with AI we can." False on both ends — developers always could (by hand, with a team, in months); they didn't because they didn't want to *operate* the result. The blocker was never capability.
- **What arrives with the first user:** bugs and regressions, feature requests, "something's not working / working wrong / didn't work," logs, monitoring, on-call, uptime responsibility. The project built "to save on a subscription" becomes a standing job with dedicated people — exactly the job the vendor was paid to do.
- **The two-business paradox:** a company whose product is X, quietly carrying a self-hosted tracker/logger, is running two IT businesses. Bad for the company (pays for one product, staffs two) and for the developer (a primary job you're blamed for neglecting, plus a secondary one you're blamed for neglecting).
- **The pendulum case:** March 2026 — a company builds its own Jira clone and migrates; July 2026 — the same (or a similar) company returns to a bought tracker (Linear). Status: tentative (second-hand tweets, fuzzy identification), but it is the corpus's only *observed outcome* of the build-your-own-tools thesis, and it's a reversal.
- **The build-vs-buy checklist** (prescriptive): rewrite only small, non-evolving dependencies; if it needs ongoing support, cost it as a separate project; count the operational load; ask whether the business wants a second IT business inside itself. Otherwise keep paying the vendor — the money buys operational offload, not code.
- **Where it agrees with the vault's spine:** "writing code was never the bottleneck" is the same premise as [[harness]]-over-model and [[make-more-cheap-code]]'s verification bottleneck. The corpus now has three candidates for the *real* bottleneck — context (Thorsten), verification (Theo), maintenance (this source) — which are not rivals: they are the costs at authoring time, at shipping time, and over the artifact's lifetime, respectively.
## Evidence
- All claims, the pendulum case, the checklist, the Datadog self-report — [[2026-07-29-what-if-we-vibe-code-it]].
- The objection was already latent in the vault before this source named it: [[explosion-of-internal-software]] ("nobody owns the result") and [[emacsification-of-software]] ("maintenance is assumed away") both flagged it as their own weakest point.
## Related Pages
- Concepts: [[explosion-of-internal-software]] (the thesis this bounds), [[emacsification-of-software]] (forks age too), [[code-as-throwaway]] (throwaway is safe *because* unmaintained), [[make-more-cheap-code]] (the ship/no-ship line is also the maintain/no-maintain line), [[shedding-weight]] (the inverse move — deleting owned software rather than acquiring it), [[product-ownership]] (owning an outcome includes owning its ops)
- Entities: [[thorsten-ball]] (the predictions this bounds)
## Contradictions / Uncertainty
- **vs. [[explosion-of-internal-software]] / [[thorsten-ball]]:** Thorsten predicts teams remix mid-size software ("Riverside but audio-only") and the Excel layer becomes real tools; this source's pendulum case is that pattern failing in the wild. Partial reconciliation: the club app *passes* this source's own checklist (tiny, no SLA, no external users) — the disagreement is only about where the threshold sits, not whether one exists. Recorded on both pages.
- **Does the objection survive agents doing the maintenance?** The author assumes ops load lands on humans. The corpus's outer-loop material ([[agentic-loops]], [[async-by-default]]) implies agents could absorb some of it — but no source demonstrates agent-carried ops for an internal service, and [[async-by-default]]'s own caveat (proof produced by the thing being checked is not verification) cuts against trusting it blind. Open.
- The pendulum case is one anecdote, second-hand. The author's own company is *currently* building a Datadog replacement — if it ships and survives, he becomes his own counterexample. Status: tentative.
## Next Questions
- Where exactly is the graduation threshold — the point at which a personal/internal tool must be owned like a product (on-call, schema, backups)? [[explosion-of-internal-software]] asks the same question; this source supplies the checklist but not the line.
- For the webinar's HR audience: which of their candidate tools (candidate knowledge base, transcribe→summarize) fall on the safe side of the checklist, and which quietly cross into "second business"?

View File

@@ -15,16 +15,19 @@
- **Exploration patterns:** slop-port a service to another language just to benchmark it; test 3 theories of an ambiguous PR in parallel; **use dumb-model agents as API usability testers** — if a weak model can't build on your SDK, that's a UX bug in the SDK.
- **Reading economics.** Reading still costs attention (the human-side analog of [[context-as-scarce-resource]]): don't read faster, read *only what's worth reading* — every signature and API always, function bodies rarely, per-file agent summaries instead of giant diffs (via Dax). Have AI review code before humans do.
- **What this is not:** a license to merge unreviewed slop. Theo explicitly keeps hand-verification of shipped code unchanged and disowns vibe-coders who ship slop ("I hate them too").
- **Variations, not answers** (added 2026-07-28). [[thorsten-ball]] extends the same economics past code into *design decisions*: ask for 1015 variants and pick one. His orb icon came from 15 AI-generated versions across styles and 18 palettes; AMP's news imagery from turn-by-turn Midjourney rounds. Generation is cheap, so the human's job moves from producing the artifact to **choosing among artifacts** — taste at AI speed, which is his answer to the slop objection ([[code-as-throwaway]]). The webinar-relevant part: this is the version of "make more cheap code" that needs no codebase, so it transfers directly to a non-engineer ([[2026-07-24-non-engineer-throwaway-verification]]).
- **Ask for proof, since you're waiting anyway.** Screenshots, benchmarks, dark-mode and light-mode variants, fifty tests in parallel — cheap generated artifacts whose only job is to make a claim checkable. See [[async-by-default]], where the practice belongs to delegation rather than to reading.
## Evidence
- All claims, ratios, tier table, slop patterns, Dax/Shao citations — [[2026-07-24-youre-reading-way-too-much-code]].
- Groundwork (code disposable, kill without guilt, G-brain markdown tier) — [[2026-07-14-everything-we-knew-about-software-has-changed]].
- 15 icon variants, Midjourney rounds, "ask the agent for proof" — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[code-as-throwaway]] (parent claim: cost → zero; this page is its *discipline* — what cheap code is actually for), [[think-wider-not-bigger]] (same breadth logic applied to generation volume rather than ambition), [[product-ownership]] (verifying as the human's remaining job), [[solve-first-then-skillify]] (contrast: slop is frozen into nothing; skills freeze the procedure), [[leave-less-room-for-imagination]] (tension — see below), [[context-as-scarce-resource]]
- Entities: [[theo-browne]], [[eugene]]
- Concepts: [[code-as-throwaway]] (parent claim: cost → zero; this page is its *discipline* — what cheap code is actually for), [[think-wider-not-bigger]] (same breadth logic applied to generation volume rather than ambition), [[product-ownership]] (verifying as the human's remaining job), [[solve-first-then-skillify]] (contrast: slop is frozen into nothing; skills freeze the procedure), [[leave-less-room-for-imagination]] (tension — see below), [[context-as-scarce-resource]], [[async-by-default]] (proof artifacts as the delegated form of the same move)
- Entities: [[theo-browne]], [[eugene]], [[thorsten-ball]]
## Contradictions / Uncertainty
@@ -35,4 +38,5 @@
## Next Questions
- What does the throwaway-verification bucket look like in a non-engineer's workflow (the webinar audience) — is there an HR/BA analog of "10,000 lines of slop to verify one line"? *(Answered by synthesis 2026-07-24: generated checks, not generated content — fresh-agent misread tests, parallel interpretations, checker skills, synthetic-candidate simulations. See [[2026-07-24-non-engineer-throwaway-verification]].)*
- Does tier-A slop generation stay cheap once context is accounted for — or does reviewing *agent behavior* replace reviewing code as the attention sink?
- Does tier-A slop generation stay cheap once context is accounted for — or does reviewing *agent behavior* replace reviewing code as the attention sink? *(Sharpened 2026-07-28: [[async-by-default]] multiplies parallel agents without multiplying review capacity, and Thorsten names **token budget** as a winner/loser variable — so the honest answer may be that cheap code is cheap in money and expensive in attention, which is precisely the resource this page says is binding.)*
- Does "15 variations, pick one" hold where the choice needs a criterion rather than taste? Picking an icon is judgment you already have; picking among 15 candidate job descriptions or architectures may require the analysis the variations were supposed to replace.

View File

@@ -20,21 +20,26 @@ Three layers, built bottom-up:
Mindset reframes: AI as **first-class teammate** (not intern), as an **OS** (not a tool you open), and **[[context-as-scarce-resource|context engineering]]** (not prompt engineering). The 4-tier ladder of AI work: Microtask → Companion → Delegate → Teammate. This is the non-engineer's counterpart to the [[harness]].
**The fourth layer the corpus keeps circling: tools you build for yourself.** Allie's three layers are all *context and orchestration*; [[explosion-of-internal-software]] adds the artifact — a real, small piece of software replacing the spreadsheet. [[thorsten-ball]] supplies the non-engineer-shaped proof (a 20-person club's ordering process, ~2 hours of phone typing) and [[eugene]]'s webinar arc lands on the same place: "little tools you make for yourself." The interface question is where they differ — Thorsten deletes UI so he can prompt ([[build-for-the-agent-not-the-human]]); the OS framing builds a tiny UI so you need not prompt. Both agree the *generic* surface, chat box or admin panel, is what disappears.
## Evidence
- 3 foundation docs, 4 surfaces, "just complain," proactive workflows, 4-tier model, trust calibration — [[2026-07-14-gap-between-ai-users-irreversible]].
- Setup scale: 36 workflows, ~28 master agents, ~100 agents; 210× productivity.
- Independent convergence on tools-you-build-for-yourself, from a frontier engineer applying it to a non-technical group — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]], [[levels-of-ai-usage]]
- Entity: [[allie-miller]], [[eugene]]
- Tools: [[claude-code]]
- Concepts: [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]], [[levels-of-ai-usage]], [[explosion-of-internal-software]], [[build-for-the-agent-not-the-human]], [[async-by-default]] (scheduled workflows are its non-engineer form)
- Entity: [[allie-miller]], [[eugene]], [[thorsten-ball]]
- Tools: [[claude-code]], [[amp]]
- Compare: [[harness]] (engineer's version of the same "universal agent + context" idea — see its *consolidation over tool-hopping* section, where Eugene independently arrives at the same "everything in one place" OS framing from the [[2026-07-21-larysa-interview|Larysa interview]])
## Contradictions / Uncertainty
- "Investment not cost" (1 hour → ~3 hrs/week saved) is Allie's framing; the payback is asserted, not independently measured. Status: tentative.
- **Persistent context vs memory-as-anti-feature** (recorded here 2026-07-28 by lint; previously logged only on [[skills-as-memory]]). Allie's layer 1 is persistent context documents, used without complaint. [[eugene]] holds that built-in agent memory is a net negative — "it gives no benefit and confuses users to hell… it'd be better if it didn't [exist]" ([[2026-07-21-larysa-interview]]). The two are largely reconcilable — both prefer *authored* context over *inferred* context, and Allie's docs are authored — but the blanket condemnation is one voice and this page never registers it. Status: tentative.
- **Does the OS need a skills layer at all?** [[thorsten-ball]] runs a 99%-AI-written codebase with no skills, no MCP and no slash commands ([[2026-07-28-agentic-engineering-10x-developer]]), which challenges layer 2 of this stack directly. Three competing readings are logged on [[skills-as-memory]]; the one most favourable to this page is that his context lives in a codebase he owns, and Allie's audience has none. Status: tentative.
## Next Questions

View File

@@ -12,21 +12,26 @@ The durable human skill in the AI era: **owning outcomes**, not completing ticke
- **Reframe the vocabulary:** stop thinking in tasks/tickets; think in problems and desired outcomes. If you don't understand what to build, "you will simply not be an engineer anymore"; if you *do* get closer to the product, the software gets better (product-wise, even if not always technically).
- **Verification is the new craft.** As [[code-as-throwaway|code becomes disposable]], the engineer's value is *directing and verifying* — Sebastian's printer anecdote: his edge was knowing how to instruct and check the result, not writing Java. This is also the senior's advantage: **read what you approve** ([[seniority-and-the-junior-squeeze]]).
- **Allie's parallel:** the meta-skill is **knowing what good looks like** (taste) — you don't need to do the graphic design to judge whether the ad is good.
- **First-principles thinking becomes the top skill** ([[thorsten-ball]]). His anti-example: someone at his club asked for an app so a tablet prints a paper receipt the kitchen picks up. His push-back — *"Why do you need a printer? Why not a second tablet?"* — is the whole competence in one question. The skill is **seeing the workflow underneath the request**, and it is now the scarce half of the job: *"everyone becomes an architect,"* and the value is knowing solutions from other industries and having the right idea for this problem. Note the direction of travel: the profile-picture story above is a failure to check the *output*; the printer story is a failure to check the *problem*. Ownership now runs at both ends.
- **What just got commoditised.** What senior engineers used to hand-teach over 23 years — his example, the safe multi-step column-drop migration — is a 30-second model output. Also gone is the lucky overlap of the last 2030 years, where "the guy who loves Haskell on weekends is also the guy who models the finance backend well." Technical depth and domain judgment have come apart, and only the second is still scarce. See [[seniority-and-the-junior-squeeze]].
## Evidence
- Profile-picture story, "problems not programmers," printer anecdote, ownership as mindset — [[2026-07-14-sebastian-eugene-interview]].
- "Knowing what good looks like" / taste as the meta-skill — [[2026-07-14-gap-between-ai-users-irreversible]].
- The printer/tablet push-back, "everyone becomes an architect," the 23-years-to-30-seconds migration example, the dissolving Haskell/finance-backend overlap — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[code-as-throwaway]], [[seniority-and-the-junior-squeeze]], [[connections-as-moat]], [[decoupling-identity-from-profession]]
- Entities: [[sebastian]], [[eugene]], [[allie-miller]]
- Concepts: [[code-as-throwaway]], [[seniority-and-the-junior-squeeze]], [[connections-as-moat]], [[decoupling-identity-from-profession]], [[explosion-of-internal-software]] (where the framing skill gets exercised), [[shedding-weight]] (deciding what should exist at all), [[make-more-cheap-code]]
- Entities: [[sebastian]], [[eugene]], [[allie-miller]], [[thorsten-ball]]
## Contradictions / Uncertainty
- "Get closer to the product" can improve product quality while *reducing* technical quality — the interview flags this trade-off explicitly.
- "Everyone becomes an architect" is asserted, not argued. The corpus's own non-engineers reach for AI to do the framing *for* them ([[levels-of-ai-usage]]), and nothing establishes that first-principles thinking distributes more widely than the technical skill it replaces. Status: tentative.
## Next Questions
- How do you *teach/hire for* ownership if it's a personality trait, not a checklist?
- If the senior's 23 years of hand-taught pattern knowledge is now a 30-second output, what is the new apprenticeship — and does it produce the judgment the printer story requires? Compounds the pipeline problem on [[seniority-and-the-junior-squeeze]].

View File

@@ -12,20 +12,24 @@ Counter-intuitively, AI has *raised* demand for seniors and made juniors "comple
- **The junior risk (a security argument):** the habit of clicking "yes… yes… allow for all future" is how "API keys are leaked, databases get dumped or deleted." A junior can't evaluate a 250-line bash script; a senior at least *could*. "Give a junior fresh out of university access to this almighty Claude and… the codebase — they will [wreck] it in two days." **Read what you approve.**
- **Team shape:** the ~8-person scrum team (scrum master + PM + requirements engineer + big dev team) collapses to **23 people** — one coordination/ownership role plus one or two who manage the coding agents, sharing responsibilities.
- **Leveling caveat:** on *pure programming skill*, AI **levels** senior and junior (same output). The senior's edge is entirely in judgment, verification, and knowing failure modes — not typing speed. Contrast with [[connections-as-moat]], where the edge is relationships.
- **What the levelling actually consumed** ([[thorsten-ball]], 2026-07-28): the transferable content of seniority. "What senior engineers used to hand-teach in 23 years" — his example is the safe multi-step column-drop migration — "is now a 30-second model output." So the *knowledge* half of seniority is commoditised while the *judgment* half is not, which is a sharper version of this page's claim and a harsher one for the pipeline: juniors are squeezed out of the entry-level work **and** the apprenticeship that work used to constitute. He also notes the end of a lucky historical overlap: the person who loved Haskell on weekends was also the person who modelled the finance backend well; those two skills have now come apart, and only the domain half is scarce.
- **The floor rose, not just the ceiling.** *"You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."* Read alongside the levelling caveat, the competitive line is no longer senior-vs-junior but tooled-vs-untooled — which is the same claim [[allie-miller]] makes about the irreversible gap, stated about professionals rather than individuals.
## Evidence
- Seniors more valuable, juniors squeezed, "allow-all" security habit, junior-wrecks-it-in-2-days, team collapse to 23 — [[2026-07-14-sebastian-eugene-interview]].
- 23 years of hand-taught knowledge → 30-second output; the dissolving Haskell/finance overlap; "crushed by a mediocre programmer with AI"; "don't compare yourself to the 1%" — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[product-ownership]], [[enterprise-ai-reality]], [[connections-as-moat]], [[code-as-throwaway]]
- Entities: [[sebastian]], [[eugene]]
- Concepts: [[product-ownership]], [[enterprise-ai-reality]], [[connections-as-moat]], [[code-as-throwaway]], [[explosion-of-internal-software]], [[shedding-weight]]
- Entities: [[sebastian]], [[eugene]], [[thorsten-ball]]
## Contradictions / Uncertainty
- Tension: if a junior + Claude can match a senior's output, "juniors are irrelevant" may reflect *today's* hiring psychology more than a permanent truth — and it raises an unspoken pipeline problem (where do future seniors come from?). Status: tentative.
- **Don't generalise from the 1%.** Thorsten's caution cuts across this whole page: online debates cite Mitchell Hashimoto (Ghostty, a GPU-accelerated terminal emulator) as proof AI "isn't good enough," but that is one of the best programmers alive on atypical software. Most software is CRUD, "MySQL and something-something," which agents handle fine. The senior's judgment premium is real where failure is expensive and thinner than the discourse suggests everywhere else.
## Next Questions
- If juniors can't get in, how does the industry produce the next generation of seniors?
- If juniors can't get in, how does the industry produce the next generation of seniors? *(Compounded 2026-07-28 — the apprenticeship content itself is now a 30-second output, so the answer cannot be "they'll learn it on the job.")*

View File

@@ -0,0 +1,44 @@
# Shedding Weight
#concept
## Summary
[[thorsten-ball]]'s operating discipline: **most of your process exists because humans used to be the bottleneck, and it should be deleted.** Not optimized — deleted. "Don't optimize for what looks safe today, optimize for the ability to move fast tomorrow."
## Current Understanding
The test for any workflow, feature or artifact: *would this exist if agents had always been available?* If not, it is weight.
Named casualties from the source:
- **Backlogs.** Old loop: bug reported → backlog → weeks later someone decides it's worth doing → estimate → maybe fix. New loop: *"optimistically spawn these agents, have them parked somewhere, then go through the bug fixes."* You no longer estimate whether a bug is worth fixing when the fix ran while you slept. **Backlogs are an artifact of expensive humans.**
- **CI that re-runs the agent's own tests.** The agent is already in an isolated sandbox and already ran the tests; pushing so CI can repeat them for ten minutes is waste motion.
- **IDE extensions.** [[amp]] killed its VS Code extension — "who has the editor open anymore?"
- **Admin panels and forms.** They existed so that *no code had to change*; changing the code is now cheaper. See [[build-for-the-agent-not-the-human]].
- **Local dev environments.** Predicted to go away as remote sandboxes take over ([[async-by-default]]).
The corporate version is aggressive self-cannibalization: AMP publicly kills its own features and accepts churn from users pushed out of their comfort zone. The commercial logic is that a defensible-looking 2025 product ("single agent in a VS Code sidebar with enterprise permissions and per-line attribution") would have been obsolete within a year.
**The honest form of the exercise** is his suggested internal doc: *"Software Is Dead — Now What?"* — be specific about which of your processes only survive because humans used to be the bottleneck.
## Evidence
- Backlogs, CI, VS Code extension, "AMP Frontier Corporation," the frontier bet, the suggested internal doc — [[2026-07-28-agentic-engineering-10x-developer]].
- The same instinct one layer down: killing code without guilt and resetting rather than guilt-merging — [[2026-07-14-everything-we-knew-about-software-has-changed]], via [[code-as-throwaway]].
## Related Pages
- Concepts: [[code-as-throwaway]] (the artifact-level version of the same move), [[build-for-the-agent-not-the-human]], [[async-by-default]], [[explosion-of-internal-software]], [[product-ownership]] (deciding what should exist is the surviving job), [[enterprise-ai-reality]] (the strongest counterweight)
- Entities: [[thorsten-ball]], [[amp]], [[theo-browne]]
## Contradictions / Uncertainty
- **Compliance doesn't shed.** In [[enterprise-ai-reality|regulated enterprises]], CI, audit trails, backlogs and permission systems are frequently *the deliverable* to a regulator, not overhead. Thorsten is describing a startup on the frontier and never scopes the claim; [[sebastian]]'s clients cannot install their own tools, let alone delete their pipeline. Status: tentative.
- "The agent already ran the tests" assumes you trust the agent's report of its own run. Nothing in the source addresses a lying or truncated test run — an obvious place for [[make-more-cheap-code|generated verification]] to re-enter.
- Deleting the backlog and "parking agents" replaces one queue with another; the source does not say who triages the parked fixes or what that costs in attention.
## Next Questions
- What is the smallest safe version of this for a non-frontier team — which single pre-agent workflow gives the biggest return when deleted first?
- Does shedding weight have a floor for a *person* rather than a company? The webinar audience's equivalent of "kill your backlog" is unclear. *(Proposed 2026-07-28: the audience-facing form is the question "which of your processes only exist because **you** were the bottleneck?" — carried as thesis T10 in [[2026-07-28-webinar-theses]], where it is suggested as an opener. Untested on a non-engineer audience.)*

View File

@@ -14,6 +14,8 @@ A classic skill is "**von Neumann without data**" (code, no data). Adding data +
The **method** for populating skills is [[solve-first-then-skillify]]: reach the final solution once, then freeze it (Eugene's variant of the heuristic: any correction loop longer than ~3 messages becomes a skill). The HR interviews add a social payoff: a packaged skill is a **handoff/de-risking asset** — a junior "with not even a third of your HR experience" can deliver a decent result, and the expert can take a vacation.
**The dissent: a frontier practitioner who skips skills entirely.** [[thorsten-ball]] — 99% of his company's code is AI-written — reports "**no custom slash commands, no skills, no MCP servers**" ([[2026-07-28-agentic-engineering-10x-developer]]). His substitute is not weaker context but *differently located* context: the codebase itself, a team-maintained `AGENTS.md`, and a long prompt written "like a Slack message to a senior engineer" (set the standard → state intent → riff on design → specify process → set sub-agent economics). He agrees with this page's premise — "where does the agent get its information from?" is the only question he thinks matters — and rejects its mechanism. Recorded as a live contradiction under *Contradictions* below rather than reconciled.
**The negative case: built-in memory as anti-feature.** The [[2026-07-21-larysa-interview|Larysa interview]] supplies the demand-side reason this architecture exists. Her core frustration is that the agent doesn't carry context between sessions — she re-explains, and re-pays in time and tokens. Eugene's answer is not "better memory" but *no* memory: "Memory is the worst thing agents have — it gives no benefit and confuses users to hell. Why even go there? … The memory exists, but the way it's implemented, it'd be better if it didn't." The claim is that an opaque, always-on memory that silently decides what to recall is worse than nothing, because the user can neither inspect nor correct it — whereas a skill is a file you can read, edit, version and delete. Skills are the memory you *author*.
## Evidence
@@ -24,19 +26,27 @@ The **method** for populating skills is [[solve-first-then-skillify]]: reach the
- Skill as zip-and-hand-over onboarding asset; "create a skill for this" — [[2026-07-14-nina-interview]].
- ~3-message correction-loop heuristic; skills as the non-programmer ceiling (with CLAUDE.md) — [[2026-07-14-yulia-interview]].
- Cross-session memory loss as the #1 practitioner pain; "memory is the worst thing agents have"; skills committed as the webinar remedy — [[2026-07-21-larysa-interview]].
- Counter-evidence: no skills, no MCP, no slash commands at a 99%-AI-written company; `AGENTS.md` + codebase + rich prompt as the substitute — [[2026-07-28-agentic-engineering-10x-developer]].
## Related Pages
- Concepts: [[evolution-of-agent-tooling]] (tools → MCP → skills), [[harness]], [[context-as-scarce-resource]], [[agentic-loops]], [[personal-ai-operating-system]], [[solve-first-then-skillify]], [[levels-of-ai-usage]], [[leave-less-room-for-imagination]]
- Tools: [[hermes]], [[claude-code]]
- Entities: [[konstantin]], [[allie-miller]], [[eugene]], [[larysa]]
- Tools: [[hermes]], [[claude-code]], [[amp]] (a harness with vendor-curated sub-agents and no user-authored skills layer)
- Entities: [[konstantin]], [[allie-miller]], [[eugene]], [[larysa]], [[thorsten-ball]]
## Contradictions / Uncertainty
- **Skills vs RAG** (recorded here 2026-07-28 by lint; previously logged only on [[context-as-scarce-resource]]). This page's Summary asserts load-on-activation beats RAG pre-injection as settled mechanism, but [[2026-07-22-ai-is-stupid]] names **RAG and long-term assistant memory** as *the* practical context mechanisms for a business audience. Possibly not a real disagreement — business *data* may want RAG where *procedures* want skills — but the corpus has never separated the two cases. Status: tentative.
- No standards yet for *what* data to put in a skill or its size limit (Konstantin: 200 GB in one, 100 KB in another, both fine — "ceiling not found"). Status: tentative.
- "Built-in memory is a net negative" is Eugene's strong position, not a corpus consensus — [[allie-miller]]'s [[personal-ai-operating-system]] happily uses persistent context docs and never condemns the memory feature. The two are reconcilable (both prefer *authored* context to *inferred* context), but the blanket "better if it didn't exist" is one voice. Status: tentative.
- **Skills may be unnecessary at the frontier** (added 2026-07-28). [[thorsten-ball]] ships 99%-AI-written code with no skills, no MCP and no slash commands. Three readings, none settled by the corpus:
1. **Situational.** He works daily in *one codebase he controls*, where context can live in the code and `AGENTS.md`. Skills earn their keep when work is spread across many ad-hoc tasks with no codebase to encode into — which is exactly the corpus's HR/BA audience ([[nina]], [[yulia]], [[larysa]]). Under this reading both are right and the disagreement is about who is speaking.
2. **The abstraction is premature.** Skills are scaffolding for models that needed it; a strong model plus a rich prompt plus a good repo may simply beat a skills library, making the whole layer a 2025 artifact. This is the uncomfortable reading for the webinar's central promise.
3. **He has skills under another name.** AMP's Oracle/Painter/Puck sub-agents and a maintained `AGENTS.md` *are* curated, reusable, two-stage context — just authored by the vendor and the team rather than the user. Under this reading the dispute is about who curates, not whether curation is needed.
Status: tentative. Note the evidential asymmetry — his is a first-hand report of daily practice at scale, where the pro-skills case rests on Konstantin's architecture argument plus self-reported individual workflows. **Presentation-safe restatement:** [[2026-07-28-webinar-theses]] reframes the claim as *context you author beats context that's inferred*, which holds under all three readings — Konstantin's skills, Allie's foundation docs, Eugene's anti-memory position and Thorsten's `AGENTS.md` are all authored context.
## Next Questions
- ~~What's a starter skill set for a non-engineer?~~ Answered in [[2026-07-14-best-first-skill-for-beginner]] (skill-creator as meta-skill; tone-of-voice + anti-AI-language as first content skill).
- Do skills actually solve *cross-project* context, or only per-procedure recall? Larysa's complaint may be the former, which skills don't obviously address.
- Is there a test that would separate reading 1 from reading 2 above? The cheapest one available: give a non-engineer the same task with and without a skill and compare drift — the corpus has never run it, and the webinar's promise rests on the answer.

View File

@@ -25,6 +25,7 @@ Theo Browne's core reframe: you can't out-improve the models by "getting better"
## Contradictions / Uncertainty
- "Bolt a database platform in a day or two" is an ambition claim; reliability parity with incumbents (RDS) is explicitly *not* promised. Status: tentative.
- **Wide latitude vs tight specs** (recorded here 2026-07-28 by lint; previously logged only on the other side). [[eugene]]'s [[leave-less-room-for-imagination]] argues the opposite reflex: every gap you leave gets filled invisibly, so specs should be tightened and frozen into skills. The reconciliation offered there is *breadth of attempts vs tightness of each spec* — many cheap wide attempts, each individually well-constrained — which preserves both, but neither source addresses the other and the reconciliation is the wiki's synthesis, not either author's. Status: tentative.
## Next Questions