DEV Community: Kodus

.Net Code Review: Best Practices and AI Tools (2026)

Edvaldo Freitas — Tue, 26 May 2026 11:24:00 +0000

A good .NET code review process should do more than just quality control. It can be a way to transfer knowledge, reduce risk, and keep the architecture coherent. For many teams, though, it is just a bottleneck. Pull requests sit idle, feedback becomes inconsistent, and senior engineers burn out fixing typos instead of evaluating design decisions. The standard review process simply does not scale with today’s .NET applications.

The main problem is divided attention. A reviewer has to switch between finding style guide violations, looking for common bugs such as poor async patterns, and thinking about the architectural impact of a change. AI tools can automate the first two jobs, leaving engineers free to focus on architecture, where their experience actually matters.

Why code review in .NET is different

Reviewing .NET code is different from reviewing code in other languages. C# is expressive and often gives you several ways to solve the same problem, which leads to inconsistency if you do not have clear standards. The .NET Base Class Library (BCL) is huge, and it takes experience to know which APIs are better for performance and memory usage.

On top of that, frameworks like ASP.NET Core and Entity Framework Core add their own layers of abstraction. A change that looks good in isolation can generate terrible SQL queries or slow down the middleware pipeline. A good review requires understanding how the code interacts with the runtime and the framework, not just the code itself.

Best practices for .NET code review

Correct behavior

Does the code do what the change promises to do, including error, timeout, cancellation, and edge cases? In .NET, this matters a lot for async flows, external integrations, and public API contracts.

Maintainability

Six months from now, will someone on the team understand this code without opening four files and guessing the intent? Oversized classes, vague names, too many dependencies, and mixed responsibilities tend to become expensive in C#.

Performance

Are there obvious signs of unnecessary cost? This includes blocking async calls, poor EF Core queries, bad projections, avoidable allocations in hot paths, and careless use of serialization or I/O.

Security

Does the change create room for a known problem? Unvalidated input, exposed secrets, loose authorization, logs with sensitive data, and new endpoints without proper access control still show up often.

Architectural cohesion

Does the change respect the way this system is already organized? Does it belong in this service, this layer, and this boundary? In larger .NET codebases, this matters a lot because it is easy to solve a local problem while creating structural mess elsewhere.

When these criteria are clear, feedback improves a lot. Instead of isolated comments, reviewers can explain why something needs to change.

A practical .NET code review checklist

A checklist systematizes the review process and helps make sure common issues are not missed. It should be a living document, updated as the team learns and the codebase changes.

Architecture and design

responsibility of the change: does this class, method, or handler have a clear responsibility, or is it mixing business logic, data access, and external integration?
architectural cohesion: does the change belong in this service, project, and layer? Does it follow the patterns already used by the codebase, or does it create a deviation that will be hard to maintain?
dependency management: are dependencies coming through dependency injection in the right way? Does the lifetime make sense? Is there unnecessary coupling to concrete implementations?
configuration and secrets: are critical configurations strongly typed and validated? Do secrets come from a secure source instead of code or a versioned file?
error handling: are exceptions handled consistently? Does the code distinguish expected errors, domain errors, and unexpected failures? Do logs help with investigation without leaking sensitive information?

C# and .NET specifics

async/await usage: is the flow async end-to-end when there is I/O? Look for .Result, .Wait(), and .GetAwaiter().GetResult() in controllers, handlers, jobs, and consumers. In ASP.NET Core, this often turns into blocking and lower throughput.
cancellation: is CancellationToken being propagated to the database, HTTP, storage, and queues when the operation can be canceled?
LINQ and EF Core queries: is the query executed only when needed? Is there premature materialization with .ToList() or .ToArray()? Is there a risk of N+1, lazy loading in a hot path, unnecessary tracking, or poor projection?
resource management: are disposable objects, such as streams, HTTP responses, and readers, being disposed of correctly? Does the code avoid unnecessary resource retention?
allocations and hot paths: in critical paths, does the code avoid unnecessary allocations, repeated string concatenation, large payload copying, and excessive serialization?

API and ASP.NET Core pipeline

HTTP contract: do the route, verb, status code, and payload make sense for the case? Does the endpoint make it clear what happens on success, validation error, not found, and conflict?
input validation: is all external input treated as untrusted and validated before use?
middleware and pipeline: do changes in Program.cs or in the HTTP pipeline respect the correct order of routing, CORS, authentication, and authorization? Is any custom middleware doing too much work?

Security

authorization: does the new endpoint or operation require authentication and authorization at the right level? Is access protected by the appropriate policy, role, or rule?
data access: does the code avoid SQL injection, unsafe concatenation, and uncontrolled dynamic execution? In EF Core, is the query being built safely?
sensitive data: do secrets, tokens, connection strings, and personal information stay out of code, versioned config, exceptions, and logs?
output and rendered content: in applications with rendered HTML, is output encoding preserved to avoid XSS?

Testing and operations

coverage for the change: does the new endpoint, critical query, or important rule have a test at the right level?
observability: if this fails in production, can the team investigate it? Do logs, metrics, and traces carry enough context?
operational impact: does the change alter timeouts, retries, queues, cache, health checks, or behavior under load without making that clear?

Common .NET problems that AI finds

Static analysis tools can find some of these things, but they often do not have enough context to catch subtle problems. AI tools analyze code in a different way. They can recognize anti-patterns by understanding what the developer was trying to do and how data flows through the application. They can automate a good part of the checklist above.

Here are a few examples of common .NET problems that AI reviewers tend to catch well.

1. Blocking async code

A classic mistake that can lead to thread pool exhaustion and deadlocks in server applications.

Before:

public class UserController : ControllerBase
{
    private readonly IUserService _userService;

    public UserController(IUserService userService)
    {
        _userService = userService;
    }

    [HttpGet("{id}")]
    public ActionResult<User> GetUser(int id)
    {
        // This blocks the request thread, waiting for the async operation.
        var user = _userService.GetUserByIdAsync(id).Result; 
        if (user == null)
        {
            return NotFound();
        }
        return Ok(user);
    }
}

After, AI suggestion:

public class UserController : ControllerBase
{
    private readonly IUserService _userService;

    public UserController(IUserService userService)
    {
        _userService = userService;
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<User>> GetUser(int id)
    {
        var user = await _userService.GetUserByIdAsync(id);
        if (user == null)
        {
            return NotFound();
        }
        return Ok(user);
    }
}

AI tools can trace the call chain and flag the synchronous call over async code as a high-risk pattern, suggesting the correct implementation with async/await.

2. Inefficient queries with Entity Framework Core

Loading a full dataset into memory before filtering is a common problem that destroys performance.

Before:

public async Task<List<ProductDto>> GetActiveProducts(string category)
{
    // Pulls ALL products from the database into memory first.
    var allProducts = await _context.Products.ToListAsync(); 

    // Then filters in-memory.
    return allProducts
        .Where(p => p.IsActive && p.Category == category)
        .Select(p => new ProductDto { Name = p.Name, Price = p.Price })
        .ToList();
}

After, AI suggestion:

public async Task<List<ProductDto>> GetActiveProducts(string category)
{
    // Builds a SQL query with a WHERE clause, only fetching needed data.
    return await _context.Products
        .Where(p => p.IsActive && p.Category == category)
        .Select(p => new ProductDto { Name = p.Name, Price = p.Price })
        .ToListAsync();
}

An AI with context can recognize that _context.Products is an EF Core IQueryable and that calling .ToListAsync() immediately is almost always a mistake. It understands the semantics of deferred execution.

3. Improper use of HttpClient

Instantiating HttpClient inside a using block is a well-known anti-pattern that can lead to socket exhaustion.

Before:

public async Task<string> GetExternalData()
{
    using (var client = new HttpClient())
    {
        var response = await client.GetStringAsync("https://api.example.com/data");
        return response;
    }
}

After, AI suggestion using IHttpClientFactory:

// In Startup.cs or Program.cs
services.AddHttpClient();

// In the service class
public class MyService
{
    private readonly HttpClient _client;

    public MyService(IHttpClientFactory clientFactory)
    {
        _client = clientFactory.CreateClient();
    }

    public async Task<string> GetExternalData()
    {
        var response = await _client.GetStringAsync("https://api.example.com/data");
        return response;
    }
}

AI tools can identify this pattern and suggest a refactor to use IHttpClientFactory, which is the standard practice in .NET applications for managing the lifecycle of HttpClient instances.

4. Forgetting to dispose IDisposable resources

A simple mistake that can lead to resource leaks.

Before:

public void WriteToFile(string filePath, string text)
{
    var stream = new FileStream(filePath, FileMode.Create);
    var writer = new StreamWriter(stream);
    writer.Write(text);
    writer.Flush();
    // stream.Close() and writer.Close() are never called if an exception occurs.
}

After, AI suggestion:

public void WriteToFile(string filePath, string text)
{
    using var stream = new FileStream(filePath, FileMode.Create);
    using var writer = new StreamWriter(stream);
    writer.Write(text);
}

This is a direct check that advanced linters can also perform, but AI tools can suggest the more modern C# syntax, with using declarations, for the fix.

Best AI code review tools for .NET

The market for AI code review tools is growing. Although many tools offer generic language support, their effectiveness in .NET varies. A tool’s understanding of the CLR, BCL, and common frameworks like ASP.NET Core is what separates a useful assistant from a noisy one.

Here is a comparison of several tools and how they apply to .NET development.

Kodus

Kodus is the best option for .NET teams when the goal is to improve review inside a real codebase, not just add an AI commenting on pull requests. In C# and ASP.NET Core projects, many problems depend on context: incorrect use of async/await, poor Entity Framework queries, authorization rules spread across the codebase, services that are too large, or changes that drift away from internal architectural patterns. This is where Kodus stands out. Kody reviews PRs automatically or on demand, comments directly in the Git workflow, and lets teams configure their own rules so the review follows the team’s standards, not just generic best practices.

The main differentiator for .NET is Kody Rules. The team can turn internal standards into review rules, with file scope, severity, and path filters. In a .NET application, this makes it possible to create specific rules for controllers, services, repositories, migrations, tests, or the domain layer. For example: avoiding business logic in controllers, requiring validation on public endpoints, reviewing Include usage in Entity Framework, or ensuring tests for critical changes.

Kodus also learns from team feedback, which helps reduce noise over time. This matters a lot in .NET because each codebase usually has its own decisions around architecture, exception handling, service organization, testing, and framework usage. Instead of treating every C# project the same way, Kodus becomes more aligned with the team’s standards as it is used.

Another important point is control. Kodus is open source, works with GitHub, GitLab, Bitbucket, and Azure DevOps, supports BYOK, and lets the team choose the AI provider and model. For .NET teams that care about cost, privacy, and lock-in, this makes the tool a more flexible option for bringing AI code review into the pull request workflow.

CodeRabbit

CodeRabbit is an AI code review platform focused on pull requests, IDE, and CLI. For .NET teams, it can mainly help as an initial review layer in PRs, pointing out bugs, inconsistent patterns, and quality issues before a human reviewer goes deeper. The tool also allows teams to configure guidelines, path filters, and directory-specific instructions, which can be useful in C# projects with a clear separation between APIs, domain, infrastructure, tests, and front-end. In an ASP.NET Core application, for example, the team can use different instructions for controllers, migrations, services, middlewares, and tests. This helps reduce generic comments and brings the review closer to the decisions that actually matter in a .NET codebase.

GitHub Copilot Code Review

Copilot makes sense when the company is already heavily centered on GitHub and wants to add automated review to the workflow with as little friction as possible. For many teams, this already solves part of the problem. It helps capture basic patterns, localized improvements, and quick comments in smaller PRs.

The limitation appears when the team wants more control over the process, more model freedom, and more specific rules based on repository context.

Bito

Bito positions its AI Code Review Agent as a set of specialized agents that analyze different aspects of the PR, such as performance, code structure, security, optimization, and scalability. This fits well with the kind of care .NET applications often require, since a seemingly simple change can affect Entity Framework performance, authentication flow, dependency injection, API serialization, or async behavior. The documentation also mentions the use of Symbol Indexing, AST, and embeddings to better understand the code and its dependencies. In practice, Bito can work as a review layer that helps the team identify common problems before human review, leaving seniors more focused on architecture, domain, and long-term decisions.

CodeAnt AI

CodeAnt AI has an approach closer to code health and security, combining AI code review with quality analysis and security risk detection. For .NET teams, this is relevant when review needs to cover not only readability and maintainability, but also vulnerabilities, bad practices, and risks related to authorization, input validation, data exposure, and unsafe dependency usage. The documentation shows that codeant review analyzes changes with an agentic architecture, reads context around the codebase, and returns suggestions with severity. This kind of approach can be useful in C# projects where the team wants to prioritize findings by risk, especially in APIs, internal systems, financial applications, or products with stronger security and compliance requirements.

Comparison of code review tools for .NET

Tool	Best fit in .NET	Context used in review	How review is customized	Before the PR	Infrastructure and control
Kodus	Teams that want to turn internal C#, ASP.NET Core, and EF Core standards into versioned rules in the repository itself	Diff, repository files, code search, repo-wide semantic context, and MCP plugins for external context	`Repository Rules` in Markdown, rules by path, directory, and severity, sync of existing rule files	Yes, via CLI on the working tree, staged diff, branch, or commit	Cloud or self-hosted, BYOK by default, choice of provider and model
CodeRabbit	Teams with a monorepo or context spread across code, issues, docs, and related repositories	Diff, knowledge base, linked repos, code guidelines, MCP, web search, issues, and learnings	`.coderabbit.yaml`, `path_instructions`, AST rules, custom checks, and code guidelines	Yes, via IDE and CLI, in addition to PR review	Flow centered on the CodeRabbit service, with versioned configuration in the repository
GitHub Copilot Code Review	GitHub-first teams that want to add automatic review to the workflow with little friction	Diff, additional repository context, and repo instructions	`.github/copilot-instructions.md`, path-specific instructions in `.github/instructions/**`, `AGENTS.md`, `CLAUDE.md`, or `GEMINI.md`	Yes, in IDEs like Visual Studio and VS Code; in PRs, it runs directly on GitHub	Managed service in the GitHub ecosystem; customization through repository files
Bito	Teams that want contextual review by repository, with local configuration and the option to run on their own infrastructure	Diff, repository context, symbol indexes, embeddings, and AST	`.bito.yaml`, general and language-specific guidelines, filters, summaries, secret scanner, and lint feedback	Yes, via CLI and also in the PR workflow	Bito-hosted or self-hosted; supports GitHub/GitLab self-managed
CodeAnt AI	Teams that want to combine PR review with security, code policy, and broader codebase analysis	Diff, full codebase context, security and quality findings, language rules, and application security	`.codeant/configuration.json`, custom review rules, code governance, and review instructions	Yes, via IDE and CLI, in addition to automatic PR review	Cloud and documented self-hosted scenarios for SCM and private deployments

How I would set up an AI review workflow for a .NET team

If I were setting this up for a .NET team today, I would start with a few rules and a lot of focus. The most common mistake at this stage is trying to turn the tool into a universal reviewer in the first month. That almost always increases comment volume and reduces trust. I would rather start with the areas where C# and ASP.NET Core tend to hide expensive problems: blocking async, EF Core reads, nullability, new endpoints without tests, and changes to the middleware pipeline.

The second important decision would be to limit automatic review to issues that actually change risk, cost, or maintainability. Too many comments get tiring fast, especially in a small PR. It also makes sense to version the rules in the repository itself, so the team reviews the rule with the same care it reviews code. External context, such as a ticket, spec, or internal contract, I would only add when it improves the review decision. And I would measure it from the start: comment usefulness, false positives, and time to merge by PR type.

If I were doing this with Kodus, an initial rule for C# could be this:

---
title: "Blocking async calls in HTTP and background execution paths"
scope: "file"
path: ["src/**/*.cs", "app/**/*.cs", "api/**/*.cs", "services/**/*.cs", "workers/**/*.cs"]
severity_min: "critical"
languages: ["csharp"]
buckets: ["performance", "error-handling", "public-contract"]
enabled: true
---

## Instructions
Review C# code that runs in ASP.NET Core request paths, background jobs, hosted services, queue consumers, and application services for blocking async calls.
- Flag any use of `.Result`, `.Wait()`, or `.GetAwaiter().GetResult()` on `Task` or `Task`.
- Flag sync wrappers around async I/O, especially database, HTTP, storage, cache, and message broker calls.
- Treat this as critical when the code is reachable from controllers, endpoints, MediatR handlers, background workers, or consumer handlers.
- Prefer async end-to-end, including `async` method signatures, `await`, and propagation of `CancellationToken`.
- If a sync boundary is truly unavoidable, require explicit justification and verify that it is outside latency-sensitive or high-concurrency flows.

## Examples

### Bad example


```csharp
public IActionResult GetCustomer(Guid id)
{
    var customer = _customerService.GetByIdAsync(id).Result;
    return Ok(customer);
}
```



### Good example


```csharp
public async Task GetCustomer(Guid id, CancellationToken ct)
{
    var customer = await _customerService.GetByIdAsync(id, ct);
    return Ok(customer);
}
```

After that, I would add three more rules: one for EF Core reads, focused on N+1, lazy loading, and poor projections; another to require tests when the PR creates or changes an endpoint; and a third to review changes in the middleware pipeline, since order in ASP.NET Core affects authentication, authorization, CORS, and observability.

The future of code quality in .NET

Where AI helps, and where human review is still irreplaceable

AI tools help a lot when the problem is pattern recognition. In .NET, this includes blocking async, poor use of CancellationToken, suspicious EF Core queries, unresolved nullability, and new endpoints without tests. This type of error shows up often, costs a lot, and, with the right rule, can be caught early.

What AI still does not do well is the hardest part of review. It does not understand with the same depth whether a change respects the architectural direction of the system, whether the business rule was translated correctly, or whether that trade-off between simplicity and performance makes sense for the current product moment. It also does not replace the role of review as mentorship. When a more senior engineer explains why a solution is technically correct, but still a bad idea in that context, that kind of learning does not come from a checklist.

When the tool takes over the repetitive, rule-driven part, the PR conversation moves up a level. Instead of spending time on mechanical details, the team can discuss production impact, public contracts, behavior under load, and long-term consequences.

How I would improve the .NET review process from here

I would not start by trying to automate everything. I would start with a tool running in consultative mode, without blocking merges, and measure two things from the beginning: comment usefulness and false-positive rate. If the feedback is not helping, the problem is almost always in the rule, the scope, or the comment volume.

The next step would be to use real incidents to improve the system. After a regression, a bad query in production, or a long debugging session, the useful question is not “who made the mistake?” The useful question is “could this have been caught in review?” If the answer is yes, then it is worth turning that learning into a team checklist or a tool rule.

In the end, the most interesting gain from AI review in .NET is not reviewing more PRs per day. It is making human review spend less energy on noise and more energy on decisions that actually change the quality of the system.

Frequently asked questions

What is the best AI code review tool for .NET?

It depends on your main goal. For PR summaries and line-level suggestions, GitHub Copilot or CodeRabbit are good choices. For deeper architectural analysis and applying custom team standards, Kodus was built for that purpose with repository-level context and natural-language rules.

Does Kodus work with .NET?

Yes. Kodus works with any language and was designed to understand the structure of complex projects, including .NET solutions with multiple projects. Its ability to track dependencies across a repository makes it especially effective for C# and the .NET ecosystem.

What about the complexity of async/await in .NET?

This is an area where AI tools help a lot. They can detect common async pitfalls, such as sync-over-async blocking, forgetting to use await on a Task, or using async void in inappropriate contexts. Because they can analyze the full call stack, they can find problems that a simple linter may miss.

Are there free code review tools for .NET?

Many AI tools, including Kodus, offer free plans for open source projects or small teams, which is a good way to evaluate them before committing to a paid plan.

Are there self-hosted options for .NET reviews?

Yes. Kodus is the most complete option on this list. The platform combines self-hosted deployment, BYOK by default, open source code, and freedom to choose the model and provider. In practice, this gives more control over where the code runs, how keys are managed, and which external services enter the review workflow. For organizations with strong privacy, security, or governance requirements, this combination puts Kodus in a better position than tools that treat self-hosting as an exception or limit model choice.

Best Devin Alternatives in 2026

Edvaldo Freitas — Mon, 25 May 2026 17:18:00 +0000

Devin put an important idea on the table: delegating development tasks to a more autonomous AI agent. From there, “Devin alternatives” became a broader search. Teams are not always looking for a Devin clone. Many times, they are trying to understand which type of AI tool makes the most sense for their own engineering workflow.

In practice, not every team wants to add a separate agent outside the current flow to handle changes end to end. In many cases, the problem is more specific: slow reviews, PRs that are too large, lack of context, repetitive tasks in the editor, or difficulty keeping standards consistent across repositories.

That is why the search for Devin alternatives usually falls into three groups.

Some teams want tools that fit into the workflow they already have. Something that works in VS Code, in the terminal, in GitHub, in GitLab, or directly in the pull request, without requiring a major process change.

Others want more control over what the AI does. They want to use AI to speed up parts of the work, but still review the steps, guide the changes, and decide what gets into the code.

And some teams are not looking for a generic agent. They are trying to solve a very specific bottleneck. For one team, that might be code review. For another, refactoring. For another, test generation or repetitive tasks in the editor. In those cases, a more focused tool usually works better than a broad solution trying to cover everything.

8 top Devin alternatives

This list covers different types of tools, from AI-native IDEs to terminal-focused agents and code review specialists. We ranked the options based on how they fit into different development workflows.

1. Kodus

Kodus is an open source AI code review tool, not a code generation agent. It focuses on improving code quality and consistency before merge. It integrates directly into your Git workflow, reviews pull requests automatically, and delivers feedback based on general best practices and custom rules your team defines in natural language. It is the best alternative to Devin Review.

Pros:

Specialized in code review. Kodus was built to review code, prioritize relevant issues, and reduce noise. It analyzes security risks, performance problems, error handling issues, maintainability concerns, and team-specific standards.
More context than tools that only review the diff. The review still stays anchored in the PR, but Kodus also uses full repository context, code search, and, when enabled, cross-file analysis and pull request-level checks. This usually leads to more useful comments than tools that only look at the isolated patch.
Customizable rules. Teams can create Kody Rules for their own engineering policies, version those rules inside the repository, and control behavior at the global, repository, and directory level. This is especially useful in monorepos or teams with different standards across services.
Model-agnostic with real BYOK support. You can use your own keys from any LLM provider, giving you control over costs and model choice.
Self-hosting. Teams with strict data privacy requirements can host Kodus in their own infrastructure.

Cons:

Not for code generation. If you are looking for an agent to write features from scratch, Kodus is not the right tool. It is built to review and improve code, not create it.

Pricing:

The Community plan is free with BYOK.
The Teams plan costs $10 per active developer per month + tokens.

Best for: Teams that want to automate the code review process, apply consistent standards, and improve code quality without slowing down development.

Explore the open source repo: https://github.com/kodustech/kodus-ai

2. Cursor

Cursor is an AI IDE before anything else. It provides autocomplete, chat, multi-file editing, background agents, and Bugbot for review.

The comparison with Devin makes sense because both help produce code changes and automate part of the work. The workflow, however, is very different. Cursor starts in the editor. Devin starts from a more autonomous proposal. That is why Cursor tends to make more sense when the developer still wants to drive most of the process.

Pros:

Very good workflow for developers who want to use agents and assisted editing directly in the IDE. Background Agents and Bugbot expand its use beyond autocomplete.
Rules and project context can be versioned in the repository.
Good option for teams that want to iterate quickly inside the editor.

Cons:

Although it is a VS Code fork, it is its own editor. That can be a blocker for teams with strict policies around approved development environments.
It is great for helping a developer who is actively coding, but it will not take a high-level prompt and finish an entire project by itself.

Pricing:

Pro at $20/month
Pro+ at $60/month
Ultra at $200/month
Teams at $40/user/month.

Best for: Teams that want IDE-centered AI, with agents and some automation, without completely changing how they write code.

3. Aider

Aider is an AI pair programming tool based in the terminal. It edits code directly in your local Git repository.

Its proposal is very different from Devin’s. Aider is closer to an AI pair programmer, controlled by the developer, than to an autonomous agent. It uses a repository map to better understand context, supports architecture and implementation modes, integrates well with Git, and works with many models, both cloud-based and local.

Pros

Open source
Works with many providers and local models
Excellent Git integration, including auto-commits and undo
Lightweight and easy to fit into the terminal

Cons

Not designed for long-running autonomy in the background
The workflow is more focused on one session per repo
PR review is outside its main scope

Pricing: Free; model costs are separate.

Best for: Engineers who want terminal-based pair programming with a really good Git integration.

4. GitHub Copilot Coding Agent

GitHub Copilot Coding Agent is GitHub’s most direct answer to the issue-to-PR workflow. If your team already works inside GitHub, wants to automate tasks, and does not want to bring another platform into the process, it is a very natural alternative to Devin.

The main difference is scope. Copilot Coding Agent is more tied to the GitHub ecosystem. Devin tries to work as a broader and more autonomous layer.

Pros

Works directly with issues and PRs in GitHub.
Included in existing paid Copilot plans.
Adoption tends to be simple for teams that already use GitHub as the base of their workflow.
Benefits from the rest of the GitHub ecosystem.

Cons:

Its functionality is almost entirely tied to GitHub. Teams using Bitbucket, GitLab, or other platforms are left out.
Works better for incremental work than for teams that want a more independent agent.

Pricing: Included starting with Copilot Pro, at $10/month. Pro+ costs $39/month. Business and Enterprise are available for organizations.

Best for: Teams that mainly work in GitHub and want to automate tasks without leaving the platform.

5. Continue.dev

Continue.dev has become a broad open source platform for AI development. It covers IDE extensions, CLI workflows, PR checks, cloud agents, MCP integrations, and paths for self-hosted models.

That breadth is exactly what attracts some teams. You can treat Continue.dev as a customizable alternative to Devin when the goal is to build an AI workflow around your own checks, prompts, rules, and infrastructure, instead of adopting a more closed and opinionated agent.

Pros

Open source and suitable for self-hosted setups or private models.
Good customization with model roles, rules, prompts, and MCP servers.
Makes sense for platform teams that want to build internal AI workflows instead of buying a closed product.
Works both in the IDE and in the terminal.

Cons

More configurable than ready to use.
The product surface is broad, so new users need time to understand how the pieces connect.
If you want a ready-made autonomous coding agent, with strong and opinionated defaults, other tools are simpler to start with.

Pricing: Starter costs $3 per million input and output tokens, on a pay-as-you-go model. Team costs $20 per seat/month and includes $10 in credits per seat. Company has custom pricing.

Best for: Teams that want open source flexibility, custom AI checks, self-hosting options, and more control over the stack than Devin usually offers.

6. Claude Code

Claude Code is Anthropic’s tool for working with code using Claude models. In practice, it stands out when you need to understand a real codebase, investigate bugs, refactor larger parts of the system, or discuss architecture decisions in the terminal.

Claude Code works more like a terminal-based work tool than a full IDE. It helps edit files, run commands, navigate the codebase, and use parts of the Claude ecosystem, such as skills, memory, and connectors, inside a workflow that is closer to day-to-day development.

Pros

Terminal-native and easy to fit into the engineering workflow.
Works with Anthropic, Bedrock, and Vertex.
Project settings can be versioned in the repository.
Good option for teams that want an agent with constant human supervision.

Cons

The cost for teams depends more on token consumption than on a simple per-user price.
It does not have the same backlog and collaboration layer that Devin tries to offer.

Pricing: Claude Pro costs $20 per month with monthly billing. Max starts at $100 per month. Standard Team seats cost $25 per seat per month with monthly billing, and Enterprise starts at $20 per seat plus usage.

Best for: Developers who want a high-quality coding agent for deep reasoning, code understanding, and good terminal workflows.

7. OpenAI Codex

OpenAI Codex is a coding agent that reads, edits, and runs code in cloud environments. It can also be used locally through the CLI and extensions.

The main difference compared with more editor-centered tools is delegation. You can assign multiple background tasks to Codex, let each one run in its own sandbox, trigger it through GitHub, and control internet access by environment. Among Devin alternatives, it is one of the closest when the focus is longer, parallel programming work running in the cloud.

Pros

Good cloud task model, with sandboxed environments and parallel execution.
Works on the web, in the IDE, CLI, GitHub, and also through mobile entry points.
Very explicit security controls, including rules and internet access allowlists by environment.
MCP, SDK, and GitHub integration create room for internal automations.

Cons

The price currently depends on credit consumption based on tokens, so uncontrolled use can get expensive quickly.
The best results still depend on well-configured environments, which adds operational work.
It is not as natural in the GitHub review flow as Copilot, nor as specialized in review as Kodus.

Pricing: Codex is included in ChatGPT Plus, Pro, Business, Edu, and Enterprise plans. After that, usage is charged through credits. OpenAI updated Codex to token-based pricing and estimates average usage at around $100 to $200 per developer per month.

Best for: Teams that want to delegate tasks in the cloud, in a workflow similar to Devin, but with more control over the sandbox and more integration options with the OpenAI ecosystem.

8. Cline

Cline is an open source coding agent that runs in the editor and the terminal. It can read and edit files, execute commands, use the browser, and work with different providers.

The comparison with Devin makes sense for teams that want more autonomy in development, but still need transparency, BYOK, and explicit approval before certain actions. Cline makes the workflow more visible to the developer, which usually appeals to more technical teams.

Pros

Open source.
BYOK with several providers.
Runs locally in your IDE, so it uses your exact development environment.

Cons

Requires more setup decisions than a managed platform.
Teams that want a ready-made cloud workflow may prefer Devin or Windsurf.
More complete governance features are more tied to the enterprise offering.

Pricing: Free open source extension. Model costs or Cline credits are separate. Enterprise is available on request.

Best for: Teams that want an open coding agent and are willing to assemble more parts of their own stack.

Full comparison table

Tool	Main category	Custom rules and policies	Starting price	Best fit
Kodus	AI code review	Yes. Kody Rules, global/repo/directory config, and versioned rules in the repository.	Community free; Teams at $10 per active developer/month + tokens	Teams that want repository-aware code review and stronger governance
Devin	Autonomous software agent	Yes. Session instructions and task context.	Free; Pro at $20/month; Teams from $80/month minimum	Teams that want to delegate implementation, debugging, and long-running tasks
Cursor	AI-first code editor	Yes. Rules, skills, hooks, and team context.	Hobby free; Pro at $20/month; Teams at $40/user/month	Developers who want AI embedded in the editor all day
Aider	Terminal pair programming	Partial. Configuration and git-based workflow.	Free; inference costs only	Developers who want local repo editing with a git-centric workflow
GitHub Copilot Coding Agent	GitHub-native agent and assistant	Yes. Repository instructions and GitHub policy controls.	Free; Pro at $10/month; Business at $19/user/month	Teams already centered on GitHub Issues, PRs, and Actions
Continue.dev	Open source agent and checks platform	Yes. Rules, tools, checks, and custom configuration.	Starter at $3 per million tokens; Team at $20/seat/month	Teams that want a more customizable and controlled AI development stack
Claude Code	Terminal-first coding agent	Partial. Projects, memory, skills, and context.	Claude Pro at $20/month; Max at $100/month	Developers who want strong reasoning for refactoring, debugging, and implementation
OpenAI Codex	Coding agent with cloud execution	Yes. Environment controls, permissions, and automations.	Included in paid ChatGPT plans + usage credits	Teams that want parallel task delegation with sandbox and internet controls
Cline	Open source coding agent for editor and terminal	Yes. Rules, MCP, hooks, skills, and permission controls.	Free; inference costs only	Power users who want fine-grained control over model, tools, and execution

Frequently asked questions

What is the best Devin alternative in 2026?

It depends on what you want to replace. If the goal is to replace Devin as an autonomous implementation agent, tools like Claude Code, OpenAI Codex, and GitHub Copilot Coding Agent usually make more sense. If the main point is improving code review with AI, the best alternative is Kodus.

Is Kodus a good Devin alternative?

Yes, especially for teams that do not need an agent to implement entire features on its own, but want to raise code quality before merge. Kodus is the best option when the real problem is review: inconsistency between reviewers, shallow feedback, lack of repository context, and difficulty applying team standards in a predictable way.

Is Kodus better than Devin Review?

For AI code review, in many scenarios, yes. Devin Review makes sense for teams that are already inside the Devin ecosystem and want to extend that experience to PRs. Kodus, on the other hand, is more specialized in code review and code review governance. It stands out by offering repository context, custom rules in natural language, versioned configuration, BYOK, a model-agnostic approach, and more control over the review workflow. In teams that treat review as a critical engineering process, that usually matters more than having a more generalist tool.

Can I migrate from Devin to Kodus?

Not in a 1:1 sense, because the two tools solve different parts of the workflow. The most common path is to keep a coding agent for implementation and add Kodus at the review layer. For many teams, that works better than trying to force a single product to do both things well.

Are there self-hosted Devin alternatives?

For coding agents, Cline and Aider are good options. Continue also makes sense for teams that want to build a more custom workflow. For PR review, Kodus is the best option.

Node.js Code Review: Best Practices, Checklist, and AI Tools (2026)

Edvaldo Freitas — Mon, 25 May 2026 14:11:53 +0000

Code review is one of the best ways to improve code quality in a growing Node.js codebase. It helps teams catch bugs earlier, keep patterns consistent, and avoid changes that make services harder to maintain over time. In a Node.js code review, that matters even more because many problems are easy to miss in a quick pull request. Async flows, runtime validation, middleware order, external calls, and query behavior can all look fine at first and still create expensive issues in production.

That is why a good review process for Node.js should do more than check style and names. It should help the team look at runtime behavior, system boundaries, operational risk, and long-term maintainability. In this guide, I will go through a practical checklist for reviewing Node.js code, common problems that AI tools tend to catch well, and how I would set up a review workflow for a team building modern Node.js services.

Challenges in Node.js code review

Node.js code often looks simpler than it really is. A short route handler, for example, can hide weak input validation, missing authorization checks, expensive queries, or an external call with no timeout. In the diff, the change looks small. In production, though, the behavior depends on what happens at runtime, under concurrency, and across service boundaries.

That is why reviewing Node.js is not just about looking at the code inside a file. It is about understanding how that code behaves when it receives real traffic, processes untrusted input, talks to the database, publishes to a queue, or depends on a package that just changed versions. A good reviewer needs to follow the path the code takes through the application, not just judge whether the implementation looks clean.

The areas I would always review first

In Node.js, many important problems do not show up as an obvious error in the pull request. The change can look small, pass the tests, and still create production risk. So before spending time on naming, formatting, or small refactors, I would look at these areas first.

runtime boundaries: Node.js services receive data from many places: query params, request bodies, headers, webhook payloads, and queue messages. If those inputs are not validated carefully, the issue can show up as an authorization bug, a validation failure, or leakage across tenants.

async behavior: many reliability problems come from promises without clear handling, retries with side effects, and async flows that work in the happy path but fail badly under load or partial failure.

performance risk: blocking the event loop, using Promise.all without limits, or doing expensive I/O inside a critical flow can easily pass review. Each line looks simple, but the whole change can become heavy in production.

data access: a short handler can still trigger a query that is too heavy, too broad, or inconsistent under load. This is one of the most common ways a small change becomes a problem after deploy.

operational impact: changes to packages, timeouts, logs, configuration, and observability also need to be part of the review. In Node.js, these details often define whether an incident will be easy to understand or hard to investigate.

I prioritize these areas because this is where small changes tend to create the most expensive problems. Cosmetic adjustments can wait. Runtime errors and operational failures almost never can.

A practical Node.js code review checklist

Input validation and runtime boundaries

request input: are req.body, req.query, req.params, headers, cookies, and webhook payloads validated before use?
runtime assumptions: does the code rely on TypeScript or casts where the runtime still accepts different formats?
external data: are responses from third-party services treated as untrusted until they are parsed and validated?
configuration input: are environment variables parsed and checked instead of being assumed correct?

Authorization and tenant isolation

auth checks: does the route, command, or job apply authentication and authorization at the right level?
tenant boundaries: does the code use IDs from the request in a way that could weaken isolation between tenants or accounts?
ownership rules: are user and resource ownership rules explicit before sensitive actions happen?

Async flow

promise handling: is every promise awaited, returned, or intentionally left in the background with explicit error handling?
side effects: if a process retries or runs twice, does the code remain safe?
job behavior: do workers, schedulers, and queue consumers make their assumptions about retry and delivery clear?

Error handling

expected versus unexpected failures: are validation errors, domain errors, and system failures handled differently?
error visibility: does the code preserve enough context to debug what failed?
safe responses: do error responses avoid leaking stack traces, secrets, or internal structure?

Timeouts, cancellation, and external calls

timeouts: do external HTTP calls, storage, cache, and brokers define explicit timeouts?
abort behavior: does the code pass abort or cancellation signals where the stack supports them?
third-party reliability: if the dependency becomes slow or returns bad data, does the application still behave predictably?

Performance and event loop

blocking work: does the PR add synchronous filesystem access, heavy CPU transformations, large JSON parsing, compression, or encryption on a hot path?
memory usage: does the code load more data into memory than it needs?
cost on the request path: could this change increase latency or reduce throughput under real load?

Database access and query behavior

query shape: does the ORM or query builder generate the query the author expects?
pagination and filters: does the code avoid accidental broad reads or missing limits?
projection: does the API return only the fields it needs?
write behavior: are transactions or conflict-handling patterns clear where multiple writes need to remain consistent?

Concurrency and consistency

parallel work: does Promise.all or batch fan-out create more concurrency than the system can safely handle?
duplicate execution: does the code behave safely if the same event or job is processed more than once?
races: are there obvious race conditions in writes, state transitions, or shared resources?

Middleware, HTTP pipeline, and execution order

middleware order: if the PR changes Express, NestJS, or Fastify middleware, do auth, validation, logging, rate limiting, and error handling still happen in the right order?
single responsibility: is the middleware focused, or is it doing too much work for one layer?
HTTP behavior: do routes return the right status codes and predictable payloads for success and failure cases?

Dependencies and supply chain

package changes: does a new dependency or version upgrade deserve manual review for security history, maintenance, or install scripts?
lockfile review: are lockfile changes and transitive dependencies being treated as part of the review surface?
need: is the new dependency worth the long-term cost of maintaining it?

Configuration and environment variables

startup validation: does the application fail fast when configuration is missing or malformed?
safe defaults: are defaults explicit and appropriate for the environment?
secret handling: do secrets stay out of code, logs, example files, and versioned configuration?

Observability

logs: if this fails in production, will the logs explain what happened without exposing sensitive data?
metrics and traces: does the change preserve enough visibility into latency, retries, external calls, and job behavior?
correlation: can the team connect a user-visible failure to the internal path that caused it?

Tests

coverage by risk level: are tests added where the risk actually is, such as route boundaries, auth rules, queue behavior, or failure modes?
unhappy paths: are malformed input, timeout paths, retries, and edge cases covered?
real formats: do the tests reflect runtime behavior instead of only ideal typed inputs?

Readability and maintainability

clarity: are names, module boundaries, and control flow easy to understand?
coupling: does the change create hidden dependencies between route code, service code, data access, and infrastructure?
future review cost: will the next reviewer understand this code quickly, or will they need to reverse-engineer the intent?

Common Node.js problems an AI tool can help find

Using untrusted input too early

Before:

app.get('/projects', async (req, res) => {
  const organizationId = req.query.organizationId as string;
  const projects = await projectService.listForOrganization(organizationId);
  res.json(projects);
});

After, AI suggestion:

app.get('/projects', async (req, res) => {
  const rawOrganizationId = req.query.organizationId;

  if (typeof rawOrganizationId !== 'string') {
    return res.status(400).json({ error: 'organizationId must be a string' });
  }

  const projects = await projectService.listForOrganization(rawOrganizationId);
  res.json(projects);
});

Missing timeouts in external calls

Before:

export async function fetchProfile(userId) {
  const response = await fetch(`https://profiles.example.com/${userId}`);
  return response.json();
}

After, AI suggestion:

export async function fetchProfile(userId) {
  const response = await fetch(
    `https://profiles.example.com/${userId}`,
    { signal: AbortSignal.timeout(3000) }
  );

  if (!response.ok) {
    throw new Error(`profiles returned ${response.status}`);
  }

  return response.json();
}

Broad concurrency without limits

Before:

await Promise.all(orderIds.map((id) => syncOrder(id)));

After, AI suggestion:

for (let i = 0; i < orderIds.length; i += 20) {
  const batch = orderIds.slice(i, i + 20);
  await Promise.all(batch.map((id) => syncOrder(id)));
}

Blocking the event loop on the request path

Before:

import { readFileSync } from 'node:fs';

app.post('/preview-email', (req, res) => {
  const template = readFileSync('./templates/email.html', 'utf8');
  res.send(render(template, req.body));
});

After, AI suggestion:

import { promises as fs } from 'node:fs';

const template = await fs.readFile('./templates/email.html', 'utf8');

app.post('/preview-email', (req, res) => {
  res.send(render(template, req.body));
});

What I would look for in an AI code review tool for Node.js

I would care less about whether the tool says it supports JavaScript or TypeScript and more about how much it helps with the real review problems in Node.js.

repository-specific rules: can the team encode standards for routes, workers, packages, and architectural boundaries?
cross-file context: can the tool reason beyond the changed line and understand the surrounding flow?
dependency awareness: does the review flow treat package and lockfile changes as real code review material?
signal over noise: does the tool reduce repetitive failures or just create more comments to ignore?

Good code review tools for Node.js teams in 2026

A good code review tool for Node.js is not just the one that comments on the pull request. It needs to help the team find problems that easily slip through small diffs: runtime validation, tenant isolation, async flow, concurrency, bad queries, and operational impact.

The options below have different approaches. It is worth looking less at the feature list and more at the type of review each one actually improves.

Kodus

For Node.js teams, Kodus makes more sense when review needs to reflect the real context of the repository, not just generic best practices. This matters in codebases with APIs, workers, queues, external integrations, and internal rules that do not show up in linters.

The practical difference comes down to three points.

The first point is repository context. In Node.js, the bug is rarely only in the changed line. It usually appears in the path between route, middleware, service, query, queue, and external integration. That is why reviewing only the diff is almost never enough. What makes Kodus different is evaluating the change inside that larger flow, considering the repository structure and the rules the team has defined for each part of the system.

Second, custom rules in natural language with Repository Rules and Kody Rules, useful for turning route patterns, middleware, jobs, boundaries, and data access into review criteria.

Third, control: Kodus is open source, supports BYOK, is model-agnostic, and allows teams to use MCP plugins to bring external context, such as specs and tickets, into the review.

In practice, this helps a lot in Node.js because many serious problems depend on context. A generic reviewer can find local bugs. Kodus makes more sense when the team wants to create rules like: “no public route should use req.query or req.body in authorization decisions before validating the runtime shape” or “changes to queue consumers need to be reviewed with a focus on idempotency and retry safety”.

This kind of rule is not cosmetic. It targets expensive, recurring bug classes in Node.js APIs.

CodeAnt AI

CodeAnt leans more toward security and code health than pure contextual review. The platform combines pull request review, IDE, CLI, and a unified view of code, dependencies, infrastructure, and secrets.

For Node.js teams, this makes sense when review needs to look more at risk, severity, and security posture than internal architecture conventions. The strong point is combining line-by-line comments with codebase context and a clearer layer of findings and prioritization. It also supports custom rules by repository and file glob, which helps apply specific policies to routes, services, or handlers.

In practice, I see CodeAnt working better for Node.js teams that want to use review as part of a broader security and quality pipeline. It seems more useful when the question is “which changes increased risk?” than when the question is “how do we apply the internal rules of our monorepo and service architecture?”.

For a Node.js API with a lot of public surface area, sensitive integrations, or compliance requirements, this approach can help. For a team that wants review more tied to boundaries and internal patterns, the result will depend a lot on the quality of the configured rules.

Graphite

Graphite has a slightly different approach. It is stronger as a PR workflow platform, especially for teams that live in GitHub and want to add automated review without changing much of their current process.

Graphite Agent focuses on fast setup, comments directly in the PR, concrete fix suggestions, custom rules, and acceptance analytics by rule. For Node.js, this helps when the main problem is review speed and feedback quality in pull requests, not deeper repository governance.

I would place Graphite as a good option for Node.js teams that already have strong PR discipline, want high-signal feedback on bugs, edge cases, security, and performance, and prefer to iterate quickly with custom prompts and exclusions.

The limit, compared with Kodus, is that the approach seems more centered on the GitHub PR flow and less on turning the repository into the source of truth for deeper operational and architectural rules. For day-to-day review, it may be enough. For Node.js teams that want to encode expected behavior by folder, boundary, service type, or internal domain policy, Kodus tends to be more interesting.

CodeRabbit

CodeRabbit sits in a good middle ground between broad coverage and convenience. It runs in PRs, IDE, and CLI, supports GitHub, GitLab, Bitbucket, and Azure DevOps, and detects guideline files like AGENTS.md, CLAUDE.md, and .cursorrules.

For Node.js teams, this helps reduce the gap between “the rules the team wrote in markdown” and “what the automated reviewer actually enforces”. The tool also seems well thought out for catching problems before the PR, which is useful in Node.js stacks with a lot of service, route, and integration code, where a simple mistake can spread quickly.

In practice, I see CodeRabbit as a good option for teams that want review across multiple surfaces and value the ability to use patterns that are already documented. It makes sense in Node.js when the goal is to increase review coverage without changing everything at once.

I would still put Kodus ahead when the team wants more control over the workflow, more model freedom, an open source posture, and the ability to bring external context through MCP plugins. CodeRabbit helps a lot with review distributed across PR, IDE, and CLI. Kodus tends to fit better when review needs to reflect how that repository and that team actually work.

Comparison of code review tools for Node.js

How I would introduce this process in a real team

I would start with a small checklist and a small set of rules. No blocking merges in the first month. No trying to automate every review habit at once. The goal at the beginning is to catch the problems the team already knows are expensive, then measure whether the feedback is actually useful.

For a typical Node.js service, I would probably start with three rule areas: runtime validation at public boundaries, timeout requirements for external calls, and tests for new endpoints or queue consumers. That already covers a large part of the expensive errors teams see in production.

After that, I would use real incidents to improve the checklist. If the team spends a day debugging a broken retry flow, a bad query, or a tenant isolation bug, that should become review knowledge. Good review systems get stronger because the team keeps feeding those systems with real failures, not because the checklist started big.

Frequently asked questions

How do you create a code review checklist for Node.js?

A good Node.js code review checklist should be short and focused on the points that most often create production problems. Instead of trying to cover everything, it is worth starting with higher-risk areas, such as runtime validation, authorization, async flow, external calls, queries, dependency changes, and tests. The best checklist is not the longest one. It is the one that helps reviewers avoid missing points that really matter in almost every PR. As the team learns from real bugs and incidents, that checklist can evolve with the codebase.

What should you review first in a Node.js code review?

Start with the points that most often break in production: runtime validation, authorization, async flow, external calls, queries, and dependency changes. In Node.js, a small PR can hide a route that trusts input too early, triggers unlimited concurrency, runs a heavy query, or calls an external service with no timeout.

What is the best code review tool for Node.js?

It depends on what the team needs. For quick adoption in the current PR flow, several tools can help. But if the team wants review with repository context, custom rules in natural language, external context through plugins, model choice, and more control over the workflow, Kodus is one of the most complete options for Node.js. This matters in codebases with routes, workers, queues, shared packages, and internal rules that do not show up just by looking at the diff.

Which AI code review tool is best for Node.js teams that need custom rules?

Kodus stands out here. Node.js teams often need rules that go beyond style, such as requiring runtime validation in public endpoints, checking tenant isolation, reviewing queue consumers with a focus on idempotency, or applying patterns by folder and service type. Kodus supports natural-language rules at the repository level, external context through plugins, and a model-agnostic flow, which gives the team more control.

Can AI code review catch async and promise problems in Node.js?

Yes. AI reviewers are often useful for missing await, weak timeout handling, broad concurrency patterns, and other async errors that can slip through a quick manual review.

Does TypeScript reduce the need for code review in Node.js?

TypeScript helps, but it does not replace code review. It catches many errors early and improves code structure, but it does not validate input at runtime, does not guarantee correct authorization, does not prevent event loop blocking, and does not make external integrations safe. In Node.js, many bugs appear exactly between the static type and the real behavior of the application.

Should package.json and lockfile changes be part of Node.js code review?

Yes. Dependency changes also need to be reviewed. A package upgrade can change installation, introduce security risk, change transitive dependencies, or create performance and maintenance cost. Reviewing only the application code and ignoring package.json or the lockfile lets too much risk through.

Should lockfile changes be part of code review in Node.js?

Yes. In Node.js, dependency and lockfile changes can affect security posture, installation behavior, and operational risk. They should be treated as part of the real review surface.

How should a team start improving code review in Node.js?

Start small. Use a short checklist, focus on the highest-risk areas, and add automation only where it clearly improves signal. A smaller review process the team actually follows is better than a perfect process nobody uses.

The Future Of Software Engineering according to Anthropic

Kody from Kodus — Mon, 30 Mar 2026 20:48:00 +0000

The initial productivity gains from AI code assistants are starting to come with a cost. The speed is undeniable. You can generate hundreds of lines of boilerplate code or even a complex algorithm in seconds. The problem shows up later, in the pull request. Reviewing AI-generated code feels different from reviewing a colleague’s work. You can’t ask for its reasoning or discuss trade-offs. You’re left looking at a block of code that is syntactically correct and often seems logical, but whose assumptions are a mystery. The gap between how fast we can generate code and how long it takes to verify it is the main challenge of bringing AI into our work, and it shows how our roles need to change. Anthropic’s research suggests a path forward, a future of software engineering where the engineer’s primary role is directing systems, not writing code.

This is a fundamental shift in where we apply our expertise.

The growing gap between generation and verification

We’re hitting a limit with the current generation of AI tools. They are excellent at speeding up tasks we already know how to do. The bottleneck is no longer writing code; it’s making sure the generated code is correct, maintainable, and safe to merge.

The speed vs. control problem

A junior engineer submits a 500-line pull request. You can review it by inferring intent, correcting logic, and teaching better patterns. A 500-line pull request coming from an AI is all or nothing. You can accept it, reject it, or spend more time editing it than it would take to write it from scratch. The tool gives you speed, but you give up control and understanding. This leads to a process where engineers generate code and then spend an equivalent amount of time reverse engineering the logic to write tests and confirm the behavior matches what they originally wanted.

From implementation details to specification failures

Our current code review process focuses on implementation. We check style, performance, and logical errors. But when a bug shows up in AI-generated code, the root cause is usually a flaw in the original prompt or a misunderstanding by the model, not a simple coding mistake. The conversation has to move to a higher level. The question is no longer “is this for loop correct?” but “did my prompt describe all edge cases accurately?” The developer’s focus shifts from writing code to writing an unambiguous specification that a machine can execute.

Managing complex generated systems

The problem gets worse when you move from isolated functions to generating entire services. You end up with a large amount of code that no one on the team fully understands. Who owns it?

When something breaks in production at 3 AM, who has enough context to debug it quickly? The codebase starts to become harder to understand, and knowledge about the system erodes over time.

Anthropic’s perspective: the engineer as an AI system architect

Anthropic’s view is that this discomfort is a sign of a temporary phase. They propose a future where engineers are architects and validators of AI-driven development systems, rather than programmers focused on implementation. The value shifts away from the amount of code written and toward how we define problems and evaluate solutions.

A shift in value: from implementation to specification and validation

The core idea is that an engineer’s primary output will no longer be code. It will be a combination of two things:

1. A precise, machine-readable specification of the problem. This is not a Jira ticket. It’s a formal definition of inputs, outputs, behaviors, and constraints.
2. A complete validation and verification setup. This includes tests, property-based checks, and performance benchmarks that can certify, without human review, that the generated solution meets the specification.

In this model, the AI agent’s job is to find any implementation that satisfies the specification and passes the tests. The engineer’s job is to make the specification and tests so solid that any passing implementation is, by definition, correct.

AI agents as collaborators

This turns AI from a simple tool (like a compiler) into an active collaborator. It’s a system that takes structured, high-level direction and executes the repetitive work of implementation. The creative part of engineering, breaking down complex problems into logical and verifiable parts, remains deeply human. The mechanical part of translating that into syntax is handed off to the machine.

What this means for our daily work

If this idea is right, several of our practices will need to change. The structure of teams, daily routines, and how we define “done” will all be affected.

Code reviews become specification reviews

The pull request process tends to change. Instead of reviewing 500 lines of generated code, the focus shifts to the specification and the tests that support that solution.

The review is no longer centered only on readability or small implementation details. The main point becomes the clarity of the specification, whether it leaves room for misinterpretation, and whether the tests properly cover the defined scenarios, including more extreme cases.

The generated code might not even be the main focus. It becomes more of a piece of evidence that a valid solution exists for that specification.

Architecture as orchestration of AI agents

Architectural design also moves up a level. Instead of designing class hierarchies, you design systems of interacting AI agents. A diagram might show an “authentication agent” with a spec for handling JWTs and security policies, a “data processing agent” with a spec for a pipeline, and the APIs that define how they connect. The architect’s role is to define boundaries and success criteria for each part, and let the AI build and connect them.

Debugging starts with the specification

When a bug appears in production, the first step is not attaching a debugger to the generated code. It’s reproducing the failure in the verification environment. If you can write a test that demonstrates the bug, there are two possibilities:

1. The implementation is wrong. The AI agent failed to generate code that satisfies the specification. The solution is to report the failure and have the agent generate a new version that passes the stronger test suite.
2. The specification is wrong. The code correctly implements an ambiguous or incomplete spec. The solution is to fix the spec, strengthen the tests, and regenerate the component.

In this scenario, technical debt shifts toward poorly defined specifications and insufficient test coverage.

Where this vision is incomplete or optimistic

This idea is strong, but in practice things are messier. The model assumes new projects, where you can write good specifications from the start.

How do you apply this to a legacy codebase with no documentation and few tests? Creating a clear specification for a system no one fully understands is often harder than just fixing a bug.

Many software problems, especially in product work, are not mathematically precise. Requirements are discovered along the way. You build, show it to users, and adjust. A system that demands perfect specifications upfront doesn’t fit well with this kind of exploratory work.

And models are not compilers. They are non-deterministic. The same prompt can produce different results. This creates a new class of bugs where something works one day and breaks the next after a seemingly unrelated regeneration. Handling this requires a level of tooling and discipline we are only starting to build. This vision works better for well-defined problems like sorting algorithms or protocol parsers. It is less convincing for complex, user-facing products where the “spec” is always evolving.

What to do if Anthropic is even partially right

We don’t have to wait for this future to arrive to start adapting. If the most important work is moving from implementation to specification and validation, we can start now.

1. Treat specifications like code. Start writing more detailed and formal descriptions of component behavior before coding. Use more structured formats than a README, like TLA+ for system thinking or well-defined OpenAPI specs for APIs. Review the spec with the same rigor as code.
2. Invest in automated verification. Go beyond simple unit tests. Use property-based testing to validate rules across a wide range of inputs. Use mutation testing to find weaknesses in your test suite. The goal is to build a setup that gives you strong confidence in correctness, whether the code was written by a human or AI.
3. Practice instructing the machine. Knowing how to tell an AI agent what to do is a different skill from programming. It requires clarity of thought, understanding the model’s limits, and the ability to break problems into prompts that produce verifiable results. Start practicing this with current tools. When using an assistant, focus less on the generated code and more on refining your instructions until the output becomes consistently correct.

The engineer of the future may write less code, but will need to think with more structure than ever. The work is not going away. It is just moving up a level in the stack.

Will Engineers Be Replaced by AI? What’s Actually Changing in Software Engineering

Kody from Kodus — Mon, 30 Mar 2026 12:46:00 +0000

The question of whether engineers will be replaced by AI is not new, but this time it feels different. Previous automation focused more on build and deploy. Now AI goes straight into the code, generating functions and classes that look correct at first glance.

This touches what many of us considered our job and starts to create a constant concern about the future.

The answer is not a simple yes or no. While the cost of producing a line of code is dropping close to zero, the cost of understanding a complex system is not. The real work in software development is shifting. It is becoming less about typing and more about validation, integration, and making good decisions.

Where AI helps today

AI coding assistants do speed up some tasks. They are good at generating a first version of common patterns, writing boilerplate for a new component, or creating unit tests. Give them a well-defined problem with little context, and they can produce a solution in seconds.

I use them to understand unfamiliar code in legacy systems or to convert data from one format to another. In these more isolated tasks, the tool generates a solution, I review it, adjust what is needed, and move forward faster than if I had done it from scratch.

The limits of a quick draft

The code AI generates is usually a good starting point, but it is rarely a complete solution. It lacks the deep, implicit context of your project. It does not know about the technical debt in LegacyUserService, the upcoming database migration, or the specific coding conventions the team agreed on last quarter.

The output is clean, but without context. Our work is now more about reviewing, correcting, and integrating AI-generated code. We are the ones responsible for fitting that generic block into our specific and nuanced system.

The new problems in our workflow

While AI removes much of the repetitive work, it also introduces new problems that are harder to notice. The code it generates often looks correct, which makes the errors less obvious.

It may generate a function that follows the code style well but ignores error handling that the system requires to operate safely. It can also introduce a security vulnerability by using a library in a way that seems correct but is already known to cause issues.

This creates an additional mental load because every suggestion needs to be verified. We have to understand what the code does and also anticipate what it fails to do. The risk is accepting a block of code we do not fully understand, which is a fast path to accumulating technical debt. The bugs that come from this may only appear months later and will be much harder to trace. We are shipping more code faster, which increases the pressure on the review process.

The skills that matter more

As generating code becomes cheaper, the value of other skills increases. These are the parts of the job that AI does not do.

An engineer’s value comes from architectural design, which involves understanding dependencies between services, planning data flows, and making high-level decisions about system structure. AI can write a function, but it cannot design a distributed system that balances trade-offs between consistency, availability, performance, and cost.

It also comes from the ability to translate ambiguity. Turning a vague business need into a concrete technical plan involves asking questions and negotiating scope. This is a human process of building shared understanding. Complex debugging is another example, like tracing a production issue across multiple systems, logs, and dashboards. This requires a deep mental model of how everything fits together. Finally, communication and mentorship remain essential to explain technical trade-offs to product and set technical direction for the team.

Faster code generation makes a good engineer more valuable. An experienced engineer can use AI to increase output, test ideas, and build prototypes quickly, while applying system knowledge to ensure the final result makes sense.

Our role is to provide context

Our value is shifting. We are less focused on writing code and more on understanding the system context. Our job is to connect business requirements with technical constraints and ensure the code remains sustainable in the long term.

We spend less time writing a sorting algorithm and more time making sure the right data enters the system in the right way. Our role is to connect parts of the system that AI cannot see.

The focus shifts from the syntax of a loop to the coherence of the system as a whole.

How to adapt

This shift requires a conscious change in focus.

You need to treat AI as a very fast junior engineer that has no memory of past conversations. Give clear and specific instructions and small, well-defined tasks. Then critically review every line it generates. Do not fully trust it.

Build the habit of evaluating AI suggestions against your project’s constraints. Ask whether it follows your style guide, whether it introduces a dependency you do not want, or how it will behave under load.

Deepen your understanding of system design. Spend time reading architecture documents and analyzing how services in your company interact. The more you understand the system as a whole, the better you can guide AI-generated code to fit into it.

Focus on the human parts of the job. Get better at explaining complex ideas, negotiating technical plans, and working with your team. The hard problems have always been deciding what code to write. That part of the job is not going away.

AI Fatigue for Developers: Managing Cognitive Overload from Code Assistants

Kody from Kodus — Sun, 29 Mar 2026 08:44:00 +0000

The constant stream of suggestions from AI code assistants is creating a new kind of mental tax. The problem isn't prompt engineering or model accuracy. It's a deeper issue of control and focus, leading to what some engineers are calling AI fatigue.

When your IDE is constantly suggesting entire blocks of code, your job changes from creating to validating. You become a full-time reviewer for a junior developer who never sleeps, never learns your project’s specific context, and never gets tired. This model of passive assistance has a real, non-obvious cost. It trades the focused effort of building for the scattered effort of auditing, which can compromise the system’s integrity and the deep thinking that good engineering requires.

The silent cost of constant suggestions

Code assistants see a local window of your code, but they have no architectural awareness. They can generate a function that correctly implements an algorithm, but they don’t know about the new data access pattern the team agreed to last month or the long-term plan to deprecate a library. The developer is left to catch these subtle, critical deviations.

Shifting the review burden to the engineer

Every AI suggestion is a tiny pull request. You have to stop, read the suggestion, parse its logic, check its correctness, and make sure it aligns with the project's architecture. This is a real context switch that interrupts your train of thought.

When you write code from scratch, the logic flows from your mental model of the system. When you review an AI suggestion, you first have to reverse-engineer the AI's logic and then map it back to your own. This validation cycle, repeated dozens or hundreds of times a day, fragments your attention. The cognitive load isn't reduced, it’s just changed from a focused block of creative work into a scattered series of validation checks.

Why passive assistance erodes critical thinking

Deep work in software engineering requires holding a complex problem in your head. You build a mental model of how components interact, how data flows, and where things might fail. Constant suggestions from an AI assistant actively work against this. The stream of code snippets keeps your attention at the surface level, focused on the next few lines instead of the overall structure.

This continuous interruption prevents the sustained focus you need to see a better abstraction, question a requirement, or spot a potential performance bottleneck. The AI optimizes for local correctness, while an experienced engineer optimizes for the system’s global health. By offloading the "easy" parts, we risk losing the context that helps with the hard parts.

AI fatigue: A new source of engineering debt

The speed gains from AI assistants are immediate and easy to measure. The architectural drift and fuzzy ownership that come with them are not. This asymmetry creates a new, quiet form of engineering debt.

The subtle drift in code ownership

When you accept an AI suggestion, a small part of the code's "why" is lost. The code is there and it works, but the reasoning behind its structure and the alternatives that were discarded exist only in the model's latent space. You, the author, don't have the same depth of ownership because you didn't go through the process of creating it.

When it comes time to refactor or debug that code six months later, that lack of deep context is a liability. The team has a block of code that is technically sound but feels architecturally foreign. No one feels a strong sense of ownership, which makes it harder to evolve or fix.

When speed obscures architectural intent

An AI assistant will happily generate code that violates your team's established patterns if it saw a different, more common pattern in its training data. It might use a direct database call where you've built a repository layer, or implement custom state logic in a component that should be using a centralized store.

These small deviations seem harmless by themselves. They get the immediate task done faster. Over time, they break down the architectural coherence. The system becomes a patchwork of different patterns, making it harder to understand, maintain, and test. The speed you gained on the first commit is paid back with interest during every future maintenance cycle.

Defining AI boundaries: A control-first approach

The answer isn't to abandon these tools. We need to shift from passive, continuous assistance to explicit, on-demand use. The developer must be in control, deciding when and how to ask for help.

Explicit ways to use AI

Instead of a constant stream of suggestions, we can use AI for specific, high-value tasks.

Scaffolding on demand. Use the AI for boilerplate. Ask it to generate a new gRPC service with stubs, a new component with a test file, or a CI/CD pipeline from a template. This is a one-shot generation task that saves setup time without interfering with the core logic.
Generation from your patterns. For well-defined, repetitive tasks, show the AI examples of your own code. Give it a few existing data models and their repository classes, then ask it to generate a new repository for a new model. This constrains the AI to your project's specific conventions.
Help with refactoring. Use AI for mechanical changes on a selected block of code. Tasks like converting a `for` loop to a `map`, extracting a method, or changing a Promise chain to async/await are well-suited for automation. The scope is small and your intent is clear.

Team policies for code assistant output

To manage the code that comes from AI, teams need simple conventions. This is about managing risk and maintaining clarity.

Flag AI-generated code in reviews. A simple comment like `// AI-generated, reviewed for correctness and style` or a pull request label tells the reviewer to apply a different kind of scrutiny. The focus should be less on syntax and more on architectural fit.
Check for architectural compliance. The main job of a human reviewer for AI-assisted PRs is to be an architectural backstop. Does this code use the right data layer? Does it follow our error handling standards? Does it introduce dependencies we are trying to remove?
Document AI use in pull requests. A brief note in the PR description about which parts were AI-generated helps build a history. If you start seeing bugs from AI-generated code, this data becomes useful for refining team policies.

Measuring AI’s impact on architecture and reliability

Productivity claims for AI often focus on lines of code or commit frequency. These metrics miss the point. The real measure of a tool’s effectiveness is its impact on our mental state, the system’s reliability, and its long-term maintainability.

Evaluating the real cognitive load

We need to measure the total effort, not just the time it takes to write the first draft.

Compare time spent. For a given feature, track the full cycle time. Does the time saved in generation get eaten up by validation, debugging, and refactoring?
Track bugs from AI code. When filing a bug, add a field to identify if the code was known to be AI-generated. Over time, you can see if there is a correlation between AI use and certain types of defects, especially subtle logic or integration bugs.
Ask developers how they feel. Do they feel more focused or more fragmented? Do they feel like they are spending more or less time in a state of deep work? Anonymous surveys can provide honest feedback on the perceived mental cost.

Prioritizing deep work over suggestion streams

The goal of any developer tool should be to get out of the way so engineers can solve hard problems. AI assistants, in their current always-on form, often do the opposite. They pull your attention to the surface and encourage a reactive workflow.

By establishing clear boundaries and using AI for specific, targeted tasks, we can reclaim control. The goal is to make AI a tool you pick up for a job and then put down, not a constant presence that reshapes how you think. The most valuable work in engineering still happens during quiet, uninterrupted stretches of deep thought, and our tools should protect that focus.

Context Engineering vs Prompt Engineering: the shift in how we build AI systems.

Kody from Kodus — Sat, 28 Mar 2026 19:46:00 +0000

You receive a pull request coming from an AI. The code looks clean, follows the prompt, and all unit tests pass. Then you notice it uses a library the team deprecated last quarter. And a design pattern that violates the service’s architecture document. The code looks right, but it is completely wrong in the context of your system. This is the absolute limit of prompt engineering. The whole "context engineering vs. prompt engineering debate" comes down to a practical problem: our AI tools keep delivering code that requires careful manual fixes.

Prompt engineering works well for isolated tasks. Building software is not a sequence of isolated tasks. It is a chain of decisions constrained by existing code, team habits, and business rules. The problem is not a poorly written prompt. The problem is that the model has no idea what is happening outside its small window. Asking a better question does not help when the model cannot see the rest of the codebase.

The costs of prompt engineering at scale

Using prompt engineering for anything larger creates a fragile, high-maintenance system. You get stuck in a loop of tweaking prompts to fill gaps in the model’s knowledge, and then everything breaks when the model gets updated or the problem becomes harder.

A maintenance nightmare

When an AI system depends only on the prompt, the system becomes hard to maintain and easy to break. Engineers write absurdly complex prompts to get the right behavior, and those prompts turn into a mess that is impossible to maintain, full of assumptions about how the model "thinks".

This fails in a few ways. A small change in the output means you have to go hunting for which prompt to modify, which is even worse when prompts are chained. When a provider releases a new model version, your carefully tuned prompts can break. An instruction that worked perfectly yesterday can produce a completely different format or a logical error today. And when something fails, it is hard to debug. You end up guessing whether the problem was the prompt or the lack of context, because you cannot easily reproduce the exact state the model was in.

You can only optimize a prompt so far

There is a limit to what you can achieve by only refining a text prompt. Building software requires awareness, not just a good instruction. A prompt cannot contain a project’s dependency graph, the reasoning behind an old architectural decision, or how the team prefers to handle asynchronous operations.

You end up with code that is technically correct, but in practice is useless. Error handling is a perfect example. A model will generate generic `try/catch` blocks because it knows nothing about structured logging, error types, or the system’s metrics patterns. The code works, but it is incomplete and does not fit, which means a developer will need to fix it. Without system awareness, AI produces unpredictable results that make people lose trust in the tool.

Context Engineering vs. Prompt Engineering: a different way to think

We need to stop trying to cram everything into the prompt. We should focus on designing the environment the model works in, not just optimizing the instruction. This means building systems to provide the model with the specific and explicit information it needs to make decisions that actually fit.

Context engineering is the work of designing, building, and maintaining the systems that collect, filter, and provide this information to the model.

More than just a prompt

An interaction with an LLM should not be `prompt -> output`. It should be `(context + prompt) -> output`. The prompt is just a small part of a much larger package. This operational context can include data, like relevant code from other files, database schemas, or API contracts. It can also include tools, which are functions the model can call to get more information (like running a linter or checking user permissions). It can even include state, like which files the user has open or which commands they just ran.

This completely changes the work. We are architecting an AI environment, not just writing prompts. The real work is deciding which information needs to be explicitly provided and what the model can be expected to know. A code style guide is explicit context. Python syntax is implicit knowledge.

Context engineering is system design

This approach changes how we build with AI. Instead of endlessly tweaking text, we move to building structured and predictable components. A context engineer thinks about the whole system, while a prompt engineer focuses on a single interaction.

A prompt engineer tries to improve a response. They might change a prompt from "write a function that does X" to "acting as a senior software engineer, write a pure function that does X, follow functional programming principles, and include property-based tests." This might give you a better answer in that specific case.

A context engineer wants to make the entire system more consistent and reliable. They build the infrastructure that automatically finds the team’s functional programming principles in the wiki, pulls examples of existing property-based tests from the code, and provides all of that as context. The prompt can stay simple. The system becomes more reliable because the model’s decisions are now based on real project data.

The real intelligence is not in the model. It is in the system that feeds it. Building AI products that are sustainable depends on this.

Principles for building with context engineering

This requires a more disciplined way of passing information to models. It looks a lot like system design, which is a good sign.

Design your system to deliver context

The first step is to treat context as a core part of your system architecture. The code that fetches the database schema should not be mixed with the code that formats the prompt. You should create separate modules or services that only provide specific pieces of context. This makes the system much easier to test and maintain.

Whenever possible, provide context as JSON or YAML, not just as a large block of text. This helps the model interpret the information more reliably. For example, provide the style guide as a JSON object of lint rules instead of pasting raw text.

You also need versioning for your context. API schemas change, documents get updated. Your system should be able to point to specific versions of these sources. This is the only way to reliably reproduce a past generation for debugging.

Thinking in layers of context

It helps to think of context as a stack of layers. Each layer provides a different type of information. This helps prioritize and filter what you send to the model, which matters for staying within token limits and avoiding noise.

A context stack for a coding task could look like this:

Layer 0 (Global): The model’s built-in knowledge of a programming language.
Layer 1 (Organization): Company engineering standards or preferred libraries.
Layer 2 (Project): Architecture patterns for this project, lint rules, and dependency list.
Layer 3 (Local): The content of the current file and other related files the user has open.
Layer 4 (Dynamic): Real-time feedback from a compiler or test runner.

A feedback loop is already embedded in this idea. If the model generates code that fails a lint check, that failure becomes dynamic context for the next attempt. The system can self-correct using immediate and factual feedback.

Applying context engineering in practice

To make this work, you need to build the infrastructure to manage context as code.

Managing context with code

Orchestration tools can help, but a well-defined set of functions or microservices also works. The point is to have a programmable way to assemble and provide context. An orchestrator can call different context providers depending on the user’s request, assemble the final package of information, and send it to the model.

You also need to validate and monitor your context. Before sending information to the model, check it. Does the API schema parse? Does the file path exist? Keep an eye on the quality of your context sources. Outdated or incorrect context is worse than no context.

Finally, the system needs to adapt the context to the task. A request to refactor a function needs different information than a request to write a new database migration. Your code needs to be smart enough to fetch the right context for each type of work.

A checklist for building with context

When you are designing a new AI feature, ask these questions:

What information is needed? Identify every piece of information the model needs to make a good decision (source code, docs, schemas, git history, team patterns).
What is the scope? For a specific task, what is the boundary of the context? The current file, the package, the entire repository? How do you define this in code?
How do we know the context is good? How do you ensure the context is correct and up to date? What is the fallback if a source is unavailable?
How does it stay updated? When and how is the context updated? On every request, on a time interval, or after an event like a git commit?
Can we debug it? Are you logging exactly which versioned context was sent to the model along with the prompt? Can you perfectly reproduce a past generation

Answering these questions shifts the work from guessing the magic words in a prompt to building a software system that is reliable and easy to debug. Small improvements in a prompt lead to small improvements in the output. Improving the context changes the reliability of the entire system.

What Is Context Engineering and How to Apply It in Real Systems

Kody from Kodus — Fri, 27 Mar 2026 22:43:00 +0000

An AI code assistant generates a function to handle user uploads. The code looks correct, compiles, and passes all tests. You merge it. Two days later, a high-priority bug comes in. Files from premium plan users are being processed by the standard, slower queue. The generated code called the generic function `enqueue_job()` because it had no idea that a utility `priority_enqueue_job()` existed for specific user roles. The code was correct, but wrong for the system.

This is the ceiling that most teams hit with LLMs. The model’s reasoning ability is good, but it is almost completely unaware of your system’s operational reality. Fixing this requires a system-level approach. This is context engineering: the process of selecting and structuring the right information to give to the model, so the output is not just plausible, but correct within your specific environment.

The cost of disconnected models

When a model operates with incomplete context, it produces outputs that are plausible, but wrong. These errors are tricky because they pass static analysis and even basic unit tests. They are integration and logic bugs that reveal a gap between the model’s world and the reality of the codebase.

I have seen this happen in a few ways. A model suggests adding `axios` to a Node.js service, without knowing there is already an internal, hardened HTTP client with tracing and built-in error handling that is required for all network calls. An LLM refactors a method in Python to gain efficiency, changing the data type of a rarely used return value from `list` to `generator`. The local module’s unit tests pass, but a downstream service that consumes this output now fails at runtime because it expects to be able to call `len()` on the result. Or a model writes a database query that works perfectly in isolation, but omits a required `WHERE tenant_id = ?` clause because it is not aware of the system’s multi-tenant architecture.

In each case, a developer needs to manually step in, figure out what the model missed, and rerun the task with the missing information. This manual process of re-engineering context for each request is a productivity tax that does not scale. It is what turns a “10x” tool into a 1.1x tool with a high maintenance cost.

What is context engineering

Prompt engineering focuses on refining the instructions given to a model, on properly formulating the command. Context engineering is about providing the operational information required for the model to execute that command correctly. A prompt engineer works on the `System:` message. A context engineer builds the data pipelines that populate the `User:` message with everything the model needs to know.

This goes beyond simply throwing data into the prompt. It is about identifying the critical pieces of information that define the operational boundaries of a task. This information should be treated as a first-class architectural concern, not a last-minute detail.

Main operational context boundaries include:

Relevant data points: Instead of the entire database schema, provide the schemas of the tables related to the user’s request. Instead of all API endpoints, deliver the OpenAPI specs of the services involved.
User interaction history: What did the user just do? What error did they just see? What is their role and what permissions does that grant?
System state variables: Current feature flags, API rate limits of a dependent service, or the load on a database replica. This information is volatile and exists outside the codebase.

Treating context as a detail is why so many AI integrations feel fragile. Treating it as part of the system architecture is how you make those integrations reliable.

How to manage context

A systematic approach to context means identifying what matters, designing how to deliver it, and keeping the information up to date.

First, you need to map the categories of information a model needs to execute a task correctly. User context includes ID, permissions, preferences, and recent activity. Is the user an admin or a standard user? Are they on a free or enterprise plan? This often defines which business rules apply. Domain context is your business logic and constraints, like “Orders above $10,000 require a manual approval step”. Operational context is the real-time state of your system, like API rate limits or active feature flags. This is the most dynamic type of context. Finally, interaction context is the state of the current session, like previous questions in a chat or the error message from the last failed test.

Once you know what you need, you have to get it to the model. There are a few patterns, each with different trade-offs in performance and complexity. The simplest method is direct parameter passing, where you include short-lived context like a `session_id` directly in the API call. For more persistent information, a context store like Redis can store user profiles or permission sets, which your application retrieves before calling the model. To fetch information from large volumes of text like documentation or the codebase, Retrieval-Augmented Generation (RAG) can find the most relevant chunks to include. Some context can even be inferred from system events, like automatically injecting information about a high-latency microservice.

The main trade-off is between completeness and performance. A full RAG query can add 500ms of latency to a request. A larger context increases token cost and can introduce noise that worsens model performance. The goal is to provide the minimum sufficient context, not the maximum possible.

Outdated context is as bad as no context. A model that thinks a deprecated function is still in use will generate code that is already broken. Just like your API schemas, the structure of the context you provide also changes, so you should version your context objects. You need to monitor how stale the information is and define expiration limits. This should not be manual. Connect this to your CI/CD pipelines. When documentation is updated, a post-commit hook should trigger reindexing. When a new microservice is deployed, its OpenAPI spec should be automatically published to your context store.

Putting it into practice

Building context-aware systems means designing services where context assembly is a primary responsibility. Instead of each feature calling the LLM directly, you can have a central service that gathers information from different sources and provides it to other services.

This also means designing for failure. What happens when a context source is not available? The system should degrade in a controlled way. A code generation tool that cannot access the full codebase might refuse to perform a complex refactor and offer a simpler, safer alternative. It should signal that the response is based on incomplete information.

You need to measure the impact. Track how often the model’s output is accepted without changes versus when it requires manual edits. Instrument your systems to log when the lack of a specific type of context leads to an error. This data will show where context matters most and where it is worth investing in improving your retrieval pipelines.

Teams that treat AI as a prompt engineering problem quickly get stuck in a loop of tweaking instructions and manually fixing plausible but wrong outputs. They hit a reliability ceiling.

Teams that treat AI as a systems integration problem, a context problem, will build the infrastructure to provide models with the information they need to be actually useful. They will unlock a higher level of performance and reliability.

Scaling DevOps Culture: From Improvised Scripts to Platform Engineering

Kody from Kodus — Fri, 27 Mar 2026 12:41:00 +0000

The collection of scripts, manual configurations, and unwritten rules that helped your company get started will eventually begin to hold you back. What once felt improvised and efficient becomes slow and fragile as the team grows. This is a predictable breaking point in an organization’s DevOps culture. The systems that helped a team of ten people move quickly now create friction for a team of fifty. Operational work spreads out, slowing down feature development until you are spending more time dealing with custom deploy logic than writing code.

The costs of “good enough” automation

Early automation is usually just about being practical. You write a script that solves the immediate problem, set up the CI job that gets the build running, and move on. This works for a while, but the cumulative weight of these one-off solutions eventually starts pulling the entire engineering team down.

The limits of ad hoc scripts and tribal knowledge

The first signs of trouble are inconsistencies. Team A’s services run on a slightly different base image than Team B’s because they were configured months apart. One developer’s local environment works perfectly, while a new hire spends their first week fighting with dependencies because a setup script is outdated. It is a direct tax on productivity.

These improvised and undocumented setups end up creating recurring problems. Staging environments start drifting away from production as manual changes accumulate. As a result, deploys become less predictable.

Engineers end up getting pulled into tasks that have no direct connection to the product, such as debugging infrastructure, manually provisioning resources, or investigating deployment failures caused by differences between environments.

Pipelines start depending on specific scripts run locally or CI configurations that are difficult to understand and maintain. And new engineers face a steeper learning curve, not only to understand the codebase, but also to figure out which tools and processes they need to use in order to work on the system.

When “you build it, you run it” hits a limit

The principle of “you build it, you run it” is a great way to create a sense of ownership. A product team is responsible for its service, from code all the way to production. In a small company, this works well. At scale, the problems start to show.

When you have five, ten, or twenty teams all following this principle on their own, duplication appears. Each team builds its own Terraform modules for the same S3 bucket configuration. Each team creates its own alerts for CPU usage. Each team writes its own deploy pipeline for a standard web service.

This model creates bigger problems. The company pays for the same infrastructure and CI/CD work repeatedly, solved in slightly different ways by each team. Without a centralized approach, ensuring that all services follow security best practices or compliance standards becomes almost impossible. The burden ends up falling on individual teams that may not have the required expertise. Product engineers are forced to become specialists in Kubernetes, cloud networking, and observability tools just to keep their features running. Their attention gets split between building the product and managing its operational details.

Platform engineering as an evolution of DevOps culture

The answer is to evolve the environment where developers work while keeping the principle of ownership. That is the idea behind platform engineering. It changes the question from “How do we help each team run their own infrastructure?” to “How do we provide a platform that makes running infrastructure simple and consistent for everyone?”

Going beyond tool-centric DevOps

Many organizations see DevOps only as a set of tools such as CI/CD servers, infrastructure-as-code files, and monitoring dashboards. A platform approach is more about offering shared services and clear workflows.

Instead of simply giving developers raw access to cloud provider tools, a platform offers a higher level of abstraction. A developer should not need to write a complex CI/CD pipeline from scratch. They should be able to add a simple configuration file in the repository that connects to a standard pipeline managed centrally.

This means treating your internal infrastructure as a product. Your developers are your users. The success of the platform is measured by how much faster and more reliably they can deliver value to real customers. Self-service is a huge part of this. A developer should be able to create a new testing environment or check service logs without opening a ticket and waiting for another team.

Redefining roles and responsibilities in a scaling DevOps culture

This shift changes team structure and responsibilities. A common and effective pattern is to create a dedicated platform engineering team. This team is different from a traditional operations team that only acts as a gatekeeper. Its main job is to improve the developer experience and make engineers more effective.

The platform team concentrates the operational knowledge of the system. They build and maintain the core infrastructure, the CI/CD systems, and the observability stack. They also provide the tools and services that product teams use every day.

This creates a collaborative relationship. The platform team builds the standard path for development, and product teams use that standard to move faster. Product teams remain responsible for their own services, but the heavy lifting of the underlying infrastructure is already solved for them. That way they can focus on business logic, while the platform team ensures the infrastructure is secure and reliable.

Building your internal developer platform

Creating a platform is an ongoing process of identifying what slows developers down and building solutions to fix it.

Defining platform capabilities

Start by identifying the most common needs and problems across your engineering teams. The first platform services usually cover a few core areas.

You can offer standardized CI/CD pipelines, with reusable templates or workflows that handle build, testing, security analysis, and deployment for common application types. This way the developer only needs to define what is specific to their service.

Another important area is environment management, offering a simple way to create and destroy development, testing, and staging environments that stay consistent with production.

It is also worth centralizing logs, metrics, and traces. Services can be instrumented automatically with standard configurations, giving teams immediate visibility without requiring a lot of manual setup.

Finally, provide a secure way to manage application secrets and adopt strong security practices by default, such as secure network rules and IAM policies.

Adopting a product mindset for internal tools

Your platform will only succeed if developers actually use it. You cannot simply build it and assume they will show up. You need to treat it like any other product.

That means collecting feedback constantly. Talk to developers, run quick surveys, and create open office hours to answer questions and understand how they work and where they struggle. Use that information to decide what to build next.

Prioritize initiatives that solve real and recurring problems for multiple teams, not just ideas that seem technically interesting. Whenever possible, try to quantify the impact. Ask whether a new tool will save each developer an hour per week or reduce deployment failures by 50%.

It is also important to measure success by tracking adoption of platform services and developer feedback. Look at metrics such as deployment frequency, lead time for changes, and mean time to recovery. A good platform should improve these numbers.

Principles for a platform team

The culture of a platform team determines whether it becomes a help or an obstacle. Some principles tend to work well for successful platform teams.

Focus on helping developers, not controlling them. The platform should provide a standard path, with strong tools and well-supported patterns, but it should also allow alternatives when a team has a good reason to do something differently.

Treat platform services as internal products with clear APIs, good documentation, and easy-to-find materials. Build something small that already delivers value, put it into use, and evolve it based on feedback from teams. The idea is to avoid long cycles trying to build a “perfect” solution that may not solve what developers actually need.

It is also important to communicate continuously. Announce new features, changes, and deprecations through internal demos, posts, or newsletters. Teams should always know what the platform offers today and what is changing.

Making the transition without causing disruption

The goal is to evolve infrastructure gradually without needing to stop product development for a year to rebuild it.

Start with the biggest problem, the thing that generates the most complaints or wastes the most time. It might be inconsistent local environments or the manual process for creating a new service. Solve that first.

For each new platform service you build, provide clear instructions and support to help teams migrate from the old improvised way of working. Sometimes that means creating tools that automate parts of the migration.

The first team that adopts your new CI/CD pipeline and cuts deploy time in half will likely become a strong advocate for the change. Results like that help build momentum and encourage other teams to adopt the new approach.

How to Manage Dependencies and Packages in Large-Scale Projects

Kody from Kodus — Thu, 26 Mar 2026 10:35:00 +0000

When a single dependency update in one service causes a runtime failure in another, that is not an accident. It is what happens when lack of coordination becomes the norm. Any large project that treats dependency management as a local decision made by each team will eventually reach this point. The problem becomes a burden on the engineering team, showing up as build failures and hours spent debugging version conflicts instead of shipping features.

The impact of dependencies in large systems

How this affects engineering speed

Uncontrolled dependencies cost time. When Team A uses version 1.2 of a library and Team B’s service pulls version 1.3 through a transitive dependency, the build system may not flag any issue. At runtime, however, a small difference in the API can trigger NoSuchMethodError exceptions that are difficult to trace. Debugging this requires engineers to understand not only their own code, but also the dependency graphs of several loosely connected services.

This complexity slows down the build process. Resolving conflicting dependency trees is expensive for CI/CD pipelines. More dependencies mean larger artifacts. A service that should be a 50MB container grows to 500MB because it includes three different HTTP clients and two JSON parsing libraries, each with their own transitive dependencies. Every developer pays this tax on every build.

Security and compliance risks that go unnoticed

Every package you add is a new attack surface. A vulnerability in a library three levels deep in your dependency tree is just as exploitable as one in your own code. Without a central view, teams often do not even know they are using a vulnerable package until it is too late. The response turns into an emergency state where engineers run through multiple repositories trying to find affected services and apply patches.

License compliance is another blind spot. A developer might include a library without realizing its license conflicts with the company’s legal rules. Manually auditing licenses across thousands of dependencies is impossible. Without automated checks, you are exposed to legal risk, and fixing it later often requires expensive rewrites to replace the problematic dependency.

The case for more opinionated dependency management

Why individual package choices by teams cause problems

Giving every team full autonomy to choose their dependencies creates divergence that slows down the entire organization. When different teams pick different libraries for the same task, such as logging or database access, shared knowledge disappears. An engineer moving between teams has to relearn basic tools. Solutions developed in one part of the organization do not transfer.

Maintenance is usually the biggest problem. When a security flaw appears in a library used by several teams, each of them has to stop what they are doing, understand the patch, and deploy it. If a central library releases a new major version with breaking changes, this work repeats in every team.

This distributed effort is far less efficient than addressing the problem once, in a coordinated way by a platform team.

How to give autonomy without breaking system stability

We need to frame the question of developer choice more carefully. Instead of thinking only about which package solves the problem fastest, the team also needs to consider which option is more stable for the system. Autonomy means being able to ship features without worrying that the platform will behave unpredictably.

The short-term convenience of adding a new dependency without review creates a long-term cost paid by everyone. That cost appears as weekend hours responding to incidents or weeks of work fixing a vulnerability. Adding a bit of friction at the start, such as requiring new dependencies to be evaluated, prevents much larger problems later. You are choosing the stability of the whole system instead of the local optimization of a single team.

Establishing a dependency governance model

Choosing approved packages and versions

A good governance model starts with an approved list of libraries for common tasks. Instead of ten teams choosing ten logging libraries, you standardize one or two. This list works as the default path for development. It provides clear, supported options that have already been evaluated for security and license compliance.

This list should also come with clear versioning guidelines. For example, you might decide that all services must use the same minor version of a framework to avoid compatibility problems. This can be enforced using internal package registries or mirrors. They act as an intermediary between your developers and public repositories, allowing you to host validated versions of packages. This creates a central control point that prevents unapproved packages from entering the system.

Automating security and compliance checks

Human review does not scale, so your dependency policy needs to be automated. Integrate vulnerability and license scanners directly into your CI pipeline. A build should fail if it introduces a dependency with a known vulnerability or an incompatible license.

This automation turns security and compliance into part of the development cycle. Developers receive immediate feedback on pull requests and can fix issues before merge. Security debt does not accumulate, and the policy becomes a mandatory check for everyone instead of a document that nobody reads.

Strategies for managing transitive dependencies

The dependencies you declare are only a small part of the story. Transitive dependencies, the packages your dependencies rely on, make up most of your node_modules folder. Managing them is essential to maintain stability.

You should pin exact versions in lockfiles. Every package manager generates a file such as package-lock.json or yarn.lock that records the exact version of each dependency. Committing this file to the repository makes every build reproducible, whether on a developer’s laptop or on the CI server. This eliminates “works on my machine” problems.

You also need an explicit override policy. Sometimes a transitive dependency has a vulnerability, but the direct dependency has not yet been updated to fix it. You need a way to override the version of that transitive dependency. This should be a temporary and documented fix that you track and remove once the main package is updated.

Finally, regularly audit the entire dependency graph. This can reveal excessive packages and show where libraries can be consolidated. It also gives a high-level view of the third-party surface of your system.

Practical approaches for managing dependencies at scale

Tools and practices for large projects

In a monorepo, use a package manager that enforces a single version of any dependency across all projects. This makes version conflicts impossible by definition. If one project needs to upgrade a library, all other projects that use it are upgraded at the same time, forcing a single coordinated change.

For any type of repository, automated dependency update bots can reduce the work required to keep packages up to date. These bots open pull requests to update dependencies and usually include release notes. This turns updates into a simple task of “review and merge”, preventing your dependencies from becoming dangerously outdated. To add new dependencies, a review process with a platform team can ensure that new additions follow your standards and do not introduce risks.

Building a shared dependency policy

Having these rules documented makes your approach clear. This document should explain the “why” behind the decisions and be updated as things change.

Your policy should define how upgrades are handled. You might decide to apply minor and patch updates quarterly, while planning major version upgrades as separate projects. This creates a predictable rhythm for maintenance.

It should also define deprecation paths. When a standard library is replaced, give teams a clear deadline for migration, along with documentation that helps with the process. Set a firm date to remove the old library from the approved list.

The policy also needs to cover incident response. When a zero-day vulnerability like Log4Shell is announced, what happens? The policy should specify who evaluates the impact and who coordinates the remediation effort. Having that plan before you need it helps a lot.

How to implement DevOps without creating more complexity

Kody from Kodus — Wed, 25 Mar 2026 21:40:00 +0000

Most large DevOps projects fail to deliver results. They usually start with a new tool or with a top-down directive to “be more agile,” but they rarely solve the real problems that are slowing down software delivery. Teams end up with complex CI/CD pipelines that only automate a broken process, or with Infrastructure as Code that provisions inconsistent environments. Instead of faster and more reliable releases, everyone just ends up frustrated. Everything goes wrong because people start from the solution instead of starting from a specific and expensive problem.

The mismatch in adopting new practices

The desire to adopt a new tool is often the starting point. A platform team builds an internal deployment system, only to discover that product teams won’t use it. The reason is usually simple. The new tool solves the platform team’s problem, but creates new problems for the product team. Maybe it requires a major rewrite of the application’s deployment logic or imposes a workflow that simply doesn’t fit how the team operates.

That is why migrations done all at once usually fail. Forcing every team to adopt a new CI system or a standard Kubernetes platform by a specific date almost always creates resistance. Teams with stable legacy systems are pushed to do high-risk work with low return. Teams with tight deadlines see the directive as a distraction. If they don’t see an immediate benefit to their own work, the new system is just extra overhead.

Many times we also measure success in a way that is disconnected from reality. Deployment frequency is a popular metric, but it can be misleading. A team might deploy 20 times a day, but if the lead time from commit to production is still five days because of slow manual QA and long review cycles, the real bottleneck is still there. You only sped up the final, automated step. Real improvement comes from measuring lead time, change failure rate, and mean time to recovery (MTTR), which show the health of the delivery process as a whole.

Why good intentions fail: understanding resistance

When people resist change, there are usually good technical or organizational reasons behind it. No one is against something new just for the sake of opposing it.

Established workflows are hard to change. A senior engineer who knows exactly how to manually deploy a critical service tends to see a new automated system as a risk. The current process, even if it is slow, is predictable. A new pipeline that the team does not fully understand yet can fail in ways that are hard to diagnose. The resistance comes from the need for stability.

Skill gaps are another major obstacle. You cannot ask a backend team that has always depended on a central ops team to suddenly start writing and maintaining its own infrastructure configuration. That requires training, time to learn, and a manager willing to accept a few mistakes along the way. Without that time and support, teams will go back to the old methods because they are faster and safer in the short term.

A lack of clear leadership sponsorship can also kill any new initiative. If engineering managers do not protect the team’s time to learn and adapt, this work will always be pushed aside in favor of features. When leadership celebrates feature releases but ignores engineering improvements, the message is clear. The initiative dies from neglect.

Focus on outcomes, not practices

Instead of saying “We need to adopt Infrastructure as Code,” ask: “What is the most expensive problem in our delivery process?” Cost is not just money. It is developer time, delayed releases, and production incidents.

Look for places where a small change can generate a large impact.

An unstable end-to-end test environment that takes hours to spin up might be a bigger problem than deployment speed. Fixing that can free up more developer time than any new CI tool.
A manual database schema migration process that requires coordination between three people is an obvious bottleneck. Automating that single step might be the most valuable project you can take on.

This way, engineering work becomes tied to something the business actually values. Reducing the time to fix a production bug from four hours to 15 minutes is a clear win for everyone. It is a much simpler conversation than discussing the abstract benefits of a specific tool.

Define and measure success

To get buy-in for this type of work, you need to connect the initiative to measurable metrics. Before starting anything, establish a baseline.

If you cannot measure the problem, you cannot prove that you solved it.

For a problem like “Staging environments are always broken and out of sync with production”:

Baseline: It takes two days to provision a new staging environment. We receive 25 support requests per month related to staging issues.
Goal: A developer can provision a new production-like environment in less than 30 minutes. Staging-related requests drop by 90%.

For a problem like “Hotfixes for critical bugs take hours to reach production because of manual tests and release checklists”:

Baseline: Our mean time to recovery (MTTR) for P0 incidents is 4.5 hours.
Goal: We can get a hotfix into production within 20 minutes after the code is merged. Our MTTR drops below one hour.

When you communicate these numbers to stakeholders, an internal engineering project starts to be seen as a visible business improvement. The conversation stops being about cost and becomes about investment.

A step-by-step approach to improving

A successful rollout is a sequence of small wins, not a single massive project. First, understand where your teams are today. Some may have excellent CI setups, while others still deploy manually via FTP. A single plan for everyone will fail. The idea is to find the biggest bottleneck for a team or service and solve that point. Then you find the next bottleneck.

A simple way to move forward

Here is a path to get started.

Step 1: Find the biggest source of delay.

Sit down with a team and map the entire process from commit to production. Where does work get stuck? Waiting for code review? A QA environment? Manual approval from another team? Identify the biggest waiting time. For example, a team may realize that their two-week sprints are always delayed because getting a new database instance from the DBA team takes, on average, four days. That is where you start.

Step 2: Define a specific and measurable goal.

Based on the delay you identified, define a clear outcome. Using the database example, the goal might be: “Any developer on the team can provision a new database for testing in less than 10 minutes without opening a ticket.”

Step 3: Choose the smallest change that works.

What is the simplest tool or process change that achieves the goal? Maybe you do not need a full self-service cloud platform. The first step could be a set of standardized and versioned scripts, reviewed and approved by the DBA team. This moves the process from a manual ticket-based flow to an automated code-based flow. That is Infrastructure as Code used as a solution to a specific problem, not as an end in itself. In the same way, you can introduce CI simply by automating the unit tests that everyone should already be running locally.

Step 4: Run a pilot with one team.

Choose a team that feels the pain and is willing to experiment. Do not start with the most critical system or the most skeptical engineers. You want a quick win to learn from the process and generate momentum. That pilot team becomes your first success case.

Step 5: Measure, learn, and repeat.

After the pilot, go back to the baseline metrics.

Did you reach the goal?

Did the change create new problems?

Maybe the self-service database scripts worked, but now developers forget to deprovision them and costs are rising. That is just a new problem to solve. This feedback cycle is what actually drives improvement over time.

How to maintain progress

As more teams adopt new practices, the risk of fragmentation appears. If every team builds its own deployment pipeline or writes its own infrastructure modules, you create a maintenance nightmare. This is where some patterns come in.

The goal of governance is to make the right way the easiest way.

This usually becomes the responsibility of a platform team or internal engineers who build improvements for others to use.

Shared pipeline templates: Provide preconfigured CI/CD templates for common application types (such as a Go backend or a React frontend). A team can have a secure and efficient pipeline running in minutes instead of weeks.
Reusable infrastructure modules: Create a library of versioned IaC modules for standard resources such as databases, caches, and load balancers. This ensures consistent and security-approved configurations.
Clear ownership: Define who is responsible for each part. Does the product team own the application pipeline end-to-end? Does the platform team own the build infrastructure? Lack of clarity about responsibilities leads to systems that no one maintains.

This approach gives teams the freedom to move quickly using the standard paths, while the platform team ensures stability for the entire organization.

You avoid both the chaos of everyone doing their own thing and the bottleneck of a central Ops team that has to approve every change. The only way to keep this working is to keep listening to what teams need and constantly improve the standard paths they use in their day-to-day work.

Platform Engineering Best Practices for Building Internal Platforms That Scale

Kody from Kodus — Wed, 25 Mar 2026 16:32:32 +0000

Many companies see the cost of their internal developer platform skyrocket. The goal of Platform Engineering is to unify tools and accelerate delivery, but things rarely go as planned. Soon, teams start struggling with inconsistent tools. Some give up and keep their own customized setups, in a silent resistance to the platform. Feature delivery practically grinds to a halt, even with all the money invested in the central system. This is what happens when a platform creates more problems than it solves.

When Platform Engineering initiatives stall

The first sign of trouble is when the platform, which was supposed to be an accelerator, starts slowing everyone down. The failure is usually in the concept, not the code. The platform engineering team often makes decisions that seem to make sense at first, but turn into problems over time.

The dilemma of the product mindset for internal platforms

People love to say that you should apply a "product mindset" to an internal platform, but that advice often backfires. The team starts building for imaginary use cases instead of observing how developers actually work. They create complicated features based on what they think developers should want, while ignoring what they clearly need.

A platform built in isolation reflects the platform team’s ideal version of development, not the way the rest of the company actually builds software. You end up with a tool that solves theoretical problems while ignoring the repetitive day-to-day tasks developers deal with. The platform may offer a perfect one-click deploy for a certain type of service, but if 90% of the company’s services don’t fit that model, the effort was wasted.

Abstraction debt and rigid design

Good platforms use abstraction to reduce complexity. Bad platforms use abstraction to hide important decisions. When abstraction goes too far, it hides exactly the details engineers need to debug and tune performance.

The developer tries to understand why the service is slow but cannot access infrastructure configurations, network rules, or resource limits. They have no visibility into what is really happening.

This rigidity traps teams. If someone needs a database version that is not offered by the platform, or a specific sidecar for observability, there is nowhere to go. The platform’s design blocks basic technical choices and they lose the ability to manage their own services. They become completely dependent on the platform team even for small changes, which turns that team into a permanent help desk.

Practical ways to build a good platform

To avoid these stalls, the approach needs to change. Stop building a monolithic product and start providing a layer that helps developers do their work.

Focus on developer experience and workflow

A useful platform is a usable platform. The focus needs to be on the main developer workflows, or “journeys.” First, map the most common and critical tasks. This might include scaffolding a new service, running tests in a CI environment, deploying a change to staging, or accessing production logs. These are the flows that should be simplified first.

Then measure what really matters. Track adoption rates of platform components, but also keep an eye on developer satisfaction. Simple surveys or regular office hours provide direct feedback on what is working. If adoption is low, find out why developers are choosing other tools. The goal is for developers to be able to do their own work without opening a ticket. For that, you need clear documentation, well-defined standards, and interfaces such as API, CLI, or UI that allow them to create resources and access metrics without depending on another team.

The platform as a support layer

A good platform does not solve every problem. It solves common, undifferentiated problems so development teams do not have to. It should feel less like a restrictive system and more like a set of prepared paths.

That means standardizing things like Kubernetes clusters, IAM roles, or VPC networks. The platform provides clear boundaries and well-chosen defaults, giving developers a safe and efficient starting point. It offers a standard set of tools for CI/CD, observability, and secrets management, so teams do not have to research and configure everything from scratch.

But it also provides escape hatches for teams with specific needs.

Iterative development and continuous feedback

All-at-once platform launches almost always go wrong. They arrive late, over budget, and when they finally ship, the problems they were meant to solve have already changed.

A better approach is to launch MVPs. Deliver the smallest possible improvement that creates value for a small group of developers.

Create clear communication channels, such as a dedicated Slack channel or user forums, to collect immediate feedback. This feedback loop should drive priorities. The platform roadmap should come directly from the needs of your internal customers, not from a big predefined vision.

Breaking down common anti-patterns

Recognizing and actively dismantling bad habits is just as important as adopting good practices.

The idea that “if you build it, the team will use it”

A platform engineering team cannot simply launch a new tool and expect it to be adopted. This kind of thinking comes from a lack of internal communication and onboarding. Often, after the initial launch, user feedback is ignored while the platform team moves on to the next feature without checking whether the first one was actually useful. Adoption requires ongoing effort, clear documentation, and a simple explanation of the value for development teams.

Monolithic platforms and dependencies

Building the entire platform as a single system creates a huge single point of failure and limits your technological choices. If the whole deploy system is tightly coupled to a specific CI vendor, switching becomes almost impossible.

A better design uses loosely coupled components with well-defined APIs. This allows individual parts of the platform to be updated or replaced without disrupting everything else, which reduces the cost of swapping any isolated component.

The Platform Engineering team as a support desk

When a platform lacks self-service capabilities or has unclear boundaries, the platform team becomes a support queue. They spend the day handling operational tasks such as provisioning access, debugging application-specific deploy issues, or manually configuring resources.

This work consumes all their time, preventing improvements to the platform itself. It is a vicious cycle: a difficult platform generates more support requests, which leaves less time to make it easier to use.

A way to guide platform team decisions

To stay on track, a platform team needs a simple way to guide its choices.

Assess developer needs, not just technical specifications

Start with user research. Talk to developers. Map their current workflows, from local machine to production.

The goal is not to ask which features they want, but to observe what slows them down.

Prioritize work based on a combination of impact (how much time an improvement would save) and frequency (how many developers face this problem).

Define clear boundaries and responsibilities

Be explicit about what the platform provides and what development teams are expected to own. This contract prevents confusion and finger-pointing.

Platform responsibility: The platform engineering team may be responsible for the Kubernetes control plane, CI runner infrastructure, and base container images.

Development team responsibility: The development team is responsible for application code, its dependencies, pipeline configuration, and production monitoring.

Define clear service level objectives for platform components. If the platform provides a shared database, what are its availability and latency guarantees?

Finally, create clear ways for teams to contribute to or extend the platform. An inner source model can be a powerful way to scale platform development and ensure it meets diverse needs.

Measure value through adoption, efficiency, and satisfaction

A platform’s success comes from its impact, not its technical complexity.

Adoption: Track usage metrics of platform components. How many services are using the standardized CI pipeline? How many teams have migrated to the new logging system?

Efficiency: Quantify time saved. This can be measured through metrics such as “commit-to-production time” or by calculating the reduction in time spent on manual operational tasks.

Satisfaction: Run regular surveys with your users. A simple Net Promoter Score (NPS) or a more detailed survey can provide useful qualitative data about where the platform is succeeding or failing.

A successful internal platform is not the one with the most features. It is the one developers voluntarily choose to use because it makes their work simpler and faster.