Coding is solved? Probably not only coding

“Coding is solved!” is one of the ideas you hear a lot these past months.

This statement became possible because the quality of code produced by agents is already often good enough for a short, classic engineering cycle: a couple of comments in a PR, a couple of review iterations, fixes, and a merge.

What’s next?

It seems that in 26/27 we will see more changes in the Delivery part of the SDLC. We will learn to automate a larger part of the work, and the role of specialists will increasingly shift toward setting direction and validating results.

I’m working on a tool, and I’m using that same tool to build it. This tool brings AI deeper into the SDLC process.

Without too much polish, the process currently looks roughly like this:

  • I create a task on the board and describe the requirements almost like voice input. Then I move it to In Analysis.
  • The analyst agent turns it into a properly structured task and moves it to the Tech Design stage.
  • The architect agent analyzes the task and, if the task is complex enough, prepares a document describing how it will be implemented, attaches it to the task, and moves it to Review Result.
  • I read the document, leave comments, point out what needs to be fixed, and after one or two iterations move the task to In Development.
  • The developer agent gets the requirements, tech design, comments, attached documents, and reports, and then starts implementation: writes code, tests, creates a PR, and moves the task to Deploy to Staging.
  • The Deploy Manager agent waits for quality checks in CI to finish — including tests and linters — and, if they pass, deploys the branch to staging. If the checks fail or deployment fails, it leaves comments on the task describing the problem and moves it back to In Development.
  • Then the QA agent takes over. It analyzes the requirements and the tech design, builds a test plan, verifies that it covers all expected behavior, then opens the browser and executes the test plan in the staging environment. Based on the results, it adds a report to the task and either moves it to Review Result or sends the task back into the loop, where the developer agent gets the QA report and the cycle repeats.
  • After that I open the PR, do the review, look at what was tested and how, and check the artifacts. Then I either write comments and send the task back to In Development, or, if it’s done, move it to Release.
  • The Release Manager agent makes sure all tests have passed, all comments in the PR are closed, QA has passed, and closes the PR, after which the changes are rolled out to production.

Throughout the process, the agents write reports in the task, attach artifacts, report the problems they ran into, and document what exactly was done.

At the same time, there are between 3 and 8 tasks in the pipeline, not counting what I still do “the old way” in the IDE with an agent.

In real SDLCs, processes may be structured in more complex ways. But the core point is already quite visible: more and more stages are being handed over to agents, while the human role is gradually shifting toward result validation and process control.

The main value of a specialist will no longer be only in producing results manually, but also in evaluating what exactly the agent did, giving feedback, controlling, and correcting the process.

This applies not only to development. The same shift is gradually affecting UI design, testing, analytics, and other roles.

Here are a few observations I’d like to share:

Context switching

Working on one task all day will become less and less typical. More likely, you will have to run 3–5 tasks in parallel and keep switching between them. While an agent is working on one part of the pipeline, a person is validating already completed work on another task: reviewing a PR, checking artifacts, reading reports, giving feedback, and putting the task back into the loop. So the important skill is no longer just the ability to hold context, but the ability to enter it quickly, leave it, and return to it again without major losses.

Broader skill set

If previously analysis, design, backend, frontend, infrastructure, security, testing, etc. were more clearly separated by roles and stages, now those boundaries are starting to blur.

An agent can move through several of these areas within the same task, which means result validation increasingly requires looking at the work from several angles at once. Not because one person is required to replace everyone else, but because the transitions between disciplines themselves are becoming shorter and cheaper.

This leads to a practical change in what is required from a person: broader expertise becomes more valuable. It has become easier to move through adjacent areas, and if a significant part of that validation can be closed within one person, that greatly reduces the cost of synchronization and context transfer.

Productivity

The productivity gap will grow between those who can hold broad context and validate results at the intersection of several disciplines, and those whose role remains narrower.

When agents perform a significant part of the SDLC, a larger and larger share of time is spent not on producing the result itself, but on validation, decision-making, synchronization, and context transfer. A specialist with a broader profile can validate results across several areas independently without constantly handing the task over to other people.

Because of this, their handoff and coordination overhead goes down, and in the new model those overheads become even more noticeable than before.

Of course, a scenario is possible in which tools will be able to offset this, and we will build a more efficient process for transferring work on a task between people. But so far, we have not been very good at that.

Lead Time is shrinking

The biggest change is not only the absolute delivery speed, but also the difference in time between tasks of different complexity.

Where the difference between a simple and a more complex task used to be hours vs weeks, now the first decent result for both increasingly appears within hours.

In other words, delivery lead time is not just getting shorter — in some sense it is collapsing. The difference in task complexity shows up less and less in the time to first result. Now both “fix a line” and “build a new feature” can produce a first working outcome very quickly.

Your role

We talk a lot about how AI is changing coding. But coding is only the first obvious part of the change.

AI is gradually taking over almost the entire Delivery part of the SDLC — from requirements analysis and UI design to testing, release, and process documentation — leaving humans with control points.

Humans are less and less the ones manually producing every piece of output, and more and more the ones who set direction and validate the result.


To view or add a comment, sign in

Others also viewed

Explore content categories