DEV Community: Edvaldo Freitas

.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.

Open-source, model-agnostic alternative to Claude Code Review

Edvaldo Freitas — Tue, 10 Mar 2026 14:33:56 +0000

Claude just launched code review and the announced price is $15–$25 per pull request. 🤯

I got curious and decided to run a simple calculation.

There are teams processing ~1,000 PRs per week.

Nothing unusual for larger companies.

If each review costs $25, that’s something close to $100k per month just for code review. 🫠

Just to review PRs.

Code review is a continuous activity. The more a team grows and the more code gets produced, the higher the volume of PRs.

If the cost scales with the number of PRs, the financial impact can get pretty large pretty quickly.

You can use Kodus, which is open source, run any model you want, and pay less than 1/10 of that.

If you want to try it, you can get started right away.

No credit card, no PR limits, no user limits, and no need to configure an API key.

🔗 https://kodus.io

Repo: https://github.com/kodustech/kodus-ai

I gathered more than 10,000 skills for AI agents in one place

Edvaldo Freitas — Wed, 28 Jan 2026 13:30:43 +0000

Over the past few months, I’ve been spending a lot of time studying how AI agents are actually being built in practice.

One thing became very clear: there’s a huge number of skills scattered all over the place, but everything is fragmented, hard to search, and even harder to reuse.

So I decided to run an experiment:

👉 a site with more than 10,000 agent skills, organized, searchable, and with direct links to each implementation.

You can check it out here: https://ai-skills.io/

I’m still refining a few things and adding more skills, so I’d really love your feedback :)

Dealing with legacy code in modern applications

Edvaldo Freitas — Fri, 16 Jan 2026 12:01:00 +0000

A new feature request lands, and you realize it has to touch the old permissions module. The project planning meeting suddenly gets very quiet because everyone knows any change in that part of the legacy code means weeks of careful testing, unpredictable behavior, and a high-stakes deployment.

This is the friction point where building new things slows to a crawl, constrained by decisions made years ago by people who are no longer on the team.

Beyond the "Rewrite or Refactor" Dichotomy

In these moments, someone will almost always suggest a full rewrite. It’s an appealing idea, a clean slate where all past mistakes are erased. The reality is that a full rewrite is rarely a practical solution. It freezes the delivery of new business value for months or even years, introduces a massive amount of risk, and discards years of battle-tested logic that, for all its faults, currently runs the business. The code might be hard to read, but it contains valuable, implicit knowledge about edge cases you haven't even thought of yet.

The alternative, incremental refactoring, works much better when treated as a continuous process instead of a standalone project. The goal is to evolve the system, not to achieve a perfect, idealized state. The most valuable code is often the oldest, and learning to work with it is a core engineering skill.

When legacy code becomes a real bottleneck

The term "technical debt" can be a bit abstract, but a bottleneck is painfully concrete. It’s the module that slows down every new feature. It's the source of recurring performance incidents or the component with a known security vulnerability that’s too entangled to patch easily. You know you've found a bottleneck when multiple teams have to coordinate for even minor changes, or when the operational overhead of keeping a service running outweighs the value it delivers.

These are the areas that actively impede progress. Identifying them is the first step, because you can't fix everything at once, and trying to do so just leads to paralysis.

An Approach for Evolving Systems

The most effective approach is to stop thinking about "fixing everything" and instead focus on "strategically evolving" the system. Your job is to create pathways for new development while safely containing the old. Architectural patterns like the Strangler Fig are built on this idea: you gradually intercept traffic to an old system, route it to new services, and eventually, the old system is "strangled" out of existence without a high-risk cutover.

This requires prioritizing changes based on a combination of business impact and technical risk. A part of the codebase might be messy, but if it’s stable and rarely changes, it's probably not where you should spend your time. Focus on the parts of the system that are both critical and under constant pressure to change.

Techniques for Managing the Boundaries

To evolve a system safely, you need to manage the boundaries between the old and new parts of your codebase. Here are a few practical techniques that work well:

Identify Seams and Interfaces: First, you have to find the natural joints in the system. These are the points where you can intercept calls between components without rewriting either one. A seam could be an API call, a method invocation, or a message being passed to a queue. Once you find them, you can start to redirect behavior.
Isolate Functionality: When you have a particularly problematic area, the goal is to contain it. You can write an adapter or an anti-corruption layer that sits between the old code and the rest of the application. This new layer translates requests and responses, hiding the complexity of the legacy component and providing a clean, modern interface for new code to interact with.
Write Characterization Tests: You can't safely change code if you don't know what it does. Before you touch anything, write a suite of tests that document the current behavior, including its bugs. These "characterization tests" don't judge the code; they just capture its existing state. When you make a change, you can run these tests to ensure you haven't broken an implicit assumption somewhere else in the system.
Implement Observability: You need to see what the old components are doing in production. Adding detailed logging, metrics, and distributed tracing gives you the insight needed to understand runtime behavior. Without this, you're flying blind every time you deploy a change that touches the older code.

The Incremental Evolution Framework: Decide, Delimit, Develop

1. Decide: Where is the real pain?

Your resources are finite, so prioritization is everything. The place to start is at the intersection of business value and frequency of change. Which part of the system is most often a blocker for important projects? Evaluate the impact of modernizing a component versus the effort required. Often, the highest-leverage targets are areas with high coupling or poor testability, because improving them unlocks velocity for multiple teams.

2. Delimit: How can we contain the change?

Once you've decided where to focus, the next step is to draw a boundary around the problem area. This is where architectural decisions come in. You might create a new microservice to house the new logic, using an API gateway or a message queue to bridge the gap between the old and new systems. The key is to create a clear interface that abstracts away the legacy implementation. The rest of the application shouldn't need to know whether it's talking to a 10-year-old monolith or a brand-new service.

3. Develop: Execute with small, well-tested iterations

With a clear boundary in place, you can start developing. New features that interact with the legacy code should be built using test-driven development to ensure the new logic and the integrations are correct. Small, incremental changes deployed via an automated pipeline give you the confidence to move quickly. Each pull request should be a small, verifiable step forward. Code reviews for this kind of work should be especially focused on the clarity and durability of the new interfaces you're creating.

Cultivating a Sustainable Relationship with Your Codebase

Working with legacy systems isn't a one-off project with a defined end. It's a continuous process of improvement. The most effective teams build a culture that values this incremental work, not just reactive fixes when something breaks. This means investing in developer tools and practices that support safe, small changes and make refactoring a low-ceremony activity.

Ultimately, "modern" is a moving target. The shiny new service you build today will be somebody else's legacy code in five years. The real skill is learning to manage complexity as an ongoing practice, ensuring the codebase you have is one that allows you to keep building, testing, and delivering value.

How to structure technical planning for engineering

Edvaldo Freitas — Fri, 16 Jan 2026 10:57:00 +0000

In a fast-growing company, the default state of engineering is reactive. The product roadmap is packed, deadlines are tight, and the team is constantly switching context to put out the fire of the moment. This environment makes any kind of intentional technical planning feel like a luxury you can’t afford, so most teams don’t even try. You end up stuck shipping features, fixing bugs, and hoping core systems don’t fall apart, while technical debt quietly piles up in the background.

This “just build” approach looks productive in the short term, but it comes with a real and cumulative cost. Before long, you notice engineers on different teams solving the same scaling problem in different ways. A simple feature request now requires changes across five services, each with its own quirks. The speed you were so proud of six months ago starts to drop, and no one can point to a single clear reason why. This is the slow accumulation of uncoordinated decisions.

Technical planning for unstable environments

Breaking out of this reactive cycle requires a shift in how we think about planning. Most frameworks are too rigid for a company where priorities can change in a week. A detailed two-year technical roadmap is useless if it becomes obsolete a month after it’s written.

The goal is adaptability, not prediction. It’s about creating shared understanding around technical direction so that, when engineers make local decisions, they align with a broader direction. That forward-looking view is what allows a team to handle change without breaking everything. It turns planning from a bureaucratic obstacle into an accelerator, because you stop wasting time on duplicated work and architectural dead ends. Understanding the real cost of uncontrolled growth is the first step; it shows up as longer onboarding times, higher bug rates in critical modules, and a general sense of friction when trying to build anything new.

A practical and adaptable model for technical planning

A good technical plan doesn’t live in a dense document no one reads. It’s a living guide that connects engineering work directly to what the business is trying to achieve. It needs to be flexible enough to change quickly, but structured enough to provide real direction.

Define your North Star ⭐️

Every meaningful technical initiative should be traceable back to a business goal. This isn’t about pleasing stakeholders; it’s about making sure you’re solving the right problems. When the company decides to move upmarket and serve enterprise customers, that translates into very specific technical requirements, like more robust permissions, audit logs, and integrations with common identity providers.

Framing the work this way pulls the conversation out of the abstract and into concrete outcomes. Discussions that used to sound like “we need to refactor the authentication service” become directly tied to clear business goals, like closing enterprise customers in Q3, which requires supporting SAML and role-based access control. The reason behind the work becomes clear, and the engineering team understands why it matters, not just what needs to be done.

Building the “What”: Scope and Outcomes

With a clear “why,” prioritization becomes much simpler. You can evaluate technical work side by side with product features based on impact to company goals. A large refactor might not deliver immediate, visible value to users, but if it unlocks the ability to iterate 50% faster in a core part of the product over the next year, the value is obvious.

This is also where you make conscious trade-offs. You might decide to accept some technical debt in a non-critical area to free up resources and fix a serious scalability bottleneck that’s threatening user growth. The key point is to make these decisions explicitly, instead of letting them happen by accident. When defining scope, the goal is to design for what you know is coming, not every possible future. Build with extensibility where you anticipate change, but avoid overengineering based purely on speculation.

The “How”: Planning and Execution

Execution needs to happen within the workflow the team already has. When parallel processes or extra ceremonies appear, they tend to be ignored as soon as pressure ramps up.

Here are a few practices that work well:

Architectural Decision Records (ADRs). A simple markdown file in the right repository is enough. This is where decisions are recorded, along with the alternatives considered and the reasoning behind the final choice. That context ends up being valuable both for new team members and for your future self.
Involve senior engineers early in the design phase. Don’t wait for a 5,000-line pull request to show up. Have conversations about the “how” before implementation starts. That might be a short design doc, a whiteboard discussion, or even a dedicated chat channel. This helps spread knowledge and catch architectural issues while they’re still cheap to fix.
Create regular review and adaptation cycles. A technical plan isn’t static. Review it quarterly. What changed in the business? What did we learn from the last quarter’s work? Adjust priorities based on new information. This helps keep the plan relevant and useful.

Turning Technical Planning into an Advantage

Introducing this process doesn’t require a company-wide initiative. You can start small, with a single team or a critical system. Pick an area of the codebase that’s a known source of pain and build a clear plan to improve it, directly connecting the effort to a product or business outcome.

At the end of the day, it’s about fostering an engineering culture where everyone feels responsible for the health of the system. When engineers understand the “why” behind the work and see a clear path to improving the codebase, they’re more engaged. You can measure the impact directly through improved development velocity, system stability, and, most importantly, the ability to respond to new business opportunities without having to rebuild everything from scratch.

How Small Pull Requests Improve Team Flow

Edvaldo Freitas — Thu, 15 Jan 2026 14:05:08 +0000

A 2,000-line Pull Request lands in your review queue on a Thursday afternoon, touching a dozen files spread across three different parts of the application. Everyone knows what happens next. You either give it an LGTM while hoping for the best, or you block two hours of your day, completely breaking your own flow, just to understand the changes.

This is not an exception, it is usually routine for the team. Large PRs slow the team down, increase the risk of errors slipping through, and make the delivery cycle less predictable. The problem is not just the code inside the PR, it is the time it ties up people, decisions, and deploys throughout the entire process.

The weight of large changes

Large pull requests create bottlenecks that spill outward. The most immediate impact falls on the reviewer, who now faces massive context switching. A change of this size requires not only reading the code, but reconstructing the entire mental model of the person who wrote it. This cognitive load makes it tempting to postpone the review, leaving the PR sitting idle for days while the author’s own context starts to fade. When the review finally happens, the feedback is usually less detailed, because the reviewer is just trying to understand the architecture at a high level instead of identifying logic flaws.

This delay creates cascading effects. While the large PR waits for review, the main branch keeps moving forward, making merge conflicts almost inevitable. The longer a branch stays open, the more it diverges and the harder final integration becomes. Dependent work gets blocked, and if a fundamental design issue is found during this late review, the rework cost is huge. A problem discovered days after the code was written is much more expensive to fix than one caught in minutes. The entire process slows down, and the team’s predictability suffers.

Why small PRs make a difference in the team’s process

Moving to smaller, more frequent pull requests tackles these bottlenecks directly. When a review is limited to something around a hundred lines, it can be done in minutes, often between other tasks, without a major context switch. The cognitive load is low, which encourages reviewers to engage quickly and provide more focused and constructive feedback. The author gets this feedback while the code is still fresh in their mind, allowing for fast iterations. This creates a short cycle of coding, review, and integration that keeps work flowing continuously.

The benefits compound over time. Small, incremental changes are easier to validate and, if needed, to roll back. The blast radius of any potential issue stays contained within a small, understandable unit of work. Instead of a monolithic, high-risk merge once a week, you end up with a steady flow of low-risk changes reaching production every day. This continuous progress is great for team morale and makes it easier to course-correct if a feature is heading in the wrong direction. The team moves from a batch-processing model to a real-time flow.

Main reasons to do small PRs

1. Faster and more accurate reviews

When the scope of a Pull Request is small, the reviewer can focus on the details that really matter. This not only speeds up the review but also increases the quality of the feedback. Issues are detected earlier and with greater clarity.

2. Faster feedback

Smaller PRs make life easier for everyone. Reviewers can respond more quickly, and those waiting for feedback can move forward with less idle time. This speed is essential to keeping productivity high.

3. Reduced conflicts

Each small PR is processed quickly, which reduces the chances of conflicts with other code changes. That means less rework and more focus on what really matters: creating value for the product.

4. Clearer intent

When you limit the scope of a PR, it becomes much easier for everyone to understand what is being solved. This not only improves communication within the team, but also makes the project history more organized and traceable.

5. Higher deploy frequency

With small Pull Requests, it becomes possible to do smaller, more frequent deploys. That means features and fixes reach users faster, while the risk of something breaking in production goes down.

Read also: How to improve PR quality

Building a culture of small Pull Requests

Breaking work into smaller parts

It is not enough to tell people “make smaller PRs”. You need to offer techniques for slicing work into independent, mergeable pieces.

Implement feature toggles for incomplete functionality. This is the most powerful tool for decoupling deploy from release. It allows incremental merging of the code for a larger feature, even when it is not yet ready for users. Each part can be reviewed and tested in isolation behind a flag.
Prioritize refactoring as a distinct, isolated change. Avoid mixing refactoring with feature delivery in the same PR. When a change only touches structure, it is much easier to review. When it mixes code reorganization with new behavior, the review becomes confusing and risky. Clean up first, merge it, and only then build the feature on top of a clearer base.
Slice user stories vertically into minimal viable increments. Instead of building an entire feature horizontally (backend, then frontend, then API), find the smallest possible vertical slice that delivers a bit of value to the user. Maybe the first PR only adds the API endpoint with a hardcoded response. The next adds the database schema. The following one connects the two. Each step is a small, verifiable improvement.

Team agreements and practices for Pull Requests

Consistency comes from shared expectations. The team needs to have explicit conversations about what a “good” PR looks like.

Set guidelines for acceptable size and complexity. Some teams use lines of code as a rough proxy (for example, under 250 lines), while others look at the number of files touched or the conceptual weight of the change. The exact number matters less than having a shared understanding.
Define clear expectations for review turnaround times. Agree on a target response time for reviews, such as a few business hours. This prevents PRs from being forgotten in the queue and signals that reviewing is a priority responsibility for everyone on the team.
Use tools to identify and flag exceptionally large Pull Requests. Many CI/CD platforms and Git tools can be configured to automatically mark PRs that exceed a certain size threshold. This works as a gentle, automatic reminder of team agreements, without making the conversation confrontational.

Measuring the impact on delivery flow

To know whether the change is working, you need to measure. Adding flow metrics can provide clear evidence of improvement and help justify the investment in this practice.

Track Lead Time for Changes. This metric measures the time between the first commit on a branch and the code running in production. Smaller PRs tend to reduce this number directly by shortening review and integration stages.

Monitor Code Review Cycle Time. How long does a PR sit waiting for review or iteration? This metric helps surface process bottlenecks and should drop as PRs get smaller and more focused.

Watch for a reduction in merge conflict frequency and defect rates. With shorter branches and smaller changes, conflicts tend to decrease. The faster feedback cycle also helps catch bugs earlier, reducing the rate of defects that get reintroduced or make it to production.

At the end of the day

Creating smaller PRs is about building a more efficient and sustainable workflow. It is not something that happens overnight, but over time these practices become part of the team’s culture and make all the difference.

Code Standards and Best Practices for Growing Teams

Edvaldo Freitas — Thu, 15 Jan 2026 10:55:00 +0000

When an engineering team is small, informal agreements tend to work just fine. There’s a shared understanding of how things should be built, because any disagreement can be quickly resolved in a Slack thread or a conversation. But as the team grows from five to fifty developers, these unwritten rules start to cause problems. Suddenly, you find yourself in pull request comments debating brace placement, naming conventions, and which async pattern to use, for the third time in the same week. That’s when the need for explicit code standards becomes painfully obvious.

The friction isn’t limited to PRs. It also shows up in the cost of context switching, when each microservice has its own rules for errors and configuration, for example. A developer from the checkout team trying to fix a bug in the inventory service first has to spend an hour just understanding the local conventions, before even starting to debug. This fragmentation slows down collaboration and makes the entire system harder to understand. If teams can’t even agree on something basic, like a branching strategy or commit message format, you lose the ability to automate release notes or reliably track changes across services.

Code standards as a foundation for shared context

The most common reaction to this chaos is to impose a top-down set of rules. An architecture group might write a very comprehensive document dictating everything from file structure to design patterns. This approach almost always creates more problems. It feels bureaucratic, and developers, who are paid to solve problems, will naturally work around any rule that gets in the way without delivering clear value. The goal isn’t to impose dogma, but to build a shared understanding that reduces cognitive load.

Code standards exist to get trivial decisions out of the way, allowing the team to focus its energy on the real business problem. When they work well, they provide default answers to common questions and clear the path for what actually matters. This is the balance between moving fast now and building a system that remains sustainable for years. The decision to skip writing tests might speed up the release of a feature by a day, but the long-term cost of that missing context and safety net will be paid with interest during the next production incident or refactor.

The real purpose is to reduce cognitive load

Think about the decisions an engineer makes every day. Many of them are repetitive: how should I format this file? What should I name this component? How should I structure API error responses? Good standards provide a single answer, automated or well documented, to these questions. For example, an agreed-upon JSON structure for logs, like {"level": "error", "timestamp": "...", "service": "auth-api", "message": "..."}, means everyone can query and filter logs across the platform using the same tools and techniques, without having to learn the logging quirks of each service.

How to keep code standards adaptable over time

Good code standards are the ones that can evolve over time. They need to be grounded in principles, not rigid rules, and make sense to the people writing code every day. The focus is on making collaboration easier and maintaining quality, without getting in the way of flow.

Defining core principles, not rigid rules

Instead of a hundred-page document, start with a small set of principles that are easy to remember and apply. Some good examples:

Focus on clarity and intent. Code should be written to be understood by everyone first. A variable name like customerData is too vague, but activePayingCustomers clearly communicates intent. This isn’t something a linter can always catch, which makes it a great topic for discussion during code review.
Promote consistency where it matters most. Be opinionated about what truly affects collaboration across teams, such as API design, security standards, and the use of core libraries. The style of a private function inside a single module matters much less.
Automate some processes to sustain standards over time like code review . People’s time is too valuable to be spent debating formatting or standards everyone should already be following. Automating this makes life easier for everyone, especially when new people are joining the team.

The “balance zone”

There’s always a point of balance. Every new standard adds a bit of friction, so it’s worth asking whether it really improves day-to-day clarity and consistency.

Too little: Leads to a chaotic codebase, where every file feels like it was written by a different team. This is where technical debt piles up through duplicated logic and inconsistent patterns.
Too much: Creates an overly rigid environment that stifles the team and innovation. If engineers have to fight the tools or fill out a form just to try a new library, they’ll stop experimenting. Standards become a source of frustration for the people building.
Just right:Defines a default path for most cases, while still leaving room for exceptions when they make sense. Consistency where it matters helps collaboration, and flexibility everywhere else gives the team space to innovate.

Some strategies you can try

Putting standards into practice requires more than just writing them down. You need to integrate them into the daily workflow and create a mechanism for them to evolve.

Define a default path for common tasks. Build tools that make doing the right thing the easiest path. A CLI command like platform-cli create-service, which scaffolds a new project with the correct CI/CD pipelines, logging libraries, and lint configs already set up, is far more effective than a wiki page.
Make standards a team responsibility. Create a space to discuss and update standards, such as an engineering guild or a dedicated Slack channel. Changes to standards should be proposed and discussed via pull requests in a shared repository, just like any other code change. This increases team buy-in and helps keep standards up to date.
Implement a feedback loop for refinement. Standards aren’t immutable. The team should regularly ask itself, “Is this rule still helping us, or is it getting in the way?”. If a specific lint rule is constantly being ignored, it might be a sign that the problem is with the rule, not the code.

Integrating best practices into the workflow

In the end, the best standards become part of the team’s daily routine. They’re simply part of how things are done, without adding another checklist.

Code reviews become learning opportunities, where a senior engineer can point to documentation that explains the rationale behind a particular standard. Documenting the why behind a decision in an ADR gives future engineers the context they need to make better decisions. This creates a virtuous cycle in which standards help simplify onboarding for new team members, who in turn learn the conventions and help maintain them, making the entire engineering organization more cohesive and effective as it grows.

The challenge of managing multiple projects as a Tech Lead

Edvaldo Freitas — Wed, 14 Jan 2026 13:52:36 +0000

Your scope as a Tech Lead almost never stays confined to a single, clean workstream. As a product grows, you end up responsible for a new feature initiative, a critical infrastructure migration, and a lingering performance issue, all at the same time. This isn't a promotion; it's an expansion of responsibility that quietly creeps in until you find yourself spread across three different stand-ups, answering questions about domains you haven't had time to think deeply about in weeks.

The immediate result is a huge spike in cognitive load. You’re holding multiple complex system diagrams in your head, trying to recall the specifics of a data model for one project while a stakeholder from another is pinging you about their timeline. The pressure to keep all the plates spinning forces a reactive mode of operation, where multitasking feels like the only option, even though we all know the heavy penalty of constant context switching.

The Systemic Challenges of Capacity and Focus

When everything feels slow despite everyone being busy, it’s tempting to look for individual productivity hacks or better time management techniques. But the root cause is usually systemic. The problem isn't how you manage your calendar; it's that the system is overloaded, and the assumptions about team capacity are fundamentally broken.

Resource Allocation

Most planning starts with an optimistic view of team bandwidth. We map out projects as if they will be worked on in isolation, with developers dedicating 100% of their focus. In reality, that focus is fragmented. A developer assigned to Project A still gets pulled into on-call rotations, bug fixes from their previous work on Project B, and code reviews for Project C. The actual available bandwidth is much lower than what the roadmap assumes, and this mismatch creates a cycle of missed deadlines and rushed work. Output doesn't just degrade linearly under these conditions; it falls off a cliff once the team hits a certain threshold of cognitive overload and fragmentation.

The Productivity Drain of Constant Context Switching

Every time an engineer has to switch from thinking about a Kubernetes operator configuration to a complex SQL query for a different project, there's a significant mental cost. The context from the first task gets flushed, and it takes time to load the new one. When a team is responsible for multiple unrelated projects, these switches happen all day long. Interruptions from different Slack channels, competing stakeholder requests, and unexpected bugs from various domains create a constant churn that destroys any chance for deep work. As a leader, one of your most important jobs becomes creating an environment that actively protects focused time, which is nearly impossible when the team's mandate is too broad.

Dealing with competing priorities

Without a clear framework for prioritization, the "annoying" stakeholder often wins. This leads to a reactive cycle where the team bounces between strategic initiatives, urgent customer requests, and critical maintenance. The most difficult part is advocating for the invisible work, like paying down technical debt or refactoring a brittle module. These tasks have no external stakeholder championing them, but neglecting them guarantees that all future projects will be slower and more painful. Your role shifts from technical guidance to making a business case for technical health, connecting a refactor today with the ability to deliver a key feature next quarter.

The Compounding Effects on Quality and Team Health

A perpetually overloaded system doesn't just move slower; it starts to break down in predictable ways. The small compromises made to keep things moving accumulate, affecting the codebase, the architecture, and the team itself.

Cross-Project Dependencies and Unforeseen Bottlenecks

When you're managing separate projects, it’s easy to miss the subtle ways they connect. A delay in one team's API development can completely block another team's frontend work. These dependencies are often unmapped, living only in people's heads until something goes wrong. A single person who is the sole expert on a legacy service becomes a bottleneck for three different initiatives. The only way to manage this is to stop viewing projects as independent silos and start mapping them as an interconnected system, proactively identifying and tracking the dependencies between them.

The weight of accumulating technical debt

In a multi-project environment, "cutting corners" becomes a rational survival strategy. When faced with a tight deadline for one project and an urgent request from another, it’s almost always easier to write the quick hack than to do the "right" thing. Each of these small decisions adds up, and the accumulated technical debt acts as a drag on all future development. Simple changes start requiring complex workarounds, and the team's velocity slows down.

Preserving Team Morale and Preventing Burnout

The human cost of chronic overload is severe. Engineers become demoralized when they can't take pride in their work because they're always rushing. Unclear priorities and constantly shifting goals create a sense of chaos, leading to frustration and burnout. Adding more pressure never accelerates delivery in these situations; it only accelerates attrition. As a leader, your most critical responsibility is to model sustainable work practices and be the person who protects the team from unrealistic expectations. This often means saying no, which is one of the hardest but most necessary parts of the job.

Some frameworks Tech Leads can use to manage multiple projects

Getting out of this reactive trap requires moving from simply managing projects to actively shaping the environment. This involves establishing a few frameworks that bring clarity, distribute responsibility, and create more sustainable workflows in both the short and long term.

Shifting from Project Management to Portfolio Optimization

Instead of treating projects as a checklist to be completed, view them as a portfolio of investments. This means thinking about how they relate to each other.

Cross-project prioritization: Is it possible to organize projects so that the learnings or capabilities built in the first one directly benefit the second? For example, building a new authentication library for one project that can then be used by two others.
Resource Constraints: Identify cross-project constraints early. If you only have one database expert and three projects need database work, that needs to be factored into the timeline for all three. Don't pretend you can do them in parallel.
Holistic View: Use tools like a multi-project Kanban board to visualize all work in one place. This makes the competing demands visible to everyone, including stakeholders, and forces a more realistic conversation about what's possible.

Who decides what (and why)

A Tech Lead who is the bottleneck for every decision is a system failure. The goal is to push decision-making down to the people with the most context. Define who owns what. For example, a sub-team might own the architectural decisions for their set of microservices, while a chapter lead owns the standards for frontend development. This moves the team from endless debate to clear accountability. Empowering team members with defined boundaries of ownership not only speeds things up but also develops their skills and sense of responsibility.

Distributing decisions and responsibility

Delegation isn't just about offloading tasks; it's a core strategy for managing workload and growing your team. When you delegate a piece of a project, you're also delegating the responsibility and authority that comes with it. This means providing clear expectations and the necessary support, but then trusting your team to execute without micromanagement. Doing this effectively frees you up to focus on the higher-level concerns that only you can handle, like cross-team alignment, architectural strategy, and stakeholder negotiations.

Building a culture of communication

When multiple workstreams are in flight, communication needs to be solid to avoid turning into chaos. That’s why you need to design clear protocols to manage the flow of information.

Consistent rhythms: Create regular, lightweight mechanisms, like a shared weekly update document or a short demo. This keeps everyone aligned without adding a meeting overload.
Shared Sources of Truth: Use dashboards or shared project boards that pull information directly from your ticketing system. This provides real-time visibility and prevents stakeholders from having to ask you for status updates constantly.
Minimize Interruptions: Establish clear channels for communication. For example, use a specific Slack channel for urgent operational issues and direct all feature requests and planning questions to your ticketing system. This helps protect the team's focus.

These frameworks are a good starting point because they force conversations that usually stay implicit: what’s at stake, what depends on what, who decides what, and what actually fits into the same quarter. That takes weight off your shoulders and reduces the need to be involved in everything.

Refactor or Rewrite? Dealing With Code That’s Grown Too Large

Edvaldo Freitas — Sat, 10 Jan 2026 09:11:00 +0000

The decision to refactor or rewrite a large codebase usually starts with a feeling of friction. Small changes that should take a day suddenly take a week. Every new feature seems to break an old one, and the team’s bug backlog grows faster than it shrinks.

This happens because systems don’t just age, they accumulate history. Every feature request, urgent fix, and change in direction adds another layer of code. Over time, what was once a clean architecture turns into a web of dependencies and workarounds. The pressure to ship new features means there’s rarely time to go back and clean things up, so technical debt piles up. When you reach this point, the system starts actively resisting change, and every pull request becomes a painful negotiation with the past.

Signs the system is at its limit

It’s easy to complain about a codebase, but there are clear signs that a system is close to breaking. The most obvious one is a steady drop in development speed. You can measure this with cycle time or, more simply, by comparing how long it takes to ship a basic feature today versus a year ago.

Another clear sign is an increase in regressions in specific parts of the system. When fixing one bug almost always creates another, it usually points to an architecture that’s too tightly coupled, where small changes have side effects that are hard to predict.

There are also human costs. When engineers spend more time fighting the system’s limitations than building with it, motivation drops fast. Onboarding new people becomes hard because the cognitive load required to understand the system is huge. And when your most experienced engineers start asking to work on anything else, or you struggle to hire because no one wants to touch the “legacy” stack, that’s usually a sign the system has reached a critical point.

Accidental complexity vs. essential complexity

Before making a good decision, you need to understand what kind of complexity you’re actually dealing with. Software complexity usually falls into two groups: essential and accidental.

Essential complexity is inherent to the business problem you’re solving. If you’re building a payment processing system, you have to deal with regulations, fraud detection, and multiple payment gateways. No matter how clean the code is, that complexity doesn’t go away. The best you can do is keep it under control.

Accidental complexity, on the other hand, comes from the choices we’ve made along the way. It’s the result of outdated libraries, poorly designed abstractions, inconsistent patterns, or quick fixes that were never revisited. This is the complexity that makes code hard to read, test, and change, even when the business logic itself is simple.

Why this distinction is everything

This distinction is the most important factor in the refactor versus rewrite debate.

Refactoring is an excellent tool for attacking accidental complexity. It helps improve abstractions, simplify parts of the system that no longer make sense, and make the codebase more consistent, which makes day-to-day work easier. If your problem is mostly accidental complexity, a series of targeted refactorings is almost always the right answer.

A full rewrite, however, is often proposed as a solution to all complexity. The problem is that a rewrite doesn’t remove essential complexity.

If the team doesn’t deeply understand the business domain and its inherent challenges, they’ll simply recreate the same essential complexity in a new language or framework, only now without years of bug fixes and edge-case handling baked in.

That’s why so many rewrites fail. They confuse essential complexity with accidental problems and end up producing a new system with the same issues as before, plus several new ones.

What are the costs of refactoring or rewriting?

Both refactoring and rewriting come with costs that go far beyond engineering hours, and they’re often underestimated.

The price of refactoring

The most significant cost of refactoring is opportunity cost. Every hour your team spends on internal improvements is an hour not spent on customer-facing features. This can be a hard sell to product and business leaders who don’t see immediate value. On top of that, a large refactoring effort sometimes fails to deliver the promised benefits if it doesn’t address the real architectural problems.

You can spend months cleaning up modules only to realize that the real issue is how the database is structured or how services communicate.

The problem with a full rewrite

A full rewrite is one of the riskiest projects a software team can take on. Timelines are almost always wildly optimistic. While the new system is being built, the old one still needs to be maintained, which means running two systems in parallel and splitting the team’s focus. All the unwritten rules and implicit knowledge about why the old system works the way it does get lost, leading to a new wave of bugs and regressions.

This often leads to what’s known as the “second system effect.” Free from the constraints of the old system, architects try to build a perfect, overengineered solution that solves every problem they can think of. Scope grows out of control, the project drags on for years, and by the time it’s finally ready, the business needs have changed again.

When should you refactor or rewrite?

Instead of relying on gut instinct, you need a structured way to evaluate your options. The decision should be based on a clear analysis of the trade-offs.

Criteria to evaluate your options

Here are a few key areas to assess with the team:

Technical viability

Being realistic, can the current system be maintained for the next two or three years? Or are there architectural decisions, like a monolith that blocks teams, that refactoring won’t fix?

Risk to business continuity

What can go wrong with each option? Refactoring too aggressively can create production instability. Rewriting everything introduces a different kind of risk, with many unknowns and a long, delicate migration.

Team capacity and knowledge

Does the team have the skills to execute a rewrite in a new technology? Just as important: is there enough knowledge about the quirks of the old system to avoid repeating past mistakes?

Total cost of ownership

Look beyond the initial project cost. Consider long-term maintenance costs, the cost of running systems in parallel during a rewrite, and the impact on hiring and retention.

A simple heuristic

If you need a simpler way to look at the decision, compare the estimated cost of incrementally refactoring the existing system to a state that meets future requirements with the total cost of starting from scratch.

Be honest and comprehensive in your estimates, including parallel maintenance, migration, and the operational overhead of a new system.

If the cost of a rewrite is even close to the cost of refactoring, the incremental path is almost always the safer and better choice, because it allows you to deliver value more continuously and manage risk along the way.

How to execute

Once the decision is made, everything depends on execution. Both paths can work, as long as there’s discipline, clear ownership, and a direct connection to business goals.

Incremental refactoring with Strangler Fig

If the decision is to stick with the existing system, improvement needs to be continuous, not a large, one-off project. Make room in every sprint to reduce technical debt and improve what’s already in production.

When larger architectural changes come into play, the Strangler Fig pattern often works well. The idea is simple: pick a specific piece of functionality, implement it as a separate service, and start routing traffic to this new component through a proxy or routing layer. Gradually, parts of the old monolith stop being used and can be removed.

Over time, the legacy system gets replaced in a controlled way, without a big-bang migration. This lets you modernize gradually, keep delivering value, and significantly reduce the risk of breaking something critical along the way.

Phased rewrites with a minimum viable scope

If a rewrite is truly unavoidable, the key is to aggressively limit scope. Define a Minimum Viable Rewrite (MVR) that focuses on a small, well-understood vertical slice of the system.

The goal is to get part of the new system into production as quickly as possible, even if it runs alongside the old one. Use feature flags and canary releases to roll the new system out gradually to users, giving yourself time to find and fix issues before a full cutover. This phased approach turns a huge, high-risk project into a series of smaller, manageable steps.

Governance and long-term alignment

No modernization effort will succeed without clear governance. This might mean setting up an Architecture Review Board to guide technical decisions or implementing automated tools to monitor code quality and technical debt.

More importantly, any refactoring or rewrite initiative needs to be tied to clear product and business goals. If you can’t connect the technical work to real improvements, like faster delivery, greater stability, or a better user experience, support tends to fade over time.

Engineering metrics: using data (DORA and others) to improve the team

Edvaldo Freitas — Thu, 08 Jan 2026 11:10:00 +0000

The conversation around engineering metrics often gets stuck on the wrong things. We end up tracking activities like lines of code or number of commits per week, which say almost nothing about the health of our system or the effectiveness of the team. In practice, these metrics are easy to game and create incentives for the wrong behaviors, like splitting a single logical change into ten tiny commits.

This gets even more complicated with AI-based coding assistants. The 2025 DORA report highlights how AI acts as a problem amplifier. Teams using AI are shipping code faster, but they’re also seeing stability get worse. What happens is that AI makes it easy to generate a lot of code quickly, but if your review processes, testing culture, and deployment pipelines are weak, you’re just pushing broken code to production faster than before.

The core problem is still the same: we need a way to measure the health of the system as a whole, not just the speed of individual developers.

DORA: A framework to understand system health

The DORA metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery) offer a way to do that. They focus on system-level outcomes rather than individual output. Looking at these four metrics together gives you a clearer picture of speed and stability, which often complement each other. Improving one without considering the others usually leads to problems.

Deployment Frequency

This metric measures how often you can successfully deploy to production. A higher frequency generally points to a healthier, more automated CI/CD pipeline and a workflow based on small, manageable changes. When deployment frequency is low, it’s usually a sign of large and risky batches, manual deployment steps, or fear of breaking things. For a tech lead, tracking this can help justify investments in better CI or more robust testing.

Lead Time for Changes

This is the time it takes for a commit to reach production. It’s one of the most useful diagnostic metrics for a team. A long lead time can point to several different issues: PRs that are too large, a slow code review process, flaky tests in the CI pipeline, or manual QA gates. By breaking lead time into stages (time to first review, time in review, time to merge, time to deploy), you can pinpoint exactly where work is getting stuck. If PRs sit idle for days waiting for review, that’s a team process conversation, not an individual developer speed issue.

Change Failure Rate

This metric tracks how often a production deployment causes a failure, such as an outage or a rollback. It’s a direct measure of quality and stability. A high failure rate suggests that your testing and review processes aren’t catching issues before they reach users. This often correlates with large batches, since bigger changes are harder to understand and test thoroughly.

Mean Time to Recovery (MTTR)

When a failure happens, how long does it take to restore service? That’s MTTR. A low MTTR is a sign of a resilient system and a solid incident response process. It shows that you can detect problems quickly, diagnose them effectively, and roll back or fix issues without causing new ones.

AI and engineering metrics

AI tools for code don’t change the basic principles of how software is delivered. What they do is amplify what’s already there. AI works as a multiplier of the systems and practices a team already has. If you have strong technical fundamentals, a habit of working in small batches, and a healthy review process, AI tends to accelerate all of that and reduce friction.

The real risk shows up when those practices don’t exist. If your team already tends to create huge pull requests, AI will help generate even bigger PRs, just faster. If there’s already a lot of technical debt, AI-generated code without context can easily make it worse.

That’s why good practices become even more important with AI, especially working in small batches, which becomes even more critical. A small, well-understood change is always safer to ship to production, whether it’s written by a person or with the help of AI.

What needs to be in place before using AI, according to DORA

To get value from AI without amplifying existing problems, teams need a solid foundation. DORA’s research summarizes this into seven essential capabilities for adopting AI the right way:

1. Clear guidance on AI usage

Everyone on the team needs to know the rules of the game: which tools can be used, what kind of data can be shared, and how to handle AI-generated code in day-to-day work.

2. Healthy data ecosystems

The quality of the help AI provides depends directly on the quality of the data behind it. Garbage in, garbage out.

3. Internal data accessible to AI

To be truly useful, AI needs context. That includes internal libraries, APIs, company standards, and relevant documentation.

4. Working in small batches

Working with small changes reduces risk and keeps the feedback loop short. This becomes even more important when code can be generated very quickly.

5. Focus on the end user

AI is a means, not an end. It should help solve real user problems, not just increase the amount of code produced.

6. Well-maintained internal platforms

A good internal platform removes repetitive work and provides clear paths to test and deploy. That makes it much safer to integrate AI-generated code.

7. Strong technical fundamentals

Loosely coupled architecture, comprehensive test automation, and solid engineering standards are not optional.

Other metrics that can help

DORA metrics go a long way toward understanding the health of the delivery pipeline, but on their own they don’t explain everything. Other frameworks complement this view by connecting delivery performance to developer experience and overall value flow.

SPACE

The SPACE framework broadens the view of what actually makes developers productive and satisfied. It argues that you can’t measure output alone. To understand real productivity, you need to look at multiple signals at the same time:

Satisfaction and well-being: How fulfilled and healthy are your engineers? Burnout is a major productivity killer.
Performance: How do individuals and teams perceive their own performance?
Activity: Output metrics like commits or PRs. They’re useful, but dangerous when analyzed in isolation.
Communication and collaboration: How well do people and teams work together? Think about how easy it is to find information and the quality of reviews.
Efficiency and flow: How effectively can developers work without interruptions or friction? This ties directly to DORA’s Lead Time for Changes.

The goal of SPACE is to create a balanced set of metrics so you don’t accidentally optimize one area at the expense of another, like increasing activity at the cost of burnout.

Value Stream Management (VSM)

Value Stream Management is a way to visualize, measure, and improve the entire process, from idea conception to customer delivery.

While DORA gives you key outcomes (like lead time), VSM helps map all the intermediate steps to understand why your lead time is what it is. It focuses on flow metrics such as:

Flow Velocity: How many work items are completed per unit of time?
Flow Time: How long does an item take from start to finish? (Similar to Lead Time)
Flow Load: How many items are currently in progress? (A proxy for WIP)
Flow Efficiency: What percentage of the total flow time is spent on active work versus waiting? This is often the most revealing metric. It’s common to discover that a ticket spends 90% of its time just waiting for a review, a build, or a handoff.

VSM adds context to DORA metrics. Your Change Failure Rate might be high, and a value stream map might show that this happens because there’s no dedicated time for QA, forcing developers to rush tests at the last minute.

Using metrics to improve the team

Collecting metrics doesn’t help much if you don’t act on them. The idea is to use the data to spark good conversations and improve the team, not to create yet another dashboard that no one opens. The DORA improvement loop helps close that gap.

The DORA improvement loop

Establish a baseline: First, simply measure your four core metrics to understand where you are today. You can’t improve what you don’t measure.

Have a conversation: Metrics tell you what is happening, but not why. The next step is to talk with the team. A value stream mapping exercise can be extremely useful to visualize the entire process, from idea to production, and identify where the real friction is.

Commit to improving the biggest constraint: Don’t try to fix everything at once. Identify the biggest bottleneck slowing the team down or causing failures and focus on that.

Turn the commitment into a plan: Create a concrete plan with leading indicators. For example, if the bottleneck is code review time, an indicator might be “average PR size” or “time from PR open to first comment.”

Do the work: This involves systemic changes, not quick fixes. It might mean investing in better tools, changing a team process, or paying down a specific chunk of technical debt.

Check progress and iterate: After a few weeks or a sprint, review your DORA metrics and indicators to see if the changes had the expected effect. Then choose the next biggest constraint and repeat the cycle.

It’s also useful to remember that DORA isn’t the only framework. The SPACE framework is a great complement, as it brings in developer satisfaction, well-being, and collaboration.

The most common mistakes when using engineering metrics

When you start using these metrics, it’s easy to fall into a few common traps.

Using metrics to evaluate individual performance: This is the fastest way to destroy trust and encourage metric gaming. DORA metrics measure team and system performance, period. They should never be used in individual performance reviews.

The “gaming” metrics trap: If you incentivize a specific metric, people will find a way to optimize it, often at the expense of what actually matters. For example, focusing only on Deployment Frequency can lead a team to ship tiny, meaningless changes just to inflate the number.

Metrics overload: Don’t try to measure everything. Start with the four core DORA metrics. Once you have a handle on them, you can add others, but keep the focus on a small set of indicators directly tied to your improvement goals.

Not acting on the data: The worst outcome is spending time and effort collecting data and then doing nothing with it. Metrics should always be a catalyst for conversation and action. If they aren’t, it’s worth asking why you’re collecting them in the first place.

Some recommendations

If the goal is to use data more deliberately to improve the team, here’s a path you can follow:

- Establish baseline DORA metrics: Use a tool or script to get an initial reading of the four core metrics. This gives you a starting point.

- Focus improvement efforts on the team’s biggest constraint: Work with the team to identify the most painful bottleneck right now and make a clear agreement to focus on improving that first.

- Treat AI adoption as a systemic change: It’s not just about handing out Copilot licenses and hoping for the best. Set clear guidelines and reinforce good habits so AI doesn’t simply accelerate existing problems.

- Complement DORA with other frameworks: Consider using elements of SPACE to get a more complete view that includes developer experience.

- Embrace continuous improvement as a cultural practice: The goal isn’t to achieve a “perfect” score on metrics. It’s to build a culture where the team is constantly working to improve its workflow and the health of its systems.