DEV Community: Eva Clari

The New Cost Curve of LLM APIs and What It Means for Your Side Project Budget

Eva Clari — Fri, 23 Oct 2026 10:31:36 +0000

Building an AI-powered side project used to sound expensive. You needed infrastructure, computing resources, machine learning expertise, and enough money to experiment without worrying about every API call.

That picture has changed.

Today, a solo developer can build a chatbot, content assistant, coding tool, research agent, or small automation product using hosted large language model (LLM) APIs. You don't need to train your own model or maintain a GPU server to get started.

But there's a catch: making an AI prototype affordable is one thing; keeping a useful product affordable as people start using it is another.

LLM API pricing has introduced a new kind of budgeting challenge. Your costs depend not only on which model you choose, but also on how much context you send, how long the responses are, how often users interact with your product, and how efficiently your application handles each request.

If you're building a side project on a limited budget, understanding this cost curve can help you avoid paying for more AI than you actually need.

1. Why LLM API Costs Are Changing the Way We Build

Traditional software often has predictable costs. You might pay a monthly hosting fee, purchase a domain, and cover database expenses.

LLM APIs work differently. Many providers charge based on usage, especially the number of input and output tokens processed.

Tokens are the small pieces of text that language models read and generate. They can represent complete words, parts of words, punctuation, or other text elements.

Most API pricing separates three categories:

Input tokens: The instructions, user messages, and context sent to the model.
Output tokens: The text the model generates.
Additional usage: Depending on the provider, this may include cached input, image processing, audio, tool calls, or other specialized capabilities.

The distinction matters because input and output tokens can have different prices. A model that generates a long report may cost substantially more than one that answers a short question.

Consider a simple AI writing assistant. A user asks for a product description, but your application also sends a lengthy system prompt, brand guidelines, previous conversation history, and several examples.

The user sees one response. Your API bill reflects all the information processed to produce it.

This is why the real cost of an LLM-powered product isn't determined by the model name alone. It's determined by the combination of model pricing and application design.

2. Understanding the New LLM API Cost Curve

The biggest opportunity for small developers is that different models can serve different needs.

You don't necessarily need the most capable model for every request. A lightweight model may be sufficient for classification, simple rewriting, extracting structured information, or answering straightforward questions. More capable models can be reserved for tasks involving complex reasoning, difficult coding problems, or nuanced analysis.

The result is a more flexible cost curve.

A practical way to think about model selection is to divide tasks into three groups:

Low-complexity tasks: Categorizing support tickets, cleaning up text, generating short summaries, and extracting fields from documents.

Medium-complexity tasks: Drafting articles, answering questions using retrieved documents, producing marketing content, and helping users with everyday coding tasks.

High-complexity tasks: Multi-step research, complicated debugging, complex planning, and problems that require careful reasoning across multiple sources.

These categories are starting points, not fixed rules. A smaller model may perform well on a seemingly difficult task, while a larger model may be necessary for a task that looks simple but requires high accuracy.

The key is to test model quality against your actual use case.

A cheaper model isn't automatically better if it produces unreliable answers that require expensive retries or human correction.

Likewise, an expensive model isn't automatically worth its price if users can't distinguish its output from that of a less costly alternative.

3. Calculate Your Monthly API Budget Before You Launch

Let's turn the idea into a simple calculation.

Suppose you're building an AI assistant that handles 1,000 requests per month. Each request uses an average of 2,000 input tokens and generates 500 output tokens.

Your estimated monthly usage would be:

Metric	Monthly usage
Requests	1,000
Input tokens per request	2,000
Total input tokens	2 million
Output tokens per request	500
Total output tokens	500,000

Now suppose the model you select has an illustrative price of $0.50 per million input tokens and $2.00 per million output tokens.

Your estimated API bill would be:

Input: 2 × $0.50 = $1.00
Output: 0.5 × $2.00 = $1.00
Total: $2.00 per month

These prices are hypothetical examples for demonstrating the calculation, not current quotes from a particular provider. Actual pricing varies by model, provider, region, and billing conditions.

The formula is straightforward:

Monthly API cost = (input tokens ÷ 1,000,000 × input price) + (output tokens ÷ 1,000,000 × output price)

For planning purposes, convert the result into your local currency and account for exchange-rate changes, taxes, and any applicable payment or billing fees.

The calculation also assumes that each request makes one model call. If your application uses multiple calls for planning, tool selection, verification, and final responses, you must count those calls too.

This is where seemingly inexpensive prototypes can become more costly than expected.

4. Why Your First Cost Estimate Might Be Wrong

The biggest budgeting mistake is estimating costs using only the first prompt you test.

Real users behave differently from developers testing a prototype.

They ask follow-up questions, paste large documents, request multiple revisions, upload files, and expect the application to remember previous interactions.

Here are four common reasons your actual API bill may be higher than expected.

Long conversation histories

If your chatbot resends the entire conversation with every message, the input token count can grow with each turn.

A short interaction might be inexpensive, but a long session can require considerably more processing.

A practical solution is to summarize older conversation turns and retain only the information relevant to the current request.

Overly detailed system prompts

A long system prompt may contain instructions that are redundant or irrelevant to most requests.

Review your prompts and remove unnecessary examples, repeated instructions, and information that can be retrieved only when needed.

The goal isn't to make every prompt as short as possible. It's to preserve the instructions that improve output quality while eliminating unnecessary overhead.

Uncontrolled output length

A model that generates a 2,000-word answer when the user needs a short paragraph can increase your costs without improving the experience.

Set reasonable output limits, provide clear length instructions, and offer users control over the depth of their responses.

Multiple model calls per action

An AI agent might call a model to understand a request, another model to select a tool, another to evaluate the result, and a final model to write the answer.

That workflow can be useful, but every additional call needs a reason.

For simple tasks, a single well-designed call may be enough. Reserve multi-step workflows for situations where they provide measurable value.

5. Five Ways to Keep Your Side Project Affordable

You don't need a complicated infrastructure setup to control your AI spending. A few deliberate design choices can make a meaningful difference.

1. Start with the smallest model that meets your quality requirements

Choose a representative set of real tasks and compare available models.

Measure accuracy, response quality, latency, and cost. If a cheaper model handles a task reliably, use it instead of paying for additional capabilities you don't need.

For example, an AI email assistant might use a lightweight model to classify an email and a more capable model only when a user requests a detailed response.

2. Use retrieval instead of sending everything

Suppose you're building a chatbot for a collection of technical documentation.

Sending the entire documentation library with every request is inefficient. Instead, retrieve the most relevant passages and send those to the model.

This retrieval-augmented generation (RAG) approach can reduce unnecessary context while improving the relevance of answers.

The retrieval system introduces its own costs, including storage, embeddings, and search infrastructure, so evaluate the complete workflow rather than assuming retrieval is always cheaper.

3. Take advantage of prompt caching where available

Some API providers offer discounted pricing for eligible repeated input prefixes.

This can be useful when your application repeatedly sends the same system instructions, policy documents, or other stable context.

Caching eligibility, pricing, and minimum requirements vary by provider and model. Check the current documentation before building your budget around expected savings.

4. Put limits on usage

A public AI tool can attract unexpected traffic, automated requests, or users who generate unusually long outputs.

Consider implementing:

Per-user request limits.
Maximum input and output sizes.
Daily or monthly usage quotas.
Authentication and abuse protection.
Spending alerts and emergency usage controls.

These safeguards are especially important if you offer a free tier.

A useful product can become financially unsustainable if a small number of users consume a disproportionate share of your API budget.

5. Measure cost per successful task

Total monthly spending doesn't tell the whole story.

Imagine two models. One costs less per request but frequently produces unusable results. The other costs more but consistently completes the task correctly.

If the cheaper model requires repeated attempts, its effective cost can be higher.

Track the cost of delivering a successful result, not just the cost of an individual API call.

6. Build a Budget Around Your Product's Stage

A side project doesn't need an enterprise-scale AI budget from day one.

Instead, increase spending as you gather evidence that users value what you're building.

Stage 1: Prototype

Focus on validating one core feature. Use a small test dataset, set strict usage limits, and record token consumption from the beginning.

Stage 2: Early users

Track average and maximum usage per user. Identify which features generate the most expensive requests and whether users return after trying the product.

Stage 3: Monetization

Calculate your variable cost per paying customer. Set subscription limits that reflect actual usage, and avoid promising unlimited access until you understand your cost distribution.

Stage 4: Growth

Introduce routing between models, caching, better retrieval, asynchronous processing, and other optimizations where the data supports them.

At every stage, the question is the same: does the additional spending produce enough value to justify itself?

7. Don't Forget the Costs Beyond the API

An affordable LLM API doesn't mean your entire application is free to operate.

Your budget may also include:

Web hosting and serverless functions.
Database and file storage.
Embedding generation and vector search.
Authentication, analytics, and monitoring.
Payment processing and subscription management.
Domain registration and email services.
Taxes, currency conversion, and other billing charges.

Some projects can run comfortably on free tiers during experimentation. Others need paid infrastructure much earlier.

Keep API expenses separate from infrastructure costs in your budget. That makes it easier to identify whether rising expenditure comes from more users, inefficient model calls, or an entirely different part of your application.

8. A Simple Rule for Pricing an AI Product

If you plan to charge users, estimate the cost of serving a typical customer before setting your subscription price.

For example, imagine a paid plan costs $10 per month and your average customer's LLM usage costs $2 monthly.

That leaves $8 before hosting, payment processing, support, taxes, and other expenses.

But if heavy users consume $12 in API calls, that customer generates a loss before those additional costs are included.

The lesson isn't to avoid generous usage limits. It's to design pricing around realistic usage patterns.

You might offer a fixed number of monthly credits, different plans for different usage levels, or a fair-use policy with transparent limits.

For products where customers value predictable spending, clear usage limits can be more appealing than an unlimited plan that later requires unexpected restrictions.

Final Thoughts

The changing economics of LLM APIs have made it easier for independent developers to experiment with AI without committing to expensive infrastructure upfront.

But access to affordable models is only part of the opportunity.

The real advantage comes from understanding your users' needs, selecting models deliberately, minimizing unnecessary context, and monitoring the cost of every meaningful action your application performs.

You don't need to predict your API bill perfectly before writing your first line of code. You need a reasonable estimate, a way to measure actual usage, and safeguards that prevent costs from growing faster than the value your product delivers.

Build small, measure early, and optimize what the data tells you to optimize.

That approach gives your side project a better chance of staying affordable while you turn an interesting AI experiment into something people genuinely want to use.

Why Vibe Coding Still Needs a Human Architect

Eva Clari — Fri, 16 Oct 2026 09:47:22 +0000

AI has changed the way we build software. What once required hours of writing boilerplate, debugging syntax, and connecting components can now begin with a simple conversation with an AI coding assistant.

Describe an application, explain how you want it to work, and watch the code take shape. This approach, commonly known as vibe coding, has made software development more accessible to beginners, entrepreneurs, and experienced developers alike.

But there is an important distinction between generating code quickly and building software that works reliably in the real world.

AI can help build the application. A human architect makes sure it is the right application, built on the right foundations.

What Is Vibe Coding?

Vibe coding is an AI-assisted development approach in which developers describe their requirements using natural language and rely on AI tools to generate, modify, and debug code.

Instead of manually implementing every component, developers can focus on describing the desired outcome, reviewing the results, and refining the application through repeated interactions.

For example, a developer might ask an AI tool to:

Build a responsive dashboard.
Connect an application to a database.
Create user registration and login functionality.
Generate API endpoints.
Fix common errors and improve the user interface.

This approach can significantly accelerate prototyping and reduce repetitive work. It also enables people with limited programming experience to experiment with ideas that might otherwise require a dedicated development team.

However, speed does not automatically guarantee good software engineering. A prototype that works during a demonstration may still have architectural weaknesses, security vulnerabilities, or maintenance problems.

That is where human architectural judgment becomes essential.

1. AI Generates Code, but Architecture Defines the System

Software architecture determines how an application is structured, how its components communicate, and how it handles changes over time.

AI can generate a database schema, create frontend components, or implement an API. But without clear architectural direction, these pieces may not fit together into a coherent system.

Imagine building an e-commerce application using vibe coding. The AI successfully creates product listings, a shopping cart, user accounts, and a checkout page.

Everything appears to work independently.

But what happens when inventory changes during checkout? How should payment failures be handled? Which service owns order status? How do you prevent duplicate transactions?

These questions require decisions about data ownership, service boundaries, transaction handling, and failure recovery.

A human architect considers the entire system before approving individual implementations.

The lesson: Use AI to accelerate implementation, but establish the architecture before allowing code generation to expand across the application.

2. Working Code Is Not Necessarily Production-Ready Code

One of the biggest misconceptions about vibe coding is that an application is finished when it runs successfully.

A working application is only the beginning.

Production software must also be reliable, maintainable, secure, and capable of handling unexpected situations.

AI-generated code may contain:

Inadequate input validation.
Missing error-handling logic.
Inefficient database queries.
Unnecessary dependencies.
Poor separation of responsibilities.
Incomplete test coverage.

These issues may not appear during a quick demonstration. They often emerge when real users interact with the application, data volumes increase, or external services fail.

A human architect evaluates the application beyond its visible functionality. They ask whether the code can be tested, whether its behavior is predictable, and whether future developers can understand and maintain it.

The goal is not simply to make the software work today. It is to make sure the software can continue working tomorrow.

3. Security Cannot Be Left to Assumptions

Security is one area where relying entirely on generated code can become particularly risky.

Consider an application that stores customer information. An AI assistant might generate a login system and database integration that appear functional, but the implementation still needs to be evaluated for authentication flaws, authorization gaps, exposed credentials, and improper handling of sensitive information.

A human architect must establish security requirements before implementation begins.

Important questions include:

Who can access each resource?
How are user permissions enforced?
Where are API keys and other secrets stored?
How is sensitive information protected?
What happens when a request contains malicious input?
Are third-party dependencies trustworthy and up to date?

Security should not be treated as a final checklist added immediately before deployment. It needs to influence architectural decisions from the beginning.

AI can assist with threat modeling, security testing, and code reviews, but its recommendations must be independently verified.

The responsibility for approving the system's security cannot be delegated to the tool that generated the code.

4. Human Architects Understand Business Requirements

AI tools respond to the instructions they receive. They cannot reliably resolve every ambiguity in a business requirement without additional context.

Suppose a company asks for an employee training management platform.

An AI assistant might quickly generate course listings, employee dashboards, registration forms, and reporting pages.

But the actual business requirements could be much more complex.

Should managers approve registrations? Can employees access only assigned courses? How should training completion be recorded? What happens when an employee changes departments? Which reports should administrators receive?

These decisions influence the application's data model, permissions, workflows, and integrations.

A human architect works with stakeholders to translate business objectives into technical requirements. They identify missing information, challenge assumptions, and prioritize the features that deliver meaningful value.

Without this step, developers risk building an application that looks impressive but solves the wrong problem.

Good architecture begins with understanding the problem, not generating the solution.

5. Scalability and Maintainability Require Long-Term Thinking

An application that serves ten users may not need the same architecture as one expected to serve thousands.

During early development, it can be tempting to accept whatever implementation an AI assistant produces because the immediate result looks good.

However, early decisions can influence performance, infrastructure costs, deployment complexity, and the effort required to introduce new features.

A human architect considers questions such as:

Will the application need to support more users over time?
Which components are likely to change frequently?
Can modules be tested independently?
Where could performance bottlenecks develop?
How will database changes be managed?
Can the application be monitored and recovered after failures?

Not every project needs microservices, complex infrastructure, or an elaborate design pattern. Sometimes a well-structured monolith is the better choice.

The architect's job is to select an approach that fits the application's actual needs rather than adding complexity unnecessarily.

AI can suggest possible designs, compare trade-offs, and help implement the chosen approach. Human judgment ensures that the design remains appropriate for the business and its future direction.

6. AI Makes Code Review More Important, Not Less

When AI can generate large amounts of code quickly, reviewing that code becomes a critical part of the development process.

A developer may receive a working implementation in minutes, but understanding its assumptions, dependencies, and potential side effects still takes effort.

This creates a new challenge: code generation can become faster than an engineering team's ability to validate the results.

A responsible vibe-coding workflow should include:

Define the requirements: Specify expected behavior, constraints, and acceptance criteria.
Review the implementation plan: Understand which components will change and why.
Generate code in small increments: Avoid making large, interconnected changes in a single step.
Run automated tests: Use unit, integration, and regression tests where appropriate.
Inspect the code changes: Review the actual differences rather than trusting the AI's explanation.
Check security and performance: Evaluate risks relevant to the application.
Validate before deployment: Confirm that the implementation satisfies the requirements in a suitable test environment.

This process does not eliminate the speed advantage of AI. It makes that advantage more sustainable.

The objective is to reduce the time required to deliver reliable software, not merely to maximize the amount of code generated.

7. The Best Developers Will Combine AI Skills With Engineering Fundamentals

Vibe coding is changing how developers work, but it does not eliminate the value of understanding software engineering.

Developers still benefit from knowledge of databases, APIs, networking, data structures, testing, version control, system design, and application security.

These fundamentals make it easier to recognize when generated code is incorrect, evaluate competing solutions, and debug problems that AI cannot resolve independently.

AI literacy is equally important. Developers need to understand how to communicate requirements clearly, provide relevant context, evaluate AI-generated output, and recognize the limitations of automated assistance.

For professionals looking to strengthen their understanding of artificial intelligence and its practical applications, Edstellar's AI for Everyone Training is a useful learning resource to explore.

Combining AI knowledge with sound technical fundamentals helps developers use these tools more effectively while retaining control over important engineering decisions.

A Practical Framework for Human-Led Vibe Coding

The most effective approach is neither to reject AI coding tools nor to trust them blindly. It is to establish clear boundaries between automated implementation and human decision-making.

Development activity	AI's role	Human architect's role
Requirements	Help clarify and organize requirements	Define business goals and priorities
System design	Suggest architectures and trade-offs	Select and approve the design
Implementation	Generate and refine code	Guide implementation and review changes
Testing	Create tests and identify potential defects	Validate coverage and interpret results
Security	Assist with security analysis	Define security requirements and verify controls
Deployment	Help automate deployment workflows	Approve release readiness and manage risk
Maintenance	Assist with debugging and refactoring	Preserve architectural integrity over time

This division of responsibility allows teams to benefit from AI's speed without surrendering the judgment required to build dependable software.

The level of oversight should also reflect the risk involved. A small personal project may tolerate more experimentation than a payment platform, healthcare application, or enterprise system handling confidential data.

The higher the potential impact of failure, the stronger the verification process needs to be.

Conclusion: AI Is the Accelerator, Architecture Is the Direction

Vibe coding has opened new possibilities for software development. It helps developers experiment faster, reduces repetitive implementation work, and makes it easier to turn ideas into working prototypes.

But generating an application is not the same as engineering a dependable system.

Architecture determines how the pieces fit together. Security protects users and their data. Testing provides evidence that the application behaves as expected. Human judgment connects technical decisions to real business requirements.

These responsibilities remain essential, regardless of how quickly AI can produce code.

The future of software development is unlikely to be a choice between human engineers and AI tools. It will increasingly depend on how effectively the two work together.

The developers who succeed with vibe coding will not necessarily be those who generate the most code. They will be those who know what to build, how to structure it, what to verify, and when to question the output.

Because in software engineering, speed creates possibilities. Good architecture turns those possibilities into reliable products.

Choosing Between a Terminal Agent and an In-Editor Agent for Your Team

Eva Clari — Fri, 09 Oct 2026 09:47:06 +0000

AI coding agents are changing how development teams write, debug, test, and maintain software. Tasks that once required hours of manual work can now be completed with the help of agents that understand code, suggest changes, execute commands, and assist with complex development workflows.

However, choosing the right AI coding agent is not as simple as picking the most popular tool. One important decision teams face is whether to use a terminal-based agent or an in-editor agent.

Both approaches can improve developer productivity, but they support different workflows. A terminal agent is often suited to command-line operations, repository-wide changes, and automated tasks, while an in-editor agent offers a more visual and interactive coding experience.

So, which approach makes more sense for your team?

Let's explore the differences, benefits, limitations, and practical considerations that can help you make the right decision.

What Is a Terminal Agent?

A terminal agent is an AI-powered coding assistant that operates through a command-line interface. Developers interact with it using text prompts, shell commands, and repository-level instructions.

Instead of limiting assistance to the file currently open in an editor, a terminal agent can often work across multiple files, inspect project structures, run tests, and execute supported development commands.

For example, a developer might ask an agent to:

Identify and fix failing unit tests.
Refactor a function across multiple files.
Investigate a bug by examining logs and source code.
Generate documentation for an existing repository.
Run a test suite and explain the failures.
Prepare changes for a code review.

Depending on the tool and its permissions, the agent may perform these tasks directly or propose changes for the developer to approve.

Terminal agents can be particularly useful for experienced developers who already rely on command-line tools, Git, automated testing, and scripting.

What Is an In-Editor Agent?

An in-editor agent works within an integrated development environment (IDE) or code editor. It brings AI assistance closer to the developer's everyday coding activities.

Rather than switching between a terminal and a separate interface, developers can ask questions, generate code, review suggested changes, and iterate on implementations within their existing workspace.

Common use cases include:

Generating functions and boilerplate code.
Explaining unfamiliar code.
Suggesting improvements to existing implementations.
Debugging errors while working on a file.
Creating unit tests for selected functions.
Applying changes across files when the tool supports agentic editing.

In-editor agents can also provide contextual assistance by using the currently open files, selected code, project structure, and other information made available by the editor.

This makes them appealing to developers who prefer visual feedback and want to review AI-generated changes as part of their normal coding process.

Terminal Agent vs. In-Editor Agent: Key Differences

Although both approaches use AI to assist with software development, their interfaces and workflows differ.

Factor	Terminal Agent	In-Editor Agent
Primary interface	Command line	IDE or code editor
Typical workflow	Commands, repository tasks, scripts	Interactive coding and visual review
Repository-wide changes	Useful for multi-file operations, depending on tool capabilities	Also possible with agents that support multi-file editing
Code review	Often through diffs and terminal-based Git workflows	Often integrated into the editor's diff and review interface
Automation	Well suited to scripts and repeatable command-line workflows	Depends on editor integrations and supported automation
Learning curve	May be steeper for developers unfamiliar with terminals	Often easier for developers comfortable with visual editors
Best-fit scenarios	Repository maintenance, testing, scripted workflows	Day-to-day coding, exploration, and interactive debugging

The distinction is not absolute. Modern agents can overlap significantly in their capabilities. The more useful question is how each tool fits your team's existing development workflow.

When Should Your Team Choose a Terminal Agent?

A terminal agent is worth considering when your team regularly performs tasks that extend beyond writing code in an individual file.

1. You Work Across Large Codebases

Large repositories often contain interconnected modules, shared dependencies, configuration files, tests, and documentation.

When investigating an issue, developers may need to examine several parts of the project before identifying the root cause.

A terminal agent that supports repository-wide context can help trace dependencies, inspect relevant files, and propose coordinated changes.

For example, updating a shared API response structure may require changes to application logic, tests, documentation, and related components. A repository-oriented workflow can make these changes easier to coordinate.

2. Your Team Relies on Automation

Teams with mature development workflows frequently use scripts for testing, linting, formatting, building, and deployment preparation.

Terminal agents can fit naturally into these workflows because they operate close to the tools developers already use.

They can help diagnose failed commands, generate scripts, prepare repetitive maintenance tasks, and support automated checks where the selected agent and environment permit it.

However, access to a terminal does not automatically make an agent safe for unattended execution. Destructive commands and production-related operations should remain subject to appropriate controls.

3. You Need Repeatable Repository Maintenance

Consider a team maintaining dozens of services that use similar dependencies or coding conventions.

Updating configuration files, identifying deprecated APIs, or preparing migration changes can involve repetitive work across many repositories.

A terminal-based workflow can make it easier to standardize these tasks and combine them with version control and testing.

For teams handling frequent maintenance work, this can be a meaningful productivity advantage.

When Should Your Team Choose an In-Editor Agent?

An in-editor agent may be the better starting point when most development work happens interactively inside an IDE.

1. Developers Need Immediate Feedback

During implementation, developers frequently move between writing code, reviewing suggestions, testing assumptions, and fixing errors.

An in-editor agent keeps these activities close together.

For example, a developer building a new authentication function can ask the agent to explain an unfamiliar library, suggest an implementation, generate tests, and revise the code based on feedback.

The developer can inspect the resulting changes without leaving the editor's normal workflow.

2. Your Team Has Different Experience Levels

Developers have different levels of familiarity with command-line tools and AI-assisted development.

An editor-integrated experience may be easier for junior developers to adopt because it builds on a familiar interface.

It can also help experienced developers explore unfamiliar frameworks or understand legacy code more quickly.

Still, ease of use should not replace code review. Developers need to understand what the agent changes, why it makes those changes, and whether the resulting implementation meets project requirements.

3. Code Review Is Part of Everyday Development

Visual diffs, inline suggestions, and file navigation can make reviewing AI-generated changes more convenient.

An in-editor agent can help developers inspect a proposed implementation, identify potential edge cases, and refine code before committing it.

This is particularly useful when teams want AI assistance without sacrificing developer oversight.

Five Factors to Consider Before Making a Decision

Choosing an agent should be a team-level decision rather than an individual preference alone. Evaluate these five factors before standardizing on a tool.

1. Existing Development Workflow

Start by examining how developers currently work.

Do they spend most of their time inside an IDE? Do they frequently execute scripts, inspect logs, and run complex command-line operations?

Choose an agent that complements these habits instead of forcing everyone to adopt an entirely new workflow.

2. Project Complexity

A small application may benefit most from quick code generation, contextual explanations, and interactive debugging.

A large monorepo may require broader repository understanding, coordinated multi-file edits, and extensive testing.

Evaluate how well each agent handles your actual codebase rather than relying exclusively on product demonstrations.

3. Security and Permissions

AI agents can introduce security and operational risks when given excessive access.

Before deployment, establish clear rules for:

Access to source code and confidential information.
Approval of file modifications and shell commands.
Handling of credentials, environment variables, and secrets.
Access to external services and network resources.
Review and approval of changes before merging.

Use least-privilege permissions, protected branches, and human approval for sensitive operations. The precise controls available will depend on the agent and its execution environment.

4. Integration With Existing Tools

An agent should work with your team's version control, testing framework, editor, and code review process.

Check whether it supports the languages, frameworks, repository structure, and development tools your team actually uses.

Also consider how easily developers can share instructions, configure project-specific rules, and maintain consistent practices across the team.

5. Measurable Productivity

Do not evaluate AI agents only by how quickly they generate code.

Measure whether they help developers deliver reliable software with less unnecessary work.

Useful metrics include:

Time required to complete representative development tasks.
Test pass rates after AI-assisted changes.
Number of defects discovered during review.
Time spent correcting AI-generated code.
Developer satisfaction and adoption.
Review time and rework required before merging.

A tool that generates code quickly but creates additional debugging and review work may not deliver the productivity gains your team expects.

Can Your Team Use Both?

Yes. In many development environments, using both terminal and in-editor agents can be more effective than choosing only one.

An in-editor agent can support implementation, explain unfamiliar code, and help developers iterate on individual changes.

A terminal agent can then assist with repository-wide analysis, test execution, scripted maintenance, and other tasks that benefit from command-line access.

Consider a practical workflow for introducing a new feature:

Explore: Use an in-editor agent to understand the relevant modules and plan the implementation.
Implement: Generate or refine code and tests within the editor.
Validate: Use terminal commands to run tests, linting, and other project checks.
Review: Inspect the Git diff and verify that the changes meet the requirements.
Finalize: Commit and merge only after the required checks and approvals are complete.

This approach gives developers flexibility while maintaining a consistent quality-control process.

The goal is not to maximize the number of AI tools in your development environment. It is to use the right tool for each task without creating unnecessary complexity.

Common Mistakes Teams Should Avoid

Even a capable coding agent can create problems when teams adopt it without clear expectations.

Choosing based on popularity alone: A widely used tool may not fit your codebase, preferred workflow, or security requirements.

Giving agents excessive permissions: Start with limited access and expand it only when there is a clear need.

Skipping tests and code review: AI-generated code can contain logic errors, outdated assumptions, security weaknesses, and incomplete implementations.

Measuring only code-generation speed: Include testing, review, debugging, and rework in productivity evaluations.

Ignoring team consistency: Shared instructions, documented conventions, and agreed review standards help developers use agents more consistently.

Avoiding these mistakes helps teams focus on sustainable improvements rather than short-term gains.

Final Thoughts

Choosing between a terminal agent and an in-editor agent depends on how your team develops, tests, reviews, and maintains software.

A terminal agent is a strong candidate for repository-level work, scripted tasks, and workflows built around command-line tools. An in-editor agent is a natural fit for interactive implementation, contextual assistance, and visual code review.

Neither approach is universally better. Both can be valuable, and many teams will benefit from combining them.

Start with a small pilot. Select a few representative tasks, evaluate both approaches against the same criteria, and measure the quality of the final results—not just the speed of the initial output.

The best AI coding agent is the one that helps your team ship reliable software more efficiently while keeping developers in control of the code.

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.