| Stack | Golden path | Convention strength | Type / compiler feedback | Agent tax | First-party agent tooling |
|---|---|---|---|---|---|
| Laravel | Very short (artisan) | High, blessed file layout | Medium-high (PHP 8 + Pest) | Facades and provider / migration coordination | High (Laravel Boost) |
| Django | Short (manage.py) | High, MTV + batteries | Medium static safety, strong Python prior | Celery and API style sit outside the core | Low-medium |
| Nest.js | Short if you stay on modules | High module shape | High recovery with strict TypeScript | Circular DI, ORM / auth menu sprawl | Low-medium |
| ASP.NET Core | Short if you pick one template | Medium (Minimal APIs vs controllers) | High (C# / Roslyn) | Mixing Minimal APIs, controllers, Identity | Low-medium |
| Spring Boot | Short for demos (start.spring.io) | Medium (starters + annotation density) | Medium-high (Java compile) | Auto-config guesses, Security recipes go stale | Low-medium |
One obvious place for the boring jobs
| Concern | Laravel | Django | Nest.js | ASP.NET Core | Spring Boot |
|---|---|---|---|---|---|
| Auth | Starter kits + Sanctum (Passport when you mean OAuth2) | Built-in django.contrib.auth | Fragmented (Passport, JWT, modules) | Identity + scaffold | Spring Security (powerful, many recipes) |
| Migrations | First-party Artisan | First-party makemigrations | Depends on ORM (Prisma / TypeORM / …) | EF Core (dotnet ef) | Flyway / Liquibase / Hibernate DDL (a choice) |
| Validation | Form requests | Forms / serializers | class-validator pipes (common, not unique) | Data annotations / FluentValidation | Bean Validation |
| Jobs | First-party queues | Celery (usual, external) | Bull / BullMQ etc. | Hosted workers / Hangfire / cloud patterns | @Scheduled + messaging starters |
| ORM default | Eloquent | Django ORM | None (database-agnostic) | EF Core | Spring Data JPA (default-ish) |
None of those rows says “best.” They say where the agent will thrash, and where you must pin a choice in the ruleset before the first session.
Laravel: conventions the agent can recite
Laravel is the most opinionated of the five about where things live. Controllers, form requests, migrations, jobs, and queues have documented homes. The install path is a CLI. The docs now go further and talk about AI coding against those conventions, including Laravel Boost as an MCP surface for agents.
That matters. Agents guess the documented default. They thrash when your repo invents a parallel style. Spatie’s own PHP guideline is the same rule we want for agents: follow the framework’s documented way first, and only deviate with a reason (Spatie PHP guidelines).
Laravel also published a vendor eval, Boost Benchmarks: 17 Pest-verified Laravel tasks, with and without Boost. Models improved or held with Boost, with the biggest lifts on harder framework features. Treat that as evidence that framework-aware context helps Laravel work, not as proof Laravel beats Nest on a shared suite.
The tax is magic and coordination. Facades are static proxies into the container. Agents love the one-liners. When the boot fails because a provider, a migration, and route model binding have to agree, the second prompt gets expensive. An AppSignal Cursor experiment in June 2026 saw Laravel use about 105k tokens for a CRUD-plus-auth prompt that Django finished around 31k, largely because Laravel needed a debug pass (AppSignal). Small sample. Same N+1 bug shipped on all three stacks they tried. The useful line in that piece is the one we agree with: the cheapest stack long-term is the one your humans can fix when the agent is wrong.
Pick Laravel for agents when your product is a conventional web or SaaS backend, your team already thinks in Artisan, and you will pin starter kits / Sanctum (or Passport when you mean OAuth2) instead of letting the agent invent auth.
Django: batteries, and a language agents already know
Django’s golden path is old and stable: startproject, startapp, models, migrations, admin, auth. That stability is a gift to agents. There is less to invent. PyPI fluency in models is high, and Django’s own packages cover a lot of the surface before you reach for a third party.
Python also sits at the center of most agent eval harnesses. SWE-bench style work is still Python-heavy. Multi-SWE-bench and related work show large language gaps across ecosystems, with Python usually the strongest baseline and other languages trailing depending on the scaffold (Multi-SWE-bench). That is a language signal, not a Django-over-Laravel ranking. It does mean agents have seen a lot of Python bug-fix loops.
The tax is what sits outside the core. Celery is the usual answer for jobs, not a first-party queue. API style is a choice (plain views, DRF, something async). Agents will pick one and then another in the same PR if you do not pin it. Django also does not make your product an ML product. Adjacency to PyTorch is a product argument, not an agent-coding argument. We are scoring coding agents here, not inference hosting.
Pick Django for agents when the domain is data-shaped, the admin is a real surface, and the team can keep the agent inside apps, models, and first-party auth.
Nest.js: TypeScript structure, optional chaos
Nest gives agents a shape they recognize: modules, providers, controllers, a CLI (nest new, nest generate). Strict TypeScript plus a compiler is a real feedback loop. That is why Nest often feels “agent ready” in demos.
The tax is that Nest is honest about being database-agnostic. TypeORM, Prisma, Sequelize, MikroORM, Mongoose. Auth is similarly fragmented: Passport strategies, custom JWT, third-party modules. Humans like that menu. Agents treat the menu as permission to mix three ORMs and two auth libraries in one week.
Circular dependencies are the other bill. Nest documents them as something to avoid, with forwardRef as an escape hatch (circular dependency docs). Agents reach for forwardRef the way juniors reach for a global. The app boots. The graph gets worse.
Pick Nest for agents when the team is TypeScript-native, you pin one ORM and one auth path in the repo ruleset, and you treat a new forwardRef as a review smell.
ASP.NET Core: strong feedback, pick a template and stay there
C# gives agents something Nest wishes every JavaScript codebase had: a compiler that refuses nonsense early. dotnet new, EF Core migrations, and Identity scaffolding are first-party. Official docs now recommend Minimal APIs for new projects, with controllers as the alternative.
That recommendation is also the trap. Agents happily mix Minimal API endpoints, controller-based APIs, and Identity scaffolding patterns in one solution. Each template is fine. Three templates in one repo is a consistency tax your reviewers pay forever.
Public agent benches under-cover C#. Multi-SWE-bench does not include it. SWE-Sharp-Bench exists because the .NET gap was real. So do not let a missing leaderboard talk you out of ASP.NET if your team already ships it. Absence of a bench is not a failing grade.
Pick ASP.NET Core for agents when the org already lives in NuGet and Azure-shaped ops, you choose Minimal or controllers up front, and Identity plus EF is the written default.
Spring Boot: demos are easy, Security is where agents age poorly
start.spring.io plus a starter set is a beautiful golden path for humans and agents. Spring Boot’s own first-app docs say auto-configuration will “guess how you want to configure Spring” from the jars on the classpath. Guessing is great until the guess is wrong at 2 a.m.
Spring Security is the station that most often shows agent age. Practitioner write-ups (and skill files teams keep for agents) keep listing the same misses: field injection, invented exception trees, ignoring Flyway, and Security config patterns that were retired years ago. Java itself can score well on multi-language agent benches when the toolchain is deterministic. Spring Boot’s magic layer is what turns a good Java run into a long boot log.
Maven starter names are a blessing and a curse. spring-boot-starter-* is a vocabulary agents can recite. Wrong coordinates and pre-Jakarta habits still show up.
Pick Spring Boot for agents when the enterprise constraints already point at the JVM, you pin Security and migration tooling in a ruleset the agent must read, and a senior person still owns the filter chain.
What the benches actually measure
If you only read leaderboards, you will crown Python and feel clever. Multi-SWE-bench reports large gaps across languages and does not include PHP or C# (paper). That cannot rank Nest against Laravel against Django against Spring against ASP.NET. It can only warn you that language corpus and harness quality move the needle.
Framework-adjacent evidence pulls in two directions:
– Laravel’s Boost benchmarks say framework-aware context helps on real Laravel tasks. – AppSignal’s small Cursor study says Django can be cheaper on tokens for the same prompt, and that all three frameworks they tried still shipped an N+1.
Use both. Do not flatten them into a winner.
GitHub stars are a worse proxy. On 2026-09-10 the rough star counts were Django ~90k, laravel/laravel ~85k, Spring Boot ~81k, Nest ~77k, aspnetcore ~38k. That mostly measures age and awareness. The aspnetcore monorepo undercounts enterprise use. We ship these stacks because clients need them, not because a star chart said so. BlueLupin lists NestJS, Django, Laravel, .NET Core, and Spring Boot among backends we ship with on About.
How we decide on a client repo
When a client asks which backend to put under agentic development, we do not open with a fashion answer. We ask:
- What does the team already debug at 11 p.m. without an agent.
- Can we write a one-page ruleset: one ORM, one auth path, one test command, one migration command.
- Will CI run that test command on every agent PR.
- Who reads the diff, and do they know this framework’s magic well enough to catch a confident wrong answer.
Then we match the stack:
– Conventional SaaS with a PHP team: Laravel, with Boost or an equivalent rules file. – Data-heavy product with a Python team: Django, with Celery and API style pinned. – TypeScript shop sharing types with the frontend: Nest, with ORM and auth pinned, forwardRef banned without a note. – Microsoft shop: ASP.NET Core, Minimal or controllers, Identity and EF written down. – JVM enterprise with compliance gravity: Spring Boot, Security and Flyway (or Liquibase) owned by a human, starters pinned.
If the team cannot name those pins, the agent is not the problem. The floor is.
The decision is still human
Agents reward conventional, typed, CLI-driven stacks with a short golden path. That property is real. It is also not stronger than a squad that already ships Spring, or a product that already lives in Django admin.
We will keep putting coding agents on all five. The productivity difference we see is rarely “the model likes Nest.” It is “this repo told the agent where auth lives, how to migrate, how to test, and which magic is off-limits.”
Write that down before you crown a framework. The framework choice is still yours. The agent will fill whatever gap you leave.