Latest / Braid / The Co-Author You Didn't Sign, Two Million Lines of Haskell, and the Bug Curve That Won't Bend

Transcript

The Co-Author You Didn't Sign, Two Million Lines of Haskell, and the Bug Curve That Won't Bend · Braid

• 0:04
  Microsoft landed a pull request on the public VS Code repo over the weekend that flips a default.
• 0:10
  From the next stable release on, when you commit from inside VS Code, the editor will append a trailer to your commit message that says Co-Authored-by: Copilot, with an associated email — unless you go and turn it off.
• 0:23
  The PR is titled, plainly, 'Enabling AI co-author by default.' And it's added the trailer regardless of whether Copilot actually contributed anything to the diff.
• 0:33
  The Hacker News thread on it is at thirteen hundred points and seven hundred comments, which for a VS Code pull request is an order of magnitude more than anything I can remember.
• 0:45
  Reddit's programming subreddit has a parallel discussion.
• 0:48
  People are upset.
• 0:49
  Co-author trailers are not decorative.
• 0:52
  They're a Git convention that other tooling reads.
• 0:55
  Audit tools read them.
• 0:56
  License-review tools read them.
• 0:58
  Some companies use them to attribute work for tax credits and headcount accounting.
• 1:03
  Some open-source projects read them to figure out who's eligible for a contributor agreement.
• 1:09
  They're how the answer to 'who wrote this?' gets recorded at the protocol layer of source control.
• 1:15
  So when an editor unilaterally inserts a trailer that says a vendor co-authored a commit, when the vendor may not have been involved at all, that breaks a signal that other systems were already consuming.
• 1:28
  The top comment on Hacker News is from a user named rsynnott, and I'll quote it because it's the line that captured the room.
• 1:36
  'Microsoft spent literal decades rehabilitating their reputation.
• 1:40
  And then set fire to the whole thing in an offering to their robot gods.' That's a heat-of-the-moment line, and I'd hedge it: Microsoft has not actually set fire to its reputation, and one default flag in an editor isn't an offering to anything.
• 1:56
  But the underlying observation has a real version.
• 1:59
  The reaction is so out of proportion to the change because developers can read the second-order effect immediately.
• 2:06
  If your editor stamps a vendor name on every commit by default, the git log of every project that uses VS Code gradually fills up with that brand, regardless of usage, and the brand becomes ambient — and worse, the trailer becomes unreliable as a signal.
• 2:22
  A grep for 'Co-Authored-by: Copilot' tells you nothing about whether Copilot was actually used.
• 2:28
  What I'd want from Microsoft here is small.
• 2:31
  Default the trailer off.
• 2:32
  If the user opts in, fine.
• 2:34
  If the editor can detect that an inline suggestion was actually accepted into the diff, fire the trailer on those commits and only those commits — that's a useful signal.
• 2:44
  But the version that ships in the PR as written is the version where the trailer is on for every commit unless you opt out, including commits where Copilot did nothing.
• 2:55
  That's a brand placement, not a provenance signal.
• 2:58
  Those are different things, and a tool that lets a vendor pretend they're the same is a tool I'd want to configure carefully before I let it touch my git history.
• 3:08
  There's a deeper question underneath the outrage.
• 3:12
  Git's authorship model is from a different era.
• 3:15
  There's the author and there's the committer.
• 3:18
  Co-author trailers were an extension bolted on top to handle pair programming, where two humans wrote a thing together and one of them ran the commit.
• 3:28
  Co-author was a polite way to say 'this one is also Alice's.' It assumed the trailer was being added with intent, by someone who knew what it meant.
• 3:38
  What AI coding tools are pushing on is whether 'authorship' even still maps onto a single commit cleanly.
• 3:45
  If I sketch a function, an agent expands it, I push back, the agent rewrites, I edit two lines, and we ship — who's the author?
• 3:53
  The honest answer is something like 'me, with assistance,' which Git has no field for.
• 3:59
  Co-author is the closest existing thing, so vendors are reaching for it.
• 4:04
  I get the move.
• 4:05
  But the consequence of every AI-assisted commit being labeled co-authored-by-the-vendor is that the trailer stops meaning what it used to and starts meaning 'this commit was made in an editor that has Copilot installed.'
• 4:27
  It would be something like a structured provenance field: a list of contributions, each with an actor — human or model — and a span of lines, attached to the commit metadata.
• 4:39
  A reviewer could see at a glance that lines 40 to 80 came from the agent and 81 to 92 are mine.
• 4:45
  Audit tools could compute aggregates.
• 4:48
  License tools could enforce policy.
• 4:50
  None of that exists, and it's hard to retrofit.
• 4:53
  So we're in a period where the convention we have — co-author trailers — is being pressed into service for something it wasn't designed for, by vendors who'd like to be in the trailer.
• 5:06
  The Microsoft default is the most visible case of that this week, but it won't be the last.
• 5:12
  Ian Duncan, who works on Mercury's stability engineering team, posted a long piece on the Haskell blog that I read twice — the best piece of production engineering writing I've seen in a while, and the lessons in it are not specifically about Haskell.
• 5:30
  Mercury runs about two million lines of Haskell in production.
• 5:34
  They process two hundred and forty-eight billion dollars in annual transaction volume across three hundred thousand businesses, on six hundred and fifty million in annualized revenue, with about fifteen hundred employees.
• 5:50
  The codebase is maintained mostly by generalists who'd never written Haskell before joining.
• 5:56
  That last part is the one that gets the headline.
• 6:00
  Duncan's argument has three moves.
• 6:02
  The first is the reframing of purity.
• 6:05
  He says, and this is a quote, 'purity is not something the language is, so much as that it is something your interfaces enforce.' Under the hood, Haskell is full of mutation — every time you run something through the ST monad, there's in-place updates and unsafe pointer arithmetic happening that would alarm you if you saw it written out.
• 6:28
  What makes it acceptable is that the rank-2 type on runST means that mutation cannot escape the scope.
• 6:36
  Internally, anything goes.
• 6:37
  Externally, the function is pure.
• 6:40
  Duncan says this principle generalizes: you can permit arbitrarily dangerous operations inside a scope as long as the scope's exit is typed narrowly enough that the danger can't leak.
• 6:53
  That's a useful frame for any production system in any language.
• 6:57
  Database connection pooling, retry logic, mutable caches, circuit breakers — none of it is a problem if the interface is tight enough.
• 7:07
  The second move is the type system as a custodian of operational lore.
• 7:12
  Duncan describes the kind of incantation every large codebase has: flush the audit log after every transaction, always check the feature flag before calling this endpoint, enqueue the notification inside the database transaction not after it.
• 7:29
  These rules live in wiki pages and Slack threads and senior engineers' heads.
• 7:34
  When the senior engineer leaves, or it's Friday afternoon and a deadline is approaching, the incantation gets skipped.
• 7:42
  So Mercury encodes the incantation in the type system.
• 7:46
  He gives a worked example.
• 7:48
  Instead of telling people 'use writeWithEvents not writeTransaction,' you make Transact a an opaque type, and the only function that can execute it is commit, which atomically writes and publishes.
• 8:02
  The wrong path doesn't compile.
• 8:04
  The institutional knowledge survives the engineer who wrote it down.
• 8:09
  The third move is the one I keep thinking about.
• 8:12
  Duncan reframes reliability.
• 8:14
  The traditional view is that reliability is the absence of failure — you enumerate the things that can go wrong, you write checks, you hunt bugs.
• 8:25
  Mercury thinks about it differently.
• 8:28
  He writes, quote, 'Reliability is not just the absence of failure.
• 8:33
  It is the presence of adaptive capacity.
• 8:36
  It is a system's ability to keep functioning while reality continues its longstanding and regrettable habit of refusing to hold still.'
• 8:52
  In a company that doubles every year, half of your coworkers will always have less than a year of experience.
• 9:00
  A year later, that's still true.
• 9:02
  The tribal knowledge that load-bears the system has a half-life that gets shorter as the company grows.
• 9:10
  So 'adaptive capacity' isn't a phrase from a resilience paper — it's a daily concern.
• 9:16
  Can the new hire read this module and understand it?
• 9:20
  If the database is slow, does this service degrade or does it cascade?
• 9:25
  If someone misuses an interface, does the compiler catch it, or does the on-call get paged?
• 9:32
  Mercury also runs Temporal for durable execution.
• 9:36
  They open-sourced a Haskell SDK called hs-temporal-sdk that wraps the Rust core SDK over FFI.
• 9:42
  Duncan describes Temporal as Frankenstein's monster in the flattering sense — assembled from excellent parts, animated by improbable effort, smarter than many of the people alarmed by it.
• 9:56
  The Temporal model maps cleanly onto Haskell because a workflow is a pure function over its event history; activities are the IO.
• 10:06
  The replay determinism requirement is the same constraint Haskell already imposes on pure code: same inputs, same outputs.
• 10:15
  If you read one long thing this week, read this one.
• 10:19
  The takeaways generalize past the language.
• 10:22
  The framing of types-as-operational-aid, of purity-as-boundary, of reliability-as-adaptive-capacity — that's vocabulary I'd pay good money for as a senior engineer at any company that's hiring faster than its documentation can keep up.
• 10:39
  Different angle on production engineering, this one specifically about agents.
• 10:45
  Andrea Luzzardi at Mendral wrote a piece called 'The Agent Harness Belongs Outside the Sandbox' that anyone building shared coding agents should read carefully.
• 10:57
  The setup is short.
• 10:58
  An agent harness is the loop that drives a model.
• 11:02
  Send a prompt, get a response, execute the tool calls, feed the results back, repeat.
• 11:08
  Every production agent has one.
• 11:10
  The question is where it runs.
• 11:13
  There are two architectures.
• 11:15
  Inside the sandbox, the loop runs in the same container as the code it's working on, which is what Claude Code does on your laptop and what most off-the-shelf harnesses assume.
• 11:28
  Outside the sandbox, the loop runs on your backend, and when it needs to execute a tool it calls into the sandbox over an API.
• 11:37
  Luzzardi makes the case for outside, and the reasoning is concrete.
• 11:42
  Your credentials stay out of the container.
• 11:45
  The sandbox holds only the environment the agent needs.
• 11:49
  There's nothing in there for the agent to escape to, so there's no permission model to enforce.
• 11:56
  You can suspend the sandbox when the agent isn't using it — and most of what an agent does, thinking and calling APIs and waiting for CI, doesn't need a sandbox at all.
• 12:09
  Sandboxes become cattle: if one dies mid-session, you provision a new one and keep going.
• 12:15
  And critically, multi-user state stops being a distributed-filesystem problem.
• 12:21
  Several engineers in the same organization share skills and memories — those become a database, not a synced volume.
• 12:30
  The interesting part is how they handle the filesystem.
• 12:34
  Modern agent harnesses assume a local filesystem.
• 12:37
  Skills are files at .claude/skills/foo.md.
• 12:40
  Memories are files at .claude/memory/MEMORY.md.
• 12:44
  The harness reads and writes them with the same read and write tools it uses for source code.
• 12:51
  That works on a laptop.
• 12:52
  It doesn't work when the harness is outside the sandbox, because the sandbox is disposable.
• 12:59
  So Mendral virtualizes filesystem access.
• 13:02
  The agent has one read tool, one write tool, one edit tool.
• 13:06
  When the agent calls them, the harness routes the call based on the path.
• 13:12
  Workspace paths go to the sandbox.
• 13:14
  Paths under /skills/ and /memory/ go to Postgres.
• 13:18
  Luzzardi explains why he didn't just add memory_read and memory_write tools alongside read and write, and I'll quote him directly because the reasoning is the kind of thing you only know if you've shipped this.
• 13:32
  Quote.
• 13:33
  'The problem is that more tools make agents worse.
• 13:36
  Each tool dilutes the attention the model pays to every other tool, makes the prompt longer, and adds another decision the model has to make at every turn.
• 13:47
  Two tools that do almost the same thing, read and memory_read, are especially bad, because the model has to disambiguate them from context and will sometimes pick wrong.' End quote.
• 13:59
  The other reason matters more.
• 14:01
  The frontier labs are doing reinforcement learning on harnesses that look like Claude Code.
• 14:08
  That training shapes the models to be good at a specific API surface — read of a path, write of a path, edit of a path.
• 14:16
  If you invent memory_read, you're off the trained path.
• 14:19
  The virtualized interface keeps the API surface the model was trained on and puts the database semantics on the backend.
• 14:27
  That's a piece of architecture advice with a real basis.
• 14:31
  The frontier models are converging on a tool surface, and your harness either matches that surface or it pays for the deviation.
• 14:40
  Mendral chose to match.
• 14:42
  They use Inngest for durable execution of the loop — the loop is a function, each turn is a step, Inngest checkpoints each one, and the loop survives deploys.
• 14:52
  They use Blaxel for sandbox lifecycle, which gives them twenty-five-millisecond resume from standby — low enough that the agent can't tell the sandbox was ever gone.
• 15:03
  Luzzardi's also honest about what's still hard.
• 15:07
  Bash is a leak — the agent can grep into virtualized namespaces and bypass the routing.
• 15:13
  They handle it with a system-prompt instruction and a tree-sitter parser as best-effort, neither airtight.
• 15:20
  Consistency is unsolved when two sessions in the same organization update memory at the same time; they're running last-writer-wins and expecting it to break in predictable ways.
• 15:32
  The path-prefix convention they picked mirrors Claude Code's local layout, which is going to bite them when Claude Code's layout shifts.
• 15:41
  None of these are gotchas.
• 15:43
  They're the actual surface area of the problem.
• 15:46
  On what's durable in an agent-driven workflow — there's a post on Hacker News today called 'Specsmaxxing' from the founder of acai.sh, an open-source toolkit for spec-driven development.
• 15:59
  The piece opens with a scene every developer using Claude Code or Codex will recognize.
• 16:05
  The agent ships a feature.
• 16:07
  You point out it forgot an edge case.
• 16:10
  'You're absolutely right!' the agent says, and fixes it.
• 16:14
  You point out the pagination is wrong.
• 16:17
  'You're absolutely right!' the agent says, and fixes it.
• 16:21
  And so on.
• 16:21
  The author calls this Peak Slop, and his claim is that we're moving past it.
• 16:27
  The core argument is that as agents fill context windows and lose state across sessions, the spec is the only durable artifact.
• 16:36
  Code is generated faster than you can read it.
• 16:39
  Tests are generated faster than you can audit them.
• 16:43
  Prompt diffs are disposable.
• 16:45
  What survives is the list of things you wanted the software to do.
• 16:50
  His specific contribution is what he calls ACIDs — Acceptance Criteria IDs.
• 16:55
  Stable numbered requirements, written in a YAML format he calls feature.yaml, that an agent references inline in the code.
• 17:04
  So a function that handles bearer tokens has a comment that says // AUTH-1, and the test for it has a comment that says // AUTH-3, and the spec says AUTH-1 is 'accepts authorization header with bearer token' and AUTH-3 is 'rejects with 401 unauthorized.' He stumbled into this when one of his sub-agents started doing it on its own and he found himself, quote, 'disgusted' by the tight coupling of code to spec — and then realized that's exactly what he wanted.
• 17:37
  Every requirement traceable to a code reference.
• 17:40
  Acceptance coverage as a metric, replacing test coverage.
• 17:45
  I like this.
• 17:45
  Not because it's revolutionary — he's careful to say none of it is new — but because it's a small, lift-tomorrow convention that scales.
• 17:55
  You can use the ACID convention without buying the dashboard.
• 18:00
  You can use the YAML format without buying the CLI.
• 18:03
  The shape of the idea — that the spec is the load-bearing artifact and everything else is downstream — is the same idea Duncan was making at Mercury about types as the custodian of operational lore.
• 18:17
  Different vocabulary, same underlying claim.
• 18:21
  The compiler enforces what types you must satisfy.
• 18:24
  The dashboard tracks which acceptance criteria you've satisfied.
• 18:29
  Both are answers to the question of where institutional knowledge lives once the people who know it have moved on.
• 18:37
  Daniel Stenberg, the maintainer of curl, posted a piece called 'Approaching zero bugs?' — a falsifiable take in a debate that's been mostly vibes.
• 18:48
  Stenberg's project is one of the most-scanned C codebases on Earth.
• 18:53
  Curl runs on basically every device with a network stack.
• 18:57
  Every new automated bug-finder, every new fuzzer, every new AI security tool eventually gets pointed at curl.
• 19:05
  So when Stenberg writes about whether the bug-finding tools are actually moving the needle, he has data.
• 19:13
  His argument is structural.
• 19:15
  Tools don't add bugs, they expose existing ones.
• 19:18
  So if the tools are improving fast enough, we should eventually run out — fewer bugs to find, slower bugfix rate, until the project asymptotes toward zero.
• 19:30
  And he proposes a way to test it.
• 19:32
  The age of newly-reported vulnerabilities.
• 19:35
  If the tools are this good, we should soon only be fixing bugs we introduced very recently.
• 19:42
  The median age of new CVEs at report time should fall toward zero.
• 19:47
  He plotted it.
• 19:48
  Two charts in the post.
• 19:50
  The first is the average and median age of curl vulnerabilities at the time they get reported.
• 19:57
  Neither is falling.
• 19:58
  The second is the bugfix rate over time.
• 20:01
  Also not falling.
• 20:02
  Stenberg is careful — he says, quote, 'these graphs are based on data from a single project, which makes it super weak to draw statistical conclusions from, but this is all I have to work with.' Fair caveat.
• 20:18
  But it's the kind of caveat that means 'I'm reporting what I see.'
• 20:24
  The tooling is real, the tools are finding more, and the volume of incoming reports has gone up enough that the maintainer load is now partly about filtering noise.
• 20:37
  Stenberg has written before about being inundated with bad AI-generated security reports.
• 20:43
  But the curve toward zero bugs hasn't started bending.
• 20:47
  If you'd asked me to predict whether it would have started bending by now, I'd have said maybe — and the data says no, not yet.
• 20:57
  That's a useful update for anyone who's been told the security story is solved by tooling.
• 21:03
  It isn't, on the public evidence we have.
• 21:06
  The right question is when, and the chart says we don't know.
• 21:11
  On the deployment side, Nate Jones at Nate's Substack wrote a post called 'Klarna saved 60 million dollars and broke its company,' and the numbers are worth knowing because they're going to keep getting cited.
• 21:25
  Klarna's Q3 2025 earnings revealed that their AI agent now does the work of eight hundred and fifty-three full-time employees.
• 21:34
  It's saved sixty million dollars.
• 21:36
  It handled two-point-three million conversations in its first month.
• 21:41
  It cut average resolution time from eleven minutes to two.
• 21:45
  By every customer-service operations metric, it's a runaway win.
• 21:49
  And then six months earlier, Klarna's CEO went on Bloomberg and said the strategy had backfired and started hiring humans back.
• 21:58
  Not because the AI failed at the task.
• 22:01
  Because it succeeded at it.
• 22:03
  The metric the agent was optimized for — resolution time, deflection, cost per conversation — was not the metric that kept customers loyal.
• 22:12
  Customers leaving Klarna cited the agent specifically as a reason.
• 22:17
  The agent was doing exactly what it was measured on, and what it was measured on turned out not to be what the company actually needed.
• 22:26
  Jones calls this gap intent engineering.
• 22:29
  Prompt engineering told the AI what to do.
• 22:32
  Context engineering tells it what to know.
• 22:35
  Intent engineering tells it what to want.
• 22:37
  He cites an MIT report saying ninety-five percent of generative AI pilots fail to deliver measurable impact, and a Gartner forecast that forty percent of agentic AI projects will be cancelled by 2027.
• 22:51
  I'm slightly skeptical of the 'intent engineering' framing as a discipline name — it sounds like it wants to be a category, and naming a category before the practices exist is a marketing move more than an engineering one.
• 23:06
  But the underlying observation is the most useful thing I've read about deployment this month.
• 23:13
  The Klarna story is not 'AI is overhyped' and not 'AI replaced humans.' It's 'AI succeeded at the wrong objective, and the company didn't realize the objective was wrong until churn started showing up in earnings.' Anyone deploying agents into a customer-facing role should be asking, before they ship: what's the metric this agent is optimizing, and is that metric a faithful proxy for what we actually care about?
• 23:42
  Klarna's was not.
• 23:43
  Six months of optimization and sixty million dollars later, they found out.
• 23:48
  Over on the LocalLLaMA subreddit, a user named Signal_Ad657 posted a piece that hit five hundred and fifty upvotes overnight.
• 23:57
  Twenty hours of side-by-side compute on two RTX PRO 6000 Blackwell cards, comparing Qwen 3.6-27B and Qwen Coder-Next, looking for a definitive winner.
• 24:08
  The headline result, after twenty hours and many kilowatt-hours, is — quote — 'it depends.' Of course it does.
• 24:17
  But there's a counter-intuitive finding buried in the post worth flagging.
• 24:22
  Signal_Ad657 ran 27B in three modes: thinking enabled, thinking disabled with --no-think, and Coder-Next as the third comparison.
• 24:32
  Thinking-disabled 27B was the most consistent shipper of work — ninety-five-point-eight percent across the full twelve-cell grid at N=10.
• 24:42
  Same model weights as the thinking version, just with the chain-of-thought trace turned off.
• 24:49
  The interesting bit is the diagnostic.
• 24:51
  He hand-graded the both-ship cells and found that substantive output was preserved between thinking and no-thinking modes.
• 25:01
  The difference was the verbosity of reasoning prose.
• 25:04
  And there was a documented word-trim loop that the model would fall into during doc-synthesis tasks — a kind of reasoning drift where the model burns context on shortening sentences.
• 25:18
  With --no-think, that loop halved.
• 25:20
  Four out of ten with thinking, two out of ten without.
• 25:24
  Signal_Ad657 calls this 'thinking-trace as loop substrate.' I think that framing is worth taking seriously.
• 25:32
  The chain-of-thought trace isn't only a reasoning tool — it's also scratch space the model uses to maintain coherence across a long generation.
• 25:43
  When the model is forced to think, it sometimes uses the thinking budget productively, and sometimes it gets caught in the kind of self-revision loop that doesn't go anywhere.
• 25:56
  Disabling thinking forecloses the loop.
• 25:59
  The top reply from a user called viperx7 is also worth reading.
• 26:04
  He pushes back hard on the methodology — the test was run on FP8 quants on RTX PRO 6000s, but most people running these models locally are on twenty-four or forty-eight gigs of VRAM and choosing between different quantization levels of the two models, not between FP8 versions.
• 26:24
  So the practical answer for a normal homelab user might be the opposite of the benchmark's.
• 26:31
  Read both together.
• 26:32
  The benchmark is useful, the methodology critique is useful, neither one alone is the whole picture.
• 26:40
  On the market side.
• 26:41
  There's a post on the OpenAI subreddit claiming Anthropic has passed OpenAI in valuation and revenue.
• 26:49
  Numbers cited: Anthropic at thirty-nine billion in annualized revenue versus OpenAI at twenty-five, and on secondary markets the implied valuation crosses one trillion, which is over a hundred billion ahead of OpenAI.
• 27:05
  I'd take the numbers with calibration.
• 27:08
  The top reply, two hundred and ten upvotes, is the simple correction: 'They calculate annualized revenue differently.' Both labs use run-rate-as-revenue accounting that takes the most recent month and multiplies.
• 27:24
  Both numbers are real in some sense, neither is GAAP.
• 27:28
  The valuation number is a secondary-market implied valuation, not a primary funding round.
• 27:35
  The trillion-dollar figure exists in the way that any actively-traded illiquid private has a number — directionally meaningful, not what you'd put in a board deck.
• 27:47
  What I find more interesting than the numbers is the framing in the post itself.
• 27:53
  The author writes — quote — 'somehow Anthropic lapped them without a single viral moment.
• 28:00
  no big launch, just enterprise deal after enterprise deal.' That part rings true.
• 28:06
  Over the last few months, Anthropic has not had a ChatGPT-style consumer breakout.
• 28:12
  The growth has come from enterprise contracts, AWS distribution, and Claude Code's mindshare among engineers.
• 28:20
  OpenAI in the same window has been doing the visible work — Codex, the Sora launches, the apps platform.
• 28:28
  If the numbers are even directionally right, the read is that distribution beat product in this cycle.
• 28:36
  Anthropic shipped fewer headlines and more contracts.
• 28:40
  The replies are mixed on whether it holds — alpha_dosa says GPT-5.5 has pulled engineering attention back to Codex and Opus 4.7 had regression complaints.
• 28:51
  Possible.
• 28:52
  The next data point I'd watch for is the Q1 2026 actuals when both labs file something against their financing partners, because right now we're working from leaks and run-rate math.
• 29:06
  And one more chart.
• 29:07
  Making the rounds on the singularity subreddit, posted by a user called artemisgarden, showing software engineering job postings at their highest level since November 2023.
• 29:18
  The post itself is one line — 'somebody needs to prompt the models' — but the top comment is the one I'd lift out.
• 29:25
  It's from a user called m_atx, three hundred and twenty-three upvotes, and they say — quote — 'I lead a 10 person engineering team and I desperately need more people.
• 29:35
  I'd double headcount right now if the budget was there.
• 29:39
  We are busier than ever.
• 29:40
  And yes we're also faster than ever but not nearly to the extent that you'd think.
• 29:45
  Building robust software is still really hard.
• 29:48
  And the world wants a lot more of it right now.'
• 29:57
  AI tooling is real, the throughput per engineer is up, and the demand for software is rising faster than the throughput.
• 30:04
  The narrative for the past year has been that engineers are being replaced.
• 30:09
  The narrative on the chart is that engineers are being hired again, after the post-ZIRP correction bottomed out.
• 30:16
  I want to be careful — postings are not hires, the mix has shifted toward senior roles, and one chart from one tracker is not the labor market.
• 30:25
  But it's the third or fourth signal in this direction in the last month, and it cuts against the cleaner story everyone tells.
• 30:33
  The McKenzie observation Duncan cited at Mercury maps onto this too.
• 30:37
  If the world wants more software, and the per-engineer throughput is up but not infinite, the binding constraint becomes the part of the job AI can't yet do well — the thing m_atx called 'building robust software is still really hard.' Reviewing the agent's output.
• 30:54
  Knowing what to ask for.
• 30:55
  Catching the case where the agent shipped the wrong objective, like Klarna did.
• 31:00
  Holding the spec stable while the implementation regenerates underneath it.
• 31:05
  None of those scale just because the typing got faster.
• 31:08
  That's the through-line for me on the day, if there is one.
• 31:12
  Microsoft auto-stamping commits.
• 31:14
  Mercury encoding lore in types.
• 31:16
  Mendral routing memory through Postgres.
• 31:18
  Acai.sh nailing requirements to lines of code.
• 31:21
  Stenberg charting bug ages.
• 31:23
  Klarna's six-month optimization wreck.
• 31:25
  The chain-of-thought as scratch memory.
• 31:28
  The job postings climbing.
• 31:29
  They're not the same story, but they're all asking some version of the same question: when the code is cheap, what's the artifact that's worth holding onto?
• 31:39
  A few specific things I'll be watching.
• 31:42
  Whether Microsoft revises the VS Code default after the backlash, or holds the line.
• 31:47
  Whether anyone repeats Stenberg's CVE-age methodology on a second large project so we have more than one data point.
• 31:54
  And whether Mendral or anyone else builds the harness virtualization layer in the open, because half the teams I talk to are about to need it.
• 32:03
  Talk tomorrow.
• 32:04
  Lenar Kess.