DEV Community: Eva Clari

Repo-Aware Agents: How Persistent Codebase Memory Changes What AI Can Refactor

Eva Clari — Tue, 29 Sep 2026 10:19:37 +0000

AI-powered coding tools are changing how developers write, review, and maintain software. From generating boilerplate code to fixing bugs and suggesting optimizations, AI assistants have become valuable parts of modern development workflows. However, one challenge remains: understanding the entire codebase rather than treating every coding task as an isolated request.

This is where repo-aware agents and persistent codebase memory come into play.

Instead of simply responding to the code currently visible in a prompt, repo-aware agents aim to understand a repository's architecture, dependencies, coding conventions, historical decisions, and existing implementation patterns. By retaining useful context across multiple tasks, these agents can make more informed decisions about what to refactor, how to implement changes, and which parts of a system should remain untouched.

For development teams working with large, complex repositories, this approach could significantly change how AI-assisted refactoring works.

What Are Repo-Aware Agents?

Repo-aware agents are AI systems designed to work with a software repository as a connected environment rather than a collection of independent files.

Traditional AI coding assistants often rely on the immediate prompt, selected files, or a limited context window. While this works well for straightforward tasks, it becomes less effective when a change requires understanding relationships across multiple modules, services, configuration files, and tests.

Repo-aware agents attempt to bridge this gap by collecting and retrieving relevant information about the codebase.

Their capabilities may include:

Understanding relationships between files, modules, and functions.
Identifying dependencies and potential side effects.
Recognizing established coding conventions and architectural patterns.
Retrieving information from previous development tasks.
Using test results and repository history to guide modifications.
Identifying areas of technical debt and potential refactoring opportunities.

For example, consider a developer asking an AI agent to refactor an authentication service. A basic coding assistant might focus on the selected authentication file. A repo-aware agent could also investigate how authentication tokens are validated, which services depend on the existing implementation, how errors are handled, and which tests cover related behavior.

This broader understanding helps the agent evaluate a proposed change within the context of the entire system.

Why Persistent Codebase Memory Matters

A repository can contain years of development decisions, workarounds, architectural compromises, and undocumented assumptions. Developers who have worked on a project for months gradually build an understanding of these details. An AI assistant that starts every task with limited context must repeatedly rediscover them.

Persistent codebase memory attempts to solve this problem.

Rather than relying exclusively on the current conversation, an agent can maintain or retrieve useful information about the repository across multiple interactions. Depending on the implementation, this memory may include architectural summaries, dependency relationships, previous debugging findings, coding standards, or explanations of why specific design decisions were made.

1. Maintaining Architectural Context

Large applications rarely operate as isolated components. A change to a database model might affect API responses, background jobs, validation logic, and frontend components.

Persistent memory can help an agent recognize these relationships before proposing a modification.

For instance, if a developer requests a change to a customer data model, the agent may identify relevant API endpoints, serialization logic, database migrations, and integration tests. This reduces the likelihood of making a locally correct change that creates problems elsewhere.

2. Remembering Previous Decisions

Not every unusual implementation is accidental technical debt.

A codebase might contain a specific caching strategy because of infrastructure limitations, a custom retry mechanism because of an unreliable external service, or a legacy interface that must remain compatible with existing customers.

Without this context, an AI agent could recommend a seemingly cleaner implementation that breaks an important requirement.

Persistent memory can preserve explanations of these decisions, allowing the agent to distinguish between code that needs improvement and code that exists for a valid reason.

3. Reducing Repeated Investigation

Developers frequently investigate the same areas of a repository while fixing related bugs or implementing similar features.

An agent that can retrieve previous findings may avoid repeating expensive exploration. Instead, it can use earlier dependency maps, test discoveries, and architectural notes to focus on the current task.

The benefit is not simply faster code generation. It is a more efficient development process in which the agent spends less effort rediscovering context and more effort evaluating solutions.

How Repo-Aware Agents Change Refactoring

Refactoring involves improving a system's internal structure without changing its externally observable behavior. This requires more than generating syntactically correct code. It requires understanding dependencies, preserving contracts, and validating assumptions.

Persistent repository memory can influence several stages of the refactoring process.

Understanding the Impact of Changes

Before modifying a function, an agent needs to understand how that function is used.

A repository-aware workflow can examine callers, related modules, interface contracts, test coverage, and dependency relationships. With persistent memory, the agent may also retrieve previously identified integration points or compatibility requirements.

This broader context can help determine whether a proposed refactor should remain local or requires coordinated changes across several components.

Recognizing Repeated Patterns

As repositories grow, similar functionality often appears in multiple places. Error handling, authentication checks, logging, validation, and data transformation may be implemented differently across modules.

A repo-aware agent can search for these patterns and identify opportunities to consolidate duplicated logic.

For example, imagine that five API endpoints implement slightly different versions of the same input-validation procedure. The agent could identify the common behavior, examine the differences, and propose a shared validation utility.

However, consolidation should not be automatic. Some differences may reflect distinct business rules. Repository context helps the agent investigate those differences before recommending a shared implementation.

Preserving Existing Behavior

One of the biggest risks in automated refactoring is unintentionally changing behavior that existing users or services depend on.

Persistent memory can help an agent identify relevant assumptions, compatibility constraints, and previously encountered edge cases. Combined with automated tests and static analysis, this information can improve the quality of its recommendations.

Still, memory alone cannot guarantee correctness. Every significant refactor requires validation through tests, code review, and, where appropriate, integration or performance testing.

Supporting Multi-Step Refactoring

Some refactoring projects cannot be completed safely in a single operation.

A team might need to separate a tightly coupled module into smaller components, replace an outdated library, or gradually migrate an application to a new architecture.

These changes require the agent to understand earlier modifications and maintain a consistent direction across multiple tasks.

Persistent memory can provide continuity by recording completed steps, unresolved issues, architectural decisions, and the remaining migration work. This makes it easier to approach refactoring as a sequence of coordinated changes rather than unrelated code-generation requests.

How Persistent Memory Works in Practice

Repo-aware agents can implement persistent memory through several complementary techniques.

Repository indexing: Source files, symbols, documentation, and dependency relationships are indexed to help retrieve relevant context.

Semantic retrieval: Embedding-based search can locate conceptually related code even when the exact keywords are unknown.

Symbol and dependency analysis: Abstract syntax trees, language servers, and static analysis tools can identify definitions, references, imports, and call relationships.

Repository history: Commit messages, pull requests, and change history can provide clues about why code evolved in a particular direction.

Structured memory: The agent may retain concise architectural summaries, important constraints, coding conventions, and findings from earlier tasks.

Validation feedback: Test failures, linting results, and build errors can help guide subsequent changes.

These techniques serve different purposes. Semantic search helps discover relevant information, while static analysis provides more precise structural relationships. Repository history supplies historical context, and structured memory helps preserve knowledge that may not be obvious from the current source code.

A reliable implementation combines these sources instead of treating any single retrieval mechanism as sufficient.

For teams exploring the broader ecosystem, understanding AI agent frameworks and their capabilities can provide useful context for evaluating the tools, orchestration patterns, and architectural approaches used to build intelligent development agents.

A Practical Example: Refactoring a Legacy Service

Consider an e-commerce application with a legacy order-processing service.

Over several years, the service has accumulated duplicated validation logic, tightly coupled payment operations, and inconsistent error handling. The team wants to separate payment processing from order management without disrupting existing transactions.

A basic AI assistant might receive the service file and generate a cleaner implementation. Although the result could look well structured, it might overlook background workers, webhook handlers, database transactions, or external integrations.

A repo-aware agent could approach the same task differently.

Step 1: Map the existing architecture

The agent identifies the order-processing module, payment gateway integration, database models, API endpoints, event handlers, and relevant tests.

Step 2: Retrieve historical context

It examines available documentation, commit history, and previously recorded design decisions to understand compatibility requirements and known edge cases.

Step 3: Identify refactoring opportunities

The agent identifies duplicated validation logic and responsibilities that could be separated into smaller modules. It also distinguishes between shared behavior and logic that must remain specific to certain payment methods.

Step 4: Propose a staged implementation

Instead of rewriting the entire service, the agent recommends introducing a payment interface, extracting validation into a dedicated component, and migrating individual call sites incrementally.

Step 5: Validate the changes

The agent runs or recommends relevant unit tests, integration tests, and static checks. Failures are investigated before additional changes are introduced.

Step 6: Update repository knowledge

The implementation notes, new architectural boundaries, and remaining migration tasks can be recorded for future work.

The key difference is that the agent works toward a repository-level objective while accounting for dependencies and previous decisions. It is not merely rewriting a file; it is helping manage a controlled architectural change.

The Risks of Persistent Codebase Memory

Persistent memory introduces new challenges alongside its benefits. Development teams should understand these limitations before relying on it for complex changes.

Outdated Information

Codebases evolve constantly. A stored dependency map or architectural summary can become inaccurate after a major refactor.

Agents should verify remembered information against the current repository rather than treating historical notes as authoritative. Memory should have clear update rules, and important facts should include references to the relevant files or commits.

Incorrect Assumptions

An agent might interpret an old implementation decision as a permanent requirement, even when the original constraint no longer applies.

For this reason, remembered context should be treated as evidence to investigate, not an instruction that overrides the current source code, tests, or explicit developer requirements.

Context Overload

Storing everything is not necessarily useful. Large collections of outdated notes, redundant summaries, and unrelated implementation details can make retrieval less effective.

A practical memory system should prioritize information according to relevance, freshness, confidence, and the current task.

Security and Privacy

Repositories may contain proprietary algorithms, internal architecture details, customer information, or accidentally committed credentials.

Organizations should establish clear policies for what can be indexed, where memory is stored, how access is controlled, and whether information can be shared across projects. Secrets should never be retained as ordinary contextual memory, and sensitive data should be handled according to organizational security requirements.

Overconfidence in Automated Changes

An agent that remembers many repository details can appear more reliable than it actually is. Yet comprehensive context does not eliminate reasoning errors, incomplete tests, or incorrect assumptions.

Developers should retain control over high-impact changes, review generated diffs, and use automated validation before merging modifications.

Best Practices for Implementing Repo-Aware Agents

Organizations introducing persistent codebase memory should start with a focused, measurable implementation rather than attempting to automate every development activity at once.

Start with read-only analysis. Allow the agent to map architecture, explain dependencies, identify duplicated code, and suggest refactoring opportunities before granting write access.

Establish trusted information sources. Prioritize the current source code, build configuration, tests, and maintained documentation. Use historical records to explain context, not to override current implementation evidence.

Keep memory traceable. Architectural notes should point to relevant files, symbols, tests, or commits whenever possible. This makes it easier for developers to verify conclusions.

Use incremental changes. Break large refactoring projects into smaller modifications that can be independently reviewed, tested, and reverted.

Define clear approval boundaries. Require human review for changes involving authentication, authorization, database migrations, financial transactions, public APIs, and other sensitive functionality.

Measure results. Track review time, test failure rates, regression frequency, repeated investigation, and the number of changes accepted with minimal rework. These measures can help determine whether persistent memory is delivering practical value.

Refresh knowledge regularly. Update or invalidate stored information when dependencies, interfaces, architectural boundaries, or major implementation decisions change.

The objective is to make repository context more accessible without sacrificing transparency or developer control.

What This Means for the Future of AI-Assisted Development

The evolution of AI coding tools is moving beyond isolated code completion toward systems capable of handling broader software engineering workflows.

Repo-aware agents represent one part of this shift. By combining repository indexing, persistent memory, dependency analysis, and automated validation, they can support more context-sensitive development activities.

Their potential value is particularly relevant to large organizations maintaining multiple services, long-lived applications, and complex dependency chains. In these environments, understanding why code exists can be just as important as understanding what the code does.

However, persistent memory should not be confused with complete understanding. A repository may have undocumented requirements, hidden production dependencies, or behaviors that automated tests do not cover. Even a well-designed agent needs reliable evidence, appropriate permissions, and human oversight.

The most useful approach is to treat repo-aware agents as collaborators that improve access to engineering knowledge, help developers explore alternatives, and support safer incremental changes.

Conclusion

Persistent codebase memory changes the possibilities for AI-assisted refactoring by giving agents a way to retain and retrieve relevant knowledge across development tasks.

Instead of repeatedly analyzing the same files from scratch, repo-aware agents can use architectural context, dependency relationships, historical decisions, and previous validation results to make better-informed proposals.

The greatest benefit comes when this memory is combined with accurate repository analysis, automated testing, transparent reasoning, and developer review.

For engineering teams, the goal is not to let AI refactor everything independently. It is to build workflows in which AI can understand more of the system, identify meaningful improvements, and help developers make changes with greater context and control.

As these capabilities mature, persistent repository memory may become an important part of how development teams manage technical debt, maintain legacy applications, and approach large-scale software modernization.

Platform Engineering in 2026: Building the Internal Developer Platform Your AI Agents Actually Need

Eva Clari — Tue, 22 Sep 2026 05:56:02 +0000

An in-depth DEV.to article about platform engineering, AI-powered development, and designing internal developer platforms for the next generation of software teams.

As software development continues to evolve, AI agents are becoming more than coding assistants. They can generate code, troubleshoot errors, create pull requests, manage infrastructure tasks, and participate in complex software delivery workflows.

But there's a growing challenge that many engineering teams are beginning to recognize: AI agents are only as effective as the platforms, tools, and guardrails that support them.

Giving an AI agent access to a code repository isn't the same as giving it the ability to safely deliver production-ready software. Without reliable environments, standardized workflows, observability, permissions, and deployment controls, AI-driven development can create as many operational challenges as it solves.

This is where platform engineering in 2026 becomes increasingly important.

Internal Developer Platforms (IDPs) are evolving from systems designed primarily to improve developer experience into intelligent infrastructure foundations that support both human developers and autonomous AI agents.

The question is no longer just, "How can we make developers more productive?"

It's also:

How do we build an internal developer platform that enables AI agents to work effectively, securely, and reliably across the software delivery lifecycle?

Let's explore what modern platform engineering needs to look like, the architectural components required, and how organizations can prepare their internal platforms for AI-assisted and agent-driven development.

What Is Platform Engineering in 2026?

Platform engineering is the practice of designing and maintaining internal platforms that provide developers with self-service tools, standardized infrastructure, deployment capabilities, and operational workflows.

The goal is to reduce unnecessary complexity by allowing development teams to consume infrastructure and delivery capabilities without having to manage every underlying system manually.

In 2026, this concept is expanding to include AI agents as active participants in engineering workflows.

Traditional internal developer platforms often focus on capabilities such as:

Self-service application deployment
Infrastructure provisioning
CI/CD automation
Kubernetes management
Observability and monitoring
Security and compliance controls
Developer portals and service catalogs

An AI-ready platform needs to extend these capabilities with additional considerations:

Machine-readable interfaces for AI agents
Clearly defined permissions and access boundaries
Reliable development and testing environments
Structured operational feedback
Automated validation and policy enforcement
Traceability for agent-generated changes
Controlled access to production systems

The underlying objective remains the same: reduce cognitive load and improve engineering efficiency. However, the platform must now serve different types of users, including developers, automation systems, and AI agents.

Why AI Agents Change Platform Engineering

A human developer typically understands organizational processes, asks questions when uncertain, and can make contextual judgments about a task.

An AI agent may perform multiple steps independently, interact with tools, and respond to feedback generated by the environment. Its effectiveness depends heavily on the quality of the interfaces and constraints provided by the platform.

For example, an AI agent tasked with deploying a microservice may need to:

Understand the service's architecture.
Identify the correct deployment environment.
Retrieve approved configuration.
Build and test the application.
Scan the resulting artifacts.
Request or execute deployment through authorized workflows.
Verify service health.
Report the deployment outcome.

If every step requires navigating inconsistent tools, undocumented processes, or ambiguous permissions, the agent will struggle to complete the task reliably.

An effective AI-ready IDP turns infrastructure and engineering workflows into discoverable, structured, and controllable capabilities.

1. The Foundation of an AI-Ready Internal Developer Platform

Before introducing AI agents into engineering workflows, organizations need to establish a reliable platform foundation.

An IDP should not simply provide access to a collection of tools. It should create a consistent experience for building, testing, deploying, and operating software.

For AI agents, this means making platform capabilities accessible through predictable interfaces and well-defined workflows.

Core Components of an AI-Ready IDP

Developer Portal

A centralized interface for discovering services, documentation, templates, ownership, and platform capabilities.

Workflow Automation

Standardized processes for application creation, builds, testing, deployment, and infrastructure provisioning.

Security and Governance

Identity, authorization, policy enforcement, secrets management, and approval controls.

Observability

Logs, metrics, traces, deployment status, and structured feedback that support operational decisions.

Agent Integration Layer

Controlled interfaces that allow AI agents to discover capabilities and invoke approved platform actions.

The platform should make these components work together rather than forcing developers and AI agents to integrate each capability independently.

2. Treat Platform Capabilities as Products, Not Just Infrastructure

One of the most important principles of platform engineering is to treat the internal platform as a product.

This means understanding the needs of its users, providing a consistent experience, collecting feedback, and continuously improving the platform.

With AI agents, the definition of a platform user becomes broader.

The platform may serve:

Application developers
Site Reliability Engineers (SREs)
Security teams
Data engineers
AI coding agents
Autonomous troubleshooting workflows
Automated release and maintenance systems

Each user type interacts with the platform differently.

A developer might use a self-service portal to create a service. An AI agent might need to query the service catalog, identify a deployment template, run tests, and submit a change through an approved workflow.

If the platform is designed only for human interaction, agents may have difficulty navigating it efficiently.

Make the Platform Discoverable

AI agents need context to determine which actions are appropriate.

Consider a platform that exposes the following capabilities:

create_service
deploy_service
run_tests
get_deployment_status
rollback_deployment

Simply listing these actions isn't enough. The agent also needs information such as:

What does each action do?
What inputs are required?
Which environments are supported?
What permissions are necessary?
What validation rules apply?
What does the output mean?
What happens when an action fails?

A well-designed platform provides structured metadata and documentation that reduce ambiguity.

For example:

JSON

{
  "name": "deploy_service",
  "description": "Deploy an approved service artifact",
  "inputs": {
    "service": "string",
    "environment": "string",
    "artifact": "string"
  },
  "constraints": {
    "allowed_environments": [
      "development",
      "staging"
    ],
    "requires_approval_for": [
      "production"
    ]
  }
}

This is an illustrative interface, not a complete security mechanism. The actual authorization decision must be enforced by trusted platform services rather than by instructions presented to the agent.

The principle is simple: agents should discover what they can do, but the platform must decide what they are allowed to do.

3. Build a Golden Path for AI-Assisted Development

A golden path is a recommended, repeatable workflow that helps developers build and deploy software using established engineering standards.

For example, a platform might provide a golden path for deploying a Python API:

Select an approved application template.
Create a repository.
Configure service ownership.
Provision a development environment.
Run automated tests.
Build a container image.
Scan dependencies and artifacts.
Deploy to a non-production environment.
Validate application health.
Promote through the approved release process.

The benefit is consistency. Developers do not need to design every workflow from scratch.

AI agents can use the same golden paths to perform tasks while adhering to organizational requirements.

Golden Paths Should Be Machine-Readable

Documentation written exclusively for humans can be difficult for agents to consume reliably.

Instead, platforms should expose structured workflow definitions, API contracts, templates, and validation rules.

A golden path could be represented as:

YAML

name: python-api-service
version: "1.0"

steps:
  - name: create_repository
    action: repository.create

  - name: configure_ci
    action: pipeline.configure

  - name: run_tests
    action: test.execute

  - name: build_artifact
    action: artifact.build

  - name: security_scan
    action: security.scan

  - name: deploy_staging
    action: deployment.staging

  - name: verify_health
    action: service.health_check

In a production implementation, each step would need clearly defined inputs, outputs, dependencies, timeouts, failure handling, and authorization requirements.

A workflow definition should not be interpreted as permission to execute arbitrary actions. The execution engine must validate each requested operation against its own security and policy controls.

Why Golden Paths Matter for AI Agents

Without a standardized workflow, an AI agent may choose different tools or approaches for similar tasks.

This can increase variation in:

Infrastructure configuration
Security controls
Testing coverage
Deployment procedures
Observability setup
Service ownership metadata

Golden paths help reduce unnecessary variation while allowing teams to support legitimate exceptions.

4. Give AI Agents Access to Context, Not Unlimited Access

One of the biggest design challenges in AI-enabled engineering is providing sufficient context without exposing unnecessary permissions or sensitive information.

An agent working on a service needs to understand the service's code, dependencies, architecture, configuration, and operational requirements.

However, that does not mean it should have unrestricted access to every repository, secret, production database, or cloud resource.

Context Is More Than Source Code

A useful AI agent context layer can include:

Repository structure
API specifications
Service catalog metadata
Ownership information
Dependency relationships
Build and deployment instructions
Approved infrastructure templates
Testing requirements
Relevant observability data
Incident and operational runbooks

For example, when an agent is asked to troubleshoot a failed deployment, it may need to understand:

Which service failed, what changed, which environment is affected, what the deployment logs indicate, and which remediation actions are authorized?

Without this context, the agent may generate suggestions that are technically plausible but operationally unsuitable.

Establish Context Boundaries

A platform should distinguish between different categories of information:

Example

Access approach

Public internal documentation

Engineering standards

Broad read access where appropriate

Service metadata

Owner, dependencies, runtime

Scoped access

Deployment status

Build and release results

Scoped read access

Application secrets

API keys, credentials

Restricted access; avoid unnecessary exposure

Production operations

Rollback or configuration changes

Explicit authorization and policy checks

Customer data

Sensitive application records

Strict access controls and data minimization

AI agents should receive only the information necessary for their assigned task.

This principle is particularly important when an agent can use external tools or execute actions on behalf of a user.

5. Design for Agent Identity and Authorization

A traditional CI/CD pipeline often runs under a service identity with a defined set of permissions. Agent-based workflows introduce additional questions:

Which agent is performing the action?
Which user or service authorized it?
What task is it attempting to complete?
Which resources can it access?
Is the action read-only or state-changing?
Can the action affect production systems?
How is the action recorded for auditing?

These questions should be addressed through established identity and access management practices.

Separate Authentication From Authorization

Authentication determines who or what is making a request.

Authorization determines whether that identity is permitted to perform the requested action on the target resource.

An agent may be authenticated successfully but still lack permission to deploy a production application.

A practical design can include:

User / Agent
     |
     v
Identity Verification
     |
     v
Task and Resource Authorization
     |
     v
Policy Validation
     |
     v
Platform Action
     |
     v
Audit and Outcome Reporting

The agent should not be able to bypass the authorization layer simply because it has been instructed to complete a task.

Use Least Privilege

Least privilege means providing only the access required to perform a specific task.

For AI agents, this may involve:

Read-only access for code analysis
Limited write access for a designated repository
Short-lived credentials
Restricted environment access
Explicit permissions for deployment operations
Separate privileges for production changes
Revocable access and auditable execution

For example, an agent tasked with investigating a failed build may only need access to build logs and repository metadata. It does not automatically need permission to modify production infrastructure.

Agent autonomy should be bounded by the platform's security model.

6. Build Sandboxed and Reproducible Execution Environments

AI agents frequently generate or modify code. That code needs to be tested in environments that are sufficiently isolated and representative of the intended runtime.

Running untrusted or unreviewed agent-generated code directly on sensitive infrastructure introduces unnecessary risks.

An AI-ready platform should provide controlled execution environments that support:

Dependency installation
Build execution
Automated testing
Static analysis
Security scanning
Artifact generation
Resource limits
Network restrictions where appropriate
Environment cleanup

Why Reproducibility Matters

Suppose an AI agent generates a code change that passes its local tests but fails in staging.

Possible causes include:

Different dependency versions
Missing environment variables
Runtime differences
Operating system variations
Database schema mismatches
Network configuration
Incorrect assumptions about infrastructure

Reproducible environments help teams reduce these inconsistencies.

Containerized development environments, pinned dependencies, standardized build pipelines, and infrastructure-as-code can support repeatable workflows.

However, reproducibility does not guarantee that an application will behave identically in every environment. External services, data, infrastructure, and runtime conditions still need to be considered.

Example: Controlled Agent Execution

Agent Request
     |
     v
Task Validation
     |
     v
Ephemeral Workspace
     |
     v
Code Generation / Modification
     |
     v
Automated Tests
     |
     v
Security and Quality Checks
     |
     v
Artifact / Change Output

The agent can work within an isolated workspace while the platform controls resource access, execution limits, and the promotion of resulting changes.

7. Make Observability Available to AI Agents

Observability is not just a tool for human engineers. It is also a critical source of feedback for AI agents.

An agent that deploys an application needs to determine whether the deployment succeeded and whether the service is operating as expected.

A successful deployment command does not necessarily mean the application is healthy.

Key Observability Signals

A platform can provide structured access to:

Application logs
Metrics
Distributed traces
Deployment status
Health-check results
Error rates
Latency
Resource utilization
Incident information

For example, an agent may deploy a service and receive the following outcome:

JSON

{
  "deployment": "payments-api",
  "environment": "staging",
  "status": "completed",
  "health_check": "failed",
  "error_rate": "elevated",
  "recommended_next_step": "inspect_application_logs"
}

This example illustrates how structured feedback can help the agent determine its next action.

The platform should ensure that the data is accurate, scoped appropriately, and accompanied by clear semantics. A field such as status: completed should not be interpreted as proof that all operational health checks passed.

Closed-Loop Engineering Workflows

An AI agent can use observability feedback in a controlled loop:

Make a change.
Run validation.
Deploy to the approved environment.
Check service health.
Analyze the outcome.
Report the result or propose an authorized next step.

For higher-risk actions, the platform should stop the loop and require appropriate human review or explicit authorization.

The objective is not to make every process fully autonomous. It is to enable agents to handle appropriate tasks while keeping humans and platform controls involved where needed.

8. Integrate Policy as Code

Policy as code allows organizations to express operational and security requirements in machine-evaluable form.

Instead of relying only on documentation or manual checks, platforms can validate whether a requested action complies with defined policies.

Examples include:

Required resource tags
Approved container registries
Minimum security checks
Deployment environment restrictions
Required service ownership metadata
Network configuration standards
Infrastructure configuration rules
Separation of duties

Example Policy

Consider a rule that production deployments must use an approved artifact.

YAML

policy:
  name: approved-production-artifact

  applies_to:
    environment: production

  requirements:
    - artifact.signature_verified
    - artifact.source_trusted
    - security.scan_completed
    - deployment.authorization_valid

This is a simplified conceptual example. Actual enforcement requires a policy engine and trusted verification mechanisms.

Why Policy as Code Helps AI Workflows

AI agents may generate unexpected solutions or attempt actions that fall outside established procedures.

Policy enforcement provides a consistent way to validate requests.

Rather than depending on an agent to remember every organizational rule, the platform can enforce critical constraints independently.

This creates a more reliable boundary between what an agent proposes and what the system permits.

Instructions guide the agent; enforcement protects the platform.

9. Create a Standard Interface for Platform Actions

An AI agent becomes more useful when it can interact with platform capabilities through consistent interfaces.

Without standardization, an organization might expose infrastructure functions through a mixture of:

Custom scripts
Shell commands
REST APIs
Cloud provider CLIs
Kubernetes commands
Internal portals
Unstructured documentation

These tools may work well for experienced engineers but can be difficult to use consistently in agent-driven workflows.

API-First Platform Design

A platform should expose well-defined capabilities that include:

Clear input and output schemas
Authentication requirements
Authorization checks
Error codes
Idempotency where appropriate
Operation status
Documentation
Audit records

An agent might request a deployment using an interface such as:

JSON

{
  "service": "catalog-api",
  "environment": "staging",
  "artifact": "registry.example/catalog-api:2026.09.22"
}

The platform should then validate:

Whether the service exists.
Whether the artifact is authorized and available.
Whether the requesting identity has permission.
Whether the environment supports the operation.
Whether required checks have passed.
Whether the deployment request can be executed safely.

The platform, rather than the AI agent, should make the final authorization decision.

Tool Interfaces and Interoperability

Organizations may choose different approaches for exposing tools to AI agents, including conventional APIs, structured command interfaces, or interoperability standards such as the Model Context Protocol (MCP).

The appropriate choice depends on the platform's security, operational, and integration requirements.

MCP can be considered as one option for connecting AI systems to tools and contextual resources, but it should not be treated as a substitute for identity management, authorization, or secure execution.

10. Build a Strong Developer Portal

A developer portal is often the primary entry point for an internal developer platform.

It provides a centralized place to discover services, access documentation, use templates, and understand the ownership of software components.

For AI agents, the portal's underlying data and interfaces may be as important as its visual experience.

Essential Developer Portal Features

A modern portal can include:

Service catalog
Software templates
API documentation
Ownership and team information
Infrastructure capabilities
Deployment history
Environment status
Operational runbooks
Security requirements
Platform usage documentation

For example, a service catalog entry could include:

YAML

service:
  name: customer-profile-api
  owner: customer-platform
  runtime: python
  deployment:
    strategy: rolling
  environments:
    - development
    - staging
    - production
  documentation:
    api: /docs/api
    runbook: /docs/runbook

This information can help developers and agents understand the service's operating context.

However, catalog metadata should be validated and maintained. Stale ownership, missing dependencies, or inaccurate deployment details can lead to poor decisions by both human engineers and AI systems.

A Portal Is Not Just a UI

A developer portal can be understood as a combination of:

A user-facing experience.
A structured catalog of engineering resources.
Access to approved platform workflows.
Documentation and operational context.
Integration points for automation.

This approach makes the platform useful across different engineering workflows without requiring every user to interact with the underlying infrastructure directly.

11. Support Human-in-the-Loop Workflows

AI agents can perform a range of tasks, but not every task should be fully autonomous.

The level of autonomy should be based on factors such as risk, reversibility, impact, and the quality of available validation.

Example Autonomy Levels

Possible operating mode

Read repository documentation

Automated

Summarize build failures

Automated

Generate a pull request

Automated with review workflow

Run tests in an isolated environment

Automated

Deploy to development

Policy-controlled automation

Deploy to staging

Automated if required checks pass

Change production configuration

Explicit authorization

Execute irreversible data operations

Strict controls and human oversight

These are illustrative operating choices rather than universal requirements. Organizations should define their own controls based on the risk profile of each operation.

Approval Should Be Context-Aware

A blanket rule that requires approval for every action can reduce the benefits of automation. A system that grants unrestricted autonomy can increase operational risk.

A more practical approach is to establish risk-based controls.

For example:

Low-risk, read-only operations may be automated.
Reversible development changes may use predefined workflows.
Production modifications may require additional authorization.
High-impact or irreversible operations may require multiple safeguards.

The platform should also provide visibility into what the agent intends to do, what it actually did, and whether the operation produced the expected outcome.

12. Manage AI Agent Cost and Resource Consumption

AI-enabled development introduces new resource considerations.

Agents may perform repeated tool calls, execute tests, generate multiple versions of a solution, or launch infrastructure workflows. Without appropriate controls, resource consumption can become difficult to predict.

Platform engineering teams should consider how to manage:

Compute usage
Build minutes
Test environment lifecycle
Model and inference costs
Storage consumption
Concurrent agent tasks
API rate limits
Resource quotas

Establish Usage Controls

A platform can implement controls such as:

Per-task execution limits
Environment timeouts
Workspace cleanup
Resource quotas
Concurrency limits
Budget monitoring
Task cancellation
Usage reporting

For example, an ephemeral environment created for an agent's testing task should have a defined lifecycle. If it is no longer needed, the platform should be able to clean it up according to the organization's policies.

The objective is not to limit experimentation unnecessarily. It is to ensure that automation operates within predictable resource boundaries.

13. Measure Platform Engineering Success

Platform engineering teams need meaningful metrics to determine whether the internal platform is delivering value.

The presence of AI agents does not automatically mean that engineering productivity has improved.

Organizations should evaluate whether the platform helps teams deliver software safely, consistently, and efficiently.

Key Metrics to Consider

Developer Lead Time

How long does it take to move from a validated change to a deployed service?

Workflow Success Rate

How frequently do standardized platform workflows complete successfully?

Change Failure Rate

How often do deployed changes lead to incidents, rollbacks, or remediation?

Platform Adoption

How many teams use approved templates, workflows, and platform capabilities?

Security and Compliance

Are required checks, policies, and access controls consistently enforced?

Agent Task Outcomes

How often do agent-assisted tasks achieve their intended results without unnecessary intervention?

Avoid Measuring Only the Number of AI-Generated Changes

An agent might generate dozens of pull requests in a day, but that alone does not demonstrate improved engineering performance.

Additional questions matter:

How many changes passed review?
How much rework was required?
Did testing quality improve?
Did operational incidents increase?
How much human effort was saved?
Did platform usage reduce repeated manual work?
Were security and compliance requirements maintained?

A balanced measurement framework considers delivery speed, quality, reliability, security, and developer experience.

14. Common Mistakes When Building an AI-Ready IDP

Organizations adopting AI agents into platform workflows may encounter several implementation challenges.

Mistake 1: Treating AI Agents as Ordinary Scripts

AI agents can interpret context, select tools, and execute multi-step tasks. Their behavior may be less predictable than a narrowly scoped deterministic script.

What to do instead: Establish clear tool contracts, execution limits, authorization checks, and reliable error handling.

Mistake 2: Providing Excessive Permissions

Giving an agent broad infrastructure access simply because it needs to perform a task can increase the impact of mistakes or compromised credentials.

What to do instead: Use least-privilege access, scoped identities, and explicit permissions for sensitive operations.

Mistake 3: Ignoring Operational Context

An agent that can generate code but cannot access appropriate test results, service metadata, or deployment feedback may struggle to complete tasks effectively.

What to do instead: Provide relevant, structured context through reliable platform interfaces.

Mistake 4: Automating Without a Rollback Strategy

Automation can accelerate changes, but failed changes still need to be detected and addressed.

What to do instead: Define recovery procedures, health checks, rollback mechanisms where appropriate, and clear escalation paths.

Mistake 5: Building a Platform Without Developer Feedback

A platform designed without understanding developer workflows may introduce additional friction.

What to do instead: Involve platform users early, collect feedback, and measure whether the platform is reducing unnecessary work.

Mistake 6: Assuming More Autonomy Always Means Better Results

Greater autonomy is not automatically beneficial for every task.

What to do instead: Match the level of autonomy to the task's risk, reversibility, and available validation.

15. A Practical Roadmap for Building an AI-Ready IDP

Organizations do not need to implement every capability at once. A phased approach can help teams establish a reliable foundation before expanding agent autonomy.

Phase 1: Assess the Existing Platform

Start by documenting the current platform environment.

Review:

CI/CD workflows
Infrastructure provisioning
Service ownership
Developer portal capabilities
Identity and access controls
Observability
Deployment processes
Security checks

Identify the workflows that are repeated frequently and could benefit from standardization.

Phase 2: Establish Golden Paths

Choose a limited number of common application patterns.

For example:

Backend API
Frontend application
Scheduled data processing service
Event-driven microservice

Create standardized templates and workflows with documented requirements.

Phase 3: Improve Platform Interfaces

Expose platform capabilities through consistent APIs or structured interfaces.

Focus on:

Clear inputs and outputs
Authentication and authorization
Error handling
Audit logging
Documentation
Idempotency and retry behavior where appropriate

Phase 4: Introduce Controlled Agent Workflows

Begin with lower-risk use cases, such as:

Documentation discovery
Build failure analysis
Test generation
Code review assistance
Pull request preparation
Non-production workflow support

Measure results before expanding access.

Phase 5: Add Stronger Governance

Introduce more comprehensive policy enforcement, environment controls, and audit mechanisms.

Review whether agent actions are consistent with organizational security and operational requirements.

Phase 6: Expand Based on Evidence

Use workflow outcomes, developer feedback, and operational metrics to determine where additional automation may be appropriate.

Avoid expanding autonomy solely because the technology makes it possible.

16. Example Architecture: AI Agent Connected to an Internal Developer Platform

The following conceptual architecture illustrates how an AI agent could interact with an IDP while keeping platform controls in the execution path.

AI Agent

Task planning and tool selection

Agent Interface Layer

Structured tools, schemas, and request validation

Identity and Policy Controls

Authentication, authorization, and policy enforcement

Platform Orchestration

Approved workflows, task execution, and environment management

Build and Deploy

CI/CD and artifact workflows

Infrastructure

Approved infrastructure services

Observability

Logs, metrics, and health data

Service Catalog

Ownership and platform context

Feedback and Audit

Execution results, operational status, and recorded actions

This architecture is conceptual. The specific implementation may use different orchestration components, identity providers, deployment systems, and observability tools.

The central design principle is to separate agent reasoning from the platform's trusted enforcement and execution mechanisms.

17. Technologies That Can Support the Platform

An AI-ready IDP is not dependent on a single technology stack. Teams can combine existing platform engineering tools with agent integration capabilities based on their requirements.

Example technologies

Developer portal

Backstage or a custom internal portal

Container orchestration

Kubernetes

Infrastructure as code

Terraform, OpenTofu, or cloud-native tooling

CI/CD

GitHub Actions, GitLab CI/CD, Jenkins, or other pipelines

GitOps delivery

Argo CD or Flux

Observability

OpenTelemetry, Prometheus, Grafana

Policy enforcement

OPA, Gatekeeper, Kyverno, or equivalent controls

Agent tool integration

APIs, structured tool interfaces, or MCP-compatible integrations

Secrets management

Enterprise secrets management systems

Artifact management

Approved container and package registries

These are examples of technology categories and tools. Their suitability depends on the organization's existing architecture, operational maturity, and security requirements.

The best platform is not necessarily the one with the largest number of components. It is the one that provides reliable capabilities without creating unnecessary complexity for engineering teams.

18. The Future of Platform Engineering Is Context-Aware

AI agents are changing how software teams interact with infrastructure and engineering systems.

However, the future of platform engineering is not simply about giving agents more tools.

It is about creating an environment where agents can:

Discover available capabilities
Understand service context
Follow standardized workflows
Operate within defined permissions
Receive meaningful feedback
Recover from failures appropriately
Escalate uncertain or high-risk decisions
Produce auditable outcomes

Internal developer platforms will increasingly need to support a combination of human-driven and agent-assisted workflows.

The platform's role is to make engineering capabilities easier to consume while preserving the controls required for secure and reliable software delivery.

Conclusion: Build the Platform Before Expanding Agent Autonomy

Platform engineering in 2026 is increasingly connected to the practical challenges of AI-assisted software development.

AI agents can support developers across coding, testing, deployment, and troubleshooting. But their effectiveness depends on the surrounding platform's ability to provide reliable tools, relevant context, standardized workflows, and appropriate safeguards.

An internal developer platform designed for AI agents should prioritize:

Discoverability: Make platform capabilities and service context accessible through structured interfaces.
Standardization: Establish golden paths that support repeatable engineering workflows.
Security: Enforce identity, authorization, and least-privilege access.
Reliability: Provide reproducible environments, validation, and operational feedback.
Governance: Use policy enforcement and audit mechanisms to control higher-risk actions.
Developer experience: Reduce cognitive load for both human developers and automation systems.

The goal is not to replace engineering judgment with autonomous systems. It is to build a platform where AI agents can contribute effectively while operating within the organization's technical and operational boundaries.

The next generation of internal developer platforms will be defined not only by how much infrastructure they automate, but by how safely and effectively they enable humans and AI agents to work together.

Formal Verification for AI-Generated Code: Overkill or Overdue?

Eva Clari — Tue, 15 Sep 2026 09:59:05 +0000

Formal Verification for AI-Generated Code: Overkill or Overdue?

AI coding assistants have changed software development dramatically. Developers can now generate functions, write tests, refactor legacy code, and even build entire application components with a simple prompt.

But there is an uncomfortable question behind this productivity boom:

How do we know that AI-generated code is actually correct?

Traditional code review, unit testing, static analysis, and security scanning can catch many problems. However, AI-generated code introduces a different challenge. A piece of code can look reasonable, pass its tests, and still contain subtle logical flaws or security vulnerabilities.

This is where formal verification enters the conversation.

What Is Formal Verification?

Formal verification uses mathematical methods to prove that software behaves according to a defined specification.

Instead of asking:

"Does this code pass our test cases?"

formal verification asks:

"Can we mathematically demonstrate that this code satisfies the properties we require?"

This distinction matters.

Tests examine specific scenarios. Formal methods can reason about a much broader set of possible states and inputs.

For example, imagine an AI assistant generates authentication logic. A developer might write dozens of tests covering common login scenarios. Those tests could all pass while an unusual sequence of inputs still creates an authentication bypass.

Formal verification attempts to establish that certain properties—such as access-control rules or memory-safety guarantees—hold across the defined system.

Why AI-Generated Code Makes This More Important

AI models generate code based on patterns learned from enormous amounts of existing material. They can produce impressive results, but they do not inherently understand whether a generated implementation satisfies an organization's exact security or business requirements.

That creates several risks.

1. Plausible Doesn't Mean Correct

AI-generated code often looks convincing.

Variable names make sense. Functions are structured properly. Comments may even explain the implementation confidently.

But appearance is not proof.

A subtle logic error can survive a basic review because the implementation looks like something an experienced developer would write.

2. Security Vulnerabilities Can Be Difficult to Spot

AI-generated applications may inadvertently introduce issues involving:

Improper input validation
Broken access controls
Insecure authentication
Injection vulnerabilities
Cryptographic mistakes
Insecure configurations
Improper error handling
Unsafe dependency usage

This is particularly important when AI-generated code is integrated into applications handling financial, healthcare, customer, or other sensitive data.

Security testing should therefore remain an essential part of the development lifecycle.

Organizations looking to strengthen their teams' practical cybersecurity capabilities can also explore Vulnerability Assessment and Penetration Testing (VAPT) training, which covers areas such as vulnerability assessment, penetration testing, security controls, web application security, and security assessment techniques.

3. Tests Have Limits

Unit tests are extremely valuable. They should not be replaced by formal verification.

But testing and verification answer different questions.

Consider a function that processes user permissions.

You might test:

An administrator can access the resource.
A standard user cannot access it.
An unauthenticated user is rejected.

Those tests are useful, but they represent selected scenarios.

A formal specification might instead express a property such as:

No user without the required permission can access the protected resource.

That is a much stronger statement.

The challenge is that formal verification can also be considerably more expensive and complex than conventional testing.

So, Is Formal Verification Overkill?

Sometimes, yes.

Applying heavyweight formal methods to every line of a typical web application would be impractical.

Most business applications contain huge amounts of code, frequently changing requirements, third-party dependencies, and complex integrations. Attempting to formally prove every component correct could slow development dramatically.

But that doesn't mean formal verification is unnecessary.

The better approach is risk-based verification.

Where Formal Verification Makes the Most Sense

Formal methods become particularly valuable when software failures could have serious consequences.

Examples include:

Financial Systems

Payment processing, trading systems, banking infrastructure, and smart contracts may benefit from stronger mathematical guarantees.

Critical Infrastructure

Software controlling energy, transportation, communications, or industrial systems can justify a higher verification investment.

Safety-Critical Systems

A software failure in aviation, automotive, medical, or industrial environments can have consequences far beyond downtime.

Security-Critical Components

Authentication systems, authorization mechanisms, cryptographic implementations, and security-sensitive protocols are strong candidates.

AI Systems That Control Other Systems

As AI-generated code becomes integrated into autonomous systems and security infrastructure, proving important properties of critical components could become increasingly valuable.

A Better Development Model: Verification in Layers

The future probably isn't about choosing between testing and formal verification.

It is about combining them.

A practical development pipeline could look like this:

AI code generation → Human review → Static analysis → Unit testing → Integration testing → Security testing → Formal verification for critical components

Each layer addresses a different category of risk.

AI can accelerate implementation.

Developers provide context and judgment.

Testing validates expected behavior.

Security testing looks for weaknesses.

Formal verification provides stronger guarantees where they matter most.

This layered approach is more realistic than attempting to formally verify an entire application.

Human Developers Still Matter

There is another important point that sometimes gets lost in discussions about AI coding tools.

Formal verification does not eliminate the need for human judgment.

A system can be formally verified against an incorrect specification.

If the requirement says:

"The system should prevent unauthorized users from accessing data."

but the definition of "authorized" is wrong, proving the implementation against that specification doesn't solve the underlying problem.

The quality of the specification matters.

Human developers, architects, security professionals, and domain experts still need to determine what the software is actually supposed to do.

Could AI Help With Formal Verification Too?

Ironically, AI may eventually make formal verification more accessible.

One of the biggest barriers to formal methods is the expertise required to create specifications and verification proofs.

AI assistants could potentially help developers:

Generate formal specifications
Identify properties worth proving
Translate natural-language requirements into formal constraints
Suggest verification strategies
Generate proof candidates
Explain failed proofs
Detect inconsistencies between requirements and implementation

This could make formal verification less intimidating for mainstream development teams.

Instead of developers manually constructing every proof, AI could become an assistant for the verification process itself.

The Real Question Isn't "Overkill or Overdue?"

The more useful question is:

Which parts of AI-generated software are important enough to deserve mathematical guarantees?

Not every function needs formal verification.

A formatting helper probably doesn't.

A component responsible for authentication, authorization, financial transactions, cryptographic operations, or safety-critical decisions might.

As AI increases the amount of code developers can produce, the bottleneck may gradually shift from writing code to establishing confidence in code.

That is where formal verification could become increasingly important.

Final Thoughts

AI-generated code is not inherently unsafe, just as human-written code is not inherently safe.

The difference is that AI can dramatically increase the speed and volume at which software is produced. That makes traditional quality-control processes even more important.

Formal verification won't replace testing, code review, or security assessments. Instead, it can become another layer of assurance for the components where failure is unacceptable.

For ordinary software, formal verification may still be overkill.

For critical software increasingly written with AI assistance, it may already be overdue.

AI #SoftwareDevelopment #Cybersecurity #FormalVerification

Long-Horizon Agents: What Happens When AI Can Own a Multi-Hour Engineering Task

Eva Clari — Tue, 08 Sep 2026 05:12:05 +0000

Absolutely. For DEV Community, I’d make this technical, practical, and discussion-driven rather than overly promotional. Here’s a ready-to-publish draft:

Long-Horizon Agents: What Happens When AI Can Own a Multi-Hour Engineering Task

AI coding assistants have become surprisingly good at completing small engineering tasks.

Fix a bug.
Write a function.
Generate a test.
Explain an error.
Refactor a component.

But what happens when we give an AI agent something much bigger?

“Take this issue, understand the codebase, implement the solution, write tests, run them, debug failures, and open a pull request.”

That is a fundamentally different problem.

Instead of assisting with individual actions, the AI is being asked to own an engineering task for several hours.

This is where long-horizon agents become interesting.

What Is a Long-Horizon Agent?

A long-horizon agent is an AI system designed to work toward a goal across many steps rather than producing a single response.

A typical workflow might look like:

Understand the task
        ↓
Explore the repository
        ↓
Create a plan
        ↓
Implement changes
        ↓
Run tests
        ↓
Analyze failures
        ↓
Modify the implementation
        ↓
Run tests again
        ↓
Review the changes
        ↓
Create a pull request

The important difference isn't simply that the agent can generate more code.

It is that the agent needs to maintain context, make decisions, recover from mistakes, and continuously evaluate whether it is actually getting closer to the goal.

The Real Challenge Isn't Code Generation

Generating code is only one part of software engineering.

Consider a simple request:

Add support for a new authentication provider.

An engineer may need to determine:

Where authentication is implemented
Which interfaces are involved
How configuration is loaded
How credentials are stored
What existing providers look like
Which tests cover authentication
Whether documentation needs updating
What security implications exist
Whether backwards compatibility could be affected

A coding model can potentially generate the implementation.

But a long-horizon agent needs to figure out what implementation should exist in the first place.

That makes repository exploration and decision-making just as important as code generation.

Why Multi-Hour Tasks Are Different

Short coding tasks often have relatively clear feedback.

You ask an AI to write a function and run the tests. If the tests pass, you have a strong signal that the implementation works.

Long tasks are different.

There may be dozens or hundreds of intermediate decisions.

An agent can make a small incorrect assumption early in the process and only discover the consequences much later.

For example:

Incorrect assumption
       ↓
Wrong architectural decision
       ↓
Implementation built around it
       ↓
Tests fail
       ↓
Agent patches symptoms
       ↓
More complexity
       ↓
Task becomes harder

This is one of the biggest risks with autonomous engineering agents.

Error accumulation.

The longer an agent operates without meaningful verification, the more expensive an incorrect decision becomes.

Memory Becomes an Engineering Problem

A multi-hour task can generate an enormous amount of context.

The agent may inspect:

Hundreds of files
Documentation
Git history
Build logs
Test results
Stack traces
Previous implementation attempts
Design decisions

The agent therefore needs more than a large context window.

It needs useful memory.

A practical architecture might maintain several types of state:

Task State
├── Objective
├── Constraints
├── Current plan
└── Completion criteria

Repository State
├── Relevant files
├── Architecture
├── Dependencies
└── Existing patterns

Execution State
├── Commands executed
├── Tests
├── Errors
└── Changes made

Decision Memory
├── Decisions
├── Assumptions
├── Rejected approaches
└── Open questions

This distinction matters.

The agent shouldn't have to repeatedly rediscover why it chose a particular approach three hours earlier.

Verification Is More Important Than Generation

If agents are going to operate independently for hours, verification becomes a core capability.

A strong long-horizon workflow should repeatedly answer:

“Do I have evidence that I'm moving toward the correct solution?”

That evidence can come from:

Unit tests
Integration tests
Type checking
Static analysis
Build systems
Linters
Security scanners
Runtime behavior
Code review
Explicit acceptance criteria

The agent should not simply follow:

Plan → Code → Done

A better loop is:

Plan
 ↓
Execute
 ↓
Verify
 ↓
Observe
 ↓
Update plan
 ↓
Execute again

In other words, long-horizon agents need to behave less like autocomplete and more like closed-loop control systems.

What Happens When the Agent Gets Stuck?

This is another important question.

Suppose an agent spends 90 minutes trying to fix a failing integration test.

Should it continue?

Not necessarily.

A robust agent needs stopping conditions.

For example:

If progress is measurable:
    continue

If the same error repeats:
    reconsider the approach

If assumptions conflict:
    revisit the plan

If confidence drops significantly:
    request human input

If acceptance criteria are satisfied:
    finish

Knowing when to stop can be just as important as knowing what to do next.

Humans Don't Disappear

Long-horizon agents don't necessarily eliminate engineers.

Instead, they can change where engineers spend their time.

Today:

Engineer
  ↓
Break down task
  ↓
Write code
  ↓
Debug
  ↓
Write tests
  ↓
Review

A future workflow could look more like:

Engineer
  ↓
Define objective + constraints
  ↓
Agent executes
  ↓
Agent verifies
  ↓
Engineer reviews decisions + outcome

The engineer becomes increasingly responsible for intent, architecture, constraints, and judgment.

The agent handles more of the execution.

That is a meaningful shift.

The Pull Request May Become the Natural Boundary

One interesting model for long-horizon engineering is to make the pull request the unit of agent autonomy.

Instead of asking:

“Can the AI write code?”

we ask:

“Can the AI take an issue from description to a reviewable pull request?”

That includes:

Understanding the issue
Exploring the repository
Planning the implementation
Making changes
Running validation
Fixing failures
Reviewing the diff
Documenting important decisions
Opening the PR

The human then reviews the result.

This creates a useful boundary between autonomous execution and human accountability.

The Biggest Bottleneck May Be Trust

Technical capability is only half the problem.

Organizations also need confidence that an agent won't:

Modify unrelated files
Introduce security vulnerabilities
Break production assumptions
Leak sensitive information
Consume excessive resources
Hide failures
Misinterpret requirements
Make irreversible changes

This means agent infrastructure will increasingly need:

Permissions
+
Sandboxing
+
Observability
+
Testing
+
Audit logs
+
Human approval

An agent that can write code for five hours is impressive.

An agent that can safely operate inside a production engineering environment is much harder.

What Could Change?

If long-horizon agents become reliable, the unit of software development may change.

Instead of assigning engineers hundreds of small implementation tasks, teams could increasingly assign outcomes.

For example:

“Reduce API latency by 20% without changing the public API.”

The agent could investigate profiling data, identify bottlenecks, experiment with optimizations, run benchmarks, and prepare a PR.

Or:

“Add OAuth support while preserving existing authentication behavior.”

The agent could inspect the architecture, implement the provider, add tests, update configuration, and document the changes.

The engineer's role becomes less about manually performing every step and more about setting the direction and validating the outcome.

The Question We Should Be Asking

The most interesting question isn't:

“How much code can AI write?”

It is:

“How much engineering responsibility can AI reliably carry?”

There's a huge difference between generating a correct function and owning a complex engineering objective for several hours.

Long-horizon agents push AI toward the second problem.

And if they become reliable, software engineering may shift from human-directed implementation toward human-directed autonomous execution.

We're still early.

The difficult part isn't making agents run longer.

It's making them stay correct while they do.

What do you think?

Would you trust an AI agent to take a well-defined GitHub issue, work on it independently for several hours, run the tests, and open a pull request without human intervention?

Or would you still want a human involved at every major decision point?

Security Scanners Are Moving Into the Coding Agent Itself, Not Just CI

Eva Clari — Tue, 01 Sep 2026 11:29:47 +0000

For years, application security followed a familiar pattern: developers wrote code, committed it, opened a pull request, and security scanners analyzed the changes somewhere in the CI/CD pipeline.

That model made sense when software development was primarily human-driven.

But coding agents are changing the workflow.

AI coding agents can now generate code, modify existing files, install dependencies, execute commands, run tests, and interact with development environments with limited human intervention. According to JetBrains' 2026 Developer Ecosystem Survey, 90% of professional developers surveyed were using AI coding agents at work at least weekly, with 68% using them daily.

That creates an important security question:

Why wait until CI to discover a vulnerability when an AI agent can introduce it several minutes earlier?

This is why security scanning is increasingly moving directly into the coding-agent workflow.

The Security Gap Is Moving Earlier

Traditional CI-based security scanning remains important. SAST, software composition analysis (SCA), secret scanning, dependency checks, and other controls provide valuable protection before software moves further through the delivery pipeline.

But AI-assisted development changes the speed and volume of code creation.

An agent can generate hundreds of lines of code, add a package, modify configuration files, and make multiple changes during a single session. If security feedback only arrives after the developer commits those changes or opens a pull request, the vulnerability has already traveled further through the development process.

The new approach is to place security controls closer to where the code is actually being created.

Recent security tooling is already experimenting with this model. For example, agent-aware security solutions can trigger scans after an AI agent edits a file, evaluate dependencies before installation, and detect secrets immediately after they are introduced.

This creates a much tighter feedback loop:

Generate → Scan → Fix → Re-scan → Continue

Instead of:

Generate → Commit → CI Scan → Find Issue → Return to Development

The difference may appear small, but at AI-generated development speeds, it can have a significant impact.

Coding Agents Introduce a Different Attack Surface

The biggest mistake would be to think that securing AI-generated code is simply another version of traditional application security.

The agent itself has privileges.

It may have access to:

Source-code repositories
File systems
Package managers
Environment variables
APIs
Databases
Shell commands
Development tools
MCP servers and external services

That means an attacker does not necessarily need to insert a conventional vulnerability into the final application.

They could instead target the agent's workflow.

For example, a malicious dependency could be recommended or installed by an agent. A compromised tool could influence what the agent executes. A malicious instruction could manipulate the agent into exposing sensitive information or performing an unsafe action.

Cisco highlighted this expanding risk in 2026, noting that AI-powered IDE agents increasingly interact with file systems, APIs, shell commands, MCP servers, and other tools.

Endor Labs has similarly described AI coding agents as systems that can write code, install dependencies, and interact with filesystems, packages, databases, and CI pipelines.

So the security boundary is no longer simply the application.

**The development agent has become part of the attack surface.

Why CI Scanning Alone Isn't Enough**

This does not mean CI security scanning is becoming obsolete.

Quite the opposite.

CI remains an important control because it provides centralized, repeatable verification before software progresses toward production.

The problem is relying on CI as the first security checkpoint.

Consider a simple example.

An AI coding agent is asked to add authentication to a web application. It generates the implementation, adds a third-party library, changes configuration files, and runs the application's test suite.

Several problems could potentially be introduced:

The generated authentication logic contains an insecure implementation.
A dependency has a known vulnerability.
A secret is accidentally placed in a configuration file.
The agent modifies security-sensitive configuration.
A package with suspicious behavior is installed.

If these issues are discovered only during CI, developers have already moved away from the point where the changes were created.

Agent-level scanning can provide feedback immediately.

That is the real shift.

Security Becomes Part of the Agent's Feedback Loop

The most interesting development is not simply "scanning earlier."

It is making security something the coding agent can respond to.

Imagine an agent generates code containing a potential SQL injection vulnerability.

A traditional scanner might report the finding after the pull request is created.

An agent-integrated scanner can instead return something closer to:

"This change introduces a potential SQL injection risk. Use parameterized queries before continuing."

The agent can then modify the code and run the security check again.

This creates a fix-and-verify loop.

Modern secure-AI-coding implementations are already using post-edit hooks and similar mechanisms to scan changed code, identify vulnerabilities, detect secrets, and provide remediation guidance directly within the development workflow.

The objective isn't to eliminate developers from the process.

It is to give developers and agents security feedback at the moment when it is most actionable.

Vulnerability Management Has to Evolve Too

This shift also changes the role of vulnerability management.

Historically, vulnerability management often meant:

Discover → Prioritize → Remediate → Validate

That process remains relevant.

But AI-driven development adds another dimension:

Prevent → Discover → Prioritize → Remediate → Validate → Continuously monitor

Security teams need to understand not only which vulnerabilities exist, but also how they entered the development environment.

Was the vulnerability introduced by:

An AI-generated code change?
A new open-source dependency?
An automated configuration change?
An agent-installed package?
A compromised development tool?
A developer-approved AI recommendation?

Without this context, security teams can end up treating symptoms instead of improving the development process.

This is where strong vulnerability-management practices become particularly valuable.

Teams need the ability to identify vulnerabilities, assess their severity and business impact, prioritize remediation, track ownership, and verify that fixes actually address the underlying risk.

For organizations looking to strengthen these capabilities, Edstellar offers a Corporate Vulnerability Management Training Course designed to help teams build practical cybersecurity capabilities around proactive vulnerability management and security posture improvement.

What Security Teams Should Start Doing

As coding agents become more capable, security teams can take several practical steps.

1. Scan AI-generated changes immediately

Don't wait exclusively for pull requests or CI.

Where possible, introduce security checks when agents create or modify code.

2. Add dependency controls

AI agents can rapidly introduce new packages.

Dependency analysis should therefore become part of the agent workflow, particularly before automated package installation.

Some newer approaches can evaluate packages before installation and block known risky dependencies.

3. Scan for secrets continuously

Agents can accidentally generate API keys, credentials, tokens, or other sensitive information.

Secret detection should happen immediately after generated changes rather than relying solely on repository-level scanning.

4. Treat agent permissions as security controls

Ask what the agent can actually do.

Can it:

Execute shell commands?
Install packages?
Access production credentials?
Modify infrastructure?
Access private repositories?
Call external APIs?

The principle of least privilege should apply to coding agents just as it applies to human users and applications.

5. Keep CI as the final verification layer

Moving security into the agent does not mean removing CI scanning.

Instead, organizations should create multiple layers of verification.

A useful model is:

Agent-level scanning → IDE/developer scanning → Pull-request checks → CI/CD security gates → Runtime monitoring

Each layer catches risks that may escape another.

The Bigger Change: Security Is Becoming Continuous

The phrase "shift left" has been used in application security for years.

But agentic development pushes that idea further.

Security is no longer simply moving from production toward development.

It is moving inside the development process itself.

Recent industry discussions increasingly describe software development as an interconnected system of developers, AI agents, services, dependencies, pipelines, and automated infrastructure rather than a simple linear process.

That means security controls need to understand this entire system.

The coding agent is not just another developer tool.

It can become an active participant in software creation.

And when something is actively creating software, security needs to be present while that creation is happening.

The Future Isn't "Agent vs. CI"

The future of secure software development is unlikely to be a choice between scanning inside coding agents and scanning in CI.

It will be both.

Agent-level security provides immediate feedback and prevents risky changes from traveling further.

CI provides standardized, centralized verification.

Runtime security provides another layer of assurance after deployment.

Together, they create defense in depth for an increasingly autonomous software development lifecycle.

The key lesson for security leaders is simple:

If AI agents are writing the code, security scanners need to understand the agent's workflow—not just the code that eventually reaches CI.

As development becomes faster and increasingly autonomous, vulnerability management cannot remain a downstream activity.

Security has to move closer to the moment of creation.

The Economics of AI Coding in 2026: Why Your Stack Is Already Outdated

Eva Clari — Mon, 24 Aug 2026 13:30:00 +0000

The adoption of artificial intelligence in software development has transitioned from experimental curiosity to core operational strategy. In 2026, engineering organizations are no longer debating whether to use AI assistants. Instead, they are focused on optimizing the cost, performance, and scalability of their agentic workflows. Many teams discover that the AI stack they built just a year ago is already outdated, characterized by high API latency and unsustainable token costs. The rapid decline in model pricing and the rise of specialized code models have redefined the economics of software development.

To remain competitive, technology leaders must continuously evaluate their development platforms. Relying on a single premium model for all development tasks is a financial mistake. Building a modern, cost-effective agentic stack requires a multi-model architecture, dynamic context caching, and local execution options that protect budgets while improving developer productivity.

Analyze the Rapid Shift in Model Economics

The primary driver of the changing AI stack is the dramatic decrease in API pricing for token processing. Over the past two years, the cost of processing one million input tokens has dropped by over 80 percent across all major model providers. This price drop has made high-context tasks, such as feeding entire code repositories or documentation sets into a model, financially viable. According to a 2025 Gartner report on enterprise AI infrastructure, companies that updated their architectures to take advantage of these lower pricing tiers reduced their development platform costs by over 50 percent.

Additionally, model execution speeds have increased significantly, with modern specialized models generating code tokens at a fraction of the latency of early frontier models. This performance improvement allows developers to receive code suggestions, compilation feedback, and test results in real time. Organizations that remain tied to older, slow models suffer from operational drag, as developers spend valuable time waiting for model responses instead of writing and reviewing code.

The third economic shift is the viability of running mid-sized, specialized code models locally on developer machines or private enterprise servers. Modern local models with under 14 billion parameters can generate boilerplate code and perform simple refactoring tasks with high accuracy, eliminating API costs and ensuring that sensitive proprietary code never leaves the company's private network. This hybrid execution model offers a secure, cost-effective alternative to cloud-only APIs.

Understand the Cost of a Disjointed Context Strategy

Failing to optimize context management is the most common cause of high API bills in corporate agentic systems. Because terminal agents must read multiple files, compile logs, and search codebases, they can easily consume millions of tokens during a single run. If the agentic stack does not utilize context caching, the system must process the entire codebase context repeatedly, leading to massive token redundancy. This redundancy wastes API budget and increases response latency.

To resolve this issue, modern developer platforms implement dynamic context caching. Caching allows the system to store the tokenized representation of the codebase, libraries, and documentation in memory. When the developer makes minor edits or requests feedback, the model only processes the new changes, referencing the cached context for the rest. A 2024 GitHub engineering blog post revealed that implementing context caching in their developer tools reduced average input token costs by over 70 percent, highlighting the massive efficiency gains available.

Furthermore, teams must implement strict context boundaries. Do not feed the entire repository into the model for simple tasks. L&D and engineering leaders should train developers to specify context boundaries, providing the agent with only the relevant files and APIs required for the task. This discipline reduces token consumption, minimizes model confusion, and ensures that suggestions are more accurate and relevant.

Implement a Multi-Model Hybrid Stack

To build a cost-effective, future-ready developer platform, organizations should deploy a hybrid, multi-model stack. This architecture routes tasks dynamically based on complexity and security requirements. Simple tasks like writing boilerplate code, formatting, and executing unit tests run on local or inexpensive cloud models. Complex tasks requiring architectural planning, cross-module integration, and advanced debugging are escalated to premium cloud models with superior reasoning capabilities.

A 2025 McKinsey study on software engineering productivity showed that organizations that implement dynamic, multi-model routing report 40 percent faster task completion rates and significantly lower operational costs compared to those that rely on a single model. By treating models as specialized computing resources, you protect your budget while ensuring that developers always have the right tool for the job.

A Platform Optimization Checklist for Tech Leaders

To ensure your development platform remains cost-effective and high-performing, technology leaders should follow a structured optimization plan. When you evaluate your current agentic stack, verify that your plan addresses these essential components:

Implement dynamic context caching to reduce input token redundancy and costs across agent runs
Deploy mid-sized, specialized local models for basic code generation and sensitive internal tasks
Establish automated routing rules that select the optimal model based on task complexity and latency constraints
Set up real-time token tracking and cost dashboards for every development team
Establish strict context boundary rules to prevent agents from processing irrelevant codebase files
Implement automated fallback mechanisms that escalate tasks to premium models upon compilation failures

By implementing this structured checklist, technology leaders can build a scalable, secure, and cost-effective development platform that drives engineering productivity and protects the company's bottom line.

Navigate the Changing Landscape of AI Development

The economics of AI coding are changing rapidly, and the stacks of yesterday are no longer viable. To succeed in this fast-paced environment, technology leaders must move away from single-model architectures and embrace a hybrid, multi-model approach that prioritizes context caching and cost optimization. By building a flexible, future-ready platform, organizations can maximize the productivity benefits of AI while maintaining control over their operational budgets, ensuring long-term competitiveness in a digital economy. The future of software engineering is efficient, and the stack is ready.

Per-Subagent Model Routing: Cheap Models for Boilerplate, Strong Models for Hard Bugs

Eva Clari — Mon, 17 Aug 2026 05:29:00 +0000

The architecture of AI coding assistants is evolving from single-model chat interfaces to multi-agent systems. In these systems, a primary coordinator agent delegates specific programming tasks to specialized subagents. A key challenge in operating these multi-agent pipelines is managing the cost and latency of the underlying large language models. Running every subagent task through a premium, high-capacity model is financially unsustainable. To solve this problem, engineering teams are implementing per-subagent model routing, utilizing cheap, fast models for repetitive boilerplate tasks and reserving premium models for complex reasoning and debugging.

This routing strategy treats models as specialized computing resources, matching the complexity of the task with the capabilities of the model. By designing a coordinated model pipeline, software teams can reduce API costs dramatically while improving response speeds, making interactive AI-assisted coding practical at an enterprise scale.

Understand the Subagent Roles in the Coding Pipeline

To implement model routing, you must define the different roles within a multi-agent coding pipeline. A typical pipeline includes at least four types of subagents, each performing a distinct function. The first is the researcher subagent, which searches the codebase, reads files, and locates relevant code symbols. This task involves high-volume context processing but requires low reasoning capabilities, making it ideal for large-context, inexpensive models that can quickly parse text.

The second is the builder subagent, which generates code, writes unit tests, and drafts boilerplate structures. While this requires code syntax knowledge, it remains relatively straightforward for mid-sized, specialized code models. The third is the compiler subagent, which executes build commands and parses compilation errors. This is a deterministic task that requires parsing log outputs and mapping them to files, which can be handled by small, fast models or traditional non-LLM scripts.

The fourth is the debugger subagent, which resolves complex compilation failures, logical bugs, and system integration issues. This role requires advanced reasoning, system-level understanding, and iterative problem-solving capabilities. When the builder or compiler subagent encounters an error they cannot resolve, the system escalates the task to the debugger subagent, which runs on a premium model. This escalation path ensures that expensive computing resources are only utilized when simple approaches fail.

Analyze the Financial and Performance Benefits of Routing

The economic impact of per-subagent model routing is substantial. A typical multi-agent coding run can involve dozens of model calls as the agent searches files, drafts code, compiles, and tests. If every call runs on a frontier model, the API cost per task can quickly become prohibitive. A 2024 analysis by the Software Engineering Institute (SEI) on corporate AI adoption showed that implementing dynamic model routing reduces average API costs by over 60 percent compared to single-model architectures, without sacrificing task completion rates.

Performance latency is another critical benefit. Smaller models with fewer parameters generate tokens significantly faster than large frontier models. By routing boilerplate generation to a fast, specialized model, developers receive code suggestions in real time, reducing the time they spend waiting for the agent to complete a task. This rapid feedback loop is essential for maintaining an interactive, productive developer experience.

However, model routing requires a robust fallback mechanism. If a cheap model fails to generate valid code or resolve a compilation error after a few attempts, the system must automatically escalate the task to a more capable model. This escalation path prevents the agent from getting stuck in loops of low-quality attempts, protecting the developer's time and ensuring that complex bugs are resolved by models with sufficient reasoning capacity.

Implement a Dynamic Model Routing Pipeline

To deploy per-subagent model routing, platform engineers must build a routing coordinator that manages token allocation and task escalation. The coordinator receives task requests from the primary agent, evaluates the task complexity based on historical metadata or prompt classification, and selects the optimal model from the available providers. The routing rules should be stored in a centralized configuration file, allowing teams to swap models as new, cheaper options become available on the market.

A 2023 McKinsey report on cloud infrastructure optimization highlighted that dynamic resource routing is the single most effective way to manage the costs of generative AI applications. By treating LLMs as specialized database resources and routing queries based on complexity, enterprises can scale their AI development tools to thousands of engineers without exceeding their budgets.

A Routing Checklist for Platform Engineers

To design an effective model routing pipeline, platform engineering teams should follow a structured implementation plan. When you develop your agentic routing strategy, ensure your system incorporates these essential components:

Classify subagent tasks into distinct tiers based on reasoning complexity and context size requirements
Set up a centralized routing configuration that maps subagent roles to specific model endpoints
Implement automated latency and cost tracking for every subagent execution run
Establish strict fallback rules that escalate tasks to premium models after a defined number of failed attempts
Optimize prompt templates for each target model to ensure consistent output formatting and quality
Monitor task completion rates and API spend weekly to refine routing thresholds and model selections

By implementing this structured checklist, platform engineers can build a cost-effective, high-performance developer platform that leverages the strengths of multiple models.

Prepare for the Multi-Model Developer Platform

The future of software development belongs to coordinated, multi-agent systems that utilize the entire spectrum of language models. By implementing per-subagent model routing, organizations can overcome the cost and latency barriers that limit enterprise AI adoption. This strategic approach ensures that developers receive fast, affordable assistance for routine tasks while maintaining access to advanced reasoning capabilities for complex system integration and debugging. The engineering teams that master multi-model orchestration will lead the next wave of software productivity.

What 51% AI-Written Code on GitHub Actually Means for Review Culture

Eva Clari — Mon, 10 Aug 2026 11:43:22 +0000

The volume of machine-generated code in public repositories is growing rapidly. Recent developer telemetry indicates that a substantial portion of code committed to platforms like GitHub is generated by artificial intelligence tools. While advocates celebrate this trend as a major productivity breakthrough, it introduces a critical challenge for engineering organizations: the breakdown of code review culture. When the speed of code generation outpaces the capacity of human review, developers face a major bottleneck.

Reviewing code is a fundamental practice that protects system stability, ensures compliance, and facilitates knowledge sharing within engineering teams. However, when developers receive pull requests containing hundreds of lines of AI-generated boilerplate, the traditional review process becomes slow and exhausting. To prevent code quality from declining, engineering leaders must redesign their review workflows to adapt to the realities of AI-assisted software development.

Analyze the Impact of High-Volume Code Generation on Reviewers

The primary challenge of AI-generated code is the sheer volume of changes. Because an AI agent can write hundreds of lines of code in seconds, developers can open complex pull requests much faster than before. Human reviewers, who must manage their own programming tasks, struggle to keep up with the review queue. This imbalance leads to two negative outcomes: review bottlenecks that delay project delivery, or superficial approvals where developers sign off on code without fully understanding it.

Superficial code review is particularly dangerous for enterprise systems. AI models can introduce subtle logic errors, security vulnerabilities, or inefficient algorithms that are difficult to spot during a quick scan. A 2024 GitClear study on code quality trends showed that the proportion of code churn (code that is rewritten or deleted within two weeks of commit) has increased by over 15 percent since the widespread adoption of AI coding assistants. This statistic suggests that while developers write code faster, they also write more mistakes that require correction later.

Furthermore, high-volume code generation threatens the educational value of code reviews. Traditionally, code reviews served as a mentorship channel where senior engineers taught junior developers best practices, architectural principles, and domain-specific knowledge. When reviews consist mostly of approving machine-generated boilerplate, these learning opportunities disappear, which can stunt the long-term professional development of junior engineers.

Shift from Line-by-Line Inspection to Architectural Verification

To adapt to the volume of AI-generated code, engineering teams must change how they conduct reviews. Do not waste human reviewer time checking syntax, formatting, or basic unit tests. Automated tools should handle these checks before a human reviewer even opens the pull request. The human review should focus on high-level concerns, such as architectural alignment, system integration, security models, and long-term maintainability.

L&D and engineering leaders should train developers to write comprehensive, automated test suites that verify the behavioral outcomes of AI-generated code. If the tests prove that the code behaves correctly under various conditions, the reviewer does not need to inspect every line of boilerplate. Instead, they inspect the test design and verify that the code integrates cleanly with the existing system architecture. This shift from line-by-line inspection to verification allows teams to maintain quality without slowing down deployment.

Additionally, engineering organizations must establish clear rules regarding AI code authorization. Developers must take full responsibility for the code they commit, regardless of whether a machine wrote it. If an AI assistant introduces a bug or a security vulnerability, the developer who approved the code remains responsible for resolving it. This accountability ensures that developers remain vigilant and inspect AI outputs carefully before submitting them for review.

Implement a Automated Code Review Pipeline

To manage the review workload, organizations should implement an automated pre-review pipeline. This pipeline acts as a filter, ensuring that human reviewers only receive code that meets baseline quality standards. The pipeline should run linting tools, security scanners, dependency checkers, and unit test suites automatically upon pull request submission. If any of these automated checks fail, the pull request should be blocked, requiring the author to resolve the issues before requesting human review.

A 2024 survey by the DevOps Research and Assessment (DORA) group revealed that organizations with highly automated testing and review pipelines report 47 percent faster deployment cycles and significantly lower change failure rates than those with manual processes. By automating low-level checks, you protect your senior engineers from review burnout and ensure they can focus their expertise on complex architectural challenges that require human judgment.

A Code Review Checklist for Modern Engineering Teams

To ensure consistent quality in the era of AI-generated code, engineering teams should follow a structured review checklist. When you evaluate a pull request containing machine-generated code, verify that your review addresses these critical areas:

Ensure all automated syntax, formatting, and unit tests pass before initiating human review
Inspect the test coverage to verify that the tests check boundary conditions and error handling
Evaluate how the new code integrates with existing databases, APIs, and system architectures
Check for common security vulnerabilities, such as unvalidated input or insecure dependency usage
Verify that the code avoids unnecessary complexity and conforms to internal style guidelines
Confirm that the author has documented any non-obvious design choices or architectural changes

By implementing this structured checklist, engineering teams can safely leverage the speed of AI code generation while maintaining the high standards required for stable, enterprise-grade software systems.

Build a Resilient Review Culture for the AI Era

AI coding tools are transforming the software development lifecycle, but they do not eliminate the need for human oversight. The organizations that succeed in this new era will be those that adapt their review cultures to handle the volume of machine-generated code. By automating baseline checks, focusing human expertise on architecture, and maintaining developer accountability, engineering teams can capture the productivity benefits of AI without sacrificing code quality or system stability. The future of software engineering requires a balance between machine speed and human judgment.

Inside the Agentic Coding Stack: Terminal Agents, IDEs, and Cheap Models Working Together

Eva Clari — Mon, 10 Aug 2026 11:39:14 +0000

The software development workflow is shifting from human-authored code with AI assistance to fully agentic systems. In this new paradigm, developers do not just write code with tab-completion tools. They collaborate with autonomous AI agents that can read codebases, run tests, diagnose errors, and write multi-file edits. Understanding how these tools work together represents a critical skill for modern software engineers. The modern agentic stack is not built on a single all-powerful model, but rather on a coordinated pipeline that combines terminal agents, interactive development environments (IDEs), and specialized, cheap language models.

This shift is driven by the realization that LLMs alone cannot build complex systems. An isolated model has no tool access to verify output. Embedded in a runtime environment with filesystem, shell, and test runner access, the model becomes part of a robust agentic stack transforming software engineering.

Define the Components of the Agentic Coding Stack

To understand the agentic stack, you must examine its three core layers. The first layer is the terminal agent. Unlike code assistants that only suggest text changes, a terminal agent can execute commands directly on the user's system or in a secure sandbox. It operates in a loop: proposing a code change, running compilation or testing commands, reading the errors, and iterating until the tests pass. By using the shell as a feedback mechanism, terminal agents can verify the correctness of their work before presenting it to the developer, reducing syntax errors and build failures.

The second layer is the interactive development environment (IDE) integration. Terminal agents need context to make intelligent edits, and the IDE serves as the primary context provider. Modern agentic IDEs track user actions, such as which files are open, where the cursor is positioned, and recent compilation results. This metadata is packaged and sent to the agent alongside the user's prompt. Furthermore, the IDE provides a user interface for review, allowing developers to inspect file diffs, approve command execution, and guide the agent when it encounters ambiguity.

The third layer is the underlying language models. In the early stages of AI coding, developers assumed that only the largest, most expensive models could handle programming tasks. Today, the stack relies on a mixture of models. Large models are reserved for complex planning and architectural decisions, while smaller, cheaper models handle repetitive tasks like boilerplate generation, code formatting, and simple search queries. A 2024 GitHub developer survey revealed that over 70 percent of enterprises utilize multi-model routing to optimize cost and performance in their AI pipelines.

Analyze the Economics of Model Routing

Running every agent request through a frontier model is financially unsustainable for large teams. A typical run involves dozens of iterations processing large code contexts. By routing lookup and editing tasks to smaller, optimized models, teams reduce API costs significantly.

Furthermore, smaller models often deliver faster response times. A 2024 benchmark report by Hugging Face on code-generation models showed that specialized models with under 8 billion parameters can generate boilerplate code up to four times faster than frontier models, while maintaining comparable accuracy on simple tasks. This speed difference is critical for maintaining an interactive developer experience. When the agent can compile and test code in seconds using a fast model, the human-in-the-loop review process becomes much smoother.

Model routing must be managed dynamically. If a cheap model fails to resolve a compilation error after a few attempts, the system escalates the task to a premium model. This prevents infinite loops, balancing cost, latency, and completion rates.

Implement a Cooperative Agentic Workflow

To get the best results from the agentic coding stack, developers must adopt a cooperative workflow. Do not treat the agent as a magic solution that solves everything in one go. Instead, break down complex tasks into smaller, verifiable components. Start by asking the agent to research the codebase and outline an implementation plan. Review this plan, correct any assumptions, and then authorize the agent to execute the first step.

Once the agent completes a step, verify the changes immediately. Run unit tests, check linting results, and inspect the git diff. If the agent makes a mistake, provide specific feedback pointing to the failed test or compilation error. This iterative, step-by-step approach ensures that errors are caught early before they compound, making it much easier to guide the agent to a correct solution. Working with agents is a collaborative process that requires active developer guidance to succeed.

A Cooperative Coding Checklist for Developers

To maximize productivity with agentic tools, engineering teams should follow a structured development checklist. When you launch an agentic coding task, ensure your workflow incorporates these essential steps:

Define a narrow, specific goal for the agent before authorizing any file modifications
Research the relevant files and provide the agent with direct links or references to reduce search times
Authorize command execution, such as compiling or testing, in a secure, isolated sandbox environment
Review all file modifications using a visual diff tool before committing the changes to your branch
Establish automated test suites that the agent can run independently to verify its code edits
Implement rollback mechanisms so you can easily discard the agent's work if it goes off track

By implementing this structured checklist, developers can safely delegate repetitive tasks to AI agents while maintaining full control over the codebase quality and system architecture.

Prepare for the Agent-Led Future of Software Engineering

Software development is changing, and agents are here to stay. Developers who orchestrate these tools will lead the industry. By adopting cooperative workflows, optimizing costs, and establishing testing frameworks, engineering teams can increase output and focus on complex architectural problems. The future of coding is collaborative, and the stack is ready.

How Autonomous Systems Are Built: From Rules to Reinforcement Learning

Eva Clari — Mon, 27 Jul 2026 04:30:00 +0000

Every autonomous system you read about today, self-driving cars, warehouse robots, trading agents, traces back to a simpler ancestor: a stack of if-then rules written by an engineer who tried to anticipate every situation. That approach worked until the real world produced a situation nobody wrote a rule for. The history of autonomous systems is largely the history of teams discovering that limit and building better ways around it.

Rule-Based Systems and Why They Break

Early autonomous systems, from 1980s expert systems to first-generation industrial robots, encoded human knowledge as explicit logic. A medical diagnosis system checked symptoms against a decision tree. A factory arm followed a fixed sequence of coordinates. Engineers hand-wrote the rules, and the system executed them.

This design has real advantages. Rule-based systems produce predictable output, engineers can trace every decision back to a specific line of logic, and regulators can audit them line by line. That transparency still makes rule-based logic the right choice for narrow, well-defined tasks like tax calculation or compliance checks.

The failure mode shows up at the edges. A rule-based system handles cases its authors imagined and fails, often silently, on everything else. Add a new product line, sensor, or market condition, and someone must manually extend the rule set, and each new rule can interact unpredictably with the ones already there. MYCIN and other 1970s and 1980s expert systems hit exactly this wall: they performed well in demos but could not scale their rule bases to match real medical practice. The lesson generalized well beyond medicine, into any domain where the environment changes faster than a human can write logic for it.

Supervised Learning Solves Perception, Not Decision-Making

The next major shift replaced hand-written rules with learned pattern recognition. Instead of coding "if edge count exceeds threshold, classify as obstacle," engineers fed a model thousands of labeled images and let it learn the mapping between input and output directly. Convolutional neural networks turned computer vision from a rule-engineering problem into a data problem, and by the mid-2010s supervised learning dominated tasks like image classification, speech recognition, and object detection.

Supervised learning solved perception. A model can now identify a pedestrian, a stop sign, or a defective part on a production line with accuracy that rule-based vision systems never approached. But perception is only half of what an autonomous system needs. Recognizing an object differs from deciding what to do about it, and supervised learning has no native concept of consequence. A labeled dataset tells the model what the correct answer looked like in the past, and says nothing about how one decision changes the state the system faces next, exactly the problem sequential decision-making creates.

Why Reinforcement Learning Fits Sequential Decisions

Driving a car, managing a warehouse fleet, or running a trading strategy is not a single classification task, it is a sequence of decisions where each choice changes the situation the system faces next. Reinforcement learning (RL) models this directly: an agent takes an action, the environment returns a new state and a reward signal, and the agent updates its policy to favor actions with higher cumulative reward over time.

Two design problems define how well an RL system performs. The first is reward shaping. A poorly designed reward function produces an agent that optimizes the literal metric instead of the intended goal, a pattern researchers call reward hacking. OpenAI's 2016 boat-racing agent learned to spin in circles collecting bonus items instead of finishing the race, because the reward function rewarded points, not completion. Getting the reward function to represent the actual goal takes as much engineering effort as the model architecture itself.

The second is the exploration versus exploitation tradeoff. An agent that only exploits what it already knows never discovers a better strategy, and an agent that only explores never converges on a reliable one. DeepMind's AlphaGo and later AlphaZero research demonstrated how self-play combined with Monte Carlo tree search balances this tradeoff at scale, letting an agent explore millions of positions while still converging toward strong play. That same balancing act, tuned differently, governs how a warehouse robot learns efficient picking routes.

The Simulation-to-Real Gap

RL agents need enormous numbers of trial-and-error episodes to learn, far more than any physical robot or vehicle fleet can safely generate in the real world. The practical answer is simulation: train the agent in a physics engine where a crashed car or a broken robotic arm costs nothing, then transfer the trained policy to physical hardware.

This transfer is not automatic and does not always work cleanly. Simulators approximate friction, sensor noise, lighting, and material properties, but never fully replicate them, so a policy that performs well in simulation can degrade sharply on real hardware. Researchers call this the reality gap. Teams close it with domain randomization, where the simulator varies textures, lighting, and physical parameters during training so the agent learns a policy robust to variation rather than one overfit to a single environment. OpenAI's 2019 Rubik's Cube manipulation research used this technique to train a robotic hand in simulation and transfer the skill to a physical robot. Even with domain randomization, sim-to-real transfer remains one of the most labor-intensive parts of deploying an RL system outside a lab.

Where Full Autonomy Still Fails

Despite the progress from rules to supervised learning to reinforcement learning, no widely deployed system operates with full autonomy in an open, unconstrained environment. Three problems explain why.

Edge cases remain the hardest unsolved issue. A self-driving system trained on millions of miles of ordinary road conditions still struggles with a rare combination it has not seen, a construction worker directing traffic in an unfamiliar way, an object partially obscured by unusual weather. McKinsey's 2024 State of AI report notes that organizations deploying autonomous and agentic AI systems consistently cite reliability in rare, high-stakes scenarios as the top blocker to expanding deployment scope.

Safety guarantees are difficult to prove for learned systems in a way they are not for rule-based ones. Engineers can formally verify a rule-based system against a specification. Nobody can easily prove a neural network policy trained through RL safe across the full input space, because its behavior emerges from training data and reward shaping rather than explicit logic anyone can inspect line by line.

Interpretability compounds both problems. When a rule-based system makes a wrong call, an engineer traces the exact rule that fired. When a deep RL policy makes a wrong call, tracing that decision back to a specific cause inside millions of learned parameters takes far more effort, which slows debugging and complicates regulatory approval in healthcare and transportation.

The Practical Takeaway

The path from rules to reinforcement learning is not one approach replacing another, it is a matter of matching technique to the right layer of the problem. Rules still govern compliance boundaries. Supervised learning still handles perception. Reinforcement learning still drives sequential decisions. Teams that treat autonomy as a single model to train usually get worse results than teams that treat it as a layered system, each layer suited to what it does best.

Designing Scalable Data Pipelines for Machine Learning Applications

Eva Clari — Mon, 20 Jul 2026 04:15:00 +0000

Most ML projects do not fail because the model is wrong. They fail because the data pipeline feeding the model cannot survive contact with production. A notebook that trains a model on a clean CSV proves nothing about whether that model gets fresh, correct, timely data once real users and real systems are involved.

Data engineering and ML engineering are converging fast. Teams that treat pipeline design as a first-class discipline ship faster and break less often than teams that treat it as plumbing.

Batch vs Streaming: Choosing the Right Processing Model

The first architectural decision is whether a pipeline processes data in batches or as a continuous stream, and this choice shapes everything downstream.

Batch pipelines process accumulated data on a schedule: hourly, daily, or triggered by an event like a file landing in storage. They suit training pipelines, periodic feature recomputation, and workloads where a few hours of staleness is acceptable. Batch systems are simpler to reason about, easier to debug, and cheaper to run since compute is not always-on.

Streaming pipelines process events as they arrive, typically through a message broker like Apache Kafka, AWS Kinesis, or Google Pub/Sub. They fit use cases where prediction freshness matters: fraud detection, recommendation systems reacting to a user's last three clicks, or dynamic pricing. Streaming introduces real complexity: out-of-order events, late-arriving data, windowing logic, and infrastructure that runs continuously rather than on a schedule.

Most production ML systems do not pick one model exclusively. A common pattern is the lambda architecture, where a batch layer computes accurate historical features and a streaming layer computes approximate real-time features, with both feeding the same model through a shared feature store. Choosing streaming when batch would do adds operational cost without benefit. Choosing batch for a real-time inference need produces a model that answers questions users already stopped asking.

Feature Stores: Closing the Training-Serving Gap

The single most common bug in production ML is training-serving skew: a feature computed one way during training and a slightly different way during inference. A model trained on a seven-day rolling average and served with a feature pipeline that computes a five-day average will degrade silently, and the failure often looks like model drift rather than a pipeline bug.

Feature stores exist to close this gap. Tools like Feast, Tecton, and the feature store components inside Databricks and SageMaker let a team define a feature once and serve it consistently to both the training job and the online inference endpoint. The store typically splits into an offline store for large-scale batch training data and an online store, usually a low-latency key-value database like Redis or DynamoDB, for real-time lookups at inference time.

A feature store also solves feature reuse across teams. Without one, every model team recomputes the same customer lifetime value or session-length feature with slightly different logic, and nobody can explain why two models disagree. A shared, versioned feature definition removes that ambiguity.

Data Versioning, Lineage, and Reproducibility

A model trained six months ago on data that no longer exists in its original form is not reproducible, and that is a compliance and debugging problem, not just an inconvenience. When a stakeholder asks why a model made a specific prediction, the answer often requires reconstructing the exact training dataset, the exact feature transformations, and the exact code version used at that point in time.

Data versioning tools like DVC, LakeFS, and Delta Lake's time travel feature let you snapshot datasets the way Git snapshots code. Combine that with lineage tracking, which records how each dataset was derived from upstream sources through which transformations, and you get an audit trail that answers "where did this number come from" without archaeology.

Lineage matters even more once a pipeline breaks. When a downstream metric looks wrong, tooling like OpenLineage or Marquez lets an engineer trace the anomaly back to the source table, instead of grepping through scattered scripts and guessing.

Schema Drift and Data Quality at Scale

Upstream systems change without warning. A product team renames a column, an event schema adds a new required field, or a third-party API silently changes a data type from integer to string. In a small pipeline, someone notices immediately. In a pipeline processing millions of rows a day across dozens of sources, that change propagates before anyone catches it, and the first sign of trouble is a model producing nonsense predictions.

Schema drift detection needs to be automated, not manual. Tools like Great Expectations, Deequ, and Soda Core let teams define expectations (this column is never null, this value falls within this range, this categorical field only contains these values) and run them as part of every pipeline execution. A failed expectation should stop the pipeline before bad data reaches a training job or a serving layer, not after a model has already been retrained on corrupted inputs.

According to the Great Expectations 2024 State of Data Quality report, data quality issues remain a top cited cause of delayed ML deployments among surveyed data teams, ahead of model performance problems. Data quality is not a check bolted on at the end. It is the layer that decides whether everything built on top of it can be trusted.

Orchestration: Where the Pipeline Actually Runs

None of the above matters if there is no reliable system scheduling, retrying, and monitoring the pipeline. Orchestration tools coordinate dependencies between tasks, handle failures, and give engineers visibility into what ran, what failed, and why.

Apache Airflow remains the most widely adopted orchestrator, with DAGs defined in Python and a large ecosystem of operators for databases, cloud storage, and ML platforms. Dagster takes a more asset-centric approach, treating datasets and features as first-class objects with typed contracts between steps, which catches integration errors earlier than Airflow's task-centric model. Kubeflow Pipelines targets teams already running on Kubernetes who want orchestration spanning both data preparation and model training in the same DAG, with native GPU scheduling support.

The right choice depends less on feature checklists and more on team context: existing infrastructure, the skill set already on the team, and whether the primary need is generic data movement or ML-specific workflow tracking.

From Notebook to Production: The Gap Nobody Budgets For

A notebook proves an idea works on a fixed dataset at a single point in time. Production requires that same logic to run correctly on data that changes shape, arrives late, occasionally goes missing, and gets processed by multiple people who did not write the original notebook.

Closing that gap means turning notebook cells into tested, parameterized, version-controlled functions, adding monitoring and alerting for pipeline health and data quality, and building retry and backfill logic for the inevitable day something fails at 2 a.m. It also means separating fast, exploratory idea validation from the production-hardening work that follows the same engineering discipline as any other critical service. Teams that skip this transition end up with a fragile pipeline nobody wants to touch, and every new feature request risks breaking training or serving.

Building this discipline early costs less than rebuilding a pipeline after a bad model deployment. Structured data engineering training helps teams build these skills before the pipeline becomes the bottleneck.

Why Low-Code and AI Won’t Replace Developers, But Will Change Their Jobs

Eva Clari — Mon, 13 Jul 2026 05:30:00 +0000

Every few months a new tool promises to close the gap between "I have an idea" and "it is in production" without a developer in between. GitHub Copilot writes functions from a comment. Cursor scaffolds entire modules from a prompt. Bubble and Retool let a product manager wire up an internal tool over lunch. The pitch is always the same: developers become optional.

They do not. The Stack Overflow Developer Survey 2024 found over 76% of developers already use or plan to use AI tools in their workflow. Adoption is real and it is fast. But adoption of a tool is not the same as replacement of a role. What is actually happening is a redistribution of where developer effort goes, and that redistribution has a shape worth understanding before you plan headcount, training, or team structure around it.

What Low-Code and AI Actually Automate Well

Start with what these tools are genuinely good at, because the honest answer is: a lot.

CRUD scaffolding is the clearest win. Generating a model, a set of REST endpoints, basic validation, and a form to match takes a senior developer twenty minutes of typing they have done a thousand times before. AI code generation tools do it in seconds, and low-code platforms skip the code step entirely for simple cases. Nobody's career depended on typing that boilerplate anyway.

Simple integrations follow the same pattern. Connecting a webhook to a Slack notification, pulling records from a third-party API into a database table, or wiring a payment provider's standard checkout flow are well-documented, well-trodden paths. Thousands of developers have solved the exact same problem before, so pattern-matching tools excel here.

Boilerplate and repetitive structure round out the list: test scaffolds, config files, standard error handling, typed interfaces generated from a schema, migration scripts. These are mechanical transformations from one structured format to another, and a tool that has seen millions of examples reproduces the pattern reliably.

The common thread: these tasks have a well-defined shape, a single obvious correct answer, and low risk if the generated code needs a manual tweak afterward. That is precisely the zone where automation works.

Where These Tools Consistently Fail

The failure zone is just as clear, and it maps directly to problems that do not have a single obvious answer.

Complex business logic is the first casualty. A discount engine that applies promotional rules, loyalty tiers, regional tax exceptions, and inventory constraints in the correct order is not a pattern-match problem, it is a domain-knowledge problem. The AI tool does not know your company's pricing policy exists, let alone how the exceptions interact. It produces plausible-looking code that quietly violates a rule nobody documented anywhere it could read.

Architecture decisions fail for a related reason: they require trade-off judgment the tool cannot access. Should this service own its own database or share one? Should this workflow be synchronous or event-driven? These decisions depend on your team's operational maturity, traffic patterns, on-call capacity, and business priorities that live in meetings, not in a codebase. A generation tool has no way to weigh them.

Debugging distributed systems is where the gap becomes obvious fast. When a request times out intermittently across four microservices, the fix requires tracing causality across service boundaries, correlating logs from systems that were never designed to talk to each other, and forming a hypothesis about a race condition that only manifests under specific load. AI tools reason well about a function in front of them. They do not reason well about a system that spans a dozen files, three data stores, and a message queue.

Security review is the sharpest failure point of all. Low-code platforms in particular have a track record of generating auth flows with excessive default permissions, exposing internal APIs without proper access control, or storing secrets in a way that passes a demo but fails an audit. AI-generated code shows similar patterns: a 2023 Stanford study on AI pair programming found developers using code assistants introduced more security vulnerabilities while also feeling more confident their code was correct. Confidence without verification is the exact combination that makes a security review indispensable, not optional.

How the Developer Role Is Actually Shifting

None of this means less developer work. It means different developer work, and the shift has a consistent direction: away from typing, toward judgment.

Review is becoming a bigger share of the job. When a tool generates a pull request's worth of code in ten seconds, someone still has to read every line, check it against the actual requirements, and decide whether it is safe to merge. That review work used to be a smaller fraction of a developer's day. Now it often dominates the interaction with AI-generated output.

Orchestration is replacing some of the manual assembly work. A developer increasingly breaks a feature into pieces, decides which pieces are safe to generate and which need careful human attention, and stitches the results into a coherent system. That stitching, deciding what goes where and how the pieces talk to each other, is architecture work, and it has not gotten easier just because the typing got faster.

Prompt-and-verify has become its own skill. Getting a useful result from an AI coding tool means scoping the request tightly enough to get a correct answer, then checking that answer against edge cases the tool never considered. Developers who are good at this produce results faster than developers who either refuse to use the tools or trust them blindly.

Rote typing, on the other hand, is shrinking as a share of the job, and it should. It was never the valuable part.

The Skills That Are Becoming More Valuable

As the mechanical work moves to tools, the skills that do not automate well are the ones commanding a premium.

Systems thinking tops the list. Understanding how a change in one service ripples through five others, how a schema change affects every downstream consumer, and how a caching layer interacts with data freshness requirements is exactly the holistic reasoning that generation tools skip. It requires holding a mental model of the whole system, not just the function in front of you.

Code review judgment is close behind. Reading generated code and correctly identifying "this looks right but will break under concurrent writes" or "this satisfies the ticket but violates our data retention policy" takes real experience with how systems fail in production, not just familiarity with syntax.

Architecture and design decisions round out the set. Choosing the right data model, the right consistency guarantees, the right service boundaries, these decisions set the ceiling on how maintainable a system will be for years, and they require weighing trade-offs no tool has enough context to weigh for you.

Where This Leaves Engineering Teams

The developers who lose ground here are the ones who defined their value by typing speed. The developers who gain ground are the ones who can generate quickly, review ruthlessly, and hold the architecture of a system in their head while doing both. That was always the harder, more valuable half of the job. Low-code and AI just made the easier half fast enough that it stopped being where the differentiation lives.