AI Learned From Code Nobody Understood

“AI writes bad code.” The line comes up at conferences, on LinkedIn and in teams that view coding assistants with suspicion. Often, the person saying it maintains a repository full of duplicate functions, rules nobody can justify and integrations nobody wants to touch. That code was written by people, long before language models existed.

At Seamless Doubt, we believe code quality depends mainly on the context given to whoever writes it and on how the result is validated. That applies to a person and to an AI model. The useful question for a business is under what conditions AI helps, and when it should not yet be used.

• Bad code existed before AI: copying and pasting from Stack Overflow is an old practice.

• Business urgency and missing context explain more problems than the tool used.

• In a new project, where the context is the same for everyone, a well-supervised current model can compete with programmers at several levels.

• The decision to proceed, delay or reject AI remains human.

Bad code did not begin with AI

Copying without understanding is an old practice

For years, the fastest way to solve a problem was to search for it on Stack Overflow, find a highly upvoted answer and paste it into the project. GeeksforGeeks, blog tutorials and isolated examples in documentation served the same purpose. When the result went wrong, the blame went to the person who pasted the answer without understanding it, not to the website.

In many SME systems, the marks of this habit remain: the same validation written three times with small differences, functions with vague names and comments that describe a process that has since changed. Each decision made sense on a rushed day. Together, they became the code nobody wants to open.

One of the most common problems in legacy code is lost context. The team no longer knows why a rule exists, who validated it or what happens if it changes. A routine written three months ago can reach that point if the programmer leaves and the rule was never recorded.

Pressure and missing context explain more than the tool

A client needs an exception by tomorrow. A supplier changes a file format without warning. The month needs to be closed. Someone creates a temporary solution, and the solution stays.

In these moments, the person writing the code rarely gets the information they need. They may not know that a client has a negotiated discount, how the supplier usually fails or at what point an order can no longer be changed. An experienced programmer in these conditions writes a plausible but incomplete solution. An AI model in the same conditions does the same.

The difference lies in how each error is judged. When it comes from a person, it is usually seen as a shortcut to fix later. When it comes from a model, it becomes an argument against the whole tool.

What the studies say, and what they do not say

The most cited study on AI and experienced programmers comes from METR, an independent organisation that evaluates AI models. In 2025, 16 programmers with an average of five years of experience completed 246 real tasks in open-source projects they knew well, half with AI and half without. With AI, they took 19% longer, even though they believed they had been faster (TechCrunch).

The study is serious, but its limits are often left out when it is cited. It used tools and models from early 2025, including Cursor Pro and Claude 3.5 and 3.7 Sonnet, which are well below current models. It also took place in large repositories that participants knew deeply, where accumulated experience matters most.

In February 2026, METR tried to repeat the study at a larger scale and could not recruit participants. Programmers refused to be in the group without access to AI tools (I Programmer).

There is a more useful reading of that episode. If programmers no longer accept working without AI, even during a study, comparing people and machines has less practical value. AI has become an extension of programming work, even if that says nothing about the quality of each line it generates.

The question for a business is how much autonomy to give the model. At one end is the programmer who uses AI and remains accountable for what they deliver. At the other is generated code published without review. Most risk sits between those two points.

Programming benchmarks have a similar limit. They measure a model against automated tests on tasks that are already well defined. They do not measure the work of questioning the task, finding missing information or deciding that it should not be done.

Why the same context changes the comparison

In a system with years of history, a senior programmer's greatest advantage is context that was never written down. They know that a particular client is sensitive, remember why a rule was created and can see when the request itself is wrong. A model only has access to what it is given. Comparing both with the same context document removes the senior person's main advantage.

In a new project, with no history behind it, the situation changes. There are no forgotten rules or informal history, and all existing context is written down. The model and the person start from the same point. Our view is that, in these conditions and with supervision, a current model can produce better work than a junior or mid-level programmer and, on many tasks, compete with a senior programmer.

Supervision is the condition behind that view. Someone must decide the architecture, review what was produced and recognise when the model followed the wrong interpretation. The experienced programmer writes less code and spends more time defining the problem and validating the result.

As far as we know, there are still no studies directly comparing current models and senior programmers on the same task with the same context. Until there are, this is a position based on our reading of what models can already do, not a measured result.

Generating code and validating code are different jobs

Generating code, generating tests, running those tests and reviewing the result are four separate stages. A model can help greatly with the first two, but that does not mean the others have been done.

If the model misunderstood the request, the tests it generates tend to confirm that same interpretation. The code can pass the tests while remaining wrong. Acceptance criteria should therefore come from the people who know the process, independently of whoever wrote the code.

Business validation confirms that the result does what the operation needs. Technical review confirms security, performance and ease of maintenance. One does not replace the other.

The context that should exist before any request

Before asking for a change, from a model or a person, your team should be able to answer:

• What data enters this process, and what data changes at the end?
• What data can be shared with an external tool?
• What exceptions exist, and who decides how they are handled?
• What happens when an external system is unavailable?
• Who receives an alert if the automation fails?
• How do you roll back without stopping the operation?

These answers come from the people who do the work every day. Start with a diagnosis involving the people who know the exceptions before choosing any technology. Test a tool within your own team before taking it into a client process. A smooth demonstration does not prove that a process can handle incomplete data or a connection failure on an ordinary Monday.

When the right answer is “not now”

Good AI does not mean every process is ready for it. If rules change every week, nobody can explain how unusual cases are handled, or there is no way to roll back, delaying is the sensible choice.

AI can still help with lower-risk work: documenting the current system, mapping scattered rules or preparing test cases. This work carries less risk when you control what data is shared with the tool, who has access and how the results are used.

Banning AI completely rarely solves the issue. It can increase the risk of undeclared use, with no rules about what data may be shared. Clear rules that everyone knows are easier to control.

Responsibility still has an owner

AI writes the code, but the decision to put it into production still belongs to a person. A model does not know the cost of blocking a valid order, delaying an invoice or sending the wrong message to a client. It implements the decision it is given.

Every significant automation should have someone from the business who can say when the result is correct. That person does not need to program. They need to understand the work affected and validate the outcome in normal and less normal situations.

Frequently asked questions

Does AI write bad code?

It depends on the context it receives and the review that follows. In a new project, with written rules and supervision, current models can be very helpful. In systems with a great deal of undocumented history, they fail for the same reasons as a person who has just joined the team.

Where should you start?

Start with defined, reversible tasks and controlled data: documenting an old system, creating test cases or preparing a small improvement. Payments, personal data and client messages require clearer rules and a safe way to roll back.

Conclusion

Before discussing whether AI writes code well or badly, look at the context your business can provide. Choose a low-risk process. Write down the rules and exceptions. Define who validates the result, how a failure is detected and how you roll back.

The points where AI needs more information show what still needs organising, with or without it.