AI Has a Problem With Functional Programming

There is a pattern I keep seeing in AI-generated code. You ask it to implement something relatively simple and you get this:

const result = await processRequest(request);

async function processRequest(request) {
  const data = await getData(request);
  return transformData(data);
}

async function getData(request) {
  return repository.get(request.id);
}

function transformData(data) {
  return mapper.transform(data);
}

Every function looks perfectly reasonable in isolation. But most of those functions add almost nothing. We've turned two operations into a small guided tour of the codebase.

Very modular. I'm already tired.

And yes, saying AI has a functional programming problem is technically unfair. Functional programming isn't the issue. The problem is that LLMs seem unusually comfortable creating shallow abstractions: functions whose only purpose is calling another function.

And abstraction isn't free. Every function introduces another name, another place to jump to, another interface you need to keep in your head. You wanted to understand where the data comes from and now you're opening your fourth file.

John Ousterhout describes a similar problem with shallow modules: abstractions whose interface is large relative to how much complexity they actually hide. They don't really remove complexity. They move it.

Why does AI do this?

There isn't much evidence that LLMs inherently prefer functional or modular code.

In fact, an EMNLP 2024 study compared modular and non-modular versions of functionally equivalent code across several code models. Their conclusion was interesting: modularity itself was not a core factor in improving code-generation performance.

Revisiting the Impact of Pursuing Modularity for Code Generation - ACL Anthology

aclanthology.org

So the problem may be less about what the model wants and more about what we ask it to produce. We constantly tell AI to write code that is:

• clean
• modular
• reusable
• maintainable
• single-responsibility

Those are good goals. But they are incredibly easy to satisfy mechanically:

Take these five lines and give them a name.

There you go. Clean code. We can all go home.

The model also doesn't experience the code like we do. Creating another helper costs it almost nothing. A human maintaining the result six months later has to navigate through it, figure out whether the helper does anything special and discover that, no, it just calls the next one.

And we're starting to get actual evidence that functionally correct LLM code can still have structural quality problems.

An ICSE 2026 study measured how likely LLM-generated code was to contain code smells and found that generation strategy, model architecture, model size and, importantly, prompt formulation influence those smells.

Another 2026 study looking at real repositories found that code detected as likely AI-generated showed substantial intra-repository code cloning. Basically, repeated code inside the same repository. That's another sign that generating locally reasonable code doesn't necessarily produce a cleaner system globally.

[2607.01867] An Exploratory Study on LLM-Generated Code and Comments in Code Repositories

The use of LLMs in software development has become increasingly widespread on tasks such as code generation and summarization. Reports from large technology companies showed that around 20% to 30% of their code are generated by LLMs. However, there remains skepticism about the practical usage of LLM-generated code and comments, such as concerns on more time for debugging the generated code and the unnaturalness of the generated comments. In this paper, we study the code and comments detected as likely to be generated by LLMs and their characteristics, the differences between company- and community-maintained repositories, and how likely bugs are associated with LLM-generated code. We conduct extensive experiments on active company- and community-maintained repositories from 2021 to 2025 using various tools and techniques that detect code and comments generated by LLMs. Based on our detector-based proxy analysis, the results suggest that code detected as likely to be generated by LLMs decreased over time and appeared frequently in test cases, while that of comments remains relatively stable. Proxy results further suggest that code detected as likely to be generated by LLMs shows substantial intra-repository code clones, whereas comments exhibit a relatively low proportion of grammatically correct sentences. In addition, the company-maintained repositories show a higher percentage of code and comments detected as likely to be generated by LLMs, and only a small percentage of the human-labelled bugs are detected as being likely associated with LLM-generated code.

arxiv.org

Maintainability research has moved far enough that researchers are now trying to predict the maintainability and code-smell characteristics of generated code before the model even generates it. One October 2026 paper, PreMaQ, evaluated 2,695 tasks across four models and found that its predictions correlated meaningfully with the eventual maintainability metrics of the generated code.

[2610.05858] PreMaQ: Predicting Maintainability-Related Quality of LLM-Generated Code Before Generation

As large language models (LLMs) become increasingly capable of code generation, adopting generated code in software development requires assessing not only its functional correctness but also its maintainability-related quality. If such quality could be estimated before generation, developers could avoid the cost of generating, reviewing, and discarding low-quality code. Although prior work has shown that the functional correctness of the LLM-generated code can be predicted in advance, it remains unclear whether maintainability-related quality is similarly predictable. We introduce Pre-Generation Maintainability-Related Quality Prediction (PreMaQ), which predicts the Code Smell Score (CSS) and Maintainability Index (MI) of generated code from the internal representations of LLMs before generation. Our evaluation covers four open-weight LLMs and four Python code generation benchmarks, comprising 2,695 tasks in total. Our results show that predicted CSS and MI consistently correlate with their observed values across all 16 model-benchmark combinations, achieving mean Spearman rank correlations of 0.57 and 0.65, respectively. When used for model selection, PreMaQ achieves 59.5% of the maintainability-related quality improvement attainable by an ideal maintainability-based selector over random selection on tasks for which multiple models generate functionally correct code. Combining predictions from PreMaQ and prompt embeddings increases this proportion to 60.7%, indicating that the two signals are complementary. These findings suggest that PreMaQ can be used to predict and improve the maintainability-related quality of LLM-generated code.

arxiv.org

None of these studies proves that AI loves one-line wrappers. They do show that "the code works" doesn't tell you everything about the code you're going to maintain.

So how do we stop it?

Tell the AI that abstractions need to pay rent.

I've started preferring instructions closer to:

Do not extract a function merely to make another function shorter. Create an abstraction only when it hides meaningful complexity, represents a domain concept, or is genuinely reused. Avoid pass-through functions and one-line wrappers. Prefer fewer concepts and a shorter call path.

The ICSE study above found that prompt formulation materially affects the kinds of code smells models generate, and that targeted mitigation can reduce their occurrence. That doesn't mean this exact prompt has been scientifically blessed. It means being specific about what you want is probably more useful than asking for "clean code" and hoping we all agree on what that means.

One final rule I like:

If the function's name is basically an English translation of its body, consider deleting it.

Consider, not automatically delete. A one-liner that expresses a real domain rule can still be useful. But if the only reason it exists is that the other function was getting a little long, maybe we don't need it.

AI is extremely good at producing more code. We're reaching the point where one of the most important skills when using it is asking it to produce less.