The new de facto operating model for Software Engineering

Almost forever, software engineering has been organized around the Software Development Lifecycle. Requirements, architecture, development, testing, security, release, and operations have provided the structure through which ideas become production systems. All of this still stands very relevant, I personally don’t think any of this will get outdated soon. SDLC has always evolved with time and I believe it’s time again…

In a way operating model of SDLC is up for a overhaul (SDLC still stays intact, it’s just the operating model)… let me explain my statement.

The pre-AI operating model was largely human-led lifecycle execution supported by tools. Then AI written code became a thing, the emerging model I belive is human - agent collaboration governed through continuous engineering loops and that changes the operating model intrinsically.

AI is no longer limited to helping developers write code faster. It is starting to participate in the control points of software engineering i.e. security review, test design, code quality, dependency health, release readiness, production diagnostics, documentation, and compliance evidence.

And this I think will become the de facto operating model in times to come, may large companies have already and deeply adopted this and are bearing the fruits of the seeds they planted, it is time for a mass movement across industry.

Based on convenience or liking one may call it new operating model or new execution pattern — I believe it is here to stay.

AI-assisted coding (…the visible layer)

Most conversations about AI in software engineering still begin with code generation. Code completion and AI pair programming emerged as the earliest high-visibility use cases, but there is much more to it.

You may have read a lot of articles already stating benefits of AI.

There is evidence that these tools can improve task-level productivity. A controlled Microsoft Research study on GitHub Copilot found that developers with access to Copilot completed a JavaScript programming task 55.8% faster than the control group. McKinsey also found meaningful time savings across common software engineering activities such as documentation, code generation, and refactoring, while noting that the gains vary by task complexity and developer experience.

All of above is true.

But, the shift really happens when when AI’s full potential is leveraged (unleashing part of potential is being addressed by frontier models as they evolve).

Question one will ask: “how should I leverage the full potential”… to answer we need to invest time, need to do a lot of introspection (of existing workflows) and sign up a mandate (to identify and adopt change). If your first impression is this is too much of an ask… you can start small, as they say “take baby steps”, start with a small team, prove that it works before you start thinking to scale (there should be no rush to talk widely till you have proven success in small setup).

You will be able to relate to this article further only if your teams have at least begun using IDE based copilot’s for prompt based improved interaction (thus code generation). You may go ahead with further reading at your risk if you haven’t reached this milestone.

Now that we have the basics right, we are good to go ahead together…

A prompt changes an interaction, agent changes the workflow

From SDLC stages to Engineering Loops

High-performing engineering is governed less by linear stages and more by feedback loops. The more mature the engineering organization, the faster these loops operate and the cleaner their signals become. I think of this emerging pattern as **loop engineering**. Actually loop engineering is next level of what I want to capture here, but thought to give credit to Addy for coining this term.

Loop engineering is the practice of designing software delivery around continuous feedback, automated evidence, agent-assisted analysis, and human decision-making. The unit of improvement is no longer just the developer task. It is the engineering loop.

With loop engineering, the unit of improvement is no longer just the developer task. It is the engineering loop. The better question is not: “How much faster can a developer write code?” but “How much faster can the engineering system detect, decide, correct, and learn”

Some of the examples of engineering loops (each phase/ stage of SDLC could be transitioned to an engineering loop of it’s own.. transition may not be the right word here as that is what it is even today, just that it is slow and manual and subject to human invocation)…

• Requirement feedback loop
• Architecture trade-off loop
• Code review loop
• Security feedback loop
• …

The more mature the engineering organization, the faster these loops operate and the cleaner their signals become.

This distinction is important because research is already showing that AI adoption is not automatically equivalent to organizational improvement. The 2025 DORA report describes AI as an amplifier: it can magnify both the strengths and weaknesses of an organization’s existing engineering system. DORA also reports that 90% of respondents use AI at work, more than 80% believe it has increased productivity, and yet 30% report little or no trust in AI-generated code.

From gates to loops

Software engineering has historically relied on gates, such as, Design review gate, Code review gate, Security review gate, QA gate, Release approval gate, Operational readiness gate.

These gates are necessary because engineering needs control points. But gates often show up late, and late feedback is expensive. The agentic model does not eliminate gates. It makes them better informed by continuous loops (and faster too!).

By leveraging loop engineering:

• A security gate becomes a security feedback loop;
• A QA gate becomes a test generation and validation loop;
• A release gate becomes a release readiness loop;
• An architecture review becomes a design risk loop;
• A production incident becomes an operational learning loop.

The operating model changes when feedback moves closer to the work (think shift left). Note the difference between two statements below…

“A vulnerability discovered late becomes a release risk.”

“A vulnerability discovered early becomes an engineering task.”

Feedback loops on a security gate helps realize latter and hence the productivity and measurable gain.

Feedback loops can be agentic in nature (they need not always be coded for). Agents create the most value where engineering work has three characteristics:

• The activity is repeated often
• The output requires structured analysis
• The result influences quality, risk, or speed

This is why agents are useful around engineering control points.

A concrete example: turning security review into a feedback loop

One of the agents I created focuses on security review. The agent scans code, identifies potential vulnerabilities, classifies findings, and generates a structured report with remediation recommendations. The important part is not simply that it finds issues. The important part is that it changes security review from a late-stage activity into an earlier, repeatable engineering loop.

Code change / Pull request
        ↓
Security scan agent
        ↓
Vulnerability detection
        ↓
Severity classification
        ↓
Fix recommendation
        ↓
Developer remediation
        ↓
Reviewer validation
        ↓
Pattern learning / rule tuning

The agent does not merely finds vulnerability, it goes deeper and finds the place where it is originating from (the occurrences) with an explanation of why it matters, it’s impact and how it can be fixed too!

As a next step “loop” here can be thought of a recursive goal where you define a purpose and the AI iterates until complete. In this case goal can be to reduce/ minimize (eventually eliminate) vulnerabilities (remember this is an ever evolving goal and a moving target — as new vulnerabilities emerge with time on same code base).

You may ask agent to produce an actionable structured report (see an example below)

Security Scan Report

Repository:
Branch / Pull Request:
Scan Date:
Application / Service:
Scan Scope:

Executive Summary:
- Total findings:
- Critical:
- High:
- Medium:
- Low:
- Informational:

Top Risks:
1.
2.
3.

Detailed Finding:

Finding ID:
Severity:
Category:
File:
Line Number:
Description:
Potential Impact:
Evidence:
Recommended Fix:
Suggested Test Case:
Reviewer Notes:
Status:

What this means for engineers

For engineers, the shift is not just learning how to use AI tools. The shift is learning how to operate in agent-assisted workflows.

And the key is “The best engineers in this model will not be those who blindly accept generated output”. They will be those who can frame better problems, validate faster, and improve the loops around them.

A well crafted engineering loop/ agent can quickly have multiplier effect, it can help create lean teams, shorter cycle time, quick turnaround to business, last but not the least happy customers!

That said it is important to evaluate… and transition

Manual control points -> control points that are agent-assisted.