What changes when you stop opening the code editor?

You can ask a coding agent to change an application without opening a code editor.

The agent reads files, writes code, and runs commands. You can direct the work from a chat or terminal and inspect the result elsewhere.

I don’t think the interesting question is whether that counts as programming. I want to know where the checks I used to do in the editor will happen now.

The editor bundled several jobs

A code editor lets you change text. It also helps you find callers, compare changes, read errors, and move between related pieces of the application.

If an agent takes over the typing, the other jobs still need attention.

Suppose you ask it to add an archive button. The button appears, the request succeeds, and the test suite passes. You still need to check whether archived records disappear from the ordinary list, remain reachable where they should, and can be restored.

You can do some of that in the application. You may need to read the code to understand what happens to existing records or how the new filter affects another page.

The editor is one convenient place to do that reading. A diff viewer or terminal can work too. The choice of interface doesn’t settle how much understanding the change requires.

In the drawing, writing the patch is one step. Reviewing it and using the changed flow remain separate steps even when the agent finishes the implementation.

A green check answers a specific question

CI runs the checks someone configured.

If the tests cover the archive request but never open the archive page, a green run tells you little about that page. If the browser test checks that a button exists, it doesn’t establish that restoring a record preserves its content.

I would read what the checks cover before relying on them. For a familiar, small change, that can be quick. For a change to shared behavior, I would follow the affected callers and check the connected flows.

The agent’s summary can help me find those places. I wouldn’t let the summary replace inspecting them.

This also gives us a way to improve the workflow after finding a bug. Ask which missing check would have caught it, then decide whether that check belongs in an automated test or the review procedure.

Being able to recover still matters

Imagine the agent changes the wrong files.

You need to see the difference and decide which parts to keep. If the change has already been deployed, you need to identify the revision and understand the available rollback.

Those are practical reasons to learn Git even if you rarely type code yourself. Knowing what is staged, committed, or only present on your machine lets you ask for a precise recovery instead of asking the agent to “undo whatever you did.”

The same applies to debugging. Describing the action that failed, reading an error, and tracing where the unexpected value came from help you direct the next investigation.

Choose the interface that helps you finish

I would happily let an agent perform a mechanical edit while I inspect the result in a diff viewer. For an unfamiliar section of code, opening the editor may be the quickest way to understand the connected files.

There is no useful prize for avoiding it.

If you want to try working from chat alone, choose a small reversible change. Read the diff, use the changed flow, and make sure you could explain how to undo it. When one of those steps becomes difficult, open whichever tool makes it easier. The goal is to finish with an application you understand well enough to maintain.

Want me to talk about your product? You can sponsor this site.