The Most Valuable Skill in the AI Era: From Writing Code by Hand to Harnessing Coding Agents

When "vibe coding" lets one person ship a demo-able product over a weekend, what core competitiveness is left for programmers? In a widely circulated interview on Bilibili, developer Matt (founder of aihero.dev), who has roughly a decade of hand-coding experience, gives a counterintuitive answer: what's truly scarce isn't the speed of writing code, but the ability to clearly convey intent to agents and to build a good operating environment for them.

The Turning Point: From Skeptic to "Never Writing a Line of Code Again"

Matt admits he was long a skeptic of AI programming. With about ten years of hobby coding plus eight years of professional experience, he believed for a long time that LLM-written code was "just another bubble." The real turning point came after what he calls a leap in a certain model's capabilities—from that moment on, he began to believe "I will never write a line of code myself again."

Behind this judgment is not blind optimism about models, but his discovery that what he was truly good at throughout his career—helping colleagues, improving his team's working environment, passing on experience to others—happens to transfer directly to agents. When models become strong enough, these "soft skills" begin to translate directly into output.

According to figures he gave in the interview, he now runs four agents simultaneously handling long-term tasks across different projects, pushing 200 to 300 commits per day on GitHub, whereas during his hand-coding days "20 a day would be a good day." He himself admits the gap is "simply incomparable."

Core Argument: The Codebase Is the Agent's Working Environment

The most valuable part of the entire interview is Matt's repeated emphasis that "environment determines output." He uses a vivid metaphor: if you put a dog in a burning house, it can't behave normally. Similarly, put a powerful model into a "garbage codebase" that has never been seriously maintained and only chases output, and all you get is garbage results.

His thought experiment: suppose you manage a hundred human programmers—what strategy would you use to raise the floor of "the worst programmer"? Software engineering has accumulated decades of answers to this—write good tests, add checkpoints, prevent entire classes of bugs, make the codebase easier to modify over time. These books "read as if they were written last week," because they discuss exactly what agent-based development needs most right now.

This also explains why he insists that software engineering fundamentals are "more important, not less" in the AI era. People from non-technical backgrounds can benefit too: the key isn't whether you can write code yourself, but whether you're willing to care about codebase quality and to learn to constrain agent behavior with engineering principles.

The concept of a "floor" in software engineering refers to using engineering practices to ensure that even the least experienced members of a team don't produce catastrophic code. Common means include: automated testing (especially unit and integration tests) as a safety net, code review to block obvious errors, static analysis tools (such as linters) to catch common defects before commit, and continuous integration (CI) to validate changes before merging. The core logic of these practices is "prevention over cure"—preventing entire classes of bugs through constraints and checkpoints rather than relying on individual ability. In the AI agent context, the same logic applies: an agent's output quality depends heavily on the feedback signals and constraints in its environment. A codebase with comprehensive test coverage and clear module boundaries lets an agent quickly get "right/wrong" signals when modifying code, enabling self-correction; conversely, a codebase lacking tests and documentation leaves the agent groping in the dark, with errors accumulating. Therefore, software engineering fundamentals are not outdated in the AI era—they shift from constraining "people" to constraining "agents," and their importance only rises.

Communication Is the Real Moat

Matt repeatedly mentions an underappreciated fact: the communication barrier between humans and agents is far bigger than people imagine. No matter how smart the model, it doesn't know what you care about unless you tell it over and over again. So he designed a skill called Grill Me—having the agent turn the tables and "ruthlessly interview" the user, interrogating requirements, boundaries, and implicit preferences out into the open.

He quotes a line from The Pragmatic Programmer: no one knows exactly what they want. The so-called "unknown unknowns"—security, deployment methods, details you never even thought of—if not actively surfaced, the agent will make them up on its own, ultimately producing something completely different from what you envisioned.

Observing his own students, he found that the top performers are without exception excellent communicators: they write clear, detailed descriptions when submitting code changes, and the clarity of their thinking shows directly in the product. Conversely, those with poor output often aren't lacking in technical skill—they simply can't explain the problem clearly to the agent, nor describe where things went wrong. In his words, the quality of thinking and the quality of language are key—not only when talking to clients, but also when relaying client requirements to the agent.

He also introduces the concept of "ubiquitous language" from domain-driven design (DDD): the terms in the code, the fields in the database, the copy in the interface, and the words you use when talking with clients should all be the same set. He even built a Grill with Docs skill for this purpose, helping users gradually establish this domain language during development.

"Ubiquitous Language" in domain-driven design (DDD) is a core practice proposed by Eric Evans in the book Domain-Driven Design. Its key point: the development team and domain experts (the business side) must jointly build a rigorous, unambiguous terminology system and ensure this language stays consistent across code, databases, interfaces, documentation, and daily communication. For example, in an e-commerce system, "order" should not be called Order in code, purchase_record in the database, and "shopping list" in the interface—such inconsistency leads to misunderstandings and implementation errors. In AI-assisted development, the significance of ubiquitous language is amplified: agents have no implicit domain knowledge and rely entirely on the vocabulary and context you provide to understand requirements. If you use the same precise terminology in prompts, code naming, and documentation, the agent can infer intent more accurately; conversely, muddled terminology lets the agent "make up" meanings, producing output that deviates from expectations. Matt's Grill with Docs skill is precisely for gradually solidifying this language through dialogue, giving the agent a consistent frame of reference in subsequent tasks.

A Failed Experiment: Why Spec-Driven Development Didn't Work

In the interview, Matt rarely shares a frustrating experience. Influenced by the popular notion that "the spec is the new code," he once tried to organize his most cherished project—a custom video editor with AI-generated copy, cover design, and other features—into a massive specification document, then have an agent generate code from it.

The results were unsatisfactory for months on end: the more the code was changed, the worse it got, and the agent's output got worse too. He eventually abandoned the spec, turned his attention back to the code itself, because he realized that code is the environment the agent actually runs in, and the definition of "good code" is—easy to modify, and changing one place doesn't break another. Only after pivoting to this goal did he feel he was "finally making real progress."

This experience is valuable counter-evidence against today's popular spec-driven development frameworks: specification documents are no panacea; a maintainable code environment is the foundation.

Spec-Driven Development is a methodology that has emerged alongside AI programming in recent years. It advocates first writing detailed, formal specification documents (describing features, interfaces, data flows, boundary conditions, etc.), then having agents generate code based on the specs. Its appeal lies in separating "intent" from "implementation," theoretically allowing non-technical people to drive development through specs. However, Matt's failed experiment reveals the method's limitations: spec documents easily become bloated and hard to maintain, and cannot fully capture the implicit constraints in a codebase (such as performance characteristics, module coupling, third-party dependency behavior). More importantly, there is a "semantic gap" between specs and code—the agent must still make many interpretations and assumptions when generating code, and these assumptions often drift from the original intent of the spec. When the codebase itself is low quality, no amount of detail in the spec can stop the agent from producing bad code in a bad environment. Therefore, spec-driven development is better suited as an auxiliary means (such as clarifying requirements) rather than a replacement for the foundation of a maintainable codebase. Some current frameworks (such as GitHub's Spec Kit) attempt to lower the cost of spec maintenance through tooling, but the core challenges remain.

A Path for Non-Technical People: Learn to Brake First

For people with a full-time job, a non-technical background, and a desire to use AI to change their career trajectory, Matt's advice is to first figure out which skills will be useful in the future, and the path will emerge on its own. He believes there is a severely underestimated learning curve for agents—stronger models don't eliminate this curve, they just hide it deeper. Questions to master include: what to trust, how to organize multiple agents, how to control the information they receive, how to turn processes into agent-executable forms.

He cites Lauren Tan's "trust ladder": when learning to drive, you learn the brake first, not the accelerator. At the start you should watch the agent's every move, understand each action and each capability the toolchain offers, then gradually expand to two agents, writing custom skills, connecting data sources like Slack and Gmail. He himself has an agent for handling to-dos: dictate to the watch, the system receives it, and the agent triages and categorizes.

He also offers a view contrary to the mainstream narrative: don't have the model do your grandest tasks—give it the most boring, trivial work: drafting replies, handling chores. The reason is that such tasks are easy to measure for output quality and easy to correct if wrong, and that's exactly where AI can most reliably create value today.

The "Trust Ladder" is a progressive adoption framework proposed by Lauren Tan, describing how humans gradually hand control to automated systems. Its core idea: trust can't be achieved in one step; it must accumulate through small, verifiable steps. Typical rungs include: (1) Observe—fully manual operation, understanding each system action; (2) Assist—system suggests, human decides; (3) Supervise—system executes, human spot-checks; (4) Delegate—system executes autonomously, human handles only exceptions; (5) Full autonomy—system is responsible end to end, human sets goals. In the AI agent context, this means users should start by "watching every step of the agent," then gradually expand to multi-agent collaboration, custom skills, and external data source integration. Each rung requires establishing corresponding checkpoints and rollback mechanisms (such as version control, test suites) to ensure errors can be found and corrected. Matt's emphasis on "learning the brake first" is exactly this principle: speed without a safety net is dangerous, and the trust ladder provides a structured path.

Practical Advice: Environment Over Model Choice

When asked about his favorite toolchain, Matt's answer is surprisingly "low-key": he uses Claude Code with a certain Opus version, and deliberately uses a lower reasoning effort than most people, because after he has already "raised the floor" of the agent's operating environment, the model doesn't need to work as hard to write code that passes tests, and lower effort brings better token efficiency and response speed.

He'd rather invest energy in environment building. For example, his video editor relies on locally running third-party components like OBS, and previously the agent couldn't actually launch and click-test the app. After he solved this problem and let the agent take screenshots and actually run the app, output quality improved dramatically—he believes the effect would be similar even with an older model.

The lesson for ordinary developers: rather than chasing every model release and benchmark leaderboard, first fill in the infrastructure of tests, runnability, and observability. Models and toolchains matter, but the highest-ROI investment is usually on the environment side.

Next Steps: Software Factories and Long-Termist Agents

Matt calls himself "a teacher, not a prophet," and he declines most product preview invitations because he only cares about "whether it works now." As for the future, what excites him most is the "software factory"—an automated system that can initiate work autonomously and continuously improve the codebase.

He believes a major shortcoming of current agents is that they're not good at thinking about the codebase from a long-term perspective. What he wants is the kind of senior developer who is "annoying but right": insisting on doing the right thing rather than the fast thing, considering those who come later. How to organize large numbers of agents to work together still has no convincing solution, which in his eyes is the biggest gap and opportunity. He also looks forward to open-source models catching up with top closed-source models, because "I don't need a model that's absurdly strong—an open model that's good enough and efficient would be great."

All these judgments ultimately circle back to the same plain conclusion: in an era where everyone can build things quickly, those who stand out are the best communicators, those who best know how to create an environment for agents, and those willing to start from boring tasks and build trust step by step.

One-line Summary

In the AI programming era, core competitiveness shifts from writing code to creating a maintainable environment for agents and communicating intent clearly.

Paragraph Summary

Based on an interview with developer Matt, this article explores the core competitiveness of programmers in the era of AI programming (vibe coding). Matt argues that when agents can generate code quickly, what's scarce is no longer the speed of writing code, but the ability to clearly convey intent to agents and build a good operating environment for them. He proposes that "the codebase is the agent's working environment," and garbage codebases only produce garbage results, so software engineering fundamentals (testing, maintainability) matter more than ever. Communication is the real moat, and there's a huge communication barrier between humans and agents that requires actively surfacing "unknown unknowns." He shares a failed experiment in spec-driven development, emphasizing that maintainable code is the foundation. For non-technical people, he recommends following the "trust ladder," starting with boring, easily verifiable tasks to build trust. Finally, he argues that investing in environment building (tests, runnability) has a higher ROI than chasing the latest models.