Software engineering in AI era

The umbrella question underneath half this vault’s 2026 captures: what does the discipline keep, and what changes, when code becomes cheap? The convergent answer from every serious voice captured so far: the deliverable stays a robust, maintainable system serving users — and the engineer’s leverage moves up a level. The disagreements are about how far “up” goes, and what may safely be forgotten.

The anchors (each captured)

• Uncle Bob (2026-10-05, 545❤/10k views): “Software engineers are supposed to do exactly what we’ve always done. Ensure that the composition and structure of the system is robust and maintainable and that the behavior properly serves the needs of our users. This requires engineering discipline. It need not require detailed reading of the code; just as using compilers does not require detailed reading of the binary.”* — the compiler analogy is the strongest continuity argument made yet: source became generated artifact once before (assembly), the discipline survived by operating at the level that mattered. Notably this is Clean Code Bob conceding code-reading itself as optional while holding structure/behavior accountability fixed.
• Fowler’s fragments (2026-10-04, captured): the same continuity with a projection twist — projectional editing (storage ≠ presentation; “an LLM explaining Haskell via Python proves code matters, only its form changes”), code’s two purposes (machine instructions + conceptual model — the second role grows), DHH’s “let the drill go as deep as it can — keep the notation at the top.”
• Stanko’s photographer essay (captured): role walls break down, “AI removed the speed limit but not the limits of my imagination,” eventual excellence, “we have to become makers” — the practice-side voice from inside a successful all-agent codebase (HEY in Rust).
• Fowler’s Krell warning (same capture): building deterministic systems → nurturing inferential ones; no fix/disable for learned bugs — the new responsibility that has no pre-AI analogue.
• The wagtail/dark-factory budget discipline (captured): measure tokens/energy/spend; verification artifacts (specs both proved and executed — Temper, Bend) as the new unit of shipped work.

The structure of the debate (the map this note indexes)

1. Continuity pole (Uncle Bob, Fowler, DHH): same job, new altitude — structure, behavior, notation-at-the-top. The discipline is composition, and it was never about typing.
2. Practice pole (Stanko, poteto): the job widens — maker, photographer, verifier; blend-of-skills beats single-depth; velocity accepted with eventual excellence.
3. Verification pole (pstack, Temper, Bend, retro/Spec Gate): whatever writes the code, proof and evidence become the engineer’s primary artifact — “code review is solved” by making review unnecessary (specs verified before execution).
4. Discontinuity voices: Huntley’s bred-not-constructed software; PG’s “things that only worked because humans operate at limited rates are about to break” — the honest admission that some load-bearing habits have no successor yet.

The vault’s own position (as practiced)

Grounded in what this garden already runs: KISS + delete-before-optimize (Musk engineering process), verification survives the session (Vibecoding vs AI engineering), reading is becoming a sampling skill (projectional editing ≈ this vault’s clippings: hash-pinned provenance over full-text recall), and Sam Ruby’s operational question from the Fowler fragments is the daily test: “for the task in front of you this week, where will the information come from, and what will check the result?”

Related: Vibecoding vs AI engineering · Working with legacy code · Agile critique · Musk engineering process · Agent knowledge systems (harness engineering & contextmaxxing) · Career development

The counter-example: Uber’s JUnit migration — deterministic beats AI at scale

Gergely Orosz (152❤ / 17k views): “How do you migrate 600,000 JUnit 4 tests covering 15M lines of code? Pre-AI, I have no idea how… With AI, it’s suddenly very doable” — but the Uber engineering post he points to says the opposite, and it’s the most valuable datum in the file: “We attempted to use generative AI to migrate multiple test class files at once, but this approach was unsuccessful. AI usage was limited to debugging test and build failures. Given our codebase’s scale and custom testing patterns, a deterministic approach proved more practical than an AI-driven migration.” What actually worked — OpenRewrite (LST-based recipes, not string rewriting): 75,000+ test classes migrated, 1.25M lines modified, 5,000+ diffs, in 4 months. The load-bearing pattern for any rewrite project: (1) preconditions as file-level filters — never partially migrate; unsupported files excluded entirely, “ensuring we only transformed test targets we could handle completely”; (2) usage metrics drive recipe priority (search recipes counted every rule/runner/base-class occurrence; recipes written for the top of the histogram); (3) custom Bazel aspect to bridge OpenRewrite↔Bazel (classpath + patch files); (4) AI in its correct slot — debugging the failures, not doing the rewrite. Kin: the Vibecoding vs AI engineering Varick pattern (“decompose until most steps are deterministic; LLM only where judgment is required”) and the COT Ansible rewrite itself — spec-first, mechanical transforms, humans on the seams. Orosz’s framing isn’t wrong that AI made this era possible — but the actual mechanism is deterministic core, AI assist, the Golden Path of migrations.

The Pragmatic Engineer’s field report (2026-10-06): what changed, held, and broke

Gergely Orosz, talk transcript (~28 min, captured with full timestamped transcript; keynote tweet w/ timestamps + newsletter notes — 38 KB, both captured; slides are paywalled) — talk title: “The state of the tech industry in 2026,” LDX3 New York — the insider tour after visiting OpenAI, Anthropic, Cursor, Ramp HQs plus Uber/Linear. The four-part structure makes it the best single primary source this note has:

Changed: near-100% AI-generated code at startups (post-Opus-4.5/GPT-5.2 “January switch”); 5–10 parallel agents per engineer as the new normal (Boris Cherny, Dima Zats at Linear: “one mouse, one keyboard, one screen used to cap us — no longer”; CockroachDB’s CEO Peter Mattis same mode); IDEs fading — OpenAI nearly forked VS Code for Codex, decided terminal-first was right; JetBrains pivoting to Air (a Codex-like harness).

Held: teams as the unit of work (Anthropic’s Caitlin: “two humans + agents is not a team” — two-pizza shape survives, members supercharged); planning for complex/infra work unchanged from Stripe-era; testing ratio unchanged (Jared Sumner, Bun rewritten inside Anthropic: “AI writes pretty much all code and all tests” — trust layer intact); non-engineers still not shipping prod code (“they’re tagging the Slack bot, don’t know what a PR is”); old patterns rediscovered — Matt Pocock mining Pragmatic Programmer + Philosophy of Software Design (“deep modules”) because saying the old words makes the AI write better code.

Broke: “zombie code reviews” — “if your team is still doing code reviews, you’re probably not doing code reviews” (LGTM theater; Ramp phases them out for non-critical paths); quality visibly degrading across consumer software (“everything is broken… Spotify to Substack, paper cuts everywhere”); engineering leadership attrition (hands-on leaders exiting to fractional-CTO work because “it’s too messy”).

Next (from the notes): cloud coding agents and harnesses; engineers stop reading the code (trust moves to tests/reviews-by-machine); companies building new AI infra; the newsletter notes add Martin Fowler at The Pragmatic Summit on the unprecedented pace. The “engineers stop reading code” prediction is the one to watch against Senior mindset — it’s the zombie-review finding extrapolated to its endpoint.

Kin: zombie reviews = Meat proxy’s rubber-stamp failure and pulls.review’s grouping answer; unchanged test ratio = LLM evals’ trust layer; teams-held = Software engineering in AI era’s continuity thesis confirmed by Anthropic itself; Pocock’s old-words = this note’s classics lane getting empirical teeth.

The Lisp argument, LLM-era edition (2026-10)

vivienhenz.com via HN 49973598 (275 pts; both captured): the classic code-as-data → macros → grow-a-domain-language case, now with an LLM-native payoff table —

1. User-modifiable software: “we’re heading toward a world where software companies let their users change the product themselves — with an LLM that’s easy.” Build an opinionated DSL and user/agent changes inherit the product’s opinions instead of breaking it (his ERP example). The DSL is the Golden Path at language altitude: the paved road IS the opinion.
2. Token economics: his CL apps run 6–7× shorter than Python → fewer tokens to pay for, and more of the program fits in context — “a lot of LLM bugs stem from it changing one piece without seeing the rest.” Context-economy as a language-selection criterion (kin: Leviathan’s 450-token result cards, answer-me’s HTML economy — CLIs for agents).
3. The frozen-standard advantage: ANSI CL unchanged since 1994 as a feature — the language under user modifications never moves, “nothing they build on top of it ever breaks.” Stability as product surface for agent-written code.
4. The library desert, reframed: no npm-scale ecosystem is fine when “an LLM can write the part you need or port the whole library — LLMs are really good at porting.” (Uber’s deterministic OpenRewrite migration corroborates the porting lane.)
5. Hiring: “make them learn Common Lisp in the interview” — learning speed over prior knowledge, the Senior mindset scan in reverse.

Filed as a serious argument with a known HN-counterargument lane: niche-language bets remain bets; the ideas (DSL-as-guardrail, brevity=context, frozen substrate) transfer to any stack.

The image-based pole: ghuntley’s Jiti (2026-10-05)

Geoffrey Huntley (298❤/48k views; article captured): “an application in lisp you grow by talking to it” — Jiti, a kernel for growing a running Lisp application through LLM conversation: develop_form adds/redefines/removes functionality, execute_form calls what exists; accepted definitions become ordinary Lisp needing no further inference. No compilation ever; durable revisions; controller validates, persistent worker evaluates. “The product should build the product from the product.” The extreme pole of vivienhenz’s argument: not just DSL-as-guardrail but the entire dev loop inside the running image. Personal kin: Dipping my toes into clojure.

The clean-room collapse: /z80 and PhotoCraft (2026-10-07)

Three-part capture (acroll + esrtweet + GeoffreyHuntley → ghuntley.com/z80, all captured):

• The artifact: storytold/photocraft — 11k★ Apache-2.0 Rust, “an open-source, clean-room reimplementation of Adobe Photoshop in pure Rust”: layers/masks/adjustment layers/styles/type/vectors/full brush engine, real PSD round-trips (307/309 psd-tools corpus), GPU compositor on wgpu, and agent-ready — 500+ commands in one registry driving UI/CLI/JSON/MCP identically.
• esrtweet’s read: “they decompiled Photoshop to source, processed that to a non-code specification language, then fed the spec to an LLM with an instruction to generate Rust. Adobe just got nuked. And closed source is dead, dead, dead.”
• acroll’s legal lens (the sharp one): clean-room reverse engineering is dated law — one person documents a system, hands the spec to a second person in front of a lawyer, the second implements. “Now that we can hand code to an AI to decompile, write a spec, and implement that spec, clean-room approaches are likely to face new legal scrutiny. That’s not a thing the patent and copyright offices anticipated.”
• ghuntley’s /z80 (the technique, named): decompile → spec → LLM-implement pipeline — “running the LLM like a Bitcoin mixer for intellectual property and cloning software.” His framing: this dooms SaaS/source-available moats (his “24-month shelf life” thesis) and it’s why he’s been pitching LPs.

Vault filing: the engineering claim (spec-as-intermediate beats direct translation) matches the Software engineering in AI era migration lane (Uber’s OpenRewrite LST-recipes; LLMs-are-good-at-porting) — but pointed at software you don’t own. The economic claim (closed-source moats die when reproduction cost → $50 of GPU) is the strongest data point yet for Agent-accessible product’s “product = the moat must be elsewhere” argument. The legal claim is genuinely unsettled — the two-room procedure existed to prove non-copying; an LLM intermediary satisfies the letter while destroying the evidentiary logic. Watch this lane.

• The /z80 + clean-room theme now has its own note: Reverse engineering — method layers, the REA agent consolidation (decompile→understand→recreate, evidence-first), and the legal frame.

Dex Horthy’s “State of the software factory” (AGNTCon teaser, 2026-10-07)

Dex Horthy (~15 min, full timestamped transcript captured; HumanLayer CEO ahead of AGNTCon NA Oct 22-23):

• The thesis: “Models got really good at solving problems in 2026. I don’t think they got very good at improving codebase quality… you could tell them to improve it, but then you have to know what to tell them — which means it’s not unattended.” Root cause: RL needs an oracle, and maintainability has no fast oracle — “the cost of bad architecture is measured in months and years” while verifiers must answer in seconds.
• The receipts: SlopCodeBench (U. Wisconsin) — discloses requirements incrementally (build → add feature → add feature, like real software) instead of whole-problem-up-front; GPT-5.5, then the best model, scored 14.8%. “When you see Terminal-Bench 95% and ‘coding is solved,’ there is a benchmark that is very much unsaturated.” Corroboration: Anthropic’s own postmortem (security issue from accumulated messy code) — the benchmark’s author pointed out SlopCodeBench predicted exactly this.
• The practices (the actionable half): plan-before-build (“20-30 min up front saves hours at review”) but don’t over-plan — the expected-pain curve: yolo-prompt = 50% rework odds, 5-hour handwritten spec = 10%, 20-hour handwritten code = 0% agent-caused rework; align visually (the open-source show me skill, ~20k installs — “don’t make humans read walls of agentic prose”); give agents back pressure (browser, curl, recorded videos); Dylan Mulroy’s ~100 anti-slop TypeScript rules (catalogued agent anti-patterns); feed user feedback into the factory (“the 3 a.m. page should come with the PR the agent thinks fixes it — merge 50% and go back to bed”); feature flags for model-run UI experiments (models can’t see UIs — let users vote); loops = forward pressure + back pressure demystified (what kicks off work vs. what lets the agent hill-climb without a human); compound from past sessions; and the four-layer factory (compute / dev environment / harness / control plane) with sessions-plans-prompts as a new system of record for the forge.

Vault wiring: SlopCodeBench = the missing rung in LLM evals’ ladder (incremental-disclosure evals for maintainability); the no-fast-oracle argument is Cognitive Complexity/cccc’s opening (deterministic proxies for the slow oracle); show-me = Visualization’s trq212/HumanLayer lane shipping; the 3 a.m.-page-with-PR = oncall automation kin (Ops toolbelt); expected-pain curve = planning doctrine kin (Software engineering in AI era’s planning-held section).

”They essentially Kodaked themselves”: ghuntley’s JetBrains post-mortem (2026-10-07)

GeoffreyHuntley + ghuntley.com/kodak (both captured): he wrote the IDEs-are-dead passage as a tech lead at Canva — coworkers: “I love JetBrains… there’s no way in heck this is changing.” Then he watched JetBrains “do nothing other than jack the price of their subscriptions whilst simultaneously delivering a low-quality product” — the “private equity / Broadcom subscription-revenue-extraction phase” — while “everyone else in the agentic coding market was getting ripping results without symbolic context injection.” “They essentially Kodaked themselves.” The mechanism: “JetBrains could only see the world through the lens of the IDE… their experience and domain expertise became their curse.”

The generalization is the post’s real payload, aimed beyond JetBrains: every incumbent is blinded by its domain expertise and revenue model — and his sharpest turn applies it to the labs themselves: they believe a future model solves software verification “because tokens shape their worldview” — blinded to the fact that a better model doesn’t solve correct behavior in production under suboptimal conditions (flaky networks). Kin: the Orosz talk’s “IDEs fading” datapoint (this is its vendor post-mortem), LLM evals (verification ≠ solved — SlopCodeBench’s 14.8% is the same wall), Senior mindset (“stay highly neuroplastic and check your blind spots” = the senior reflex as corporate survival).

Protocol vs ABC for pluggable providers (2026-10-08)

pycoders → belderbos.dev (both captured): the pluggable-provider decision in Python. His reflex was ABCs (@abstractmethod, runtime refusal to instantiate incomplete subclasses — “it works”), but required inheritance is wrong when you don’t own every implementation: “a third-party provider shouldn’t have to import my base class just to count as a valid provider.” typing.Protocol = structural typing — conformance by method shape, not family tree; the type checker (ty/mypy/pyrefly) validates before runtime. Three wins: no coupling for outside implementers (“the contract lives in the shape”), providers evolve independently (no inherited stubs), reads as composition not hierarchy. The honest other side: the moment providers need to share concrete behavior (common _validate then provider-specific _call_api), ABC wins — Protocol describes contracts, ABC shares implementation. This is the agent-era plugin seam in miniature: every harness with providers/connectors (octop’s swappable lanes, Agent Client Protocol as protocol-shaped interop) faces exactly this choice — shape-conformance for an open ecosystem vs inheritance for a controlled one.

• The OpenRewrite/Uber lane now has its own concept note: Codemod — the tool landscape (OpenRewrite, jscodeshift, ast-grep, GritQL, Comby, Codemod.com, codemod-pilot) and why deterministic transforms are the migration core.

”AI-written tests empirically unhelpful”: the deepswe finding + the pushback (2026-10-08)

kunchenguid (Kun Chen; original post + full follow-up thread captured): “AI-written unit and integration tests are empirically proven to be unhelpful… on the deepswe eval set, banning Sonnet 5.5 high from writing any tests resulted in slightly higher success rate (non stat-sig) with less time and token spent (stat-sig).” The follow-up is the real payload — four objections answered:

1. “Tests are for regression” — no: tests helped in first-pass development (that’s why TDD worked); agents not inheriting that trait is itself the finding. And regression was covered: in the sampled 44 subset the existing suite was disabled wholesale and agents caused no more regression without it.
2. “But Bun’s rewrite succeeded because of tests” — yes: a human-curated suite representing desired behavior is a massive asset. The eval is about tests written by LLM default behavior without human input — the tests agents write unprompted when you ask for a change. Project owners “started being suspicious when they reviewed some of the tests.”
3. “LLMs write bad tests because your codebase is bad” — deepswe uses well-maintained repos (fastapi); “are you sure your codebases will be better maintained than fastapi?” (codebase influence is real but it’s another form of human guidance).
4. “I’ll fix it with mutation testing etc.” — no: mutation testing steers sensitivity, but the core problem is tests can’t distinguish intended vs unintended changes: “when a test fails and the test was written by your agent unprompted, how do you know whether it’s the test that’s wrong or the code? The agent can modify either — which way does it go?” Tests are an intermediate representation of the truth; written autonomously, they’re no more trusted than the implementation. “If your source of truth is agent-written tests no one certified, you are in a pretty deep hole.” E2e eval pending.

The counterpoint, same hour — IgalPines (Microsoft): mutation testing can rank unnecessary tests too (kill-matrix → importance); Bun’s rewrite rode e2e/blackbox tests, not unit; “the same way you do a review, pass the intent and let an agent run the devil’s advocate procedure — works really well”; field take: agents are “okayish at pure code tests and terrible at integration tests because they mock the shit out of the system” — good guidance + deterministic blocks for bad testing patterns produce good results; and the hierarchy: black-box tests are the important ones, the rest are nice-to-have — the hard part is non-functional requirements, “that’s where engineering comes [in].”

Vault reconciliation: this is the empirical half of this note’s two test datapoints — Bun/Anthropic’s “AI writes all code and all tests, trust layer intact” (line above) now has its controlled counterweight: human-curated tests = asset, unprompted agent tests = noise-or-worse. The certification seam is the actionable: tests need a trusted source of intent behind them (the same slot Uber gave OpenRewrite recipes and the Codemod note gives deterministic transforms). E2e-first (Pines) converges with black-box/back-pressure practice in the LLM evals lane.

Swizec at Plasmidsaurus: “when code is cheap, judgement becomes the job” (2026-10-08)

Swizec — “a real company with real stakes and a sane token budget” — the field report from ~2 years of agentic coding at his startup (19.5 KB post, fully captured). The load-bearing claims:

• Accountability-first culture: “we don’t care how you wrote the code, but you’re signing that thing with your phone number” — ship-first, high agency; “there are no ‘translate english into code’ developers on our team. We have AI for that.”
• The biggest impact is the tail-end: “I doubt we achieve more top-line goals than without AI… 2026’s MVP would’ve been a polished 6-month feature in 2020” (red queen’s race). What agents changed: the unprioritizable bugs/features nobody would’ve scheduled — frustration-driven development: @cursor make me a tool, every time a workflow annoys someone.
• The WIP trap: cheap generation means “you can work on anything and everything feels worth the effort” — the day of 6 draft PRs, “almost salvageable” big tasks, and one shipped bugfix. Fix: ruthless Not Yet, small daily budget for ad-hoc, everything else through triage (“half the sprint comes through triage”).
• Product debt: every user thinks the app would be better without “useless features,” no two users agree which; 52 shipped features × 0.5% daily bug chance ≈ a day per week of fixes. Countermeasure: product review, kill features, design systems.
• Code quality is money — now with a number: better file structure reduced token cost by 83% (Fowler’s experiment); “agents amplify the code quality you’ve got” — mud gets more mud, structure gets followed. Custom deterministic linters as the scalable review sink: describe a pattern in plain English, agents write 700 lines of AST lint, wire into CI/hooks — “increasingly your code review becomes a rubber-stamp,” then auto-approve+merge for low-risk code. A few dozen custom linters in prod.
• Agentic review lacks judgement: “you have to review the review” (half of BugBot’s comments rejected); bots don’t know which feature is bet-the-company vs throwaway — the same intent-source problem as the deepswe test finding above.
• The .md conversion: former skeptic of guidance files (“just talk to it!”) — now convinced, with the twist: “you don’t write those files for the agents, you write them for the less experienced engineers who don’t know what to ask for.”
• “In effect, everyone got promoted”: juniors-as-translators gone; everyone works like staff+ (own a domain, talk to users, concept→production); beginners own small domains, veterans critical ones. 40–50 code reviews/week, half his GitHub contributions — “exhausting… and the highest leverage activity I can find.”

Vault fit: the strongest practitioner companion to this note’s Orosz talk (same senior-IC-shape conclusion: “engineers stop reading code” vs Swizec’s “you have to read the code others produce” — the tension worth tracking), the Senior Engineer Mindset (book)‘s author practicing his own thesis, the linter lane validating Codemod/deterministic-transforms economics, and the exact intent/certification seam the deepswe test debate names. His own framing lands on the same word this note’s Varick pattern does: judgement.

Adam Jacob + Charlie Marsh: black-box-only, and Ruff/uv/ty already live there (2026-10-08)

charliermarsh (156❤) quoting adamhjk (110❤; both captured) — the third leg of this week’s test debate, from two people whose products are the evidence. Adam Jacob (Chef co-founder): “the value of unit testing was always low if you were writing in a strongly typed language. Integration testing, in particular when you used mocks and injection, was always questionable too. I think it’s entirely possible we wind up in a place where the only test suite you actually must build is the black box testing suite, and adversarial review takes care of the rest.” Charlie Marsh (Astral): “Interesting because this is effectively how we test all of Ruff, uv, and ty.” The stack of the era’s most-shipped dev tools is tested black-box-first — which lands exactly on the deepswe/Pines debate two sections up: Pines’ hierarchy (“black box tests are the most important anyway”) now has both an enterprise datapoint (Bun’s rewrite rode e2e) and a tools-vendor practice claim (Astral). The full triangulation now in the note: unprompted agent unit tests = noise (deepswe, measured) · human-curated tests = asset (Bun) · mock-heavy integration = worst lane (Pines: “they mock the shit out of the system”) · black-box + adversarial review = the convergent practice (adamhjk’s prediction, Astral’s present). Swizec’s field report adds the mechanical complement: deterministic linters encoding the review comments you keep writing — review-as-rules, tests-as-black-box.

Tanaka: TTR — “time to (fully automated, hands-off) rewrite” (2026-10-07)

poteto (1,731❤/92k views; follow-up 196❤; both captured) — lauren (React Query author): a heuristic for “how well you’ve setup your codebase for agents”: “think of it as a thought experiment and rough heuristic, not a real number that can be compared” — TTR: how long would a hands-off agent rewrite (different language/framework/architecture) take, and would you trust the result? The number’s value is diagnostic: “maybe you think your ttr is high because you wouldn’t trust the final result — because your agents don’t have a way to verify their work and convince you that their output is identical in user-visible behavior to the original. Well, that inability is likely also a problem today and slows you and your agents down.” Follow-up: think of it as token efficiency — unverifiable agents ship bugs whose rework costs tokens and customers; and TTR can be improved deterministically: high-quality test suite, XState/EffectTS to enforce business-logic invariants — “your codebase is a form of memory and an input to agents.” This is the convergence point of the whole test-debate arc: black-box verification (adamhjk/Astral) is what makes TTR finite; Swizec’s −83% token cost is TTR’s token-efficiency reading; and the “codebase as memory” framing lands the vault’s Markdown won thesis on the code side — the legible base is the context the rewrite agent reads. Kin: deepswe (the harness that measured it), Bun e2e (the suite that would verify it).

Patoarchitekci on Spec Kit: “Spec is fajny na starcie, a potem on sam umiera” (2026-10-10)

Patoarchitekci podcast (Szymon Warda + Łukasz Kałużny; full transcript captured, 42 KB, Polish): Spec Driven Development on GitHub Spec Kit, and the spec-decay problem in three sentences from the intro: “Spec jest fajny na starcie, a potem on sam umiera. To nam się zacznie rozjeżdżać i będziemy mieli kilka źródeł prawdy. A jak mamy kilka źródeł prawdy, to finalnie źródłem prawdy będzie kod, który jest autogenerowany — czyli nie mamy żadnego źródła prawdy.”** (“the spec is great at the start, then it dies on its own; things drift, you end up with several sources of truth; and then the source of truth becomes autogenerated code — i.e. you have no source of truth.”) Their frame: it’s a rerun of generate-code-from-UML, with Spec Kit as “chomąto na człowieka” (a muzzle for the human) because “myślenie jest tak bolesną czynnością niekiedy” (thinking is sometimes such a painful activity) — the discipline-mechanism diagnosis this note keeps meeting. What actually works, per the episode: Spec Kit for context dump + clarification at task start; “harness to jest twój lokalny CI po prostu” (a harness is just your local CI) with deterministic verifies — the thing Spec Kit lacks; the Affirm-style human-in-the-loop grid (agent researches/drafts/plans, human critiques specs and reviews code) with the sentence that summarizes the whole meta-harness debate: “one task = one agent session = one PR.” The docs section lands where this vault already lives: specs as ADRs — never delete, withdraw (“wycofane”) + reconciliation, because a deleted spec means “mam kod i nie wiem po co on tam jest” (I have code and don’t know why it’s there); and the closing bet on model trajectory: specs may age out as models “lepiej się domyślają o co Ci chodzi” (guess better what you mean) — the same trajectory Swizec’s junior-consultant framing rides. Sizing verdict from the episode: feature-sized tasks fit Spec Kit; epic-sized work drifts, bug-fix eras rot the spec — match the tool to the task radius.

ghuntley’s “replaced”: the vitality-curve turn (2026-10-10)

ghuntley.com/replaced (15.7 KB, captured): the follow-through on his two-year arc (oh-fuck moment → /z80 → “replaced”) — and the harshest entry in this note’s corpus. Claims ledger: usage of AI “is no longer optional” (quit AI-banning employers); “artisanal handwritten code is only possible for retired tech executives and as a hobby at home”; a testimonial of “dev worth 100K+ for 3K in sonnet tokens” re-platforming “entire stacks in about 2 weeks that we used to pay contractors half a million for” via Ralph-looping; “you’re not a senior software engineer in 2026 unless you can rebuild Claude Code”; hiring rubric with an unacceptable/acceptable/ideal vitality curve — the coding-harness interview question as the new “tell me about your home lab” (two acceptable answers: all-harnesses-fungible + cheapest tokens, or “I use my own — do you want to see it?”); wipe interviewer pools that can’t tell the categories apart; the Gates/Jevons close (demand elasticity absorbs software gains until a task is fully completable by AI — then it leaves the human salary budget entirely; “you destroy jobs and you leave no high ground”). Where this note files him: the same corpus tension as always, at maximum amplitude — Swizec’s “everyone got promoted” and lukepierceops’ enablement playbook are the humane answer to precisely this vitality-curve turn; his own /z80 (the technique powering both) is the reason the tail risk he prices is real. Personal-positioning lane: the note’s standing verdict holds — provable AI fluency (this vault’s build-in-public trail) is the 2026 edge he describes; his delivery (crisis framing, NGMI, sabotage warnings) is the stress-test, not the manual.

Capy’s Guided Review: making the diff smarter than us (2026-10-12)

luffy (@0xluffy) (X article quoted in full, captured): Capy (the agent-coding tool) shipped Guided Review because “almost nobody does” read the PR — “the PR is where you’re supposed to check what the agent did.” The honest diagnosis of agentmaxxing: “most people rarely understand what the fuck is going on in their codebase anymore. They run five threads in parallel, their CI is green and they merge.”

The build story is the interesting part — three patterns worth keeping:

• “Diffs have to be smarter than us” — the fix for unreadable diffs isn’t a summary agent (v1: “slow and expensive… still a summary sitting on top of a diff”) or a better diff view (v2: “still no one read it”), it’s restructuring the diff itself: hunks starting where the function begins (sticky-scroll logic), move detection (“GitHub shows red and green blocks; you waste neurons computing what changed”), before/after diagrams at the top, generated/tests collapsed below. The counter-zombie-review move: if nobody reads PRs, make the PR readable instead of demanding discipline.
• Paper-first UI iteration — “every version of UI starts as boards in Paper before Capy can write any code. Capy draws → I say ‘this is slop’ → Capy redraws → ‘implement it.’” Ideas die in Paper at minutes each — the pirate/architect loop as literal workflow, with taste (“this is slop”) as the only gate.
• “Capy just read the slack and built this as a feature” — customer wishes (Graphite’s code tour, before/after views) became the spec; the agent builds from Slack directly.

The receipts: code opens went 2,121 → 9,023/day (4.3×) in equal windows after guides went default (PR opens grew 2.4×, so code-opens-per-PR-open rose 14.9% → 26.7%); ~14,000 agent-written guides since Oct 1 for 222 orgs. File under this note’s zombie-review entry: Orosz documented nobody reading PRs; Capy measured it and shipped the mitigation — the review-side counterpart to swizec’s linters-and-rules answer.