blog: the context-window argument, grounded in a real measurement#3141
Merged
Conversation
The blog had two posts, both from January 2024, both written for the old positioning. This adds the post the site's current narrative actually needs, and fixes two rendering bugs the blog has carried the whole time. The post: "The Constraint Isn't Typing Speed. It's the Context Window." It deliberately does NOT lead with "~1% code surface" or "100× less code". Those numbers can't be honestly sourced — the traditional implementation they'd be measured against doesn't exist, so the ratio is a counterfactual, and the strongest in-repo data point (~300 → ~30 lines for one CRUD feature) is an order of magnitude off the claim anyway. What IS measurable is what shipped: examples/app-crm — six objects, views, a dashboard, a lead-conversion flow, permission sets, an action, translations — is 31 files / 1,792 lines / ~16k tokens. The whole business system, in 8% of a 200k window. The showcase app, which exercises every metadata type in the protocol, is ~101k and still leaves half a window free. Readers can re-run the count themselves; the post shows the command. That reframes the pitch from an efficiency claim (less code) to a capability claim (the agent can hold the entire dependency graph, so it can answer "what breaks if I change this?" instead of grepping and hoping) — and it closes on the catch, honestly: a small system is only useful if it's a correct one, which is what the validation gate is for. Also fixed, both found while checking the format: - Every post rendered its title twice — the detail page renders an <h1> from frontmatter, and both posts also opened with a duplicate `# H1`. - The index rendered posts in source order, so a new post could land anywhere. Now sorted newest-first, undated posts last. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
os-zhuang
added a commit
that referenced
this pull request
Jul 17, 2026
…tually make (#3154) The blog post that landed in #3141 deliberately declined to use "~1% code surface" — the traditional implementation it would be measured against doesn't exist, so the ratio is a counterfactual nobody has measured. That left the site arguing two things at once: the blog saying the number isn't sourceable, the homepage and README still leading with it. Worse, concepts/metadata-driven.mdx headed a section "~100× Less Code" and then, two lines down, gave its own evidence: ~300 lines → ~30 lines. The heading was 10× its own example. So all four surfaces now carry the fact instead of the ratio. examples/app-crm — six objects, views, a dashboard, a lead-conversion flow, permission sets, actions, translations — is 31 files, 1,792 lines, ~16k tokens: the whole business system in about 8% of a 200k-token window. It ships in this repo, and both docs pages give the one-line command to recount it. This is a stronger claim, not a weaker one. "Less code" is an efficiency argument a competitor can copy; "the agent can hold the entire dependency graph, so it can answer *what breaks if I change this?*" is a capability argument that depends on the system actually being that small. Both docs pages already made the context-window point — it was buried under the invented multiple. - homepage: lead + `~1% code surface` chip → `Fits in an agent's context` - README: same, with the CRM measurement and the recount command - metadata-driven.mdx: section retitled off the ratio; per-feature 300→30 kept as an aside, app-level measurement made the headline - how-ai-development-works.mdx: "two orders of magnitude" → the measurement Not touched: www.objectos.ai still carries ~1% / ~100x across eight locales. That's a sister-site call, not a unilateral one. Co-authored-by: Jack Zhuang <277994282+os-zhuang@users.noreply.github.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
blog 只有两篇 2024-01 的旧文,都是旧定位。本 PR 补上新叙事真正需要的那篇,并修掉 blog 一直带着的两个渲染 bug。
为什么不写 "~1% 代码面"
写之前先核实素材,结论是这个数字没法诚实地引用:
metadata-driven.mdx的 ~300 → ~30 行(单个 CRUD feature,10×),与"~1%/100×"差一个数量级;与维护者确认后,改走**"能装进 agent 上下文窗口"**这条 —— 它不依赖任何未实测的数字,而且是更强的主张:从效率论证(写得少)变成能力论证(agent 能不能把整个依赖图握在手里)。
改用可测量的事实
不说"1% of 一个不存在的对照",直接测已经存在的东西:
整个业务系统,占 200k 窗口的 8%。Todo ~14.5k;刻意穷举每种元数据类型的 showcase(83 文件)~101k —— 极大值也还剩半个窗口。读者能自己复算,文中给了命令。
文章结构:六周后的变更请求(第二审批人)→ 系统装不进脑子才是真瓶颈 → 可测量的数字 → 为什么"装得下"是能力论证而非效率论证 → 系统为什么会小(那 99% 本来就不是你的业务)→ 诚实的代价:小系统只有在正确时才有用,而这类错误大多不崩溃(谓词写错 → 按钮静默不渲染,TS 抓不到,因为那是个合法字符串)→ 所以有 gate,所以宿主语言是 TS。
顺带修的两个真 bug
<h1>,而两篇旧文正文又都以重复的# H1开头。blog.getPages()是源码顺序)—— 新文可能沉到任意位置。改为按日期倒序,无日期的排最后。关于两篇旧文
内容没有错(protocol-vs-platform 那篇恰好与 ontology 开放协议叙事同源),只是框架旧、日期老。本 PR 只修渲染 bug,不动内容 —— 是否重写/归档留给单独决定。
types:check✅ ·build✅🤖 Generated with Claude Code