AI Might Not Need to Write Your Backend

As a software engineer, I use AI almost every day. It helps me write code, understand a library, find the source of a bug, or simply avoid spending twenty minutes on something I could have solved myself but really didn't feel like doing. With agents that can navigate a repository, modify multiple files, and run tests, we've reached a point where we can even hand them entire features. I find that pretty fascinating, and I don't think we're going back. However, the more I use these tools, the more I find myself asking a question: is it really a good idea to give them that much freedom over the backend?

Let me make something clear from the start: I'm not saying we should stop using AI for backend development. I use it myself, and I'll explain later why I think it is probably one of the best tools we can have for certain backend tasks. My concern is more about how many decisions we are willing to delegate to it. There is an important difference between asking an AI to create an endpoint and asking it to decide how our system should behave. That difference may seem obvious, but it becomes much less obvious when an agent can explore the project, modify ten files, and present us with a nice diff that we can simply accept.

The Backend Is Where Business Rules Live

The backend has something particular about it in an application: it concentrates a large part of the rules that actually define how the system works. The frontend can decide how information is displayed, but it is usually the backend that decides whether a user is allowed to do something, whether an order can be cancelled, whether a payment can be refunded, or whether an operation should be rejected. It is also responsible for manipulating the data and making sure certain constraints are respected. A mistake in a color, some padding, or an animation is usually quite easy to notice. A mistake in a business rule can produce incorrect data for several months before anyone realizes what happened.

That is why I am much more careful when I let an AI modify my backend. The problem is not necessarily that it writes bad code. Quite the opposite, it can write extremely clean code. The problem is that it can write perfectly valid code based on a wrong interpretation of the requirement. If I ask it to create an endpoint that provides the data needed to generate end-of-program diplomas, it can very well go through the relevant models, retrieve the averages from semester 1 and semester 2, and write the corresponding tests. On the surface, everything may look correct. Yet it might completely forget about retake sessions, even though those sessions have to be taken into account when calculating the final diploma. It would therefore return data that is consistent and properly structured, but that does not reflect the academic reality of some students.

AI Cannot Guess Exceptions Nobody Gave It

In a real project, the business is rarely as clean as the model we have in our heads when we start developing a feature. There are the official rules, the ones written in the specifications, and then there are all the small rules that appeared over time. A client requested an exception, a former developer added a condition to solve a production issue, the accountant wants a notification in a specific case, or someone simply decided that a certain operation should never happen automatically. After a few years, these decisions become part of the business, even if they are not documented anywhere.

A developer who has been working on the project for a long time may know these things almost naturally. They can look at a table and know that certain rows should never be deleted. They can recognize a strange relationship and know why it exists. They may even read a condition that looks unnecessary and remember that it was added after a production incident. AI cannot invent that knowledge. It can search the repository, analyze the files it has access to, and make very relevant deductions, but it remains dependent on the context we provide. If a business rule exists neither in the code nor in the instructions, it will probably do what seems logical based on the information available to it.

And this is probably one of the things that bothers me most about the idea of an agent developing my entire backend. I don't just want it to understand how my application works. I also want it to understand why it works that way. That second part is much harder to transmit.

AI Has a Strange Relationship With Complexity

I also have a theory, probably completely subjective, that AI likes spending a little too many tokens. 😆 I obviously have no proof that it was designed to make us consume more tokens, but sometimes you only need to ask it for a fairly simple feature to see an impressive amount of code appear.

You ask for a CRUD for a resource and you can quickly end up with a repository, a repository interface, a service, a DTO, a mapper, a factory, and sometimes a strategy for something that could have perfectly well lived inside a controller and a model. Each element can be justified individually. The problem appears when you look at the whole thing and realize that you have created fifteen files for an operation that essentially consists of validating a request and saving a few fields to the database.

I don't think AI is deliberately trying to overengineer applications. It is simply doing what it is very good at: producing a solution that looks like a good solution across a wide range of possible contexts. When it lacks information about the actual constraints of the project, it may tend to add abstractions that make its proposal more generic and therefore harder to challenge. The problem is that the most generic code is not always the code our application needs.

We therefore need to be careful with a fairly subtle bias. When AI proposes a sophisticated architecture, we may tend to assume that the amount of thinking required to arrive at that architecture is proportional to its quality. Obviously, it isn't. A solution can be very well thought out and still be completely disproportionate to the problem it is trying to solve.

The Data Model Is Often More Important Than the File We're Modifying

There is also something I sometimes criticize agents for: they tend to focus on the immediate problem. If I ask it to modify an endpoint, it will naturally start by looking at the controller, the associated service, and the models directly involved. That makes sense. Yet the important context is sometimes somewhere else.

A database tells you a huge amount about an application. The relationships between tables, constraints, indexes, possible values for a field, historical migrations, and even columns that appear unused can explain why the system was designed in a certain way. A model may have a strange relationship because an old feature still depends on that structure. A constraint may look unnecessary until you realize that it prevents an impossible state in the system. If the agent doesn't take the time to understand all of this, it can perfectly well modify the code without understanding the consequences of its change.

I therefore think that a backend developer still needs to know their data model very well. This is not something I want to delegate to an agent. An AI can explain my database to me, propose a migration, or help optimize a query, but I want to be able to understand what that database represents myself. After all, the backend is not simply a collection of files that return JSON. It is a technical representation of the business.

Backend Development Isn't Actually That Hard

There is another reason why I'm sometimes surprised by how quickly we want to delegate backend development to AI: a large part of backend work isn't particularly difficult. I'm obviously not talking about designing a massively distributed system or dealing with extremely complex concurrency problems. I'm talking about the day-to-day work that most developers do on a regular application.

Creating a migration usually isn't complicated. Creating a CRUD isn't complicated. Adding validation, creating a route, returning a resource, or writing an SQL query are not problems that systematically require artificial intelligence. A developer who knows their framework properly can do many of these things very quickly. In some cases, spending more time explaining the task to an agent than it would have taken to do it yourself isn't even worth it.

I also think this situation is quite different from frontend development. A frontend feature can quickly become time-consuming because of all the visual and interactive details that come with it. On the backend, once you understand your domain and your data model, many interventions are relatively short. The value of a backend developer therefore lies less in their ability to type a controller quickly and more in their ability to make the right decisions about what that controller should actually do.

Slop Is Much Easier to Detect on the Frontend

We talk a lot about AI slop when discussing content generation or frontend development. That is probably because the result is directly visible. When an AI generates an interface with a huge purple gradient, three cards with massive shadows, a "Get Started" button, and a little ✨ next to every feature, you can usually tell pretty quickly that something is wrong. 😂

The problem with backend development is that slop is much harder to detect. A backend can be filled with useless abstractions, methods that indirectly do what a simple function could have done, duplicated logic, and business rules placed in the wrong locations without any of it being visible during a simple demonstration. The code may even look better because it contains more types, more classes, and more tests.

This is where I think blindly using agents can become dangerous. Bad frontend code is often visible on the screen. Bad backend code can simply keep working. It will save the data, return the right status codes, and pass the tests we asked it to write. The problem will appear much later, when a user comes along with an edge case nobody had thought about.

And More Importantly, Backend Developers MUST Know the Business

I think this is probably one of the reasons why the role of the backend developer is not going to disappear as easily as some people think. The important skill isn't simply knowing how to write PHP, Java, Go, or TypeScript. It also involves understanding the domain you're working in.

A developer who spends several years working on a banking application, a university management system, or a delivery platform eventually builds up business knowledge that becomes extremely valuable. They know which operations are sensitive, which data matters, which exceptions exist, and which decisions should never be made automatically. They may even end up understanding certain aspects of the business better than someone who was formally trained in that field but has never actually worked with the real system. But that's another debate.

This knowledge becomes particularly important when working with AI. The more I know my domain, the more capable I am of spotting a bad decision in generated code. On the other hand, if I don't know the business very well and assume that clean code automatically means correct code, I risk approving decisions I would never have made myself.

But Now, The Part Where I Contradict Myself

After writing all of this, I could very easily conclude that we should avoid AI in backend development. That would nevertheless be completely false, because I use AI extensively in my own work, and some tasks have become much more enjoyable because of it.

There is a lot of backend work that is repetitive, mechanical, and easy to verify. That is exactly the kind of work I prefer to give to an AI. If I have to create a standard CRUD with its migration, validations, resources, and tests, I don't really see the point of spending several hours writing every file myself. I can give the agent the data model, the business rules, and the project conventions, then let it produce a first version. I obviously remain responsible for checking what it did, but I have just removed a large amount of uninteresting work from my day.

Tests make this approach even more interesting. AI is particularly good at quickly generating test cases and checking an implementation. In my work, I often create an endpoint and then ask my agent to go through the different use cases, write the corresponding unit or functional tests, run them, and fix the problems it finds. Once everything works, I can ask it to generate the Postman JSON for that endpoint so I can import it and then give it to the frontend developer. The whole process can happen extremely quickly, whereas a significant part of this work used to be fairly time-consuming.

AI becomes much more interesting when it isn't necessarily making the decision for me. It is helping me execute a decision I have already made. I know what the endpoint is supposed to do, I know the business rules, I know which data needs to be modified, and I can define the cases that should be rejected. The agent can then take care of turning all of that into code and verifying that it works. In that context, I find it difficult to justify not using it.

Tests Also Change the Balance of Power

A few years ago, when an AI generated code, we had a fairly simple problem: how do we know whether the code is actually correct? Today, we have many more tools that allow us to constrain it. Tests are one of them.

An agent that writes a feature and immediately writes the tests that verify that feature obviously does not remove the need for human validation. If the tests are bad, they don't prove anything. But they still give the agent a much more interesting framework to work within. I can ask it to respect specific use cases, test error scenarios, verify permissions, and avoid breaking existing behavior. The more explicit I make my expectations, the smaller the space in which the AI can improvise becomes.

It is ultimately quite similar to how I would work with another developer. I wouldn't simply give them access to the repository and tell them to do whatever they think is necessary. I would explain the problem, the constraints, the business rules, and the expected behavior. I would then review their work. The main difference with an agent is the speed at which all of this happens.

Maybe the Problem Isn't AI, But What We Ask It to Decide

After thinking about it, my position is therefore much less radical than the title of this article might suggest. I don't think we should prevent AI from writing backend code. I actually think it would be a shame not to take advantage of its ability to quickly produce repetitive code, generate tests, and help us explore different solutions.

However, I am much more reluctant to delegate decisions that require a deep understanding of the business. I'm happy for it to create my CRUD, but I want to decide what that CRUD is allowed to do. I'm happy for it to write my tests, but I want to decide which behaviors should be considered correct. I'm happy for it to suggest an architecture, but I want to understand why that architecture is necessary before introducing it into my project.

I ultimately think that using AI intelligently is less about asking it to do the developer's job and more about identifying which parts of the developer's job don't actually need to be done by the developer. Repetitive tasks can be delegated. Tasks that are easy to verify can be accelerated. Business decisions, however, still require someone who actually understands the problem.

And as with most debates around AI, I think we need to remain nuanced. Saying that AI will replace the backend developer is probably just as simplistic as saying that it has no place in backend development. It is already good enough to eliminate a significant amount of daily work, and it will probably become even better.

The real question may therefore not be whether AI should write our backend, but rather which parts of our backend we are actually willing to stop understanding ourselves.