Engineering in Natural Language
I value writing high-quality code, and I’m curious how things work. Over the past few years I’ve been experimenting with AI coding assistants, with results that have ranged from genuinely useful to actively frustrating. As I’ve continued using them, though, I’ve found myself reaching for them more often, not because they replace engineering, but because they often help me write better code faster than I could before. The shift in my thinking has been realizing that natural language is becoming a first-class engineering medium.
Much of the conversation around AI in software engineering focuses on efficiency: reducing friction by automating existing engineering tasks. I often see domain expertise treated as something to capture in an AI skill so the next engineer doesn’t need to learn it. That feels like optimizing the wrong part of the system. I’d rather build tools that help the next engineer acquire that expertise faster. Natural language is a powerful interface for transferring engineering knowledge, not just hiding it behind automation.
I feel similarly about AI code review. If an agent generated the implementation, it should critique, test, and refine that work before it ever asks for an engineer’s attention. By the time a change reaches code review, the implementation loop should already be complete. Code review serves a different purpose: another engineer builds an independent understanding of the change and decides whether it belongs in the codebase. Having another AI review AI-generated code feels like an ouroboros, a metaphorical snake consuming its own tail.
In my experience, this doesn’t improve the review process, it creates another layer of generated feedback for an engineer to interpret. The implementation loop has already happened. What the review is missing isn’t another AI opinion; it’s another engineer building an independent understanding of the change.
I’ve found it more useful to think of these systems as a new engineering interface. Natural language gives engineers a way to interact with code, documentation, tools, and one another that wasn’t practical before. That opens up opportunities to build tools that amplify engineering capabilities instead of simply replacing engineering effort.
When I use an AI agent like Codex or Claude, I use it to ground my understanding in the code. It builds on the engineering tools we’ve relied on for years: search, language servers, version control, build systems, and documentation. Instead of replacing my understanding, it helps me build one faster through a natural language interface. I can navigate a large codebase like Firefox more easily than ever, jumping into a gnarly IPC messaging problem or understanding how binaries are shipped on desktop versus mobile without prior domain expertise. When I’m doing a technical analysis, I can drive the investigation with natural language while grounding every conclusion in the current source of truth: the code itself.
The same interface naturally extends into implementation. Agents can follow existing patterns in the codebase and build complete implementations from detailed specifications. I can use natural language to explore requirements, write implementation plans, and iterate on solutions before writing or reviewing a line of code. As implementation becomes easier, engineering effort shifts toward understanding the problem, choosing the right solution, and helping others understand it.
This has made me appreciate good engineering writing even more. Design docs, implementation plans, and code reviews are where engineers work through ideas, explain tradeoffs, and build a shared understanding of a change. Those skills have always mattered, but they become even more important when implementation is no longer the hard part.
As implementation becomes cheaper, engineering organizations will spend less time asking, “Can we build it?” and more time asking, “Should we build it?”, “How should we build it?”, and “How do we get there together?” When you can generate 10,000 lines of code in a day, the challenge isn’t producing more code. It’s producing the right 10,000 lines.
That’s why I keep coming back to engineering in natural language. I don’t see it as a replacement for engineering, but as an expansion of how engineering happens. Natural language lets us understand systems, explore ideas, develop plans, reason about tradeoffs, and drive implementation. As those activities become a larger part of the job, I think we’ll have an opportunity to build a new generation of engineering tools that help us do them better.