手写代码的日子永远结束了。
Writing code by hand is over, forever

原始链接: https://eliocapella.com/blog/writing-code-by-hand-is-over/

手写代码18年后,作者发现,向 AI 解释自己的意图比亲手实现更快。最初让人感到不安的做法,如今带来了解放:提示词能把设想中的改进转化为实际可用的改动,而 AI 智能体则显著提升了生产力和抱负。 在 Filestage,AI 辅助开发帮助团队将每月合并的拉取请求从大约 200 个提高到 300 个,同时没有增加漏洞报告;每位开发者每月只需支付 20 美元。完善的 CI 防护机制——包括代码检查、类型检查、重复代码检测、完整的测试覆盖率以及端到端测试——让更大规模、更有把握的改动成为可能。AI 生成的基础设施还解决了新增工作量带来的新瓶颈。 作者预计,AI 代码审查将变得不可或缺,甚至可能足以支持代码合并;但他对“编程智能体将用汇编语言或微代码取代高级语言”这一观点表示怀疑。紧凑且抽象的代码能够保留上下文和意图,而编译器已经能够可靠地完成底层转换。 更广泛的未来可能会超越手动编辑文件,转向以逻辑为先的可视化界面,并让这些界面始终与生产系统保持同步。对于一个曾经以为自己懂编程的人来说,这样的未来既陌生,又令人兴奋。

一个 Hacker News 讨论串围绕“AI 编程会让手写程序过时”的观点展开争论。批评者认为,编程仍然是一种令人享受、也能带来认知满足感的技艺;开发者必须理解生成的系统,才能调试、维护和推理。他们担心,看似合理但架构拙劣的代码可能带来隐蔽缺陷、性能问题以及长期的维护成本。 支持者则回应称,编程一直就是将抽象概念与已有组件组合起来;LLM 生成的代码只是另一种代码来源。他们表示,在提供充分上下文和明确指导的情况下,AI 可以更快地为大型项目搭建框架、编写测试、重构代码并完成部署,因此他们预测,手动实现代码在未来几年内将基本消失。 其他担忧还包括订阅费用上涨、依赖 AI 厂商、模型可用性不确定,以及 AI 生成的文字是否尊重读者的时间。评论者还批评文章的数据可视化和写作不够清晰;另一个无关的讨论则攻击了 DHH,尽管一些评论者采纳了他的技术理念,却与他无关的种族观点持批评态度。总体而言,这个讨论串预测,编程将会继续存在,但主要作为一门爱好或高阶的创造性实践。
相关文章

原文

I wrote code by hand every day for 18 years. Then, almost from one day to the next, I stopped.

Last year, AI gradually worked its way into my routine. Paste some code into a web chat for a second opinion. Describe a query in English. Ask for a regular expression instead of remembering the syntax. Useful little shortcuts.

Then Opus 4.5 in Claude Code crossed a threshold for me. Explaining what I wanted was faster than writing it myself. Just like that, a daily habit of nearly two decades was gone. Several months later, I feel less and less tempted to touch the code by hand. I can't imagine going back.

I understand why this feels unsettling. When you've spent years getting good at something, watching a machine do it is a lot to process. But the feeling I keep coming back to is liberation. So many improvements I would have put off now start with a prompt. Being able to build so much of what I can imagine is breathtaking.

1986 newspaper clipping headed Math teachers protest against calculator use. A teacher holds a sign saying OFF until upper grades.
Teachers protesting early calculator use in elementary school. The Daily Item, April 5, 1986. AP photo. Via Reddit.

At Filestage, we've gone from around 200 to 300 merged PRs a month without an increase in bug reports. That's roughly 50% more, with a $20 monthly AI subscription per developer. Everyone chooses their own tool: some use Codex, some Claude Code, some Cursor. PR counts only tell part of the story. We're also tackling bigger changes across the product in less time and with more confidence.

Monthly merged PRs from 2024 through 2026, with the smoothed trend rising from around 150 to 200 early on to around 300 near the end.
Monthly merged PRs across the team.
Monthly incoming bugs over the same period fluctuate without a sustained increase as merged PRs rise.
Incoming bug reports over the same period.

The agents keep improving, and our investment in CI guardrails is paying off: linting, type checking, duplication checks, 100% test coverage, and end-to-end tests. The feedback is there every time an agent makes a change.

Seeing that makes me wonder: could we be going even faster? Models have become good enough that I now consider it irresponsible to merge without an AI code review. Could passing our checks and getting an AI review's approval eventually be enough to merge a PR? I haven't settled that question, but it no longer sounds far-fetched.

The extra throughput has already exposed bottlenecks in our CI. We hit Cloudflare's free tunnel limits because our end-to-end test instances need to receive webhooks from third parties. CI started breaking for our engineers. We also had to give our shared development database more resources to handle the connections.

Using our infrastructure as code setup and open source FRP tunnels, I quickly vibe coded a solution to the problem. The tools creating the extra load also helped remove the bottleneck. A colleague made me laugh with this meme he generated:

An engineer's meme puts my face on Thanos, with the caption: Fine. I'll do it myself.
When the tunnel limit breaks CI and you build your own.

I agreed with a lot of DHH's Rails World keynote about the end of writing code by hand. But his prediction that agents will move from Rust and C++ to assembly and eventually microcode goes too far for me.

DHH argues that Rust and C++ are temporary prompt compilation targets, predicting that agents will eventually generate assembly and microcode.
DHH on how far down the stack coding agents might go.

I see the attraction of getting an agent to write a faster implementation in a language I wouldn't choose to write myself. But high-level representations are useful to the agent too. Given how today's LLMs generate code, I see several reasons to keep them:

  • More output means more details to get right. Generating assembly means predicting registers, offsets, and calling-convention details that a compiler would otherwise handle.
  • Compact code preserves context. users.filter(u => u.active) expresses an operation in a few tokens that can take many assembly instructions. Understanding a repository that already fills 200,000 tokens is hard enough before expanding it into lower-level instructions.
  • Abstractions help reasoning. Types, functions, modules, ownership, and data structures expose intent and constraints. Lowering everything to assembly makes much of that information harder to recover.

We also already have tools such as Clang to turn source code into native machine code. Why spend probabilistic inference reproducing routine translation that a deterministic compiler already handles efficiently? Targeted assembly optimization may be worthwhile, but I wouldn't make it the default representation for a whole system.

My bet remains: LLM → high-level representation → deterministic compiler → machine code. The representation may change. I expect useful abstractions to become even more valuable as agents take on larger systems.

I've always been frustrated with how we build software. Bret Victor's The Future of Programming captured that feeling beautifully: look at the possibilities explored decades ago, then look at what we settled for.

Years matching parentheses and quotes. Debating tabs and spaces. Searching hundreds of files to reconstruct how something works. Formatters and linters helped, but I still had to hold the system in my head while staring at little pieces of it.

If agents can handle the code, could we finally work directly with the logic, interfaces, and data models we want? Could UML and entity relationship diagrams become useful everyday interfaces to a living system, kept in sync as we change it?

I want to see a use case and zoom into its logic, all the way down to the code when I need to. See how data moves through it. Bring production context into that view: which paths people actually use, where requests get stuck, which branches never run.

I don't know what that environment will look like. But for the first time in years, it feels within reach.

After 18 years of typing code, I thought I knew what programming felt like. I'm excited to find out what it feels like next.

联系我们 contact @ memedata.com