Coding Assistants Are Moving Beyond the Next Line

The familiar picture of an AI coding assistant is a faint suggestion waiting at the cursor. A few characters become a line; a line becomes a small function. The person at the keyboard is still choosing the immediate direction. What has become interesting is how many other kinds of interaction now sit beside that original picture.

A reader can ask about unfamiliar code, discuss a possible change or delegate a bounded task to an agent that inspects files and uses tools. These experiences can share an interface while distributing the work quite differently. I find the changes easier to understand by asking what kind of decision the person is handing over at each stage.

I have been reading about those differences through an invented date-formatting problem. Product names, interfaces and availability move quickly. The more durable question is how the interaction changes the user's effort, understanding and responsibility for the result.

A suggestion at the cursor

The VS Code inline suggestions documentation describes code suggestions presented while a person edits, including suggestions for further changes. The attraction is close to the immediate activity: the tool can help express something without requiring the person to leave the code and compose a separate request for every small step.

Imagine a made-up utility that displays dates in a reading list. Its inputs are already valid dates, and the requested change is simply to display the month name. The person understands the relevant function and is choosing the local change. A suggestion near the cursor may be all the assistance needed. The smallness of the interaction is part of its convenience.

A suggestion still has assumptions. It might use a locale, a time zone or a formatting function that doesn't match the intended behaviour. Those are manageable questions when the change remains close enough to inspect. The person can accept a useful fragment, modify another part and keep the reasoning attached to the place being edited.

I like the idea of assistance that doesn't insist on taking over a whole task. Sometimes the difficult work is choosing the behaviour, and the remaining syntax is an interruption. A good suggestion can remove that interruption. It doesn't need a theatrical planning phase or a diagram announcing that the future has arrived at the semicolon.

The limitation becomes clearer when the reader doesn't yet know which behaviour is needed. If an input such as 03/04 is ambiguous, completing a formatting function won't decide whether it refers to March or April. The request has moved from expressing a known local choice to understanding a requirement. A different interaction may be more useful there.

A conversation about the code

Suppose the reader opens the invented utility and notices two date parsers. One handles imported records; another serves a preview. Before changing anything, they want to understand why both exist. A conversational interaction can help map the relevant functions, explain possible relationships and identify where the evidence for those relationships should be found.

The useful output here might be a question rather than a patch. Do the two entry points accept the same input format? Is the preview expected to match the import exactly? Does an older record depend on the existing convention? Reasoning about those possibilities can be valuable even when the person prefers to write the eventual change themselves.

I would ask an explanation to distinguish the code it actually inspected from a plausible general account. “This function calls that parser” is something a reader can verify at a location. “The system was designed this way for compatibility” may be an inference unless a comment, test or document supports it. Both can belong in the conversation if their status stays clear.

This can be especially helpful when learning an unfamiliar library or reading a repository for the first time. The assistant offers another way to approach the material, and the person can ask for a smaller example or a different level of detail. There is intellectual value in a tool that can vary the explanation before the reader has acquired all the terminology.

Yet a fluent explanation can also make understanding feel complete sooner than it is. I would still want to follow a representative input through the functions and see whether I can predict the output. If I cannot explain what happens to the ambiguous date, the conversational summary has given me a starting point rather than finished the learning on my behalf.

Handing over a bounded task

GitHub's overview of Copilot agents describes systems that can plan, use tools, inspect results and adjust their approach. Depending on the experience, that can include repository search, changes and checks. The meaningful shift is from proposing text to working through a sequence with access to an environment.

For the imagined date utility, a bounded task could be to make the preview use the same documented format as the importer, while preserving supported legacy inputs. The agent may need to locate both entry points, inspect existing tests and propose a coherent change. That is more than completing a local expression, because the relevant work spans several places.

The task still needs a statement of the intended behaviour. If the importer and preview currently disagree, “make them consistent” leaves open which one should change. The agent could make the code beautifully consistent in the wrong direction. Naming a reference example gives the investigation a purpose that survives the first promising patch.

I find it useful to imagine what a reviewable result would contain before discussing how independently the agent can operate. In this example, the result would include a visible change, the reason it follows the requirement and evidence about representative inputs. A summary should also identify any ambiguous cases left unresolved. Activity becomes easier to judge when the desired result has a shape.

The appeal is real. Searching for related code and handling the small mechanical steps can consume attention without being the part a person most wants to think about. An agent can potentially absorb some of that work. The benefit becomes clearer when the remaining human review is focused and comprehensible, rather than a second investigation of an unexplained large patch.

The useful unit of delegation is a task whose result I can still understand.

Context and instructions do different jobs

The VS Code custom instructions guide describes ways to provide guidance for AI interactions, including instructions associated with a project. Such guidance can preserve conventions or recurring constraints. It is useful to distinguish that guidance from the specific evidence needed to answer the current coding question.

In the invented utility, a convention might say that displayed dates use a particular locale and that date-only records should not acquire an unintended time shift. The immediate task might supply the failing example and the relevant input specification. One gives a recurring rule; the other describes what is being investigated now. Both matter without being interchangeable.

I would prefer instructions that state decisions clearly over a page of enthusiastic adjectives. “Use the existing date formatter” gives a direction that can be inspected. “Write exceptionally clean and robust code” expresses a pleasant wish. It leaves most of the difficult choices exactly where they were, except that the future explanation may now contain more reassuring words.

Instructions can become stale. An old rule may refer to a library that has been replaced or a command that no longer exists. That possibility is a reason to keep guidance understandable and connected to the repository's current state. A document doesn't acquire permanent authority about technical facts merely because it is loaded at the beginning of a session.

There is a related question about what the assistant sees. A relevant function, an error and a small example may be more useful than a huge collection of loosely related files. The right amount depends on the problem. I am interested in tools that help the reader inspect that working context, because omitted or misleading context can change a result before the first line is written.

What the person reviews

VS Code's review and revert documentation describes ways to inspect and manage agent changes. GitHub's application card for agents also discusses limitations and the role of review. I read those as parts of the product's behaviour, alongside its ability to produce a change in the first place.

For the hypothetical date task, the review begins with meaning. Did the patch choose the intended interpretation? Is the shared formatter actually appropriate for both entry points? A change can be concise, well named and consistent with local style while still applying the wrong calendar convention. Those questions are easier when the task's examples remain visible.

Then comes scope. Did the agent alter only what the task required? A broad refactor may be justified, but it should have an explanation tied to the problem. I would want unrelated formatting or dependency changes separated where possible, because each extra difference consumes review attention. The aim is to make the proposed behaviour understandable without making the reviewer reconstruct the whole repository.

Checks provide evidence with limits. A test showing that one supported date format survives is useful; it doesn't describe all possible imports. A failed command because a dependency was unavailable is different from a completed failing test. The result should preserve what actually ran, so the person reviewing it knows what has and hasn't been established.

The possibility of undoing a file edit also has a boundary. Reverting a diff doesn't necessarily reverse an action taken through another service or a command that changed an external system. In a learning example, I would keep the task narrow enough that a trial can be inspected before consequential action. The interface should help the reader understand what stage the work has reached.

A wider range of help

What interests me about the current direction is the variety of useful handoffs. A person can remain close to a local edit, ask for an explanation or delegate a multi-step task. These are different ways of working, and the most elaborate one needn't be the best choice every time. A small request deserves the option of a small interaction.

For someone learning, the conversational middle may be especially valuable. It gives room to ask why a change works and to compare alternatives. Delegation can also teach, if the proposed result stays small and legible enough to examine. It becomes less helpful for learning when the person receives a large answer they can neither explain nor confidently reject.

I would assess the experience partly by the work left at the end. How much context must be recovered? How much of the diff is relevant? Can the reader understand the test evidence? Time saved typing is one benefit, but time spent finding the meaning of an unexplained change belongs in the same account. Neither side of that calculation needs an invented productivity percentage.

There is also pleasure in making an unfamiliar codebase less forbidding. A good explanation can give a reader somewhere to begin; a bounded change can make a small improvement easier to explore. These are practical gains, even if no one declares that programming has become obsolete before lunch. The interesting future seems likely to contain quite a lot of reading.

I keep returning to the date example because it is so ordinary. A helpful assistant should make it easier to understand the ambiguity, choose the intended behaviour and inspect the resulting change. Whether the interaction began with a ghosted suggestion or a delegated task matters less than whether the person can still tell what the software now means. That feels like a useful direction for coding assistance to grow.

— John