待翻译：Real Engineers Dig with Their Bare Hands

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

July 14, 2026 Real Engineers Dig With Their Bare Hands Yes, Father, I have sinned. I let a machine write the boring parts. No, I am not vibe coding. There is a difference, and the difference is two weeks of rules, a clear architecture, automated checks, and knowing exactly when to take the shovel back. Two neighbors stop in front of a construction site and look through the fence. Inside, five workers are using two enormous machines to finish digging a massive hole. One neighbor shakes his head. “Fifty people could have dug that with shovels. Everyone would have had a job.” The other looks at him and says, “Why stop at fifty? A thousand people could have dug it with their bare hands.” My previous essay about working with AI generated a longer discussion than I expected on HN, and some people complained that I did not give any specific details about how I work. So, in this essay, I want to explain what I have actually automated in my engineering workflow. This includes access to a Git repository with all the rules I typically use in a large project. Before getting into the practical part, though, I need to address the predictable objections: You are vibe coding. You are AI-pilled. You will eventually forget how software works. These objections argue against a point I am not making. I am not saying that learning how things work under the hood is a waste of time. Quite the opposite. That knowledge is precisely what allows me to automate safely, inspect the result, and recognize when an agent has done something stupid. Delegating grunt work is not the same as delegating judgment. Running formatters, checking architectural boundaries, finding empty files, detecting unused dependencies, and preparing a migration plan are mostly mechanical tasks. Determining whether the generated code is correct, whether the abstraction makes sense, whether the architecture is appropriate, and whether the system should exist in the first place still requires an engineer. The machine does not assume responsibility. I do. When I was younger, I uploaded files manually through FTP and SSH. I edited code in text editors with no syntax highlighting, no autocomplete, no inline warnings, and no useful feedback until compilation failed. Sometimes the feedback arrived even later, when the system broke in production. Great times. Very character-building. To reduce human error (or at least give it fewer opportunities to express itself), I remember using Teleport Pro and WinHTTrack to crawl our applications and find broken links. Then text editors acquired syntax highlighting, which felt almost unfair. IDEs started warning us before compilation. Autocomplete became normal. Suddenly, the computer was helping instead of silently watching us make mistakes. I replaced repeated uploads with rsync, wrote shell scripts, and eventually adopted version control, automated tests, CI/CD pipelines, infrastructure as code, dependency bots, static analysis, and increasingly sophisticated deployment systems. Each new tool eliminated another task that developers had previously considered a sacred manual ritual. None of those tools made knowledge about servers, networking, permissions, failures, or rollbacks unnecessary. They simply removed repetitive execution, caught mistakes earlier, and reduced the number of Friday evenings spent discovering that someone had uploaded the wrong folder to production. AI agents feel like the next step in the same progression. I am not outsourcing understanding. I am automating execution and catching errors closer to where they are introduced and writing boilerplate code. In any case, engineers still need to decide whether the code is correct, the abstraction makes sense, the architecture fits, and the system should exist at all. Heck, even Linus Torvalds reaffirms that Linux is not anti-AI. We have used graphical Git clients, IDE refactoring tools, and autocomplete for years without declaring that engineering is dead because someone clicked a button. But as my grandfather said to me multiple times, “convenience always wins over nostalgia”, especially when it also prevents mistakes. Working with an agent is not fundamentally different from using another high-level interface over a complicated system. It is a new kind of GUI, although sometimes it is closer to a NOGUI because the interaction happens through language rather than menus. The interface is more powerful, but the principle is familiar. You describe the intended result. The tool performs a collection of lower-level operations, write boilerplate code for you. You inspect what it did. You approve, reject, or correct the result. The important difference is that agents can operate across a much larger surface area. They can read a repository, follow instructions, modify several components, run tests, inspect failures, and iterate. That does not make them infallible. It makes good instructions and verification much more important. We are also past the stage where agents only generate tiny CRUD applications for demos. Anthropic recently described an experiment in which 16 parallel agents produced a Rust-based C compiler from scratch. Over almost 2,000 Claude Code sessions, the agents generated roughly 100,000 lines of code and reached the point where the compiler could build Linux 6.9 for x86, ARM, and RISC-V. That’s impressive. Bun has also undergone a large migration from Zig to Rust, with its current repository instructions describing the project as primarily written in Rust with just one engineer. Microsoft is applying agents to codebase-wide refactoring, framework migrations, tests, modernization, and work across large repositories. Its own developer material explicitly presents agent mode as capable of changing multiple files and migrating legacy code to modern frameworks. Microsoft engineers are also working in increasingly common hybrid C++ and Rust codebases. These examples do not prove that agents can autonomously replace an engineering organization. They prove something less dramatic and more useful: agents can already perform substantial work on real codebases when experienced people provide direction, constraints, and verification. Programming was moving toward higher-level composition long before “vibe coding” became a phrase. Engineers have spent decades installing, configuring, and combining software written by other people without reading every line of its source. The relevant question is whether you understand the abstractions you depend on, the decisions you are making, and the failure modes you are accepting. The same standard should apply to agents. Agents do not automatically produce vibe-coded software. People produce vibe-coded software when they accept systems they do not understand. You can create a mess by copying code from Stack Overflow, following a tutorial, installing the wrong framework, hiring an incompetent consultancy, or giving an AI agent unrestricted access to a repository. The agent is not the defining feature. The absence of engineering judgment is. Real vibe coding happens when someone cannot explain: Why the architecture has its current shape. Why a dependency was introduced. Where business rules live. How transactions are handled. Which components are allowed to communicate. What happens when an external service fails. How data moves through the system. How to test, deploy, observe, or recover it. How to modify the software without asking the machine to rediscover everything. That is a dangerous position, regardless of how the code was produced. Using agents responsibly means retaining ownership of the decisions while delegating parts of the execution. You still write code. Often you write quite a lot of it, because agents are imperfect and some tasks are easier to start or finish by hand. Sometimes I implement the core idea myself and use agents to propagate it through the system. Sometimes the agent builds the first version and I replace the parts I dislike. Sometimes it only investigates the repository and gives me an executable plan. The relationship is not “the agent codes and I watch.” It is closer to directing several extremely fast junior engineers who have read half the internet, never get tired, occasionally misunderstand obvious instructions, and remain capable of confidently constructing something absurd. The most important part of my setup is not a clever prompt. It is the collection of rules that defines how agents are allowed to work inside a project. I do not rely exclusively on a giant AGENTS.md file. Instead, I keep a small index and a structured .agents/ directory containing focused rules. A simplified version looks like this: AGENTS.md .agents/ rules/ 00-agent-behavior.md 01-project-boundaries.md 02-git-and-branching.md 03-surfacing-gaps-and-incomplete-work.md 04-file-headers-and-comments.md 05-security.md 10-naming-files-and-folders.md 11-constants-and-enums.md 12-abstractions.md 14-code-naming.md 15-control-flow-and-nesting.md 16-conditional-logic.md ... AGENTS.md acts as the index. It tells the agent which rules exist, what they cover, and when they should be loaded. It matters because a single enormous instruction file is not necessarily better. Agents have finite context, and wasting that context on irrelevant rules leaves less room for the repository, the task, and the actual implementation. An agent working on a domain object does not always need the complete PostgreSQL migration policy. An agent updating Docker configuration does not need every frontend naming rule. The system should load the relevant constraints for the work being performed. Rules must be short enough to remain usable and specific enough to influence behavior. Writing a book for every rule defeats the purpose. The agent will spend its context reading your constitution and have no space left to govern the country. You can see an example of a monorepo with several rules and skills I normally use. Before defining language conventions or architecture, I define how I want agents to work with me (the 01-agent-behavior.md file defines this). This is the universal behavior layer. It covers things such as: Read the relevant documentation and project rules before changing code. (Yeah, that obvious) Do not silently invent requirements. Surface missing information and incomplete work. Explain uncertainty instead of hiding it. Do not change unrelated files. Do not install dependencies without approval. Do not weaken tests to make a build pass. Do not suppress errors that should be fixed. Show an implementation plan before large changes. Communicate with me in Spanish, but write code and technical identifiers in English. Keep explanations direct and reasonably short. Stop at destructive or irreversible operations. Ask for approval before deleting or replacing significant components. These instructions may sound obvious to you, but they are not obvious to an agent. Agents are optimized to complete tasks. Without boundaries, they may choose the shortest path to a green test suite, even when that path involves changing the test, bypassing the architecture, adding an unnecessary package, swallowing an error, or quietly narrowing the original requirement. A useful rule does not merely describe the desired outcome. It also defines unacceptable shortcuts. You should not blindly copy another person’s rules and assume your project is now safe. Rules encode judgment. A respected Go engineer may publish an excellent set of conventions, but those conventions reflect that engineer’s experience, preferences, architecture, and operational environment. More on this one, every LLM will execute rules differently, based on context window power, trainning, etc. Your set of rules may not perform equally if you are using Opus 4.8 than Gemini 2.5. Copying them can produce good-looking code while leaving you unable to explain why the system works that wa [truncated for AI cost control]