Six months ago our engineers worked in IDEs. Today most of them work in terminals with agentic coding tools running long-horizon tasks. Here's what changed, what stayed and what we got wrong on the way.
In late 2025 our engineering workflow looked the way it had for a decade: IDE on one screen, terminal on the other, a steady cadence of small edits with frequent context switches between code, docs and tickets.
Then the CLI-based agentic coding tools matured enough to take on multi-file, multi-hour tasks. Within four months the workflow had inverted. Most of our engineers now drive their day from the terminal, delegating substantial chunks of work to an agent and reviewing the result. The IDE is still there. It's used less.
This isn't a "AI replaces developers" piece. The work didn't go away. The shape of it changed and some of the changes were not the ones we expected.
The obvious change: longer-running tasks became viable to delegate.
A typical request used to be "complete this function" - something a developer could verify in five seconds. Now it's "implement the new validation pipeline against the spec in this RFC, write the tests and update the docs" - a multi-hour task spanning ten or twelve files. The developer reviews the agent's plan, lets it run, then reviews the result.
This shifted the ratio of writing-to-reviewing dramatically. Senior engineers used to spend perhaps a third of their day reviewing other people's code. Now they spend more than half of it reviewing - some human, some agent. Reviewing has become the bottleneck and the skills that matter most are reading code quickly and spotting subtle correctness issues.
Three things broke in the first month.
1. Tasks were sized for human pace, not agent pace. A ticket that would have taken a developer two days could be done in two hours by an agent. But the surrounding workflow - QA, design review, deployment slots - was still on the two-day rhythm. PRs piled up behind processes that hadn't been resized.
2. Context switching multiplied. Running three parallel agents on three independent tasks sounds efficient. In practice, switching attention between three reviews was more cognitively expensive than focusing on one. We over-parallelised early and slowed down.
3. Our test infrastructure became the rate limit. Agents generate code fast. CI takes the same time as before. When an agent ships ten PRs in an afternoon, each waiting twenty minutes for CI, the developer ends up babysitting a queue. We had to invest seriously in CI speed.
After six months, the workflow that stuck looks like this.
Plan in plan-mode, execute in agent-mode, review in IDE. The agent's plan is reviewed and edited before any code is written. Once approved, the agent runs. The output is reviewed in the IDE because IDE tooling for diff-reading, jump-to-definition and inline annotations is still better than anything CLI-native.
One agent at a time, mostly. A developer typically has one long-running agent task plus their own active work. Three concurrent agents was theoretically more output, practically more chaos.
Tests written by humans before code by agents, for anything important. Where the requirement is high-stakes, our developers write tests first - by hand - and then ask the agent to implement against the tests. This flipped the order from "agent writes code and tests, human reviews both" to "human writes tests, agent writes code, human reviews code." The latter has much better failure modes.
# A typical session - test scaffold first, then delegate.
$ vim tests/test_validation_pipeline.py # human writes failing tests
$ agent --plan "implement validation pipeline to satisfy tests/test_validation_pipeline.py"
# review plan, approve, let it run
$ git diff main.. # review what landed
CLI tools for breadth, IDE for depth. Refactors across a hundred files - CLI. Investigating a subtle bug in one file - IDE. Each is better at one thing.
We tried to make agents own entire features end to end. They couldn't. Not because they couldn't write the code, but because feature-ownership requires judgement about scope, trade-offs and what to leave out - and that's where agent reasoning still slips. Pulling back to "human owns the feature, agent implements the steps" was a clear improvement.
We also under-invested in observability for what agents were actually doing. When an agent ran for an hour and produced a confusing result, reconstructing the intermediate steps was painful. Structured logging for agent runs is now a hard requirement.
The shift from IDE to CLI isn't about typing less. It's about the unit of work changing from "an edit" to "a task," and that change ripples outward into how teams plan, review and deploy. Adapt the surrounding workflow - testing, CI, ticket sizing, code review - or the gains stay theoretical.