DEV Community: Akash Lomas

SDLC to ADLC

Akash Lomas — Mon, 06 Jul 2026 05:01:42 +0000

Enterprise software development is undergoing a fundamental structural shift. For decades, the traditional Software Development Life Cycle (SDLC) relied on human engineers writing deterministic code. Today, code generation is increasingly shifted to autonomous AI agents.

According to the McKinsey State of AI report, 78 percent of organizations have integrated AI into at least one business function. This operational shift is mirrored at the developer level; the 2026 Stack Overflow Developer Survey indicates that 84 percent of engineers now utilize or plan to deploy AI tools.

For initial baseline tasks—such as boilerplate code, standard API integrations, and basic scaffolding—the efficiency gains remain clear. GitHub data shows that developers complete these isolated tasks 55 percent faster when utilizing basic AI coding assistants.

The Pull Request Bottleneck

The core complication stems from integrating high-velocity AI generation tools into legacy, human-centric review workflows. This structural mismatch has shifted the engineering bottleneck from code production to code verification.

Data from software delivery platform LinearB reveals that while organizations face a 2X or greater increase in pull request (PR) volume, net engineering productivity gains remain in the low double digits. Senior engineers now has to spend disproportionate time auditing vast volumes of AI-generated code rather than designing system architecture.

Furthermore, standard AI tools frequently fail during the "last 40 percent" of the development cycle, which includes complex system integration, scalability testing, and non-functional requirements.

Consequently, an Atlan study projects that over 40 percent of agentic AI initiatives will face cancellation by 2027 due to context gaps and inadequate methodology. McKinsey data confirms these execution failures, tracing them directly to:

A lack of clear specifications: 61 percent of failed implementations
Data quality issues: 55 percent
An absence of governance frameworks: 48 percent

The Scaling Dilemma

How can enterprise engineering organizations transition from isolated, developer-centric AI assistants to an operating model that scales autonomous execution without introducing architectural debt, overwhelming human reviewers, or incurring unsustainable inference costs?

Transitioning to the Agentic Development Life Cycle (ADLC)

The industry's emerging resolution is the Agentic Development Life Cycle (ADLC)—an architecture that replaces sequential human handoffs with multi-agent AI networks operating across a continuous layer of shared context. This structural shift eliminates legacy queues that traditionally consume 60 to 70 percent of a project’s calendar time.

The Core Framework Shifts

Role Reconfiguration: Engineers transition from line-by-line syntax writers to intent architects who define environmental boundaries, security constraints, and success criteria.
Specification-Driven Engineering: Teams utilize frameworks like SPARC (Situation, Problem, Action, Result, Constraints). Because agents execute exactly what is specified, precision in the initial product requirement document dictates output quality.
Distribution-Based Evaluation: Because agent outputs are probabilistic rather than deterministic, traditional binary pass/fail testing is replaced by automated evaluation harnesses that measure code quality consistency across thousands of parallel simulations.

Adoption Patterns and Market Realities

The corporate landscape is currently divided between AI-native startups and legacy incumbents retrofitting their workflows. Gartner and McKinsey data indicates that early adopters are deploying parallel sub-agents to manage testing, build infrastructure, and automate canary deployments.

However, systemic execution remains rare. McKinsey notes that only 6 percent of organizations qualify as AI "high performers" (deriving over 5 percent of EBIT from AI). These leaders are three times more likely to have fundamentally re-engineered their operational workflows rather than simply adding tools to legacy SDLC structures.

The Operational Balance Sheet

The Targeted ROI

Compressed Time-to-Market: ADLC delivery teams compress traditional 4-to-6-month MVP timelines down to 6 to 8 weeks, representing a 60 percent reduction in overall calendar time.
Direct Cost Reduction: Full agentic integration lowers total project expenses by 40 to 65 percent, driven by a 75 percent reduction in manual coding time.
Early Defect Prevention: Generating automated test scripts directly from the requirements stage makes defect remediation 5X to 10X cheaper than fixing bugs during post-development QA.

The Accompanying Risks

Novel Governance Hazards: McKinsey reports that 12 percent of AI agent deployments introduce entirely new technical risks, including recursive execution loops, prompt injections, and authorization drift.
Logic Inaccuracy: Code hallucinations remain a persistent factor, with 33 percent of enterprise AI users experiencing logic errors that bypassed unguided agent systems.
Escalating Inference Costs: Multi-agent cognitive loops significantly increase token consumption, risking budget overruns comparable to early cloud migration miscalculations.
Regulatory Compliance: Under frameworks like the EU AI Act, companies must maintain a 100 percent auditable trail of an agent's reasoning steps, tool interactions, and data origins.

** What is your opinion on this? **

Architectural Collapse: How Extension Poisoning, Node Vulnerabilities, and Infrastructure Fog Enabled the GitHub Repository Breach

Akash Lomas — Mon, 25 May 2026 07:22:24 +0000

Enterprise perimeter defenses are fundamentally built on an obsolete assumption that, the developer's workstation is a secure, trusted anchor point. The massive security breach executed by the threat group TeamPCP, resulting in the exfiltration of 3,800 internal GitHub source code repositories, completely shattered this illusion.

This was not a standalone exploit. It was a multi-vector convergence where vulnerabilities in the Node/NPM ecosystem, the systemic ungoverned architecture of the Visual Studio Code Marketplace, and the tactical "fog of war" caused by a period of historic GitHub infrastructure instability came together to create the perfect attack.

Phase 1: The Root Exploitation (Node/NPM and the TanStack Supply Chain Pivot)

The kill chain did not begin at GitHub, it originated deep within the modern JavaScript developer tool-chain. TeamPCP executed a localized supply chain compromise targeting upstream open-source utilities, specifically targeting contributors to TanStack npm packages (a widely relied-upon suite for state management and routing).

[TanStack NPM Compromise] 
          │
          ▼
[Stolen 'gh' CLI Tokens] 
          │
          ▼
[Nx Console Pipeline Hijack (No Multi-Admin Approval)]
          │
          ▼
[Malicious Extension Version 18.95.0 Published]

By injecting malicious code into these highly trusted downstream dependencies, the attackers performed targeted local credential harvesting. Their primary target was not production application code, but the development environments of the maintainers themselves.

The exploit successfully extracted long-lived GitHub CLI (gh) authentication tokens from a legitimate core developer who maintained both TanStack and the Nx Console ecosystem. Because these developer access tokens lacked granular scoping restrictions, they provided direct administrative write access to the main release pipelines of secondary repositories.

Phase 2: VS Code Extension Poisoning (The Nx Console Triage (CVE-2026-48027))

Armed with the stolen gh tokens, TeamPCP bypassed standard perimeter security by pivoting to the Visual Studio Marketplace. On May 18, version 18.95.0 of Nx Console (a heavily utilized Monorepo orchestration extension with over 2.2 million installs) was maliciously built and uploaded.

The deployment revealed two fatal flaws within modern developer workflows,

1. The Single-Factor Release Pipeline

The malicious version was uploaded directly to both the Visual Studio Marketplace and the open-source OpenVSX registry. Because the Nx Console publishing architecture lacked a "two-admin manual validation mandate" for automated releases, the publishing pipeline accepted the stolen developer token at face value without triggering a secondary verification gate.

2. The "Silent Killer": Marketplace Metrics vs. Background Sync

Microsoft’s public marketplace logs initially registered a negligible 28 manual downloads before the package was identified and yanked 18 minutes later. However, Nx's internal telemetry revealed that ~6,000 extension activation's occurred simultaneously.

This massive discrepancy highlights the danger of VS Code's background auto-update synchronization. Thousands of developer environments pulled down, unzipped, and executed the malicious version automatically while the developers' IDEs were running in the background.

// Example of the target parameters within compromised developer workspaces
{
  "extensions.autoUpdate": true, // The default vulnerability exploited by TeamPCP
  "terminal.integrated.profiles.osx": {
    "malicious-hook": {
      "path": "/bin/bash",
      "args": ["-c", "python3 ~/.local/share/kitty/cat.py &"]
    }
  }
}

The Node Execution Layer

Upon extension activation, the poisoned payload immediately dropped an obfuscated Node.js post-install hook. Operating completely within user space to evade basic Endpoint Detection and Response (EDR) behavioral hooks, it set an environmental marker (__DAEMONIZED=1) and spawned a background Python process (cat.py).

The malware systemically scanned local paths for,

Infrastructure Configuration: Plaintext HashiCorp Vault tokens (~/.vault-token), local Kubernetes kubeconfig files, and AWS/Azure IAM metadata endpoint hashes.
Ecosystem Identity: Plaintext .npmrc registry tokens and active GitHub tokens (ghp_, gho_, ghs_).
Active Memory Subsystems: Contents of 1Password vaults via the op CLI by hijacking active, unlocked terminal sessions.

Phase 3: The Climax (The Internal GitHub Breach)

The payload achieved its ultimate goal when an internal GitHub software engineer, who utilized Nx Console for local workflow management, had their workstation pull down the background update.

The malware executed on the engineer's local machine, scraped their active internal enterprise session tokens, and exfiltrated them to a remote command-and-control (C2) server. TeamPCP then used these highly privileged internal access credentials to bypass GitHub's corporate identity perimeters entirely.

Because internal repository boundaries operate on flat network access structures once an authenticated developer endpoint is cleared, the threat actors systematically cloned and exfiltrated 3,800 proprietary internal GitHub source code repositories before the endpoint could be isolated.

Phase 4: The Tactical Fog of War (GitHub's Infrastructure Instability)

The velocity and stealth of this attack were significantly aided by an ongoing reliability crisis within GitHub’s core infrastructure. During the 12-month window surrounding the breach, GitHub recorded a massive spike in service degradation.

Total Tracked Incidents: 257 distinct technical incidents.
Major Outages: 48 major service shutdowns, totaling 112 hours and 18 minutes of total downtime.
Primary Failure Vector: GitHub Actions experienced 57 outages—three times the incidence rate of core Git storage operations.

Outage Date	Primary Root Cause	Security Alert Fallout
October 29	Outage in compute dependency (Microsoft Azure), 90% error rate across Codespaces/ Actions.	Telemetry gaps, security monitoring systems failed to track cross-border API token replication.
February 2	Configuration failure in user settings caching, cascading failures in the Git HTTPS proxy.	High volume of synchronous cache writes generated a deluge of network errors, masking anomalous Git clone calls.
February 12	Authorization claim changes in core networking dependencies,, 90% Codespace provisioning failure.	Security alerts failed to populate due to misclassified severity ratings, delaying incident detection by hours.

The Alert Fatigue Vulnerability

This constant infrastructural noise created an ideal tactical environment for the attackers. SecOps and DevSecOps teams were caught in a continuous state of alert fatigue dealing with broken GitHub Actions pipelines, Elasticsearch cluster degradation, and database timeouts.

When TeamPCP’s automated scripts began running rapid API queries and pulling massive volumes of repository data using the compromised engineer's token, the unusual spikes in data transfer blended into the background noise of an infrastructure already struggling with systemic capacity and networking failures.

Hard Takeaways: How Developers Must Harden Their Environments

If your environment was active or using automated tools during this period, you must shift your development machine from an implied trust zone to a completely zero-trust environment.

1. Kill IDE Auto-Updates Globally

Never allow your IDE to pull un-vetted code in the background. Explicitly configure your editor to require manual permission before updating any third-party extension.

In VS Code's global settings.json, enforce:

"extensions.autoUpdate": false,
"extensions.autoCheckUpdates": false

2. Isolate Development Runtimes

Stop running compilers, package managers, and complex IDE extensions directly on your bare-metal operating system.

Utilize isolated, ephemeral development environments (e.g., containerized Dev containers or heavily scoped virtual environments) where local file-system access is completely decoupled from your master ~/.ssh/, ~/.aws/, or .npmrc configuration folders.

3. Implement Strict Token Volatility

Eliminate long-lived personal access tokens (ghp_). Switch entirely to fine-grained personal access tokens configured with strict, single-repository scope constraints and maximum 7-day expiration dates.
Explicitly configure your local password managers and authentication tools to require biological verification (e.g., TouchID/FaceID) or short timeout windows for every individual call executed via the terminal command line (op signin --timeout).

Moving Beyond MediatR: Implementing Cross-Cutting Concerns with Native .NET Dependency Injection

Akash Lomas — Fri, 22 May 2026 03:45:18 +0000

For years, the MediatR package has been a default inclusion in almost every new .NET project template. It is frequently hailed as the gold standard for decoupling controllers or minimal APIs from business logic and implementing Clean Architecture or CQRS patterns.

However, as ASP.NET Core has matured, many of the architectural justifications for adding MediatR as a heavy third-party dependency have faded. If you are building standard CRUD or even moderately complex enterprise APIs, it might be time to ask yourself,

Why am I routing my HTTP requests through an abstract in-memory bus when native alternatives exist?

Let’s explore why MediatR might be an unnecessary abstraction in your codebase and how you can replace its most beloved feature Pipeline Behaviors using pure .NET Dependency Injection (DI) plumbing and the Decorator pattern.

The Core Critique of MediatR

While MediatR provides an elegant mechanism for decoupling, it introduces specific friction points into a code-base,

Obfuscated Control Flow: Because handlers are resolved dynamically, it is impossible to use standard “Go to Definition” (F12) in your IDE to trace execution directly from an endpoint to its handler. You are forced to search for the corresponding IRequestHandler type implementation.
Debugging Overhead: Stepping through code becomes a tedious exercise of bypassing internal library code generator stacks instead of moving sequentially through your business logic.
Unnecessary Architecture: In standard Web APIs, the mapping between an endpoint and its handler is almost always 1:1. Introducing a mediator pattern for a direct request-response cycle over complicates the system with minimal structural payback.

If you are using Minimal APIs or standard Controllers, you already have powerful endpoint routing. So why use MediatR? The answer almost always boils down to one critical feature, Pipeline Behaviors.

The “Killer Feature”: Cross-Cutting Concerns

Developers love MediatR because it makes addressing cross-cutting concerns, such as centralized logging, validation pipelines (e.g., using FluentValidation), metrics collection, and OpenTelemetry tracking incredibly clean.

Instead of cluttering every single business handler with repetitive try-catch blocks or explicit validation calls, MediatR lets you define a generic middleware pipeline around your requests:

// The classic MediatR approach
builder.Services.AddMediatR(cfg => {
    cfg.RegisterServicesFromAssembly(typeof(Program).Assembly);
    cfg.AddOpenBehavior(typeof(LoggingBehavior<,>));
    cfg.AddOpenBehavior(typeof(ValidationBehavior<,>));
});

It is a fantastic architectural model, but you do not need a third-party package to achieve it. Modern .NET allows you to implement this exact pattern natively using compile-time type-safe decorators.

The Native Alternative: DI-Based Decoration

Instead of an abstract pipeline behavior model, we can leverage the Decorator Pattern natively supported by the Microsoft.Extensions.DependencyInjection container. This allows us to transparently wrap any standard interface registration with cross-cutting behaviors.

Defining a Domain-Driven Request Handler Interface

First, let’s establish our own lightweight, explicit handler contract. This preserves your CQRS separation without binding your domain to external packages.

public interface IRequestHandler<in TRequest, TResponse>
{
    Task<TResponse> HandleAsync(TRequest request, CancellationToken cancellationToken = default);
}

Creating a Concrete Business Handler

Your concrete query or command handlers remain pristine. They are entirely unaware of logging, telemetry, or validation logic, adhering perfectly to the Single Responsibility Principle.

public record CreateProductCommand(string Name, decimal Price) : IRequest;

public class CreateProductHandler : IRequestHandler<CreateProductCommand, Guid>
{
    private readonly IProductRepository _repository;

    public CreateProductHandler(IProductRepository repository)
    {
        _repository = repository;
    }

    public async Task<Guid> HandleAsync
      (  CreateProductCommand request, 
         CancellationToken cancellationToken = default)
    {
        var id = Guid.NewGuid();
        // Core business logic goes here...
        return id;
    }
}

Implementing the Cross-Cutting Decorator

Now, let’s implement a generic decorator that intercepts the request execution. It implements the same interface but accepts the inner concrete handler as a dependency, wrapping it with infrastructure logic.

public class LoggingHandlerDecorator<TRequest, TResponse> : IRequestHandler<TRequest, TResponse>
{
    private readonly IRequestHandler<TRequest, TResponse> _inner;
    private readonly ILogger<LoggingHandlerDecorator<TRequest, TResponse>> _logger;

    public LoggingHandlerDecorator(
        IRequestHandler<TRequest, TResponse> inner, 
        ILogger<LoggingHandlerDecorator<TRequest, TResponse>> logger)
    {
        _inner = inner;
        _logger = logger;
    }

    public async Task<TResponse> HandleAsync
      (TRequest request, CancellationToken cancellationToken = default)
    {
        var requestName = typeof(TRequest).Name;
        _logger.LogInformation("Executing request: {RequestName}", requestName);

        try
        {
            var response = await _inner.HandleAsync(request, cancellationToken);
            _logger.LogInformation("Successfully executed request: {RequestName}", requestName);
            return response;
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Request failed: {RequestName}", requestName);
            throw;
        }
    }
}

Wiring It Together Natively in Program.cs

To register these decorators without external help, we can write a clean extension method using the native DI container’s service factory capabilities. This gives us full architectural control over which handlers get decorated and in what order.

public static class RequestHandlerRegistrationExtensions
{
    public static IServiceCollection AddDecoratedRequestHandler<TRequest, TResponse, THandler>(
        this IServiceCollection services) 
        where THandler : class, IRequestHandler<TRequest, TResponse>
    {
        // 1. Register the concrete handler with its own concrete type
        services.AddTransient<THandler>();

        // 2. Register the interface using a factory method that constructs the decorator chain
        services.AddTransient<IRequestHandler<TRequest, TResponse>>(sp =>
        {
            var concreteHandler = sp.GetRequiredService<THandler>();
            var logger = sp.GetRequiredService<ILogger<LoggingHandlerDecorator<TRequest, TResponse>>>();

            // Wrap the core handler with our logging decorator
            return new LoggingHandlerDecorator<TRequest, TResponse>(concreteHandler, logger);
        });

        return services;
    }
}

Pro-Tip: If manual registration feels too verbose for thousands of handlers, you can use assembly scanning utilities like Scrutor to dynamically apply the .Decorate() method across your entire service collection automatically.

Your application endpoints remain perfectly clean, directly consuming the generic interface via native dependency injection:

app.MapPost("/products", async (
    CreateProductCommand command, 
    IRequestHandler<CreateProductCommand, Guid> handler) =>
{
    var result = await handler.HandleAsync(command);
    return Results.Ok(result);
});

Architectural Advantages

By shifting from an in-memory mediator library to native DI decoration, you unlock major engineering benefits:

No Black Boxes: Your execution pathway is clear. If you place a breakpoint inside your API endpoint and step into handler.HandleAsync(), you will sequentially enter the LoggingDecorator, step through any validation layers, and land cleanly inside your actual business logic handler.
Zero Third-Party Vendor Lock-in: Your core business logic blocks do not depend on external packages. Upgrading your framework version will never be delayed due to a breaking change in an open-source messaging mediator.
Granular Structural Control: Unlike globally forced middleware pipelines, you can explicitly choose which command or query handlers receive specific decorators. If a high-throughput endpoint requires raw performance without validation overhead, you can register it without its decorator wrap.

Summary

MediatR has served the .NET community exceptionally well over the last decade. However, frameworks evolve. With modern ASP.NET Core DI plumbing, we can maintain clean separation of concerns, enforce CQRS principles, and leverage pipeline behaviors seamlessly using standard patterns built straight into the runtime.

Evaluate your current architecture.

Is MediatR solving a foundational problem for you, or is it merely acting as boilerplate code that your native framework can already handle?