← Back

Are we building the AI future faster than teams can adopt it?

Pablo Bermejo
Posted on August 23, 2026View on GitHub
aidevex

I recently argued that the future of Developer Platforms is creating Systems of Delegation. Since then, several ideas have appeared that resemble a similar shape that caught my attention, chief amongst them cloud coding agents, Slack Code, and the emerging notion of software factories (because everything old is new again!)

Each implementation is too new and early to prove the main argument on its own. Taken together, however, they suggest that we may be directionally converging on a new set of primitives for software development. In this new world, the unit of work is moving from a file toward a goal, while the development environment is expanding from the place where code is written into the system where we express intent, delegate work, observe progress, and verify results. Consequently, human attention is moving toward the decisions and risks where judgement is still crucial. To me, this looks a lot like a System of Delegation.

At the same time, I have an uncomfortable, bugging thought. After talking to many peers and friends in the product development industry, I've got the impression that we might be building this future faster than most development teams can adopt it. If the teams inventing the new development workflows already belong to the most advanced fraction of the industry, their tools may amplify an advantage that other teams cannot easily reproduce, leaving us to converge on direction while widening the distance between those who can execute it and those who cannot.

In any case, I might not be alone in my interpretation and AI is actually uncovering the largest product adoption challenge ever imagined.

A common shape before a common practice

When I wrote about Systems of Delegation, I was trying to describe a change in the shape of the developer’s inner loop.

The traditional loop revolves around writing, running, debugging, and reviewing code. On the flip side, the emerging loop looks closer to explaining, challenging, delegating, verifying, and steering. Code remains important, although more of the work now happens around it instead of on it because someone has to make intent a legible first-class citizen for autonomy to run safely.

Cloud coding agents are perhaps the clearest expression of this shift because they make delegated execution persistent and remote, allowing the developer to hand over a task, disconnect from the execution environment, and return later to inspect what happened. Slack Code shifts the collaboration boundary by bringing agents into the space where teams already coordinate, discuss trade-offs, and accumulate context. The channel can then become part of the control plane for software development work, with humans and agents operating inside the same conversational environment. Last but not least, software factories expand both ideas from individual delegated tasks into a sustained production loop where work is mapped, sliced, implemented, verified, and re-sliced through a system that can run for much longer than a normal interactive coding session. Then, humans review decisions and evidences while the factory handles more of the production loop.

In this article, I don't want to evaluate these new products against a checklist of delegation properties. Their implementations differ, and their interfaces will probably change many times, yet they are all seem to be responding to the same pressure: generation is becoming cheap, while specification, coordination, and verification remain scarce.

That pressure is forcing the development environment to grow around the agent. We know hat a traditional IDE (even augmented with AI assistants and copilots) lets the developer control a process that produces code. A System of Delegation, however, asks the developer to shape a system that produces outcomes. Hence, once agents can act for hours, coordinate with other agents, and operate across several systems, autocomplete is hardly an adequate mental model.

We still lack settled good practices for this, which is expected because new primitives usually appear before anyone agrees on how to use them. As people improvise and patterns spread, tools gradually crystallize those patterns into platform defaults. Slack Code and software factories may represent that middle stage where there is enough convergence to reveal a direction, yet too much variation to declare that the operating model has arrived.

Note: The factory metaphor can be misleading when it reduces engineering to code production. A useful software factory industrializes the movement from intent to verified behavior, and its output includes the reasoning surfaces that let people understand what was delegated, why the result deserves credit, and where human judgment was required. This is a much more profound change than faster code generation.

The adoption problem is also an organizational problem

The frontier version of the new development workflows is impressive, and its demands begin with the ability to slice many hours of agent work into independently verifiable pieces. However, many teams still struggle with this because unclear architectural seams make it harder to constrain work. When important constraints live as tribal knowledge held by a few senior engineers, ownership remains ambiguous, and production feedback arrives long after a change is merged, agents accelerate those weaknesses at a much higher speed.

This is where the adoption question makes me uncomfortable. These new systems like Slack Code may be built by teams that already know how to articulate intent, encode constraints, and construct verification loops, after which their workflows become product features, demos, or open-source skills. Another team can install the tool, although it cannot install the organizational judgment that made the tool emerge in the first place.

We often measure AI adoption through seats and tokens, even though those numbers can rise while the way work gets done remains largely unchanged. Inside the same company, a small group may build reusable agents and verification harnesses while everyone else either uses the tool superficially or avoids it. On paper, the organization has technically adopted AI, yet the practical outcomes form a barbell.

Developer tools have always had a learning curve, so some unevenness is inevitable. The difference here is that every increase in agent autonomy raises the consequences of using the system poorly. Misconfiguring an IDE wastes a developer’s time, whereas over-relaying on a delegation system without proper engineering and architectural discipline can produce and propagate bad decisions while appearing productive.

Agentic DevEx therefore acts as a maturity amplifier, giving teams with explicit architecture constraints and strong feedback loops more throughput while teams without them receive more output and a larger verification problem.

The maturity amplifier

The same agent amplifies two different organizations

Reading 01 · Same tool

Install the same agent

Cloud agents, Slack Code, or a software factory can give both teams the same delegated execution. The tool arrives before either organization changes how it works.

Reading 02 · Explicit system

Give one team constraints it can inspect

One team writes architecture boundaries into APIs and schemas, scopes permissions, and checks work with tests and production feedback. The agent can act for hours because the limits are visible.

Reading 03 · Implicit system

Keep the other team’s rules in people’s heads

Ownership stays ambiguous, important constraints remain tribal knowledge, and feedback arrives after merge. The agent has to guess inside the gaps.

Reading 04 · More autonomy

Turn up autonomy and watch the outcomes split

The explicit team gets more verified throughput. The implicit team gets more output, more uncertainty, and a larger review queue.

A common practice before a common platform

There is another possible direction, and it is the one that makes me optimistic. The systems that currently amplify mature teams could eventually encode that judgment for everyone else by turning constraints into reusable primitives with their platforms. As these pieces accumulate over time an use, domain-specific factories can absorb operational responsibility much as higher-level cloud platforms absorbed parts of infrastructure management.

Think of AWS. Technological primitives usually become broadly useful through a progression in which raw capability appears first, experts assemble it into idiosyncratic systems, and repeated patterns harden into platform products. Eventually, ordinary teams consume a curated abstraction without understanding every mechanism underneath, while retaining a route toward deeper control when they need it.

A mature System of Delegation should work the same way. Developers should be able to express intent, inspect evidence, and intervene at the right moments without first becoming experts in context management, agent orchestration, evaluation design, and token economics.

And I can envision such system: Slack Code contribute distribution by bringing agents into an existing coordination environment, concepts like software factories turn a collection of prompting techniques into a repeatable production system, and cloud agents supply the execution substrate on which that system can run. Together they cover important parts of the stack. If every team has to construct its own factory from skills, prompts, scripts, models, permissions, and evaluators, we have created a powerful primitive for experts. If platforms can turn those practices into domain-specific systems with understandable controls and sensible defaults, we may have created a new layer of Developer Experience, which would represent a very different level of progress.

We may be converging and diverging at the same time

I think we are witnessing genuine evidence that the industry is moving toward Systems of Delegation because the common structure is becoming easier to see: intent enters, work is delegated, constraints shape execution, software performs more of the verification, and humans concentrate on uncertain decisions (my Explain > Challenge > Delegate > Verify > Steer loop).

Yet evidence of direction says little about readiness.

Per the AI adoption article I shared at the top of this post, company-wide AI rollouts often create the illusion of adoption while concentrating real value among a small group of power users and leaving everyone else behind. This mans the industry can converge around a new primitive while individual teams diverge in their ability to use it. My feeling after discussing this with other product development leaders leads me to think that while frontier teams move from coding agents to software factories, the majority of development teams may be still trying to make autocomplete produce a manageable pull request. I see both realities exist at once.

In that sense, this future resembles the Prometheus myth in Plato’s Protagoras. Prometheus gives humanity fire and technical skill, yet people still fail to build stable communities because they lack the civic wisdom to coordinate. Capability arrives before the social system needed to use it. Coding agents may be our Promethean fire: widely distributed technical power whose value still depends on organizations learning how to constrain, inspect, and govern it together.

The next phase of DevEx therefore has two connected jobs: increasing how much work can be delegated while lowering the organizational barriers that impede to delegate that work safely. The primitive may already be emerging, while its path to broad adoption remains an open question.

Comments (0)

No comments yet.