AI coding tools should reach beyond the editor — mineti.dev<br>AI coding tools should reach beyond the editor<br>seed · Jun 30, 2026

TL;DR<br>AI-assisted coding has changed how we write code — but writing code is only one of three pillars of development work, alongside project management and infrastructure . Today's assistants accelerate the middle pillar and stop at the editor's edge. The real leverage is an assistant that works across the whole cycle — planning, building, and running — closing the loop instead of speeding up one third of it.

What AI-assisted coding is

In traditional development, a developer translates intent into code by hand: you<br>hold the goal in your head and type out the implementation. AI-assisted coding<br>inserts a new layer into that path — you describe what you want in natural<br>language, a tool turns that description into code, and you review and refine what<br>comes back. Its loosest form has picked up the name “vibe coding,”1 but the<br>mechanism underneath is the same: natural language becomes a primary interface to<br>the codebase, mediated by a tool.

Traditional development connects the developer to the code directly. AI-assisted development inserts an AI assistant, driven by natural language, with the developer reviewing what it produces.

It’s a small change in the picture with a large change in practice. And, almost<br>without exception, it is drawn inside the editor.

Development is more than coding

That picture quietly assumes the interesting work is writing code. Step back and<br>look at what building software actually involves, and coding turns out to be one<br>station on a larger loop.

Most development work circulates through three pillars:

Project management — where work is planned, discussed, and documented: the<br>roadmap, the features, the bugs. This is where intent is captured before any<br>code exists.

Coding — where that intent is implemented in the development environment.

Infrastructure — where the code is shipped to production, run, and observed.

These aren’t a straight line; they’re a cycle. You plan and document a change on<br>a project-management tool, move to the development environment to implement it,<br>and push it to production — and what you learn there, a bug or a metric or a<br>complaint, flows back into planning as the next piece of work.

The developer at the center of all three pillars, moving through them as one continuous loop — plan the work, build it, ship and observe it, then back to the plan. (No, I did not set out to recreate the Chromium logo. Not intentionally, anyway.)

Each lap around this loop is one unit of real progress. Writing the code is the<br>middle third.

Putting the assistant in the loop

Now place the AI assistant on that map. Today it lives almost entirely in the<br>coding pillar — inside the editor, helping write the next function. It is good at<br>that, and the point here is not to evict it. The point is that confining it to<br>one pillar leaves it blind to the other two, and therefore blind to whether its<br>own work mattered.

AI-assisted coding already made natural language the interface to the codebase.2<br>Widen that same move to the whole loop and the assistant becomes the interface to<br>development itself: you express intent once, and it carries that intent across<br>all three pillars — opening the ticket, writing the code, shipping it, and reading<br>back what production says. The developer still decides; the assistant becomes the<br>layer they work through to reach the entire cycle, not a code generator confined<br>to one station.

The same picture, with the AI assistant inserted as a layer around the developer — the interface through which work reaches all three pillars, rather than a tool confined to coding.

Coding

This is the pillar the assistant already occupies — directly in the development<br>environment, whether through a command-line harness in the terminal or built into<br>an editor like VS Code — and it is worth saying plainly that it works. Generating<br>functions, refactoring, explaining unfamiliar code, writing tests — the assistant<br>inside the editor has earned its place. The argument isn’t to leave the coding<br>pillar. It’s to stop mistaking it for the whole job.

Project management

Code rarely exists for its own sake; it exists to satisfy something a human<br>described in a project-management tool like Jira, Asana, or Trello — a ticket, an<br>issue, a roadmap item. An assistant that can read and<br>write the project-management layer can connect the change to its intent: pull the<br>acceptance criteria from the ticket, draft the plan before touching code, update<br>status as work progresses, and file the bug it just discovered instead of leaving<br>it for someone to notice. The plan and the code stop drifting apart because the<br>same participant is keeping both honest. The connection runs through the tools the<br>team already uses: most expose a command-line interface, and a growing number ship<br>a Model Context Protocol (MCP) server3 — an open standard for letting an<br>assistant read and write an...