If you’re a regular reader of this blog, you’ve probably expected the 3rd part of the “I got myself a magic lamp …” series - no worries, it’s coming (in more or less a week). In the meantime, I’ve collected enough interesting thoughts on how agentic coding will transform our daily SDLC to share with the world …
Writing code is not the bottleneck/constraint anymore. It’s no longer the most expensive activity, requiring specific knowledge and scarce skills. Things have turned topsy-turvy: writing code is super-fast, requires limited human interaction (few, but high-impact touchpoints), and scales tremendously well (as long as you have tokens …). But as we all know, thanks to Goldratt, Anderson, Reinertsen, and their alikes, in any workflow, there’s always a bottleneck that constrains the whole delivery pipeline.
At this moment (October 2026), this constraint is agent outcome review and CI/CD throughput - but the rapid progress of Artificial Intelligence may move things a bit again soon. Anyway, what does this bottleneck shift mean IN PRACTICE for our daily work? How will the builders’ everyday work and whole SDLC transform over the next few months? That’s what this article is all about.
On reviews & checks
- The bottleneck has shifted from writing code to reviews/checks, but the idea isn't to do them by hand (since that scales poorly). Doesn’t that mean automated check execution time (/merge time/release gates time/etc.) becomes a primary metric to observe? The one we’ll keep optimizing nearly everything (team composition, feature roadmap, infrastructure, tech stack, …) for?
- If we're not going to review each piece of code manually (at least in the vast majority of cases), what WILL humans review then? I like Addy Osmani's answer - the EVIDENCE of the check(s) executed. Humans will be responsible for:
- creating checks, making sure they are covering what should be covered in a pragmatic & creative, multi-surface way
- making sure that checks are run effectively (what and when necessary) …
- … and that the checks are updated (when the corresponding code is being changed)
- … and finally - that the checks' findings have been properly interpreted and addressed
- It doesn’t mean no one will test manually (usability feedback or visual regression tests will still be very important), but the ratio of time & effort spent on checks vs functionality will shift drastically toward more focus on checks.
On work organization
The former optimum team size (6-8 people) worked well with a typical human code-writing velocity. However, code-generation velocity is much higher now. What's the point of asking more than one developer to work on a single feature? It's not them writing the code; it's the agents, and you can spawn as many as you want (and it makes sense). But now every developer has to understand their work end-to-end: all implications, dependencies, business context, etc. - there’s no split into “thinkers” and “task pushers”.
Even having a few agent flock shepherds working in parallel on different features can be a big problem if they touch the same parts of the codebase. Agents generate code very quickly, which increases the chance of merge conflicts (& resource waste). Teams of 2 may be a sweet spot. 1 is still controversial (at this point), and 3 would be OK only for a really large domain.
Does working 8 hours straight (as a human) make any sense now? Isn't the idea to run the agents in a way that doesn't waste any budget and maximizes value? Won't planning agents to work “for the night ahead” (in a way that avoids interruption) be a new skill in (high) demand? Going further: won't there be any new on-call function for ... handling agents' questions by night?
Oh, and speaking of in-demand skills: knowing “when to say STOP” will be among the most critical ones. Why so? Because LLMs can't do that on their own. They always find/invent something to do, and since we (software engineers) have always had those perfectionist inclinations, it's sometimes hard to say “no” ... Still, it costs not just tokens but also time and CI/CD resources.
On governance
Many organizations asked (still ask?) their people to keep accurate timebooks for internal purposes. But does it still make sense in the agentic era? It's far less important to know how much time a person spends on a feature/task (which is frequently a minority of the task's life) than to make sure that this is quality time spent; YES, sometimes LESS can be much better than MORE.What is more - close governance of a modern builder who:
- works on many things in parallel
- works very asynchronously (with agents)
- has to prepare a lot of materials in advance
- builds not just imperatively (asks agents to perform specific tasks), but declaratively (defines long-living agents to perform certain duties)
… in a traditional way (monitoring their tasks, checking their estimations, setting them deadlines) seems not just unreasonable, but totally unfeasible. There are just TOO MANY conflicting, correlated, low-level metrics to optimize. The days of turning caffeine into code at a steady pace are gone.
That's another reason modern software development won't need extras, bench/second-string players, assistants, or aides. You either hire a real, no-bullshit, motivated, highly engaged builder, trust them, and hold them accountable for tangible outcomes, or this whole thing is pointless. The bygone-era software developers may have been cogs in the machine, but the now-era builders are high-impact, dense-value creators.
So, if they are, we should probably reflect a little on outsourcing, body-leasing & other similar models: bringing in mercenaries that you compensate for time & materials spent. IMHO this model is effectively dead right now, with few notable exceptions (e.g., very narrow & niche domain skills/experience). The outsourcing model puts all the risk on the client/purchaser, while the outsourced resource does what they're told - but isn’t that exactly what agents are for right now? How is involving a human subcontractor better in that case?
On running software
Let's not forget that a software developer's career was never just about writing code; running it was always far more important. So how does the bottleneck shift affect how we'll run software from now on?
- Gen AI-maintained knowledge bases will get better & better, so preserving knowledge will be easier, and the bus driver factor of a smaller team shouldn't be as big a problem anymore.
- Of course, a single developer CAN'T be on-duty 24/7/365, but is it a problem? I strongly believe we'll be joining tiny "teams" into larger "rotation pools" (for the sake of on-call support), because with Gen AI help, a specialist in X will still be able to stabilize the situation in Y (as long as X & Y do have something in common) - remember, even people in Y won't know all the code by heart anymore - they will not read it all!
- So, does it mean the end of developer specialization (in domain/app/module)? Not necessarily - because it's much easier to drive agents once you have a deep understanding of the domain's model & abstractions - and the deeper intents behind them. Besides, the implemented model is only a part of the (problem) domain, so a wider understanding (of extended context) is still important. And even the strongest models can't keep everything in their context. That said, especially in simpler domains, I think builders will be much more "flexible" when moving between topics (and onboarding time will drop tremendously).
Do you agree? Do you already see some symptoms of change in your teams? Or have you observed things going in a totally different direction? Please don’t hesitate to let me know (in the comments here, or on social media).
Thanks in advance!
