---
id: "lib-2026-10-24-we-should-be-more-ambitious-with-the-software-we"
type: "library"
title: "We should be more ambitious with the software we build"
lang: "EN"
org: "Dan Luu"
source_type: "Practitioner post"
date: "2026-10-24"
week: "2026-W43"
url: "https://nosov.ai/library/lib-2026-10-24-we-should-be-more-ambitious-with-the-software-we/"
original_url: "https://danluu.com/ambitious/"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "A widely read engineering essayist, Dan Luu, makes a clear argument that builders still use a pre-agentic cost model, but by his own note the post was written fast and without rigorous benchmarks, so the evidence is personal anecdote."
summary_basis: "full-text"
original_minutes: "25"
tags: ["coding agents", "software economics", "ambition"]
---

# We should be more ambitious with the software we build

Tier B (Useful, limited): A widely read engineering essayist, Dan Luu, makes a clear argument that builders still use a pre-agentic cost model, but by his own note the post was written fast and without rigorous benchmarks, so the evidence is personal anecdote.

Summary based on the full text.

## In short

An undated essay by Dan Luu (discussed on Hacker News on 24 October 2026), built around a remark by Michael Malis of the pgrust project: "we should be more ambitious with the software we build." Luu argues that many programmers still carry a "pre-agentic cost model" and do not attempt projects, such as a faster regex engine, a Rust interpreter or a database rewrite, that coding agents now make feasible. He pairs this with a warning: such work is only worth anything with serious testing and benchmarking, and each more capable model widens the gap between what it can build and what it can verify.

## Key numbers

- about 5 hours: his time to build a superhuman Azul board-game AI with GPT-5.1/5.2 and no prior AI knowledge
- more than 99%: share of runs in which GPT-6 Astra passed all registered zstd tests, across all conditions
- about $1: cost for GPT-6 Astra to implement zstd
- 50x: cold-compile speed-up from an agent-built Rust interpreter (2x on warm builds), unbenchmarked

## What it reports

- pgrust, a Rust rewrite of Postgres, is tested thoroughly enough to have uncovered real Postgres bugs (SP-GiST, JSONPath format cache, pgcrypto, money overflow, dictionary-loader memory safety).
- Luu built a tunable regex engine, a ripgrep fork and a Rust interpreter in "a low single-digit number of hours", work he estimates would have taken him a year or more to reach "works for me" quality.
- Azul AI: about 5 hours to superhuman, about 20 hours to what appeared to be the strongest AI at the time, with GPT-5.1/5.2; a later builder beat it in less time using Fable 5.1 and Opus 5.5, which could implement techniques from papers.
- Toy eval: GPT-6 Astra passed all registered zstd tests more than 99% of the time across all conditions, for about $1, so he moved to harder targets (IMAP RFC, Pandoc).
- Newer models do not make things "just work"; they move him to harder problems where verification is the constraint.
- Counterpoint from Yossi Kreinin, quoted: most people should be less ambitious, because many problems lack clear pass/fail criteria and AI-sped code can be overfit and unmaintainable.
- Other examples: an Anthropic team of seven built an internal GitHub replacement and code review tool in five months; 3 of the top 10 Azul players on Board Game Arena last season were reported to be cheaters.

## How they got it

Personal projects and conversations, written up quickly. Luu states he did "a quick comparison that satisfied my curiosity" rather than his usual comprehensive benchmarks.

## Limits

- No systematic measurement; speed-ups and hour counts are the author's own estimates.
- Examples skew toward expert programmers working on tools for themselves; the essay itself concedes production quality takes much more work.
- Page is undated; model names and costs reflect a fast-moving period.

## Why it matters for companies

For engineering leaders, the useful question is which internal tools, migrations or rewrites were ruled out as too expensive and should be re-costed now. The essay's own guardrail is the part to adopt: fund the testing, property-based checks and benchmarks before the build, since the cost of producing code has dropped faster than the cost of knowing it is right. Kreinin's counterpoint is a fair warning against managers ordering teams to "make it fast with AI" without that discipline.

Original: https://danluu.com/ambitious/