Stacks that work well with AI coding tools

AI coding tools write the best code in stacks with static types, clear conventions, fast tests and a widely used framework. In my experience TypeScript with a mainstream framework, C# with ASP.NET Core and Python with type hints all work well. A homegrown framework without types or tests works worse. That has less to do with the language than with how much feedback the tool gets.

Types give instant feedback

A tool like Claude Code works in a loop: write code, check it and fix what fails. The more errors the check catches, the better the result, and a type checker is the fastest check you have.

Mündler and colleagues studied TypeScript generated by language models in 2025. On average, 94 percent of compilation errors came from the type check. In a language without static types, the same mistakes only show up when the code runs, or when a user finds them.

GitHub links the growth of TypeScript to AI in its Octoverse 2025 report. In August 2025 TypeScript became the language with the most monthly contributors on GitHub for the first time. According to GitHub, developers are moving to typed languages because they make agent-assisted coding more reliable.

If you work in Python or PHP, you get part of this benefit with type hints and a checker such as mypy, pyright or PHPStan in CI.

Types only help if the data at the edges is right. Validate what comes in from APIs and forms against a schema, for example with Zod in TypeScript or Pydantic in Python. The tool can then rely on the types further in.

Conventions help the tool choose

Frameworks with strong conventions, such as Next.js, Laravel, Django or ASP.NET Core, tell the tool where things belong. A route lives in a fixed place, and so does a migration, so the tool does not have to guess.

Consistency inside your own codebase matters even more. If there are three ways to make an API call, the tool picks one, possibly the wrong one. Clean up duplicate patterns, or write down which one is correct.

Run a formatter and a linter automatically as well. The tool then sees straight away what is wrong with the style, and you no longer need to mention it in review.

Popular frameworks get better output

Language models have seen a lot of public code, and there is far more of it for React, Django or Spring Boot than for a niche library. You notice that in the output. In my experience a model invents functions that do not exist more often when a framework is rarely used.

The same applies to new versions. A model knows less about a version released after its training cut-off, so it falls back on older patterns. State the version you use in your instruction file and note what changed, or give the tool the documentation for that version.

Tests have to be fast and reliable

A tool that can test its own work produces better code. That only works when the tests are fast and give the same result every time. A suite that takes twenty minutes or fails at random gives the tool no useful signal.

My advice is to have a single command for the unit tests that finishes within a minute. Put that command in the instruction file, so the tool runs it after every change.

For bugs, a fixed order works well: have the tool write a failing test first, and only then the fix. That way you know the test actually checks something.

Write the agreements down

Claude Code reads CLAUDE.md at the start of every session. Many other tools, including Cursor, Codex and GitHub Copilot's coding agent, read AGENTS.md, an open format now stewarded under the Linux Foundation. Claude Code also reads AGENTS.md when there is no CLAUDE.md. Describe how to build and test, which conventions apply and which folders the tool should leave alone. The other agreements a team needs are in my post on AI coding tools in a remote team.

Older stacks need more checking

With .NET Framework and Web Forms, PHP without types, or business logic in stored procedures, the tool has less to hold on to. It can still work there, but you have to check more.

A rewrite is rarely the answer. Add types and tests around the code you change, and document how the system fits together. Both the tool and the next developer benefit. These stacks also need different people. Maarten wrote about finding developers for older stacks.

Do not pick a stack for the tool

An AI tool is one factor in choosing a stack. What your team knows and what code already exists count for more. A team that is good at Laravel gets more out of AI tools in Laravel than in a stack it only half knows. The stacks we work with are on our technology page.

Sources

• GitHub, Octoverse 2025
• Mündler et al., Type-Constrained Code Generation with Language Models (2025)
• Claude Code, CLAUDE.md and AGENTS.md
• AGENTS.md