This article was born from a year of fieldwork and three months of systematic rereading of the literature. It is divided intothirteen sections, grouped into four movements.

The first movement(sections 1–3) explains why the old yardstick is no longer enough and introduces the map offourteen dimensionsorganized into three floors —vertical axesmeasurables of the system (cost, quality, safety, debt, observability),normative and human axesgoverned (compliance, ethics, culture, sovereignty, effective adoption),reading lensesof perspective (roles, future programmer, overall maturity) — plus a cross-cutting target scenario (Agentic DevSecOps).

The second movement(sections 4–7) enters the densest dimensions: the cost asworkflowand not as a license; the quality-safety-debt triangle with the 2025–2026 data confirming it; thescissors effectbetween seniors who remain outside the circle and enthusiasts who enter without a map, with themap of the six postureswhat comes from it; and the three axes that decide whether we win or hide - compliance, sovereignty, culture - with the EU AI Act deadlines updated post-Omnibus.

The third movement(sections 8–10) changes angles and thinks about people: the same map read by four different roles, the evolution of the software professional of the future, and thematurity scale L0–L5with the L5.0→L5.5 agent autonomy sub-radar and cross-framework mapping towards Gartner, MIT CISR, ELEKS, AgID.

The fourth movement(sections 11–13) closes the gap: the target scenario of the team of agents doing DevSecOps in an agile way, the holistic vision that links circle, sphere and n-sphere, and what I take away from all this. Each section includes a box“What the market says”with timely and dated references; at the bottom you will find the unified list of the forty-two sources cited. It's a long article, but it's written to be readin several rounds— the first time looking for the map, the following times looking for your position within the map.

A year ago, on these pages, I added a circle. It was a choice that, as I made it, seemed more narrative than technical: the three circles ofCloud native ecosystems— people, processes, technologies — were no longer enough, and a quarter was needed to accommodate what was coming through our teams' doors without asking permission. I called him theFourth Circle, and in the following months I tried to tell it in the threeAmbassadors, then in theOverture to Act IIIand finally in the piece oncustody of the humanwhich closed one season and opened another.

That circle, today,invoice. Consume tokens. Opens pull requests. He gets it wrong, sometimes expensively. He learns, sometimes in a surprising way. It has a budget, an owner, an audit log. He even has his owngovernancelegislation: theEU AI Actis in full implementation phase (after the political Omnibus of 7 May 2026 the deadlines for the systemshigh riskare set for 2 December 2027 for Annex III and 2 August 2028 for Annex I, while the prohibited practices are already fully enforceable) [1];ISO/IEC 42001it is certifiable and becomes the operationalization of the AI ​​Act [2];AgIDhas published guidelines complete with levels of agentic autonomy [3]. What twelve months ago was a line on the plane has today become a full object, with an inside and an outside, and with a weight that you can feel when you lift it.

This article was born from a question I asked myself out loud while working on a cost assessment, and which I then kept hearing while rereading the old book:How do you measure the value of a workmate who doesn't sleep, doesn't get tired, but costs money for every word he writes — and who works very differently depending on who uses him?It is apparently a FinOps question, but underneath there is another, broader thing: how do you look at a Fourth Circle that has become alive, and that behaves differently with different people?

The answer I came across is not a formula. It's onemap. A map with fourteen dimensions, a six-step maturity ladder, a horizon — that of the team of agents doing DevSecOps together with us — that is no longer an academic hypothesis, and a human fold that the market is still trying to name: what happens when the most experienced professionals stay outside the circle, and the most enthusiastic enter it without a map.

This article is that map. The book I am writing, dedicated entirely to the Fourth Circle, will be the journey inside that map.

For fifteen years the way we have measured technology in the software lifecycle has been relatively simple:licenses, servers, people. A professional license was purchased, the infrastructure consumption was estimated, the speed of the team was calculated. The TCO was a nearly linear sum of well-known items.

The Fourth Circle breaks this meter for four reasons which, taken together, make it useless.

The first is thatthe cost has become profoundly variable. Not as variable as the cloud was, where the variability was about capacity — more CPU, more storage, more network. Variable as language is: everyphrasecosts, everycontext sentcosts, everyresponse generatedcosts, everyreflection between agentscoast. The price is no longer measured in seats but inworkflow, and two professionals with the same license can produce ten times different accounts in the same month.

The second is thatquality has stopped being a downstream control. When a person wrote the code, quality was a check that occurred on the pull request. When the code is written — or co-written — by an AI, quality comes into playin the generation process itself: it depends on the prompt, the model chosen, the context available, the historical moment in which you are working. Recent studies converge on a worrying area: the Veracode 2025 study reports thatapproximately 45% of AI-generated code introduces OWASP Top 10 vulnerabilities[4]; the independent AppSec Santa 2026 benchmark on 522 samples of six LLMs brings the average figure to25.7%[5]. The range is wide, but the message is unambiguous: quality has become an axis of measurementcontinuous, not a binary gate.

The third is thatthe risk has entered a new regulatory dimension. Between AI Act, NIS2, ISO 27001:2024 extended with AI controls, ISO/IEC 42001 and AgID guidelines, software is no longer just a product that does things: it is a subject that must bereportable. Who created this feature? Which model? With which prompt? With what level of human intervention? Without traceability, no compliance. Without compliance, no production.

The fourth — and here I want to give a name to something that I have seen grow month after month in the teams I work with — is thatadoption is not uniform. The same tool, in the same team, is rejected by some of the seniors and embraced without criteria by some of the juniors. The result is oneapparent speedwhich hides a real debt, and a patchy quality that the system metrics do not see. I'll come back to this in a few sections: it is the most lively dimension of the whole map.

To measure the Fourth Circle it is necessary, then,a new meter. Not a single meter. A meter that knows it has multiple axes, and that is not ashamed of being so.

To avoid getting lost in the complexity, I have organized the dimensions that the market is focusing on - crossed with those that we are already using in our internal assessments - intothree floors. It is a deliberate choice: not all dimensions have the same nature, and treating them as if they were homogeneous would be the first methodological error.

The first floorcollects themvertical axes: they are propertymeasurables of the system. The cost, the quality, the security, the technical debt, the observability. These are things that are quantified, monitored and compared over time. They have native KPIs.

The second floorcollects themnormative and human axes: they are propertygovernof the system. Compliance, ethics with its human oversight, corporate culture, technological sovereignty, and - the newcomer - theeffective adoption, which is the most human dimension of all. They are not measured with a meter: they are monitored with policies, evidence, processes, real conversations.

The third floorcollects themreading lenses: they are not properties of the system, they areways of looking at it. The role of the person reading the analysis (area, product, project manager, software professional), the evolution of the professional himself, the overall maturity as an integrated snapshot of everything.

Above these three floors walka transversal horizon: the architectural scenario of the team of agents doing DevSecOps in an agile way.

#	Dimension	Floor	To whoever speaks first
1	Process cost (not consumption)	A — vertical	CFO, FinOps, project manager
2	Quality of use of AI assistants	A — vertical	tech lead, QA manager
3	AI-generated code security	A — vertical	CISO, security architect
4	Longitudinal technical debt	A — vertical	architect, CTO
5	Agent observability (AgentOps)	A — vertical	DevOps lead, SRE
6	Compliance and regulatory governance	B — normative	compliance officer, DPO
7	Ethics and human-in-the-loop	B — normative	leadership
8	Culture, change management, AI literacy	B — human	HR, area managers, training
9	Technological sovereignty and neutrality	B — normative	CTO, board
10	Effective adoption and the scissors effect	B — human	tech leads, area managers, CTO
11	Roles and perspectives	C — lens	management
12	Software professional of the future	C — lens	dev community
13	Overall maturity	C — lens	CTO, board, customers
14	Agentic DevSecOps (target scenario)	Transversal	all

A note on vocabulary: I will be using a lot in this articlesoftware professionalsinstead ofprogrammers. The Fourth Circle affects everyone — developers, architects, analysts, engineers, QA, DevOps, SRE, security engineers, even those who do technical pre-sales — and reducing it to just developers is a simplification that would make us miss half the phenomenon

When we talk about the cost of AI in software development, the first thing we usually do is look at the price list. The price list tells a tiny part of the truth.

The real cost is that ofworkflow, and the workflow is the combination of five ingredients: access cost (the license), inference cost (input token, output token, cache, grounding), cost of ancillary services (code review, agent runtime, GitHub Actions, knowledge base), cost of governance (overage, budget control, audit) and related infrastructure costs.

To give a concrete idea: GitHub Copilot,from 1 June 2026, it has definitively abandoned the dei modelPremium Requeststo move on toAI Credits, with separate budgets at the user, organization and cost center levels [6]. Vertex AI works on an almost purely token-based model, where thecontextsent — the repository piece, the diff of a PR, the log of an error — becomes the dominant variable. Claude Code and the Anthropic API combine subscription and consumption, with imanaged agentswhich introduce an additional cost forsession-hour. Amazon Bedrock, finally, is not a price: it is acontainerprices that vary by model, provider and tier (on-demand, flex, priority, reserved), with significant discounts on the batch.

The practical consequence is that the cost is no longer estimated "per user". It is estimatedby workflow class:

• autocomplete and inline completions, where marginal cost tends to zero
• Technical Q&A, explanations, test generation, low but constant cost
• refactoring and reviewing pull requests, cost increasing with the size of the context
• cross-file understanding and reasoning on the entire repository, significant cost
• multi-step agent tasks, where the cost of the session runtime is added to the cost of the tokens

Then there is an item that FinOps dashboards do not see and which, from my experience in teams, is sometimes as valid as all the others put together: thewaste cost. It's the time people spend onexperiment without capitalizing: trying a model and abandoning it, rewriting a prompt from scratch every time, haphazardly evaluating tools that should already be selected at an organizational level. The waste is not on the invoice, it is on the timesheets. And a much-cited METR study quantified it counterintuitively:Experienced developers, with rigorous controls, were on average 19% slower using AI than estimated, despite perceiving themselves to be 20% faster[7]. It is the strongest data to disprove the narratives of "10x productivity".

The metric to bring to a management committee, then, is not "how much we spend on AI". ANDcost per completed feature, cost per revised PR, cost per module migration, cost per hour of assisted development, cost of waste per team.

What the market says.AgID, in the guidelines for the PA, introduces the concept ofLCOAI — Levelized Cost of AI, a metric inspired by the energy LCOE that evaluates economic sustainability over the entire life cycle, with SaaS + external API calculation examples vs self-hosted on-premises [3]. The international FinOps point of view converges: theFinOps Foundationindicates that“managing the cost and use of tokens is the top challenge facing FinOps practitioners today”and proposes a mix of API key governance, proxy layer, unit cost metrics and model right-sizing [8]. Two different lenses - Italian institutional for supply chain services, international FinOps for granular tokens - which however converge on the same point:measure by workflow, not by license.r the PA, introduced the concept ofLCOAI — Levelized Cost of AI, a measure inspired by energy metrics (LCOE), which evaluates the economic sustainability of AI onentire life cycleof the initiative, not on the initial purchase. It's the same direction we're going.

In recent months, a truth that was predictable, but which few had dared to say, has forcefully emerged:the real bottleneck is not cost. It's the quality. And within quality there are two distinct things that are worth separating: thesafetyof the generated code and thelongitudinal technical debt.

On safety, the evidence is now abundant. The range of AI-generated code with vulnerabilities attributable to OWASP Top 10 varies, depending on the sources, between25% and 45%[4][5]. Snyk converges in the same range when talking about AI code“30-40% more vulnerable than that written by humans”[9]. It is not a fact that condemns AI: it is a fact that imposes acontinuous control. It means that every pull request generated or co-generated by AI must go through SAST, dependency analysis, secret detection, and — above all —Actual human code review, not symbolic.

On technical debt, the question is more subtle and more dangerous. A team that adopts AI without measuringasits code evolves over time it doesn't see the debt growing: it sees itdon't see. A very recent academic paper (Verma, October 2025) proposes a break-even mathematical model validated on three industrial cases for 153 million lines of code, and arrives at a sharp thesis:“the productivity case for LLM coding assistants is real but incomplete — standard metrics capture the benefit on a timescale of days to weeks while costs accumulate over months, creating a systematic measurement blind spot in most current adoption programs”[10]. The apparent speed of the first months hides a stratification of quick choices, of patterns that are not always coherent, of tests generated to cover the number rather than the substance.

Then there is a point that is often skipped and which needs to be said clearly:the quality of what comes out of AI is a function of who uses it, not just the tool. The same assistant, in the hands of a trained senior who knows how to question him, critically read his answer, recognize his weak points and correct them, produces high-level code. In the hands of an untrained enthusiast, who accepts the first plausible answer and commits it, it produces well-packaged technical debt. Quality, here, is not a property of the instrument: it is theproduct tool × user.

The CodeRabbit 2026 benchmark quantifies this:AI-generated pull requests have on average 10.83 issues compared to 6.45 of human ones, with 1.75x more logic errors, 1.57x more security issues, 1.42x more performance issues[11]. And on the perception front, the 2025 Stack Overflow Developer Survey of 49,000 developers shows that adoption is at84%but trust has fallen to29%(it was 40% in 2024), while the66% say they spend more time fixing AI code“almost right but not quite” [12]. Two sources, two lenses - laboratory and mass perception - converging.

Here a dimension comes into play that the market is only now naming:the observability of the agents, Or AgentOps. It is the natural extension of DevOps when in production there is no longer just code, butcode + agents who decide. Infosys' AgentOps formalization explicitly talks about extending DevSecOps + MLOps + LLMOps with agent-specific guardrails [13], and the open-source tooling ecosystem is already active (AgentOps.ai, 5.7k star GitHub, integrations with CrewAI, AG2, OpenAI Agents SDK, LangGraph) [14]. It's not theory.

The quality-safety-debt triangle cannot be resolved with a tool. It is governed by a process. And the process, within a mature Fourth Circle, must havememory.

I arrive at the most lively dimension of the entire map, and the one that, until I saw it honestly mentioned, I hadn't understood how central it was.

There is a phenomenon that many reports summarize under the word kind“adoption rate”and which, within real teams, is instead onescissors. On the one hand there are thesenior professionals who reject AI. Not out of ignorance - that would be too simple - but out of a more complex posture, which mixes three things in variable proportions: the sensation that“I already know how to do better than this”, the legitimate suspicion of hallucinations and dangerous shortcuts (which seniors, it must be said, see before others), and an identity defense towards a profession built over twenty years which now risks being renamed.

On the other side of the divide are theenthusiastic professionals with no training. They use AI all day, in every step of the job. They change models on the fly, write different prompts each time, haphazardly evaluate tools that should already be selected on an organizational level. They produce code that works today and will be difficult to maintain tomorrow. Their apparent speed hides thecognitive dispersionwhich I have already called waste.

In the middle, between the two blades of the scissors, there is thesilent majority: People who use AI in an average way, without position, without opinion. They are the most important audience of all, because it depends on them whether the organization really moves towards L3-L4 of the maturity scale or remains stuck at L1-L2.

I tried to draw oneposture mapthat we can live in the face of AI in our profession. There are six of them, and it seems to me that each of us recognizes ourselves in at least one.

Posture	Dominant characteristic	Cost it produces	Lever to move
Rejecting	“AI is useless, it causes damage”	Know senior outside the circle	Guided experiences on known cases
Skeptical-observant	“I look, but I don't touch”	Slow adoption of practices	Pair programming with trained users
Messy experimenter	“I try everything, I capitalize little”	High waste, irregular quality	Method frame, shared prompt library
Average user	“I use it when it happens”	Organizational maturity blocked	Structured onboarding, team KPIs
Trained user	“I use it methodically”	Low cost, high quality	Recognition, mentor role
Orchestrator	“I use it to orchestrate systems”	High initial investment	Exposure to real agentic cases

Scissors are not destiny. ANDa state of the system, and like any state it can be changed. But specific levers are needed for each posture. The rejecter doesn't need a course: he needsa use case in which his experience is recognized as decisive. The experimenter doesn't need another tool: he needsa method that gives shape to its energy.

What the market says.The observation I built in the field finds strong empirical evidence in the Faros AI data on 10,000+ developers and 1,255 teams: the less experienced rely much more on AI tools, while“senior engineers with deep system knowledge resist”— but when seniors adopt,“ship 2.5x more AI-generated code than juniors”, while senior skeptics produce code reviews91% longer[15]. A complementary psychological reading comes from Yuliyan Gospodinov's analysis: the division is not registry, it ispsychological(process-oriented vs result-oriented), e“developers who've spent a decade or two building their identity around technical skill are being asked to shift their value proposition… that's a real psychological cost, not a trivial adjustment”[16]. On an operational level, a summary from Bain confirms that the problem is organisational, not technological:“the mistake most engineering leaders make is treating all developers the same”[17]. From many sources emerges a coherent map offive reasons for resistance(deskilling, trust, workflow disruption, quality concerns, professional identity), all rational and all addressable [18].

A sincere, due note. This is not a theoretical phenomenon. It is a phenomenon that I am seeing happen in real time in the contexts in which I work, and that many colleagues tell me in similar words. For narrative honesty I say it openly: this is the dimension I added to the mapafter writing the first version of this article, because when talking about it I realized that it was missing - and it was missing because the market hides it in the convenient box of“change management”. It's not change management. It's aassessment axis.metrics, its levers. And it should be treated that way.

The rest of the second floor of the map is what, paradoxically, is treated last by most organizations. It's a mistake.

On compliance, the 2026 regulatory framework is clear:EU AI Actin full implementation (with high-risk deadlines extended but prohibited practices already payable and fines of up to €35M or 7% of turnover) [1];ISO/IEC 42001available for AI Management Systems certification and now recognized as the technical operationalization of the AI ​​Act [2];NIS2transposed;ISO 27001:2024extended with AI controls;AgIDwith its six levels of autonomy for agentic architectures [3]. It's no longer a gray area. The question is no longer“Do we have to comply?”- And“How quickly do we become so, and how much evidence are we able to produce?”.

On technological sovereignty, the discussion is less technical and more strategic. The EU institutional framework is clear:“the EU relies on suppliers outside its borders for more than 80% of its key digital products, services, infrastructure, and IP” and “more than 70% of the EU cloud market is held by three US hyperscalers”[19]. Ursula von der Leyen summarized the stakes thus:“we cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure”[19]. AgID introduces the concept of as a pillarhardware neutrality and portability between suppliers[3]. For those who position themselves in the frameworkEuropean Secure & Sovereign AI, this is not a slogan: it is an architectural axis that decides how pipelines are designed, how secrets are managed, how vendors are evaluated.

What the market says.For editorial transparency I declare that I am part of DedaGroup, which has publicly articulated its own ESS-AI positioning. Marco Podini (CEO DedaGroup) summarizes it like this:“the most important game of this new digital era is played precisely in the ability of each organization to define its own risk sovereignty, modulated based on the sensitivity of the information, the context of use and the level of trust”[20]. An international point of view adds concrete urgency: theAnthropic's June 2026 global blackout(the “Fable Ban”) which deactivated Claude Fable 5 and Mythos 5 for US export-control, became the“practical test of sovereignty: can a foreign directive, a vendor outage, or a price change take your AI away? If yes, you are not sovereign”[21]. A SUSE survey closes the picture:“98% of IT leaders call digital sovereignty a priority — but only 52% report taking any action on it”[22]. It's the classic acknowledgment-vs-action gap.

On culturefinally, there is the point that is closest to my heart, and which now - in light of the section on the scissors effect - takes on a more precise meaning. In my work in recent months I have convinced myself that the most important phrase we can say to ourselves, in front of the Fourth Circle, is this:becoming an AI-empowered organization requires people to change before technologies.

What the market says.Gartner quantifies the cultural cost:“AI adoption demands 25% more training effort and up to 200% additional change management effort”compared to traditional technologies.“81% of CIOs say GenAI skill gaps will block their 2025 objectives, while 63% of employees haven't used GenAI in critical tasks”[23]. Culture is one of the seven pillars of the Gartner AI maturity model (along with strategy, value, organization, governance, engineering, data), not an addendum [24].

AI literacy is not a course. It is a habit that is built with repeated experiences, with small successes shared, with mistakes discussed without shame. If the scissors effect is theproblem, culture is theleverwho faces it. Intergenerational pair programming between rejecting seniors and enthusiastic juniors — not as a course, but as a regular practice. “AI office hours” conducted by the seniors who moved first. Controlled sandboxes for experimenters. Retrospectives on the use of AI on par with those on code. These are not heroic practices. They are practicalsmall, repeated, recognised.

And on theethics with human oversight, a clear reminder is necessary."Presence is not practice. Most organizations put someone 'in the loop' without training them on what to approve, when to escalate, or how to recognize automation complacency"— theEU AI Act Article 14requires oversight“demonstrably trained, measurable, and provable”, not symbolic [25]. The academic literature has already consolidated a HITL taxonomy (loop placement, interaction granularity, temporal characteristics) [26] and demonstrated in the field that“errors can propagate and compound along the workflow, especially when we string numerous agentic components together”[27]. Human-in-the-loop is not optional for real agent workflows.

One of the things I have learned in recent months is thatthe same data changes meaning depending on who reads it. The cost per completed feature, for example, says very different things to an area manager, to a product manager, to a project manager, to a software professional.

For the area manageris a metric ofwallet: compares projects with each other, decides on allocations, identifies areas of efficiency. The scissors effect is for him a metric of organizational risk.

For the product manageris a metric oftime to value: Link AI investment to market return, evaluate whether apparent speed translates into real value. Waste is a silent enemy.

For the project manageris a metric ofdelivery: he needs it to estimate better, to negotiate scopes, to manage unexpected events. The asymmetry of postures in the team is one of its main risks.

For the software professional, finally, is a metric ofoperational autonomy. Knowing how much the workflow he is using costs, understanding where his current posture places him in the map of the six positions, recognizing whether he is in a waste or capitalization phase: all this makes him an aware subject, not an unaware consumer.

What the market says.BCG, based on a study covering 165 million US jobs and 1,500 roles, classifies software engineering asAmplified Role(not Diminished):“the nature of what people do in these jobs will change significantly, even when the job title remains the same”. Estimate: 50-55% of the works will bereshapedfrom AI in 2-3 years, but only 10-15% will be eliminated in 5 years [28]. A complementary organizational reading speaks of three stages of AI workforce maturity (tool-based → workflow transformation → agent-led orchestration), with the prediction that“traditional pyramids are giving way to flatter, AI-augmented pods, redefining the need for junior, coordinator, and manager roles”[29].

For each of these roles, the same map must be read with a different order of priority. In the book I will try to build onereading guide by role. In the article just keep this in mind:perspective is not a detail. That's half the meaning of the data.

On this point I want to be clear, because it is the point on which I read the most incorrect predictions.

The software professional is not dying.He's changing jobs— and it's doing it much faster than people say. The movement I see in the teams I work in goes in this direction: less time spent writing lines of code, more time spent ondefine the contextwhere an AI will work well; less time spent reading code line by line, more time spent onjudgewhether a solution is consistent with a broader architecture; less time spent debugging by hand, more time spent ondesign the system that will debug for us.

One of the most frequent questions when talking about Artificial Intelligence in the SDLC is whether new professional roles will arise or whether existing ones are destined to disappear.

My impression is that we are observing a different phenomenon.

Even before new roles, new transversal skills are emerging that every actor involved in the software life cycle will have to progressively acquire. Analyst, Developer, Tester, Architect, DevOps Engineer, Security Specialist and Manager will continue to carry out different functions, but will be called to operate in contexts where AI models and agents become an integral part of the production process.

The transformation does not only concern the tools used, but the very way of working. The ability to build context for an agent, validate its results, select the most suitable model for the problem to be solved, understand the costs and benefits of automation, govern the quality, safety and compliance of the generated artefacts will become increasingly important.

In this scenario, AI does not automatically replace the professional. On the contrary, the value of those who develop orchestration, supervision and direction skills increases. Writing code remains important, but it is no longer the only defining skill. Instead, the weight of the ability to define objectives, build workflows, interpret results and make decisions is growing.

The Fourth Circle therefore introduces a new level of professional literacy that runs through the entire SDLC. We are not talking about a skill reserved for developers or software architects. We are talking about a set of capabilities that each role involved in the process will gradually have to acquire to collaborate effectively with models, agents and intelligent systems.

These new skills include, for example:

• the ability to collaborate with AI assistants and agents;
• the construction and management of the information context;
• the verification and validation of the generated outputs;
• understanding the costs and benefits of automation;
• the conscious selection of models and tools;
• the ability to integrate AI into decision-making processes;
• understanding the impacts on quality, safety and governance.

For this reason, the real risk is not automation itself, but the lack of professional evolution. Just as the cloud, security by design and DevOps practices have required new learning paths over the years, the Fourth Circle also requires the acquisition of new operational and decision-making skills.

Not everyone will follow the same path and not everyone at the same speed. Some organizations may choose to specialize certain skills in dedicated figures. However, the most profound change does not concern the birth of a new job title, but the diffusion of a new professional skill: collaborating effectively with ecosystems of models and AI agents within software development processes.

The professional of the future, therefore, does not disappear.

It evolves.

And the speed with which it can acquire these new skills could become one of the main distinguishing factors of the next decade.

In fact, out of all of them, a skill could arise that we now call which increasingly resembles aorchestrator of intelligences. He is a figure who still has a solid foundation of fundamentals - one cannot improvise as an orchestrator if one does not know the instrument - but who works in a higher layer: that ofprompt-as-design, Dell 'agent-as-team-member, Of the policy-as-code.

What the market says.The clearest voice is that of Nicholas Zakas (author of ESLint), who describes three phases (cruise control → conductor → orchestrator):“the software engineering job of the future won't involve writing code; it will involve orchestrating AI agents to write code for you”[30]. Anthropic gives the quantification with its2026 Agentic Coding Trends Report: developers use AI in about 60% of the work, but fully delegate only 0-20% — the developer isorchestrator, not writer[31]. JetBrains 2026 confirms with field data:85% developers use AI daily, while Microsoft states thataround 30% of the code in some repos is AI-generated(Google around 25%):“you're the engineering lead of a team of tireless, competent junior developers”[32].

However, the less optimistic part must also be said.Not all seniors will choose to transform, and it is a choice that - at least in some cases - is legitimate. Some will prefer to remain masters of the traditional code until the end of their careers, and the organization will have to decide how to enhance them without forcing them. Others will choose not to transform out of laziness or defensiveness, and the organization will have to decide how long it can afford to do so. The transformation of the profession is not automatic: it is onepersonal choice within an organizational framework, and both matter.

Within this transformation I like to think that a profession that today seems ancient but which will become very new remains central: that ofwho knows how to say no to a plausible but wrong solution. It is a profession that requires experience, taste and ethics. It is - to use a word I chose a few months ago - a profession ofcustody.

The question that closes any analysis on the Fourth Circle is always the same:“Where are we at?”. For years the market has responded with 9, 10, 12 level ladders, each indistinguishable from the previous one.

After studying the frameworks that are becoming consolidated — Gartner AI Maturity (5 levels) [24], ELEKS AI-SDLC Maturity Model (5 stages) [33], MIT CISR Enterprise AI Maturity (4 stages) [34], AgID with the six levels of autonomy for agentic architectures [3], and the recent SEI-Accenture AIM Framework (eight dimensions) [35] — I propose a scalewith six steps, from L0 to L5, built to be readable on a board and precise enough to guide an assessment.

Level	Name	Substance	Minimum KPIs
L0	Awareness	We're talking about AI. No real, structured use.	Formal adoption = 0%; investment <0.5% IT budget
L1	AI-supported	Individuals use AI tools such as autocomplete or ad hoc chat.	% developer with AI license
L2	AI-assisted	AI integrated into individual workflow, prime policy.	AI cost per developer/month; % PR with AI-assist >30%
L3	AI-integrated SDLC	AI present in all DevSecOps phases, with governance and KPIs.	Cost per feature; vulnerability for 1000 LOC; coverage ≥75%
L4	AI-native SDLC	SDLC redesigned around AI; Mature FinOps; widespread culture.	LCOAI for workflow; effective adoption rate ≥80%; ISO/IEC 42001 in progress
L5	Agentic DevSecOps	Teams of orchestrated agents that autonomously run the SDLC with human-in-the-loop.	% autonomous tasks; MTTR task agent; % HITL checkpoints passed

Inside L5 there is aautonomy sub-radar, graduated in six notches (L5.0 → L5.5), inspired by both the AgID levels and the ACMM model by Andy Anderson (IBM Research) which starts from CMMI and reaches level 6Hive— orchestrated multiple agents in production [36]:

• L5.0Suggest-and-wait (human approves each step)
• L5.1Multi-agent assisted with HITL at critical points
• L5.2Phase autonomy
• L5.3Multi-stage autonomy with checkpoints
• L5.4Autonomy with auto-rollback
• L5.5Cross-domain autonomy (today only in search)

I want to add an observation here which, in light of the section on the scissors effect, seems crucial to me.L3 is a ceiling, if the senior posture does not move.You can buy the best technology on the market, write impeccable policies, launch extensive literacy programs: if seniors stayrejecters or skeptics-observants, the organization does not pass L3. Organizational maturity hashuman unlocking thresholds, and the most important is the one that is crossed when a critical number of seniors — not all, but a perceivable mass — enter the circle as trained users or orchestrators.

What the market says.Niraj Veer (co-editor of the EU AI Act security and ISO/IEC 5338 standard) summarizes it like this:“88% of organizations use AI in at least one function; only 1.5% across all systems in production are classified as AI systems”; and again:“AI maturity will not come from a single project, pilot, or purchase. It will come from a steady, deliberate shift in how you govern your software and AI as one portfolio”[37]. A critical comparison of the main frameworks (MITRE, MIT CISR, Gartner, Microsoft, KPMG) adds a methodological warning that is worth keeping in mind:“maturity models are descriptive, not prescriptive. They tell you where you are; they do not tell you which use case to fund”[38]. The scale is a compass, not a recipe.

A methodical note: the scale is onetrajectory, not a photograph. An organization does not “is” at one level; it isin some areas, while in others it is one or two levels behind. A serious assessment photographs theprofile, not thepoint.is, while in others it is one or two levels behind. A serious assessment photographs theprofile, not thepoint. And this is where the fourteen dimensions of plan A and plan B are really useful: each has its own curve, and the overall map arises fromoverlapping curves.

I get to the point that this whole article is pushing towards: theteam of agents doing DevSecOps in an agile way.

The image is simple and powerful. A group of specialized agents, each responsible for a portion of the cycle: those who collect the requirements, those who design the architecture, those who write the code, those who write the tests, those who carry out the reviews, those who manage the security, those who carry out the deployment, those who monitor the production, those who propose refactorings based on the metrics collected. Between themthey dialogue, each is observable, each is governed by policies, each has a budget. Above them there arehumans: no more individuals performing, butarchitects, coaches, custodians, final decision makers at risk points.

The method that supports this scenario is agile, but with aretroactive accentuationstronger: high test coverage, frequent retrospectives (even between agents), continuous review, incremental improvement of prompt, policies, metrics. More thanScrum teamwe are faced with what some callteam Squared: Humans doing Scrum with agents doing Scrum with each other.

What the market says.Microsoft formalized the termAgentic DevOps: “intelligent agents collaborate with you and with each other… handling bug fixes, small features, documentation, and more”[39]. IBM releasedLoop Genie, multi-agent assistant integrated into DevOps Loop with MCP/Claude/Gemini/Ollama support [40]. Infosys has published the frameworkAgentOpsas native lifecycle management for agents, with specific guardrails [13]. The most rigorous case on an academic-operational level is KubeStellar Console, maintained by oneHivemulti-agent with 74 CI/CD workflows, 32 nightly test suites,91% code coverage, bug-to-fix in less than 30 minutes 24 hours a day. Andy Anderson's (IBM Research) thesis is clear:“testing — the volume of test cases, the coverage thresholds, and the reliability of test execution — proved to be the single most important investment in the entire journey”[36].

And here section 6 returns as an echo:an L5 scenario only holds if the senior posture has shifted. Without seniors trained as orchestrators, the team of agents becomes a team without a coach, and a team without a coach—agential or human—does not scale.

The most important thing I realized while studying this passage is thatL5 is not the end of the pro. It's the beginning of a new type of professional.One who programs orchestrations, who programs policies, who programs systems that program. One who needs, more than ever, tosolid fundamentals— because without fundamentals, orchestration becomes an illusion.

In previous articles such as2026-01 — The fourth circleor in the most recent articleThe fourth circle and the custody of the humanI introduced the vision of AI as a further component represented in the most simplified version by a Venn diagram (the circle) which sits alongside and intersects with the other three circles which describe a corporate ecosystem, people, hardware and software.

I like to close with an image which, in recent days, has become for me the common thread of the book I am writing.

The Fourth Circle, last year, was a line on the plane. A lack that asked to be named. This year it became an objectfull: it has volume, because it contains costs, people, agents, processes; hatime within space, because it changes as you watch it — the model evolves, the prompt learns, the policy updates; haas many projections as the dimensions with which you look at it— the professional sees it as a tool, the manager as maturity, the compliance officer as risk, the humanist as ethics, the tech lead as a scissors effect.

Mathematics would have a word to describe it:n-sphere. An object that lives in many dimensions and which, when reduced to the surface,it becomes a circle again. It's an image that I like because it tells something profound: the complexity of the Fourth Circle is real, but its ownmeaninghe knows how to keep himself simple when needed. It knows how to become a circle. He can be drawn on a blackboard in five minutes, in front of a board, and make himself understood.

This is the work that awaits us:live in the sphere, tell with the circle. Measure in n dimensions, decide in two. Guard the complexityisoffer the reader - the client, the colleague, the board - a drawing that can say a lot with little.

It is the work of the Fourth Circle in production. And, ultimately, it is the usual job of those who do architecture.

There is a dimension that has only emerged in recent months, and it is the reason why this map - published today - is already destined to change in the book that will be born from it. I'll tell you how I see it now, knowing that it's still inmaturation and evaluation phase, and that probably, when I have more data from the teams I work with, it will end up moved toPlane A of the vertical axesalong with cost, quality, security, debt and observability — because in fact it is ameasurable axis of the system, not a reading lens.

I'll name it like this, provisionally:Smart & Local Models — the operational autonomy of the Fourth Circle.

The idea is simple but carries enormous consequences. For the past two years, the conversation about AI in software development has been dominated by paradigmcloud-first, frontier-first: the largest model, the most powerful, the one that lives in the data centers of three American hyperscalers, reached via pay-as-you-go API. And it is exactly the trajectory that generated the other thirteen dimensions — the cost per token, the list dependency, the opacity of the prompt, the sovereignty questioned, the observability to be built from scratch.

But something else is happening, in parallel, and it's happening right on our tables.Smaller models — the SLM,Small Language Models, and local models — are getting good enough to do the specific development work we train or select them for. NotanyWork. That job over there. The company's Spring Boot. The analyst's Python. The frontend team's TypeScript. Legacy COBOL that no one wants to touch anymore but still invoices. The principle is changing:we no longer need a universal brain that knows everything wrong; you need a skilled craftsman who knows your craft well.

And with this change of principle, theinfrastructural posture. They return to the tables - to the real tables, I mean, the wooden or Ikea ones on which each of us works every day - machines designed to accommodate the model. NVIDIA workstations with dedicated GPUs. Custom Linux PC with lots of RAM (half a terabyte, one terabyte) and large NVMe disks. Apple Silicon notebook with unified memory that allows local models to work in ways that were unthinkable two years ago. Apple even gave the thing a name,Apple Intelligence, where some of the work happens under the glass of the device. Microsoft launched the categoryCopilot+ PCwith dedicated NPUs. NVIDIA putChatRTXon workstations. The open-source stack — Ollama, LM Studio, MLX, llama.cpp, vLLM — has turned the ability to run a model locally into something you do with two terminal commands.

There is something poetic in all this. After teaching for years that“everything is cloud”, a part of the frontier is returningat the desk. It is a movement that has precise technical roots — efficiency of small models, cost of cloud inference that is starting to weigh, latency that matters in agent workflows, sensitive data that does not want to leave the perimeter — but it is also a movementcultural: He says the power of AI can live in an object you keep close by, not just a distant cloud you pay for by the meter.

Because this is onedimensionand not a technical detail? Because it affects all the others at the same time. Change thecost(one-time hardware capex vs continuous token opex). Change thequality(models specialized on your operating context beat generalist models on narrow tasks). Change thetechnical debt(the model you use is more stable over time, and your code has a less mobile reference).

But above all it changestwo things together, in a profoundly intertwined way.

The first is therelationship with the data. When model and code both live on my machine — or on my server, or on my network — sensitive datahe never leaves the perimeter. Proprietary code is not sent to an external vendor for completion. The customer data does not end up in the prompt that goes out to the cloud. Corporate know-how does not, in spite of itself, become training material for someone else. It is a huge advantage — especially for those who work in regulated sectors (healthcare, finance, defense, PA), for those who develop valuable proprietary software, for those who simply want to build without exposing. It is, ultimately,the return to the beginning of the house with the door closed: what happens inside, stays inside.

The second is specular, and is the direct consequence:if the model lives in my house, who can guarantee that the model itself does not leak information?It's a new question, and it needs to be taken very seriously. A local model is aartifact— a binary file of neural weights — that I downloaded somewhere. Who trained him? What could he have learned to do beyond what he claims? Could it contain backdoors, encrypted data exfiltration in its network calls, latent behaviors that only activate in certain contexts? This is not science fiction: it is already onerisk classthat research is naming precisely —model supply chain attacks, trojaned LLMs, persistent injection prompts in weights.

In other words:resolving the sovereignty of the data opens up the issue of the sovereignty of the model. And the answer is not “let's go back to the cloud”, but “let's build a certification and attestation chain for local models too” — as we did for open source software with SBOM, signatures, source code audits. You will need the equivalent of SBOM for models (MBOM, someone is calling him), will serve thecryptographic signature of weightsreleased by those who trained them, will serve theattestation of behaviorin controlled environments before deployment, theruntime scanof the network traffic that a local model generates — because a model running on my machine and making calls out shouldn't be able to do that without someone noticing.

We are learning, in short, thatthe model is also code, and like all code needs onegoverned supply chain. Platforms are starting to respond — Hugging Face introduced signatures and scanning, NVIDIA released guidelines forModel Risk Management, the EU AI Office is explicitly touching on the topic in draft guidance — but the discipline is young, and today represents one of the most active research areas of 2026.

Therefore, it also changessafety(in the double sense of the term: less data leakage, more need for model verification). Change thesovereignty(declined on two levels, data and artefact). Change thetechnical debt(the model also enters your supply chain of artifacts to manage, like every library you use). Change thecultural posture(the dev learns to tinker with his tools again, but with new responsibilities: not only "I use this model", but "I know where it comes from, who signed it, what it does when it runs").

It's not a binary choice, though. It is not“cloud vs local”. It is a third paradigm that is being built, which I would callstratified hybrid: frontier model in the cloud for open tasks, smart specialized local model on the workstation for daily and repetitive work, agents that orchestrate one or the other depending on the task. It's atwo-speed architecture, where the human chooses which speed to use for what.

And in each of these three levels — frontier cloud, smart specialized local, orchestrating agents — the principle ofchain of trustit must be built where it wasn't there before. In the cloud we built it through contracts, supplier certifications and audits. In the venue we still have to completely invent it. It's a work in progress, and this is also why dimension 12 of this map is the youngest dimension: not because it matters less, but because we are stillin the middle of the ford.

What the market says.The principle ofcontext-specific modelfinds academic foundation in the NVIDIA paper“Small Language Models are the Future of Agentic AI”(Belcak et al., 2025):“SLMs are sufficiently powerful, inherently more suitable, and necessarily more economical”for agent tasks, with 10×-30× cost reductions on specialized workloads [43]. Microsoft confirms with its ownPhi-3/Phi-4 - “surpasses similar-sized models and is on-par with models twice its size in mathematics and coding”— explicitly designed for on-device workflows [44]. Andrej Karpathy summarizes it like this:“the future is many small models that you can run, audit, fine-tune, swap, and own”[45]. On the hardware front, NVIDIA has defined the categoryAI Workstations(RTX 6000 Ada, DGX Spark/Station 1 petaFLOP desk-side), Microsoft the categoryCopilot+ PCwith NPU ≥40 TOPS, Apple put Apple Intelligence on-device with unified memory up to 512GB on Mac Studio [46][47][48]. On the models front, Mistral withCodestral(French, open-weight, code-specialized) is the natural ally of a sovereign European positioning, alongside DeepSeek-Coder and Qwen-Coder from the open world [49][50]. Tools likeContinue.dev + Ollamathey already allow us to replace Copilot with local models in VSCode, and a community liker/LocalLLaMAit is the thermometer of how quickly this trajectory is consolidating [51]. For the Italian context, the infrastructureCineca Leonardoopens up the possibility of fine-tuning local models in a sovereign key [52].On the certification side of local models, the discipline is being born right now: NVIDIA has published a framework forModel Risk Managementstating that“just as software supply chain security became central in the 2020s, model supply chain security will define the late 2020s”[53]. Hugging Face has integrated Sigstore signatures and SLSA provenance for the models [54]. NIST codified a formal taxonomy of attacks (model poisoning, backdoor injection, data exfiltration via outputs) in the NIST AI 100-2 E2025 document [55]. OWASP has published two complementary lists — AI/ML Top 10 and LLM Top 10 — that cover infrastructure and application risks together [56]. And Article 55 of the EU AI Act, with theCode of Practice for General-Purpose AI Modelsin consultation, introduces transparency obligations on training data and model behavior that will also apply to models intended for local use [57]. We are witnessing, in real time, the birth of onesupply chain discipline of AI models— it's young, it's fragmented, but it's already here.

An honest note: by naming it as dimension 12 — rather than placing it in Plane A of the vertical axes where it would logically belong — I am declaring that I amevaluating in real time. It is a dimension that I have seen emerging from the teams I work with in recent weeks, and which the literature is naming in still fragmented ways. In the book, when I have more data and more cases, I will probably bring it back to Plan A, near Cost, because it belongs there structurally.But I wanted the piece not to come out today without her.The dimensions that are emerging deserve to be named even when they are still infants.

---

What I take away, what I bring forward

Five things I take away from this passage.

The first is thatthere is not a single meterfor the Fourth Circle. There are fourteen dimensions, collected in three levels, and the value of an analysis lies in the ability toto integratemultiple dimensions at a time, not in the perfection of a single measurement.

The second is thatmaturity is a trajectory, not a photograph. The L0–L5 scale is used to orient yourself, but the real exercise is to draw theprofileof your organization and understand where to move first.

The third is thatthe scissors exist, and it must be addressed. It's not change management. It is an assessment axis, with its costs (the waste), its metrics (the posture map), its levers (culture, pair programming, recognition of senior knowledge as a common good).

The fourth is thatthe software professional of the future already exists. I see it in the teams I work on: they've stopped wondering“Will AI replace me?”and started wondering“How will I maintain the quality of what AI will do for me?”. The answer is the book I'm working on.

The fifth - and perhaps the most important - is a fact that serves as a warning. A 2025 MIT study found that95% of enterprise GenAI pilots generate no measurable return, and only 5% scale to production, out of a total of 30-40 billion dollars invested [41]. A survey of 3,000+ IBM leaders confirmed that“worker access to AI rose by 50% in 2025” but “only 34% of companies use AI to deeply transform business”, while the83% consider sovereign AI important for strategic planning[42]. Real maturity is still rare. The good news is that those who build it today have a few years' advantage on the market. The bad news is that those who put it off have no time to waste.

On exploras.cloud, in the coming months, I will share the pieces of the journey: after the threeAmbassadors, L 'Overture to Act IIIand the piece on thecustody of the human, this is thestarting mapof the new path. On LinkedIn I will post a shorter version of this text ascommentary on the Fourth Circle in production, followed in the following days by a question to my network:in which posture do you recognize yourself, and at what level of maturity do you see yourself?It's a question I need. It's a question that - if you want to answer me - will enter the book.

The Fourth Circle is no longer a line. It is a living object. And it needs, today more than ever, toconscious custodians.

- Mauro Giuliano

---