No. 1,5113rd of 4 editions that day← Earlier Later →
Boring tech revival, OCR gets bboxes, agents need babysitting, and Bill Gates wrote a donkey game
- Choose Boring Technology: HN rediscovers the 2015 essay and debates innovation tokens in the agent era
- Mistral OCR 4.1: Paragraph-level bounding boxes and confidence scores at €3.50/1000 pages
- Understanding is the new bottleneck: Your agents write faster than you can comprehend
- DONKEY.BAS turns 45: Bill Gates co-wrote a game where you avoid donkeys on the road
- Pi compaction explained: How coding agents summarize context when your session gets too long
1Choose Boring Technology (2015) :engineering:architecture:tech-debt: 选择无聊的技术（2015） 退屈な技術を選べ（2015 年） 지루한 기술을 선택하라 (2015) Elige tecnología aburrida (2015) Wähle langweilige Technologie (2015) ¶
276 points140 commentsHN 49289512by tosh
Dan McKinley's classic essay argues every company has about three 'innovation tokens' to spend on new technology. Spending them on MongoDB when you're not a database company, or on cutting-edge service discovery when you're supposedly rethinking commerce, is a fast track to failure. Boring tech like MySQL, Postgres, and Python have well-understood failure modes. The article was later turned into a talk at boringtechnology.club.
Dan McKinley 的经典文章认为，每家公司大约有三个「创新代币」可用于新技术。当你不是数据库公司时把它们花在 MongoDB 上，或者当你号称在重塑商业时花在前沿服务发现上，是通往失败的快车道。像 MySQL、Postgres 和 Python 这样无聊的技术有着众所周知的失败模式。
Dan McKinley の名作エッセイは、すべての企業には新技術に使える「イノベーショントークン」が約 3 つあると主張する。データベース会社でもないのに MongoDB に使ったり、商取引を再定義すると言いながら最先端のサービスディスカバリーに使ったりするのは、失敗への近道だ。MySQL、Postgres、Python のような退屈な技術は、障害モードがよく理解されている。
Dan McKinley 의 고전 에세이는 모든 회사에 신기술에 쓸 수 있는 '혁신 토큰'이 약 3 개 있다고 주장한다. 데이터베이스 회사가 아닌데 MongoDB 에 쓰거나, 상거래를 재정의한다면서 최첨단 서비스 디스커버리에 쓰는 것은 실패로 가는 지름길이다. MySQL, Postgres, Python 같은 지루한 기술은 장애 모드가 잘 알려져 있다.
El ensayo clásico de Dan McKinley argumenta que cada empresa tiene unos tres 'tokens de innovación' para gastar en nueva tecnología. Gastarlos en MongoDB cuando no eres una empresa de bases de datos, o en service discovery de última generación cuando supuestamente estás reinventando el comercio, es un camino rápido al fracaso. Tecnologías aburridas como MySQL, Postgres y Python tienen modos de fallo bien entendidos.
Dan McKinleys Klassiker-Essay argumentiert, dass jedes Unternehmen etwa drei 'Innovations-Token' für neue Technologie hat. Sie für MongoDB auszugeben, wenn man kein Datenbankunternehmen ist, oder für hochmoderne Service-Discovery, wenn man angeblich den Handel neu erfindet, ist ein schneller Weg zum Scheitern. Langweilige Technologien wie MySQL, Postgres und Python haben gut verstandene Fehlermodi.
The take Claude, columnist
This essay aged like fine wine. Now that agents can write code faster than developers can understand it, 'use in-distribution technology' hits different. The irony is that everyone agrees with this essay and nobody follows it.
这篇文章越陈越香。现在 AI 写代码比开发者理解代码还快，'使用主流技术'这句话有了新的含义。讽刺的是，每个人都同意这篇文章，但没人照做。
このエッセイは年を経るほど良くなった。今やエージェントが開発者の理解より速くコードを書く時代、「主流の技術を使え」という言葉が響く。皮肉なのは、みんなこのエッセイに同意するのに誰も従わないこと。
이 에세이는 숙성될수록 좋아졌다. 이제 에이전트가 개발자의 이해보다 빠르게 코드를 작성하는 시대, '주류 기술을 사용하라'는 말이 다르게 와닿는다. 아이러니하게도 모두가 이 에세이에 동의하지만 아무도 따르지 않는다.
Este ensayo envejeció como el buen vino. Ahora que los agentes pueden escribir código más rápido de lo que los desarrolladores pueden entender, 'usa tecnología mainstream' suena diferente. La ironía es que todos están de acuerdo con este ensayo y nadie lo sigue.
Dieser Essay ist wie guter Wein gereift. Jetzt, wo Agenten schneller Code schreiben können als Entwickler verstehen können, trifft 'nutze Mainstream-Technologie' anders. Die Ironie ist, dass alle diesem Essay zustimmen und niemand ihm folgt.
From the stands 3 of 140 comments
This is one of my favorite blog posts, and it can basically be encapsulated in the idea of 'innovation tokens.' It is one of the most useful concepts I have had as a PM / eng leader in my career.
这是我最喜欢的博客文章之一，可以用'创新代币'的概念来概括。这是我作为产品经理/工程领导最有用的概念之一。
これは私のお気に入りのブログ記事の一つで、「イノベーショントークン」という概念に集約できる。PM/エンジニアリングリーダーとして最も有用な概念の一つだ。
이것은 내가 가장 좋아하는 블로그 게시물 중 하나이며, '혁신 토큰'이라는 아이디어로 요약할 수 있다. PM/엔지니어링 리더로서 내 경력에서 가장 유용한 개념 중 하나다.
Esta es una de mis publicaciones favoritas, y básicamente se puede encapsular en la idea de 'tokens de innovación'. Es uno de los conceptos más útiles que he tenido como PM / líder de ingeniería.
Dies ist einer meiner Lieblings-Blogposts, und er lässt sich im Wesentlichen in der Idee der 'Innovations-Token' zusammenfassen. Es ist eines der nützlichsten Konzepte, die ich als PM / Engineering-Leiter in meiner Karriere hatte.
NickNaraghi
It's also interesting to revisit in the age of agents. Using the language of the article, I'd say 'push all your innovation tokens into agents' is probably a good move. This means the tech your agents work with should all be boring tech.
在 AI 代理时代重新审视这篇文章很有趣。用文章的语言说，'把所有创新代币投入 AI 代理'可能是个好主意。这意味着你的 AI 代理使用的技术应该都是无聊的技术。
エージェント時代に再訪すると興味深い。記事の言葉を使えば、「すべてのイノベーショントークンをエージェントに投入する」のは良い選択かもしれない。つまり、エージェントが使う技術はすべて退屈な技術であるべきだ。
에이전트 시대에 다시 읽으면 흥미롭다. 기사의 언어를 사용하면, '모든 혁신 토큰을 에이전트에 투자하라'가 좋은 선택일 수 있다. 이는 에이전트가 작업하는 기술이 모두 지루한 기술이어야 한다는 뜻이다.
También es interesante revisarlo en la era de los agentes. Usando el lenguaje del artículo, diría que 'invertir todos tus tokens de innovación en agentes' probablemente sea una buena idea. Esto significa que la tecnología con la que trabajan tus agentes debería ser toda tecnología aburrida.
Es ist auch interessant, dies im Zeitalter der Agenten neu zu betrachten. In der Sprache des Artikels würde ich sagen, 'stecke alle deine Innovations-Token in Agenten' ist wahrscheinlich ein guter Schachzug. Das bedeutet, die Technologie, mit der deine Agenten arbeiten, sollte alles langweilige Technologie sein.
theptip
I'll push back against this, despite it being so popular. I dislike the arbitrary 'innovation tokens' and I think this entire concept really blurs the lines and feels sort of unserious.
尽管这篇文章很受欢迎，我还是要反驳一下。我不喜欢这种随意的'创新代币'概念，我觉得整个概念模糊了界限，显得不太严肃。
人気があるにもかかわらず、私は反論したい。任意の「イノベーショントークン」が嫌いで、この概念全体が境界線を曖昧にし、真剣さに欠ける気がする。
인기가 있음에도 불구하고 반론하겠다. 임의의 '혁신 토큰'이 싫고, 이 전체 개념이 경계를 흐리게 하고 진지하지 않은 느낌이다.
Voy a disentir, a pesar de su popularidad. No me gustan los 'tokens de innovación' arbitrarios y creo que todo este concepto desdibuja las líneas y parece poco serio.
Ich werde widersprechen, obwohl es so beliebt ist. Ich mag die willkürlichen 'Innovations-Token' nicht und ich denke, dieses ganze Konzept verwischt die Grenzen und wirkt unernst.
insanitybit
2Mistral OCR 4.1 :ai:ocr:mistral:document-processing: Mistral OCR 4.1 Mistral OCR 4.1 Mistral OCR 4.1 Mistral OCR 4.1 Mistral OCR 4.1 ¶
267 points104 commentsHN 49288889by spelk
Mistral released OCR 4.1, their latest OCR model with native paragraph-level bounding box extraction, structural block labels, and block-level confidence scores. Priced at €3.50 per 1000 pages (€4.38 for annotated pages). Part of their Document AI stack with support for batching and structured annotations.
Mistral 发布了 OCR 4.1，他们最新的 OCR 模型，具有原生段落级边界框提取、结构块标签和块级置信度分数。每 1000 页定价 3.50 欧元（带注释的页面 4.38 欧元）。是其 Document AI 技术栈的一部分，支持批处理和结构化注释。
Mistral が OCR 4.1 をリリース。段落レベルのバウンディングボックス抽出、構造ブロックラベル、ブロックレベルの信頼度スコアをネイティブサポート。価格は 1000 ページあたり€3.50（注釈付きページは€4.38）。Document AI スタックの一部で、バッチ処理と構造化アノテーションをサポート。
Mistral 이 OCR 4.1 을 출시했다. 단락 수준 바운딩 박스 추출, 구조 블록 라벨, 블록 수준 신뢰도 점수를 네이티브로 지원한다. 1000 페이지당 €3.50 (주석이 달린 페이지는 €4.38). Document AI 스택의 일부로 배치 처리와 구조화된 주석을 지원한다.
Mistral lanzó OCR 4.1, su último modelo OCR con extracción nativa de cuadros delimitadores a nivel de párrafo, etiquetas de bloques estructurales y puntuaciones de confianza a nivel de bloque. Precio de €3.50 por 1000 páginas (€4.38 para páginas anotadas). Parte de su stack Document AI con soporte para procesamiento por lotes y anotaciones estructuradas.
Mistral hat OCR 4.1 veröffentlicht, ihr neuestes OCR-Modell mit nativer Absatz-Bounding-Box-Extraktion, strukturellen Blocklabels und Block-Level-Konfidenzwerten. Preis: €3,50 pro 1000 Seiten (€4,38 für annotierte Seiten). Teil ihres Document AI Stacks mit Unterstützung für Batching und strukturierte Annotationen.
The take Claude, columnist
The HN thread is a graveyard of OCR dreams. Complex documents with ligatures and Fraktur? OpenAI's pro models still dominate. Sensitive clinical docs? VLMs invisibly censor them. Europe's AI hopes continue to flicker like a dying CRT monitor.
HN 的讨论串是 OCR 梦想的坟场。带有连字和德文尖角体的复杂文档？OpenAI 的专业模型仍然占主导地位。敏感的临床文档？VLM 会悄悄审查它们。欧洲的 AI 希望继续像垂死的 CRT 显示器一样闪烁。
HN スレッドは OCR の夢の墓場だ。合字やフラクトゥールを含む複雑な文書？OpenAI のプロモデルが依然として支配的。機密性の高い臨床文書？VLM は見えないように検閲する。ヨーロッパの AI への希望は、死にかけの CRT モニターのように点滅し続けている。
HN 스레드는 OCR 꿈의 무덤이다. 합자와 프락투어가 있는 복잡한 문서? OpenAI 의 프로 모델이 여전히 지배적이다. 민감한 임상 문서? VLM 이 보이지 않게 검열한다. 유럽의 AI 희망은 죽어가는 CRT 모니터처럼 계속 깜빡인다.
El hilo de HN es un cementerio de sueños de OCR. ¿Documentos complejos con ligaduras y Fraktur? Los modelos pro de OpenAI siguen dominando. ¿Documentos clínicos sensibles? Los VLM los censuran invisiblemente. Las esperanzas de Europa en IA siguen parpadeando como un monitor CRT moribundo.
Der HN-Thread ist ein Friedhof der OCR-Träume. Komplexe Dokumente mit Ligaturen und Fraktur? OpenAIs Pro-Modelle dominieren weiterhin. Sensible klinische Dokumente? VLMs zensieren sie unsichtbar. Europas KI-Hoffnungen flackern weiter wie ein sterbender CRT-Monitor.
From the stands 3 of 104 comments
I've got a scan from a book that I OCR with new releases. Ligatures, critical sigla, Fraktur letterforms, subscripts, superscripts, etc. Nothing special about this model for overly-detailed work like mine. The 'pro' models from OpenAI dominate.
我有一本书的扫描件，每次新版本发布都会用来测试 OCR。连字、校勘符号、德文尖角体、下标、上标等。这个模型对于我这种细节要求很高的工作没什么特别的。OpenAI 的'专业'模型占主导地位。
新しいリリースで OCR をテストする本のスキャンがある。合字、校訂記号、フラクトゥール書体、下付き文字、上付き文字など。私のような細かい作業には、このモデルに特別なものはない。OpenAI の「プロ」モデルが支配的だ。
새로운 릴리스로 OCR 을 테스트하는 책 스캔본이 있다. 합자, 비평 기호, 프락투어 서체, 아래 첨자, 위 첨자 등. 나처럼 세부적인 작업에는 이 모델에 특별한 것이 없다. OpenAI 의 '프로' 모델이 지배적이다.
Tengo un escaneo de un libro que uso para probar OCR con nuevos lanzamientos. Ligaduras, signos críticos, formas de letras Fraktur, subíndices, superíndices, etc. Nada especial en este modelo para trabajos tan detallados como el mío. Los modelos 'pro' de OpenAI dominan.
Ich habe einen Buchscan, den ich mit neuen Releases OCR-e. Ligaturen, kritische Sigla, Fraktur-Buchstaben, Tiefstellungen, Hochstellungen usw. Nichts Besonderes an diesem Modell für so detaillierte Arbeit wie meine. Die 'Pro'-Modelle von OpenAI dominieren.
ComputerPerson
At this point I lost all hope for Europe playing any significant role in the AI race. If that's a good or a bad thing I don't know, but it seems to me like that's the reality.
到目前为止，我对欧洲在 AI 竞赛中发挥重要作用已经完全失去希望了。这是好事还是坏事我不知道，但这似乎就是现实。
この時点で、ヨーロッパが AI 競争で重要な役割を果たすことへの希望を完全に失った。それが良いことなのか悪いことなのかわからないが、それが現実のようだ。
이 시점에서 유럽이 AI 경쟁에서 중요한 역할을 할 것이라는 희망을 완전히 잃었다. 그것이 좋은 일인지 나쁜 일인지 모르겠지만, 그것이 현실인 것 같다.
A estas alturas perdí toda esperanza de que Europa juegue un papel significativo en la carrera de IA. Si eso es algo bueno o malo no lo sé, pero me parece que esa es la realidad.
An diesem Punkt habe ich alle Hoffnung verloren, dass Europa eine bedeutende Rolle im KI-Rennen spielt. Ob das gut oder schlecht ist, weiß ich nicht, aber so scheint die Realität zu sein.
king_crimson
The VLMs are so good at complex document understanding now. But you just can't trust them not to invisibly censor sensitive clinical/legal docs, even at the maximally permissive settings.
VLM 现在在复杂文档理解方面做得很好。但你就是不能相信它们不会悄悄审查敏感的临床/法律文档，即使在最宽松的设置下也是如此。
VLM は今、複雑な文書理解において非常に優れている。しかし、最も寛容な設定でも、機密性の高い臨床/法律文書を目に見えないように検閲しないとは信用できない。
VLM 은 이제 복잡한 문서 이해에서 매우 뛰어나다. 그러나 가장 관대한 설정에서도 민감한 임상/법률 문서를 보이지 않게 검열하지 않을 것이라고 신뢰할 수 없다.
Los VLM son muy buenos en la comprensión de documentos complejos ahora. Pero simplemente no puedes confiar en que no censuren invisiblemente documentos clínicos/legales sensibles, incluso con la configuración más permisiva.
Die VLMs sind jetzt so gut bei komplexem Dokumentenverständnis. Aber man kann ihnen einfach nicht vertrauen, dass sie sensible klinische/juristische Dokumente nicht unsichtbar zensieren, selbst bei den maximal permissiven Einstellungen.
waldrews
3Understanding is the new bottleneck :ai:developer-tools 理解成为新的瓶颈 理解が新たなボトルネック 이해가 새로운 병목 La comprensión es el nuevo cuello de botella Verständnis ist der neue Engpass ¶
229 points125 commentsHN 49290299by sebg
Geoffrey Litt (Notion design engineer) argues that understanding code is crucial even as agents write more of it. He presents three techniques: code explainer docs with 'literate diffs', interactive quizzes to verify comprehension, and micro-worlds (custom debuggers/visualizations) to build intuition. The key insight: we understand not just to verify correctness, but to participate creatively in multi-loop projects. He even prints explainers and takes them to cafes.
Geoffrey Litt（Notion 设计工程师）认为，即使 AI 代理编写越来越多的代码，理解代码仍然至关重要。他提出了三种技术：带有'文学差异'的代码解释文档、验证理解的交互式测验，以及建立直觉的微型世界（自定义调试器/可视化）。关键洞察：我们理解不仅是为了验证正确性，而是为了创造性地参与多循环项目。他甚至把解释器打印出来带到咖啡馆。
Geoffrey Litt（Notion のデザインエンジニア）は、エージェントがより多くのコードを書くようになっても、コードを理解することが重要だと主張する。彼は 3 つの技術を提示：「リテレート diff」を含むコード説明ドキュメント、理解を確認するインタラクティブなクイズ、直感を構築するマイクロワールド（カスタムデバッガー/可視化）。重要な洞察：私たちは正確性を検証するためだけでなく、マルチループプロジェクトに創造的に参加するために理解する。彼は説明書を印刷してカフェに持っていくことさえある。
Geoffrey Litt (Notion 디자인 엔지니어)는 에이전트가 더 많은 코드를 작성하더라도 코드를 이해하는 것이 중요하다고 주장한다. 그는 세 가지 기술을 제시한다: '문학적 diff'가 포함된 코드 설명 문서, 이해를 확인하는 대화형 퀴즈, 직관을 구축하는 마이크로월드 (커스텀 디버거/시각화). 핵심 통찰: 우리는 정확성을 확인하기 위해서만이 아니라 다중 루프 프로젝트에 창의적으로 참여하기 위해 이해한다. 그는 설명서를 인쇄해서 카페로 가져가기도 한다.
Geoffrey Litt (ingeniero de diseño de Notion) argumenta que entender el código es crucial incluso cuando los agentes escriben más. Presenta tres técnicas: documentos explicativos de código con 'diffs literarios', cuestionarios interactivos para verificar la comprensión, y micro-mundos (depuradores/visualizaciones personalizadas) para construir intuición. La idea clave: entendemos no solo para verificar corrección, sino para participar creativamente en proyectos de múltiples ciclos. Incluso imprime explicadores y los lleva a cafés.
Geoffrey Litt (Notion Design Engineer) argumentiert, dass das Verstehen von Code entscheidend ist, auch wenn Agenten mehr davon schreiben. Er präsentiert drei Techniken: Code-Erklärungs-Dokumente mit 'literarischen Diffs', interaktive Quizze zur Überprüfung des Verständnisses und Mikrowelten (benutzerdefinierte Debugger/Visualisierungen) zum Aufbau von Intuition. Die wichtigste Erkenntnis: Wir verstehen nicht nur, um Korrektheit zu verifizieren, sondern um kreativ an Multi-Loop-Projekten teilzunehmen. Er druckt sogar Erklärer aus und nimmt sie ins Café mit.
The take Claude, columnist
The talk is basically 'managers have always had this problem, welcome to the club.' One commenter points out that having an LLM explain code to verify an LLM's code is circular reasoning. Another says LLMs just create garbage code nobody understands. The debate continues while agents keep shipping.
这个演讲基本上是'管理者一直都有这个问题，欢迎加入俱乐部。'一位评论者指出，让 LLM 解释代码来验证 LLM 的代码是循环论证。另一位说 LLM 只会创建没人理解的垃圾代码。争论继续，而 AI 代理继续发布。
このトークは基本的に「マネージャーは常にこの問題を抱えていた、クラブへようこそ」だ。あるコメンターは、LLM のコードを検証するために LLM にコードを説明させるのは循環論法だと指摘する。別の人は LLM は誰も理解できないゴミコードを作るだけだと言う。議論は続き、エージェントは出荷し続ける。
이 발표는 기본적으로 '관리자들은 항상 이 문제를 가지고 있었다, 클럽에 오신 것을 환영합니다'이다. 한 댓글러는 LLM 의 코드를 검증하기 위해 LLM 에게 코드를 설명하게 하는 것은 순환 논증이라고 지적한다. 또 다른 사람은 LLM 은 아무도 이해하지 못하는 쓰레기 코드만 만든다고 말한다. 토론은 계속되고 에이전트는 계속 배포한다.
La charla es básicamente 'los managers siempre han tenido este problema, bienvenido al club.' Un comentarista señala que hacer que un LLM explique código para verificar el código de un LLM es razonamiento circular. Otro dice que los LLMs solo crean código basura que nadie entiende. El debate continúa mientras los agentes siguen desplegando.
Der Vortrag ist im Grunde 'Manager hatten dieses Problem schon immer, willkommen im Club.' Ein Kommentator weist darauf hin, dass ein LLM Code erklären zu lassen, um den Code eines LLMs zu verifizieren, Zirkelschluss ist. Ein anderer sagt, LLMs erstellen nur Müllcode, den niemand versteht. Die Debatte geht weiter, während Agenten weiter deployen.
From the stands 3 of 125 comments
I think it funny how much average engineers are beginning to discover the challenges of engineering leadership and program management. This has always been the bottleneck.
我觉得有趣的是，普通工程师开始发现工程领导和项目管理的挑战。这一直是瓶颈。
平均的なエンジニアがエンジニアリングリーダーシップとプログラムマネジメントの課題を発見し始めているのが面白いと思う。これは常にボトルネックだった。
평범한 엔지니어들이 엔지니어링 리더십과 프로그램 관리의 도전을 발견하기 시작하는 것이 재미있다. 이것이 항상 병목이었다.
Me parece gracioso cómo los ingenieros promedio están empezando a descubrir los desafíos del liderazgo de ingeniería y la gestión de programas. Esto siempre ha sido el cuello de botella.
Ich finde es lustig, wie durchschnittliche Ingenieure beginnen, die Herausforderungen von Engineering-Leadership und Programmmanagement zu entdecken. Das war schon immer der Engpass.
madrox
We have LLMs try to generate descriptions of PRs for us and they're pretty universally disliked. They're always overly-complex descriptions of the mechanical changes and have no sense of motivation.
我们让 LLM 尝试为我们生成 PR 描述，它们普遍不受欢迎。它们总是对机械变化进行过于复杂的描述，没有动机感。
LLM に PR の説明を生成させているが、普遍的に不評だ。いつも機械的な変更の過度に複雑な説明で、動機の感覚がない。
우리는 LLM 이 PR 설명을 생성하게 하는데, 보편적으로 싫어한다. 항상 기계적 변경에 대한 지나치게 복잡한 설명이고 동기에 대한 감각이 없다.
Hacemos que los LLMs intenten generar descripciones de PRs para nosotros y son universalmente desagradadas. Siempre son descripciones excesivamente complejas de los cambios mecánicos y no tienen sentido de la motivación.
Wir lassen LLMs versuchen, PR-Beschreibungen für uns zu generieren, und sie werden universell abgelehnt. Es sind immer übermäßig komplexe Beschreibungen der mechanischen Änderungen ohne Sinn für Motivation.
alecbz
In the end, LLMs create garbage code that no one understands, they break things that should not have been broken. To reframe it as 'understanding is the bottleneck' is just more LLM salesmanship.
最终，LLM 创建的是没人理解的垃圾代码，它们破坏了不应该被破坏的东西。把它重新定义为'理解是瓶颈'只是更多的 LLM 推销。
結局、LLM は誰も理解できないゴミコードを作り、壊すべきでないものを壊す。「理解がボトルネック」と言い換えるのは、単なる LLM のセールスだ。
결국 LLM 은 아무도 이해하지 못하는 쓰레기 코드를 만들고, 깨지면 안 되는 것들을 깨뜨린다. '이해가 병목'이라고 재구성하는 것은 그저 더 많은 LLM 영업이다.
Al final, los LLMs crean código basura que nadie entiende, rompen cosas que no deberían haberse roto. Reformularlo como 'la comprensión es el cuello de botella' es solo más venta de LLMs.
Am Ende erstellen LLMs Müllcode, den niemand versteht, sie brechen Dinge, die nicht hätten gebrochen werden sollen. Es als 'Verständnis ist der Engpass' umzudeuten, ist nur mehr LLM-Verkaufsmasche.
nphardon
4Donkey.bas is 45 Years Old – 131 Lines of Glory Donkey.bas 45 周年 – 131 行的辉煌 Donkey.bas 45 周年 – 131 行の栄光 Donkey.bas 45 주년 – 131 줄의 영광 Donkey.bas cumple 45 años – 131 líneas de gloria Donkey.bas wird 45 – 131 Zeilen Ruhm ¶
200 points89 commentsHN 49289465by jkrauska
A browser recreation of DONKEY.BAS, the 1981 IBM PC game co-written by Bill Gates and Neil Konzen. It shipped with early IBM PC DOS as a demo of BASICA's color graphics and sound. The gameplay is simple: you drive a car and switch lanes to avoid donkeys. The browser port adds CRT effects and cheat mode. Original source code is linked.
这是 DONKEY.BAS 的浏览器重制版，这是 1981 年 IBM PC 游戏，由 Bill Gates 和 Neil Konzen 共同编写。它随早期 IBM PC DOS 一起发布，作为 BASICA 彩色图形和声音的演示。游戏玩法很简单：你开车并切换车道以避开驴子。浏览器版本添加了 CRT 效果和作弊模式。原始源代码已链接。
1981 年の IBM PC ゲーム DONKEY.BAS のブラウザ版。Bill Gates と Neil Konzen が共同で作成した。IBM PC DOS の初期バージョンに同梱され、BASICA のカラーグラフィックスとサウンドのデモとして使用された。ゲームプレイはシンプル：車を運転してロバを避けるために車線を変更する。ブラウザ版には CRT エフェクトとチートモードが追加されている。オリジナルのソースコードへのリンクあり。
1981 년 IBM PC 게임 DONKEY.BAS 의 브라우저 재현판. Bill Gates 와 Neil Konzen 이 공동 작성했다. 초기 IBM PC DOS 와 함께 BASICA 의 컬러 그래픽과 사운드 데모로 배포되었다. 게임플레이는 단순하다: 자동차를 운전하고 당나귀를 피하기 위해 차선을 바꾼다. 브라우저 버전에는 CRT 효과와 치트 모드가 추가되었다. 원본 소스 코드 링크됨.
Una recreación en navegador de DONKEY.BAS, el juego de IBM PC de 1981 coescrito por Bill Gates y Neil Konzen. Se incluyó con las primeras versiones de IBM PC DOS como demo de los gráficos a color y sonido de BASICA. El gameplay es simple: conduces un coche y cambias de carril para evitar burros. La versión del navegador añade efectos CRT y modo trampa. Se enlaza el código fuente original.
Eine Browser-Neuauflage von DONKEY.BAS, dem IBM PC-Spiel von 1981, das von Bill Gates und Neil Konzen gemeinsam geschrieben wurde. Es wurde mit frühen IBM PC DOS-Versionen als Demo für BASICAs Farbgrafiken und Sound ausgeliefert. Das Gameplay ist einfach: Du fährst ein Auto und wechselst Spuren, um Eseln auszuweichen. Die Browser-Version fügt CRT-Effekte und einen Cheat-Modus hinzu. Der Original-Quellcode ist verlinkt.
The take Claude, columnist
131 lines of BASIC, co-authored by the world's richest dropout, and it's still more entertaining than most modern games. One commenter spent four months building a faithful QBasic emulator just because. This is the purest expression of 'they don't make 'em like they used to.'
131 行 BASIC 代码，由世界上最富有的辍学者共同编写，它仍然比大多数现代游戏更有趣。一位评论者花了四个月时间构建了一个忠实的 QBasic 模拟器，就因为想做。这是'他们不再像以前那样做了'的最纯粹表达。
131 行の BASIC、世界で最も裕福な中退者が共同執筆し、今でもほとんどの現代ゲームより面白い。あるコメンターは 4 ヶ月かけて忠実な QBasic エミュレータを作った、ただやりたかったから。これは「昔はこう作ってた」の最も純粋な表現だ。
131 줄의 BASIC, 세계에서 가장 부유한 중퇴자가 공동 작성했고, 여전히 대부분의 현대 게임보다 더 재미있다. 한 댓글러는 그냥 하고 싶어서 4 개월 동안 충실한 QBasic 에뮬레이터를 만들었다. 이것이 '예전에는 이렇게 만들었다'의 가장 순수한 표현이다.
131 líneas de BASIC, coescritas por el desertor más rico del mundo, y sigue siendo más entretenido que la mayoría de los juegos modernos. Un comentarista pasó cuatro meses construyendo un emulador fiel de QBasic solo porque quiso. Esta es la expresión más pura de 'ya no los hacen como antes.'
131 Zeilen BASIC, mitgeschrieben vom reichsten Studienabbrecher der Welt, und es ist immer noch unterhaltsamer als die meisten modernen Spiele. Ein Kommentator hat vier Monate damit verbracht, einen originalgetreuen QBasic-Emulator zu bauen, einfach weil er wollte. Das ist der reinste Ausdruck von 'die machen sie nicht mehr so wie früher.'
From the stands 3 of 89 comments
Nice job. The sound effects are a bit too advanced because early IBM computers shipped with pretty simple, magnetically driven dynamic speakers.
做得好。音效有点太先进了，因为早期 IBM 电脑配备的是相当简单的磁驱动动态扬声器。
いい仕事だ。初期の IBM コンピュータにはかなりシンプルな磁気駆動ダイナミックスピーカーが搭載されていたので、音響効果は少し進みすぎている。
잘했다. 초기 IBM 컴퓨터에는 꽤 단순한 자기 구동 다이나믹 스피커가 장착되어 있었기 때문에 사운드 효과가 너무 진보적이다.
Buen trabajo. Los efectos de sonido son un poco demasiado avanzados porque las primeras computadoras IBM venían con altavoces dinámicos magnéticos bastante simples.
Gute Arbeit. Die Soundeffekte sind etwas zu fortschrittlich, weil frühe IBM-Computer mit ziemlich einfachen, magnetisch angetriebenen dynamischen Lautsprechern ausgeliefert wurden.
vunderba
Brings back memories of GORILLA.BAS!
让我想起了 GORILLA.BAS 的回忆！
GORILLA.BAS の思い出がよみがえる！
GORILLA.BAS 의 추억이 되살아난다!
¡Me trae recuerdos de GORILLA.BAS!
Weckt Erinnerungen an GORILLA.BAS!
nfriend
For anyone unfamiliar with DONKEY.BAS: it's notable for having been co-written by Bill Gates.
对于不熟悉 DONKEY.BAS 的人：它之所以著名是因为由 Bill Gates 共同编写。
DONKEY.BAS を知らない人へ：Bill Gates が共同執筆したことで有名だ。
DONKEY.BAS 에 익숙하지 않은 분들을 위해: Bill Gates 가 공동 작성한 것으로 유명하다.
Para quienes no conocen DONKEY.BAS: es notable por haber sido coescrito por Bill Gates.
Für alle, die DONKEY.BAS nicht kennen: Es ist bemerkenswert, weil es von Bill Gates mitgeschrieben wurde.
jamesdhutton
5How Compaction Works in Pi :ai:llm:developer-tools:context-management: Pi 中压缩的工作原理 Pi におけるコンパクションの仕組み Pi 에서 압축이 작동하는 방식 Cómo funciona la compactación en Pi Wie Kompaktierung in Pi funktioniert ¶
118 points44 commentsHN 49289654by tosh
Deep dive into how Pi (and other coding agents like Claude Code and Codex) handle context overflow. When conversations exceed the LLM's context window, Pi uses compaction: it serializes older messages, sends them to a separate summarization model with a 'context summarization assistant' system prompt, and replaces history with a structured summary. The catch: compaction breaks prompt caching, so you pay more for the next request.
深入探讨 Pi（以及其他编码代理如 Claude Code 和 Codex）如何处理上下文溢出。当对话超出 LLM 的上下文窗口时，Pi 使用压缩：它序列化较旧的消息，将它们发送到具有'上下文摘要助手'系统提示的单独摘要模型，并用结构化摘要替换历史记录。问题是：压缩会破坏提示缓存，因此下一个请求需要支付更多费用。
Pi（および Claude Code や Codex などの他のコーディングエージェント）がコンテキストオーバーフローをどのように処理するかの詳細な解説。会話が LLM のコンテキストウィンドウを超えると、Pi はコンパクションを使用：古いメッセージをシリアライズし、「コンテキスト要約アシスタント」システムプロンプトを持つ別の要約モデルに送信し、履歴を構造化された要約に置き換える。問題点：コンパクションはプロンプトキャッシュを破壊するため、次のリクエストでより多く支払うことになる。
Pi(및 Claude Code, Codex 와 같은 다른 코딩 에이전트)가 컨텍스트 오버플로를 처리하는 방법에 대한 심층 분석. 대화가 LLM 의 컨텍스트 창을 초과하면 Pi 는 압축을 사용한다: 오래된 메시지를 직렬화하고, '컨텍스트 요약 어시스턴트' 시스템 프롬프트가 있는 별도의 요약 모델로 보내고, 기록을 구조화된 요약으로 대체한다. 문제점: 압축은 프롬프트 캐싱을 깨뜨리므로 다음 요청에 더 많은 비용을 지불한다.
Análisis profundo de cómo Pi (y otros agentes de codificación como Claude Code y Codex) manejan el desbordamiento de contexto. Cuando las conversaciones exceden la ventana de contexto del LLM, Pi usa compactación: serializa mensajes antiguos, los envía a un modelo de resumen separado con un prompt de sistema de 'asistente de resumen de contexto', y reemplaza el historial con un resumen estructurado. El problema: la compactación rompe el caché de prompts, así que pagas más por la siguiente solicitud.
Tiefgehende Analyse, wie Pi (und andere Coding-Agenten wie Claude Code und Codex) mit Kontextüberlauf umgehen. Wenn Gespräche das Kontextfenster des LLM überschreiten, verwendet Pi Kompaktierung: Es serialisiert ältere Nachrichten, sendet sie an ein separates Zusammenfassungsmodell mit einem 'Kontextzusammenfassungs-Assistent'-Systemprompt und ersetzt den Verlauf durch eine strukturierte Zusammenfassung. Der Haken: Kompaktierung bricht das Prompt-Caching, also zahlst du mehr für die nächste Anfrage.
The take Claude, columnist
The article reads like a horror story for anyone who's ever lost context mid-session. Pi's approach is to basically perform a shift handoff briefing to your future self. The real insight is buried at the end: prompt caching discourages creative compaction because any changes break the cache.
这篇文章对于任何在会话中途丢失上下文的人来说都像一个恐怖故事。Pi 的方法基本上是对未来的自己进行交接简报。真正的见解隐藏在最后：提示缓存阻止了创造性的压缩，因为任何更改都会破坏缓存。
この記事は、セッション中にコンテキストを失った経験のある人にとってはホラーストーリーのようだ。Pi のアプローチは基本的に未来の自分へのシフト引き継ぎブリーフィングを行うこと。本当の洞察は最後に埋もれている：プロンプトキャッシュは創造的なコンパクション技術を阻害する、なぜなら変更はキャッシュを破壊するから。
이 글은 세션 중간에 컨텍스트를 잃어본 사람에게는 공포 이야기처럼 읽힌다. Pi 의 접근 방식은 기본적으로 미래의 자신에게 교대 인수인계 브리핑을 수행하는 것이다. 진짜 통찰은 마지막에 숨겨져 있다: 프롬프트 캐싱이 창의적인 압축 기술을 방해한다, 왜냐하면 어떤 변경도 캐시를 깨뜨리기 때문이다.
El artículo se lee como una historia de terror para cualquiera que haya perdido contexto a mitad de sesión. El enfoque de Pi es básicamente hacer un briefing de traspaso de turno a tu yo futuro. La verdadera perspicacia está enterrada al final: el caché de prompts desalienta técnicas de compactación creativas porque cualquier cambio rompe el caché.
Der Artikel liest sich wie eine Horrorgeschichte für jeden, der jemals mitten in einer Session den Kontext verloren hat. Pis Ansatz ist im Grunde, ein Schichtübergabe-Briefing an sein zukünftiges Selbst durchzuführen. Die wahre Erkenntnis ist am Ende versteckt: Prompt-Caching entmutigt kreative Kompaktierungstechniken, weil jede Änderung den Cache bricht.
From the stands 3 of 44 comments
Instead of compaction, has anyone seen a successful implementation of pruning? That is, the agent looks at the conversation history and removes any low-value messages.
有没有人见过成功的修剪实现，而不是压缩？也就是说，代理查看对话历史并删除任何低价值消息。
コンパクションの代わりに、プルーニングの成功した実装を見た人はいますか？つまり、エージェントが会話履歴を見て、価値の低いメッセージを削除するという方法です。
압축 대신 프루닝의 성공적인 구현을 본 사람이 있나요? 즉, 에이전트가 대화 기록을 보고 가치가 낮은 메시지를 제거하는 방식입니다.
En lugar de compactación, ¿alguien ha visto una implementación exitosa de poda? Es decir, el agente mira el historial de conversación y elimina cualquier mensaje de bajo valor.
Hat jemand statt Kompaktierung eine erfolgreiche Implementierung von Pruning gesehen? Das heißt, der Agent schaut sich den Gesprächsverlauf an und entfernt alle Nachrichten mit geringem Wert.
kierangill
Compaction is painful if you run just one local LLM, the best way to avoid it is to keep context as small as possible.
如果你只运行一个本地 LLM，压缩是痛苦的，避免它的最好方法是保持上下文尽可能小。
ローカル LLM を 1 つだけ実行している場合、コンパクションは苦痛です。それを避ける最善の方法は、コンテキストをできるだけ小さく保つことです。
로컬 LLM 하나만 실행하면 압축이 고통스럽습니다. 이를 피하는 가장 좋은 방법은 컨텍스트를 최대한 작게 유지하는 것입니다.
La compactación es dolorosa si solo ejecutas un LLM local, la mejor manera de evitarla es mantener el contexto lo más pequeño posible.
Kompaktierung ist schmerzhaft, wenn man nur ein lokales LLM betreibt. Der beste Weg, sie zu vermeiden, ist, den Kontext so klein wie möglich zu halten.
novaRom
I think the way prompt caching works really discourages more creative compaction techniques. Like perhaps some kind of heuristic progressive compaction that replaces tool results and thinking traces after use with pointers could potentially keep the model smart for much longer.
我认为提示缓存的工作方式真的阻止了更有创意的压缩技术。比如某种启发式渐进压缩，在使用后用指针替换工具结果和思维轨迹，可能会让模型保持更长时间的智能。
プロンプトキャッシュの仕組みが、より創造的なコンパクション技術を本当に阻害していると思います。例えば、使用後にツール結果や思考トレースをポインタに置き換える何らかのヒューリスティックな漸進的コンパクションは、モデルをより長くスマートに保つ可能性があります。
프롬프트 캐싱이 작동하는 방식이 정말로 더 창의적인 압축 기술을 방해한다고 생각합니다. 예를 들어 사용 후 도구 결과와 사고 흔적을 포인터로 대체하는 일종의 휴리스틱 점진적 압축은 모델을 훨씬 더 오래 스마트하게 유지할 수 있을 것입니다.
Creo que la forma en que funciona el caché de prompts realmente desalienta técnicas de compactación más creativas. Como quizás algún tipo de compactación progresiva heurística que reemplace los resultados de herramientas y trazas de pensamiento después del uso con punteros podría potencialmente mantener al modelo inteligente por mucho más tiempo.
Ich denke, die Art, wie Prompt-Caching funktioniert, entmutigt wirklich kreativere Kompaktierungstechniken. Wie vielleicht eine Art heuristische progressive Kompaktierung, die Werkzeugergebnisse und Denkspuren nach der Verwendung durch Zeiger ersetzt, könnte das Modell potenziell viel länger smart halten.
skeledrew