Nine stages, two workers, one topic name
The factory that writes code for me is 2,274 lines of Python. Nine stages: draft a spec, plan it, implement it, prove it ran, review the diff, commit, push, open a pull request, then watch that pull r... 
评论
点赞
收藏Other Men With Machines
Picture a farmer at the back of a church in 1400. He can’t read. Nobody ever offered to teach him, and nobody is going to. The book on the table up front is in Latin. The priest reads from it and tell...
Science fiction already tried both answers
Twenty minutes into a conversation about what an agent should be allowed to touch, when a non-expert asks: can’t we just give it Asimov’s laws? It’s always said in good faith. It’s also the most confi...
Can AI become conscious?
The Economist just dropped this article. Full disclosure: I haven’t read it in depth. But it did bring up some ideas I’ve been having around this for a while so I thought I would write them down. It’s...
The middle path between a stock agent and a custom harness
Here’s a conversation I keep watching play out. An engineering lead wants their team on a coding agent. Compliance won’t sign off on the stock one — no audit log, no way to block writes to secrets, no... 
The book I wrote because “harness” meant four different things
You’ve probably felt this. You point the same agent at two of your repos with the same lazy prompt, and one gives you a tight change you can review over coffee while the other hands back a sprawling P...
The Governance Gap Is a Boundary Problem
One of my early factory prototypes had a clean audit trail. Every action an agent took, recorded. Who did it, what it touched, and when it ran. I was proud of it. Then I watched an agent remove a stat...
Charter and Harness: What Each One Is
It seems that every time I think I know the shape of the harness, a new fact presents itself that I have to account for. I recently wrote a book Harness Engineering. But new information has caused me ...
Harness Engineering: Building Reliable Workflows Around Non-Deterministic Agents
Hello everyone. I just released a book about harness engineering. It’s on LeanPub. Pay what you want, starts at $10. What does it cover? The discipline, the taxonomy, the behavioral system, the reliab...
This just rearranged my view on harness engineering
I just read this article — I recommend you do as well. Loop Engineering Is Just Software Engineering. We Have a Name for That. I’ve been doing a lot of work on harnesses, but I have been focusing at t...
This One’s Not AI
I have a confession to make. I use AI to write articles. So what? I use AI to do lots of things. I’m not going to be embarrassed about using a tool to my advantage. However, doing this has taught me s...
Reading the Agent Log Like a Detective
The agent shipped a broken migration last month. The PR was clean, the tests passed locally, the reviewer signed off in twelve minutes, and the deploy to staging green-lit on the first try. Production...
What Breaks When You Skip the Harness
The agent kept running the tests, watching them go red, scrolling up to find the failure, and then running the tests again because it had already lost the output. Third time in one session. The model ...
Tools Are Harness Too
I had a rule in my project for months that said always check Code Health before committing. The agent followed it about 70% of the time. The other 30%, it forgot; usually on the longer tasks, when its...
驾驭工程：围绕非确定性智能体构建可靠工作流
作者Ian Johnson将其过去六个月在Medium上发布的关于非确定性Agent工作流的系列博文（包括Bridle、Sellier、IDD、Keystone等概念）整合成了一本新书《Harness Engineering》。 书中核心观点是通过实验验证了构建可靠Agent工作流的方法论：例如“飞轮效应”、“默认值优于灵活性”以及“团队层可以被具体化”。该书目前在LeanPub上线，采用“随心付”模式。 对于关注AI Agent工程化、工作流可靠性及LLM应用架构的开发者来说，这是一份经过实战检验的一手经验和系统性总结，具有较高的参考价值。
为什么我至今仍坚守在终端
作者回忆高中时期第一次安装 Linux 的经历，通过简单的管道命令快速排查日志，体会到了命令行比图形界面更高效、更直接的快感。这种初次接触终端带来的“掌控感”和效率体验，成为了他多年来坚持使用终端作为主要工作环境的核心动力。 文章通过个人故事阐述了终端在技术工作中的独特魅力。
Sensors: The Other Half of the Harness
The pre-commit hook caught a migration last Tuesday that would have shipped to staging green and broken production on the next deploy. The migration dropped a foreign key constraint without naming a b...
意外的框架：从简单脚本到架构演变的思考
作者最初构建了一个简单的Go二进制文件，用于将Markdown文件复制到仓库中，并将其称为安装程序。在规划1.0版本时，作者意识到该工具实际上具备框架的核心特征：包含运行时、命名扩展点、约定俗成的文件布局以及解析器。 文章探讨了从简单脚本演变为框架的过程，以及这种“意外”发现对软件设计和架构理解的启示。
代码规范文件也是入职导师
作者发现团队给AI Agent写的代码规范文件（如），对新入职工程师的引导作用远超传统文档。传统README是理想化的，而这个规范文件记录了团队踩过的坑、政治边界和具体操作细节，是“法医式”的真实记录。 文章提出将这份给Agent看的文档同时作为新人入职指南，通过让新人阅读并提问来反向优化文档，形成飞轮效应。建议开发者检查自己的Agent规范文件，补充人类可读的背景和原因，将其从单纯的机器指令升级为团队知识沉淀的核心载体。
Keystone 2.0：一次名副其实的升级
作者Ian Johnson详细解读了Keystone框架2.0版本的重大更新。核心变化在于确立了清晰的“框架词汇表”，将组件分为Framework和Agent两层，并通过索引文件简化了开发体验。 其次，新增了基于HTMX和SSE的实时操作仪表盘，让开发者能直观监控Agent状态。此外，还介绍了内置MCP服务器支持、带有基线对比的评估功能以及向1.x版本的平滑迁移命令。 整体而言，2.0版本通过增强可观测性和标准化接口，解决了1.x版本在工程化和维护性上的不足，是一个具有实质性改进的版本升级。
Keystone 2.0：一次值得期待的升级
作者Ian Johnson讨论了Keystone框架2.0版本的更新理念。他强调大版本升级必须带来实质性的形态变化，而非仅仅修改版本号。文章指出，开发者希望看到工具在核心架构或交互方式上有显著不同，否则就是浪费用户的注意力。 作者通过回顾Keystone 1.x的设计理念，引出2.0版本需要解决的关键问题，即如何让用户直观感受到这是一个全新的工具。这反映了当前前端框架迭代中普遍存在的“伪创新”现象，以及开发者对真正有价值的技术进步的期待。