One of the most provocative lines about coding agents is that writing code was the old job and building loops is the new one. It appears in the video that prompted this post, a conversation with Boris Cherny shared on X.

If the player does not load, the video is still available in the original post on X .

It is worth being careful with that line. It works as a provocation, but poorly as a prophecy. Programming has not become a dispensable skill; it is still the most direct way to understand a machine, review a change, and notice when a solution merely looks convincing. What changed is the center of gravity of the work.

When an agent can explore a repository, change files, and produce a first implementation, the bottleneck is no longer just typing the next line. It becomes deciding what should be done, under which constraints, how to recognize that it is done, and how to change course when the first attempt fails.

In other words: less energy spent manufacturing code text, and more engineering spent turning intent into a reliable result.

AI does not eliminate the work; it moves the bottleneck Link to heading

An agent can produce a great deal of code in a few minutes. That does not mean it knows what the business needs, understands the fiscal exception hidden in a business rule, or knows why an apparently simple screen must work on a customer’s unreliable phone.

That difference matters because software is not a competition in lines produced. It is an attempt to change a system without breaking what already works, within real deadlines, costs, policies, and human expectations.

Anthropic’s research on practical use of coding agents describes an interesting division of labor: people tend to make more planning decisions — what to do, what result to expect, and when to consider it finished — while the agent makes more execution decisions. The same research associates greater domain expertise with more successful sessions. It is not a law of nature, nor a guarantee for every tool, but it is a useful reminder: knowing how to ask questions still matters a great deal.

The 2025 DORA report reaches a compatible conclusion at another level. AI acts as an amplifier: teams with healthy processes extract more value; teams with poor context, fragile validation, and confusing handoffs can make mistakes at admirable speed.

1. Learn to define the problem before asking for a solution Link to heading

A request such as “create a customer registration screen” only looks objective until someone asks the basics:

  • who can create and edit records;
  • which fields are required;
  • what happens with duplicates;
  • which business rule applies before saving;
  • how the operation will be validated;
  • which behavior is acceptable when an integration is unavailable.

Without these answers, AI is not solving a problem. It is filling gaps with assumptions. Sometimes those assumptions are excellent. In production, that is not a particularly reassuring acceptance criterion.

Before opening an agent, it helps to write a small delivery contract:

Element Practical example
Goal Let the customer update their own phone number.
Constraints Do not expose other personal data; keep the current authentication.
Acceptance criterion An invalid number shows a clear message; the change is logged; tests pass.
Out of scope Do not build a complete profile area in this delivery.

This is not bureaucracy meant to impress AI. It is a way for the team to discover that it does not yet know what it is asking for. The agent only makes that discovery faster — and, on some days, more expensive.

2. Learn to provide the context that changes the answer Link to heading

Models understand general patterns. Your system, fortunately or unfortunately, is specific.

The context that changes an implementation is rarely “use Python” or “make it look nice.” It is knowing where the rule lives, which conventions the project follows, which command validates the change, which data is sensitive, and where the agent must not touch.

Files such as AGENTS.md, CLAUDE.md, and equivalent instructions exist precisely to turn scattered knowledge into operational context. They can record test commands, code patterns, risky integrations, branch conventions, and access boundaries. They do not perform miracles: a huge, generic file is noise too. But a short set of specific instructions reduces the amount of guessing.

Context also means choosing what not to provide. Production logs, API keys, customer databases, and .env files are not raw material for a better prompt. The more power a tool receives, the more important the principle of least privilege becomes.

3. Learn to build verification, not just instructions Link to heading

The best prompt in the world is not a proof of correctness.

Anthropic’s guidance for Claude Code puts it simply: give the agent a way to verify its own work. It can be a test suite, a build, a linter, a comparison script, a visual capture, or an independent review. The format changes; the principle does not.

Without executable verification, the agent stops when the solution looks ready. Validation is left to the memory and attention of someone who may be in another meeting, replying “LGTM” between two coffees.

With verification, the flow becomes much more honest:

  1. define the expected behavior;
  2. implement an attempt;
  3. run the test or check;
  4. read the result;
  5. fix and repeat if needed.

That cycle does not make the agent infallible. It simply trades abstract confidence for evidence. That is an excellent trade.

A test is necessary, but it is not the whole system Link to heading

It would also be naive to conclude that “the CI passed” means “it is correct.” Tests can cover the wrong rule, screenshots can miss a poor interaction, and metrics can optimize what is easiest to measure. Verification is a layer, not a metaphysical certificate.

That is why a good definition of done usually combines different signals:

  • automated tests for known behavior;
  • builds, linters, and static analysis for mechanical errors;
  • human review for risk, readability, and product decisions;
  • observability and user feedback for what only appears in real use.

4. Learn to design feedback loops Link to heading

The term loop can sound like another unnecessary loanword, but the idea is old: act, observe, adjust, and repeat.

In the reference video, the conversation emphasizes user feedback and fast corrections. That applies to product work, but also to AI-assisted development. An agent improves when it receives a clear signal that something went wrong; a team improves when that signal does not disappear into an ownerless queue.

A healthy loop has four characteristics:

  • it is short: the error appears close to the change that produced it;
  • it is observable: someone can see the result rather than merely hear that it “worked”;
  • it has an owner: feedback without a destination becomes tool decoration;
  • it changes the next step: recording a problem without changing a process, test, or instruction repeats the problem with more documentation.

In practice, that can mean adding a test case after a bug, recording a recurring rule in the repository instructions file, or creating a CI check. Every small correction reduces the need to remember the same trap in the next conversation with AI.

5. Learn to review what looks convincing Link to heading

AI-generated code has a peculiar quality: it often looks plausible before it is true.

That is the reason to keep technical fundamentals. Anyone who does not understand types, data flow, databases, concurrency, security, or the domain being served lacks the tools to challenge an elegant but wrong answer. Review turns into horoscope reading in a monospaced font.

You do not need to memorize every API to remain relevant. But you do need to preserve the ability to investigate:

  • read a diff and ask what actually changed;
  • follow a request to the database or external service;
  • distinguish a syntax error from a business-rule error;
  • identify data that should not leave the environment;
  • compare the solution with the behavior the user actually needs.

More autonomous tools make that ability more important, not less. Delegating execution does not mean delegating responsibility.

A practical exercise for this week Link to heading

Rather than trying to automate the whole job at once, choose a small, repeatable demand. It could be fixing a validation rule, adding a simple endpoint, or adjusting a screen.

Run the experiment in six steps:

  1. write the problem and three acceptance criteria before opening the agent;
  2. provide only the necessary context and identify repository boundaries;
  3. ask for a short plan before the change;
  4. ask for the implementation and for the existing checks to be run;
  5. review the diff and test the most important user journey;
  6. turn the learning into a test, documentation, or reusable instruction.

The sixth step is what makes the gain survive that session. Without it, you had a good conversation. With it, you began building a better system of work.

The developer remains central — just in a different place Link to heading

There is a lazy version of this story in which code stops mattering and everyone becomes an “orchestrator.” It has the advantage of fitting into a social-media post. It also has the flaw of ignoring almost everything that makes software reliable.

Programming remains important. But as implementation gets cheaper, other skills become more visible: framing problems, understanding the domain, designing constraints, building evidence, handling risk, and listening to the people who use the product.

The best question is not “will AI write my code?” It already writes some of it. The better question is: what system am I building so that this code is useful, verifiable, and safe?

That skill does not fit in a single prompt. And that is exactly why it is worth learning.

References Link to heading