From Command to Intent: Navigating the Interaction Shift in AI-Driven Development

First in a three-part series drawn from our internal study of how engineers work with agentic AI. Seven developers, interviewed over two weeks in August 2026.

We went into this research expecting the interface to be the problem.

The reasoning seemed straightforward. Developers have spent their careers working in environments built around precision. An IDE, debugger, or terminal provides a vocabulary in which an action has a relatively exact meaning: click this, run that command, change this line. Repeat the same operation, and you expect the same result.

Agentic AI replaces much of that interaction with something considerably less exact: a conversation. The shift is not only from keyboard to chat box, but from expressing commands to expressing intent. Our original assumption was that developers would struggle with this conversational modality itself. After all, natural language is approximate, and the same instruction can produce different results.

But in our interviews, no participant described conversation itself as difficult to adopt. The friction turned out to be in the explanation itself. Developers generally know what they are trying to achieve; the harder part is turning that understanding into something an AI agent can work with. Across our interviews, the interaction challenge was less How do I use this chat interface? and more How much of what I know do I need to explain, and what should I leave the agent to figure out?

The new work is steering

When developers write code directly, much of their intent is expressed through implementation. Decisions about structure, logic, and behavior become concrete as the developer writes the code. Working with an agent changes this relationship between the developer and the code because implementation is no longer necessarily where the developer expresses every decision.

Execution can increasingly be handed over, but someone still has to establish what the agent is trying to accomplish. At the upper end of our sample, delegation is close to total and output is reported at roughly five times what it was. However, this does not translate directly into a five-times productivity gain because more developer time is shifted toward reviewing the generated code. An agent can generate ten times the code a person can, while a person cannot review ten times more.

Figure 1 illustrates how developer effort is redistributed, with less human effort spent on code generation and more concentrated on deciding what the agent should do, reviewing its output, and checking whether the result is acceptable. Participants described the resulting fatigue differently, from the volume of code now requiring review, to the sheer number of decisions in a day, to a more compressed schedule.

More time is now spent on making AI behavior more predictable and aligned with what developers ask for, while maintaining human judgment over the code it generates. When we looked more closely at how participants steer their agents, their explanations pointed to two distinct elements: context and instruction.

Context goes up

Context is the background information the agent needs in order to make a sensible decision. It can include a project specification, requirements, architecture decisions, design documents, relevant folders in the repository, or information about how a feature is supposed to behave.

The constraint here is that a model’s attention is limited, even when the context window is large. Chroma’s context rot study found that model performance dropped as input length increased, even when the task itself stayed simple. Earlier work found a similar pattern, where models handled information at the beginning and end of the context better than information in the middle. In other words, having more context does not mean the model pays equal attention to all of it.

Participants dealt with this by directing agents toward specific files, folders, and artifacts instead of giving them everything at once. Some said they used to do this manually in each prompt, but that became less necessary as agents got better at searching the codebase themselves.

Instead, this selection is increasingly moved into project-level instruction or memory files. These files tell the agent what to read first and where to look for relevant information. This is similar to Anthropic’s guidance on context engineering, where some context is provided up front and the rest is retrieved when needed.

However, this does not remove the problem entirely. Project-level instructions also take up context and are loaded into every session. Adding more instructions can therefore leave less attention for the task itself. The decision about what context matters does not disappear. It simply moves from something developers decide in every prompt to something they decide once at the project level.

Instruction goes down

If explaining things to an AI is difficult, the obvious response would seem to be to explain more precisely. Our participants largely did the opposite. The difficulties they described ranged from natural language being a poor fit for tasks involving strict rules or precise computation to a more ordinary human limitation: sometimes you understand a concept perfectly well but cannot find the right words to express it.

Yet participants did not respond by making their prompts dramatically more elaborate. This is where context and instruction begin to pull in opposite directions. Participants supplied substantial grounding material about the problem, but they often deliberately held back detailed directions about how the agent should solve it.

Moving from suggestive guidance to detailed technical prescription appeared to produce diminishing returns. The more developers prescribed the implementation, the less room the model had to propose approaches that might be better than the developer's initial idea. In that sense, greater precision was not always equivalent to better steering. Precision remained important, but participants appeared to apply it selectively.

Our participants are not alone in arriving at this approach. Anthropic’s guidance makes a similar distinction between background information and instructions, and recommends keeping the instruction part somewhere between rigid hardcoded rules and vague guidance. It also warns against putting every possible edge case into a prompt, since a few good examples are often more useful than an exhaustive list. What our participants add is that they reached the same conclusion through experience, by trying more detailed prompts and noticing that the results sometimes got worse.

A developer still needs to be precise about the outcome, the constraints that genuinely matter, and the surrounding context. What appears less useful is being unnecessarily precise about the route the agent must take to get there. The goal is not to remove instruction altogether, but to distinguish between constraints that define a correct solution and implementation choices that the agent may be capable of making for itself.

Point, don't prescribe

Using an assistant to help write code can increase productivity, but the relationship becomes more complicated as models become more capable. The agent may be able to produce an implementation that the developer would not have produced independently, while still lacking a complete understanding of what the developer ultimately needs. The developer therefore cannot simply dictate every step, but neither can they hand over the task without direction.

One way to think about this relationship is to give the agent a space of acceptable choices rather than a single prescribed path. The developer can point the agent toward the problem, provide the relevant context, specify the important constraints, and allow it to search among possible solutions. Instead of describing every implementation decision in advance, the developer establishes the boundaries within which the agent can actively look for a suitable solution.

This changes what effective steering looks like. The developer's role is less about telling the agent exactly how to write the code and more about making the problem legible: identifying what matters, defining what a successful outcome looks like, and intervening when the agent's choices move outside those boundaries.

Overall, our findings suggest that the interaction shift in agentic development is not primarily about learning how to use a conversational interface or becoming better at “prompt engineering.” The more consequential skill is learning how to allocate information: deciding what context the agent needs, what deserves its attention, which constraints must be explicit, and which implementation decisions are better left open.