What Engineers Should Design After AI Makes Coding Faster

Using Claude Code and Codex, the speed at which I write code has increased considerably. Creating new components, adding tests, reading existing code and proposing fixes—tasks that used to take tens of minutes now often reach a first draft in just a few minutes.

But the more I use them, the more a different problem becomes visible. Even if code is written faster, what to build, how far to go, who should verify it, and how to operate it afterward are not decided automatically. In fact, as implementation speeds up, ambiguous decisions solidify into code and come back as rework later.

Honestly, at first I thought that increasing the number of tasks I could delegate to AI would speed up development overall. But in reality, the more I delegate to AI, the more the human side has to design. The engineer’s job is not disappearing; it is expanding toward designing conditions under which AI can act without hesitation.

It Is Not Just Implementation That Has Gotten Faster

The most obvious change in AI-driven development is implementation speed.

For example, creating a screen from requirements, fixing an API client to match existing type definitions, or reading an error and generating a fix—these tasks work well with AI. The relationship between input and output is relatively clear, and there are concrete materials like existing code and error logs.

On the other hand, AI is not just speeding up the act of writing code. Creating design notes from Jira descriptions, breaking down design notes into implementation tasks, extracting review points from diffs, and identifying gaps in test coverage—these “information transformation” tasks are also being heavily delegated to AI.

This is convenient up to a point. The problem is that if the premises for these transformations remain ambiguous, AI will produce outputs while still carrying that ambiguity. AI will supplement missing information with guesses, but those guesses are not necessarily correct in a business context.

Deciding What to Build Does Not Get Faster

Tasks that are easy for AI are those where the correspondence between input and output is visible.

Writing code that matches existing implementation patterns, generating candidate causes from errors, converting specifications into checklists—these tasks are quite stable if enough context is provided.

However, deciding what should be built is different.

Which customer problem should be prioritized? Will adding this feature increase the burden on operations staff? Should it be included in the current release or deferred to the next phase? If it fails, who will notice and who can roll it back? These decisions involve not just the codebase but also business priorities, on-site constraints, operational structure, and user expectations.

AI can organize discussion points. It can present options. It can list risks based on past patterns. But ultimately, which constraints to weight heavily must be decided by humans.

If you leave this boundary vague and delegate to AI, you can quickly produce “something that works.” But whether that working thing actually solves the problem is a separate issue.

What Engineers Design Expands From Code to Context

As AI makes it faster to write code, what engineers design expands from the code itself to the outside of the code.

Specifically, these things:

• Which problem to solve
• Which constraints to respect
• How much to delegate to AI
• Which output counts as passing
• What to look at to diagnose failures
• Who will operate it after it is built

These have always been important. But before implementation speed increased, the implementation work itself took enough time that ambiguity often surfaced midway. The implementer had room to notice things like “this spec seems unworkable for operations” or “who will check this branch?” while working.

With AI, code appears before these realizations. While convenient, this makes it easier for design gaps to hide behind implementation speed.

That is precisely why engineers must articulate the problem, constraints, and verification points before asking AI. This is not simply prompt engineering. It is the work of redesigning development context into a form that AI can work with.

Tasks to Delegate to AI and Tasks Requiring Human Judgment

Personally, I find it useful to think of delegable tasks in three categories.

The first is conversion at the same granularity. Tasks like turning Jira content into design notes, design notes into task lists, or diffs into review points. When the correspondence between input and output is relatively clear, this is an area where delegation to AI is easy.

The second is organizing from concrete to abstract. Tasks like generating candidate causes from error logs, extracting common problems from multiple review comments, or creating evaluation criteria from failed outputs. These can be used to assist in catching patterns that humans tend to miss.

The third is expanding from abstract to concrete. Tasks like deciding new initiatives, finalizing specifications from requirements, or setting priorities. Here too, AI is useful as a sparring partner, but handing over the decision entirely is risky. AI does not necessarily know business constraints or organizational circumstances that are not in the input.

Having this classification makes it easier to think not in terms of “whether to delegate to AI,” but “which parts to have AI transform and which parts for humans to judge.”

A Good Request Is Not a Detailed One, but a Verifiable One

When writing a request to AI, it is tempting to think that more detail is better. Specificity is certainly important. But even a detailed request is useless if the success criteria are ambiguous, because you cannot judge whether the output is good or bad.

For example, if you say “build an easy-to-use admin panel,” AI can produce a plausible UI. But it does not know what makes it easy to use. Whether that means search filters can be saved, anomalies are visible in a list, or non-engineers can operate it without confusion changes the design entirely.

What you should give AI is not just what to build, but verifiable conditions.

Objective:
  Inquiry support staff should be able to review past correspondence while checking the next reply draft.

Constraints:
  Do not unnecessarily expose personal information on the screen.
  Reply drafts must not be sent automatically; a human must always review them.

Pass criteria:
  Staff can distinguish between pending, in-progress, and completed items in a list.
  AI reply drafts include references to the historical basis for the draft.
  A human confirmation step is always required before sending.

With this kind of input, AI can work not just by building a screen, but by keeping in mind which constraints to respect and where to leave room for human judgment.

The Faster AI Gets, the More Important Review Becomes

As AI speeds up implementation, it may seem like reviews can be lighter. But the opposite is true. Because things can be built quickly, reviews must look not just at code details but at the validity of the premises.

What I want to see when reviewing AI-generated code is not just whether there are bugs.

• Are the requirements correctly understood in the first place?
• Is the AI filling in missing specs on its own?
• Is failure-time behavior designed?
• Are there logs that operations staff can check?
• Are the boundaries designed to be easy to change in the future?

These perspectives are also close to llmops. In LLM applications, even if outputs look plausible, they cannot be operated without visibility into evidence, evaluation, traces, cost, and recovery from failure. AI-driven development is the same: working code and a trustworthy development process are not the same thing.

Summary

As AI speeds up code writing, the value of engineers shifts from “writing fast” to “defining what to build, under what conditions, and in a verifiable form.”

This is not a story about coding jobs disappearing. Rather, because AI can now write code, the importance of properly designing the problems, constraints, operations, and evaluation that lie outside the code is increasing.

Personally, I believe the essence of AI-driven development is not liberating engineers from code generation, but making the premises of problem solving clearer. The number of tasks that can be delegated to AI will increase. But what counts as success, which risks are unacceptable, and who will operate it must continue to be designed by humans.

The work that remains after coding speed increases is more mundane than you might expect. But it is this mundane design that determines development quality in the age of AI.