Functional programming accellerates agentic feature development

Code examples in this post are available in five languages. Pick yours:

The pattern I keep seeing

An agent reads a function that takes a list and returns a list. It writes tests. They pass. The function fails in production because it depends on a global config and a database singleton the signature never declared. The agent had no way to know. This isn’t a model problem. Functional programmers solved it in the 1980s.

I’ve shipped AI products for over a decade, and the trajectory is always the same: impressive demo, promising pilot, gradual degradation, debugging nightmare, project abandoned. Most agent projects never make it to production. The ones that do often get rolled back within a year. MIT found 95% of AI pilots fail to deliver ROI. The instinct is to blame the models. “GPT-5 will fix it” or “we need better prompts.” The failures are architectural.

When an agent writes code into a mutable, tightly-coupled codebase, it’s producing non-deterministic output that depends on hidden state it can’t see. The global config object three modules away, the function that logs to disk as a side effect, the test that was mocking a database that behaves differently in production: the agent has no way to know about any of it.

The codebase is hostile to automation, and we keep blaming the agent.

Why agents need different code

A human developer builds a mental model of a codebase over months. They know where the bodies are buried: which functions mutate state, which modules share globals, which tests are flaky. They carry this context between sessions.

Agents don’t have that luxury. Every session starts from scratch. An agent reads the code that’s in front of it, follows the explicit contracts, and produces output based on what it can verify. This means anything implicit, any hidden state, any side effect buried inside a “pure” function, becomes a trap.

Here’s a function that looks fine to a human:

def evaluate_options(options):
    threshold = GLOBAL_CONFIG["decision_threshold"]
    history = Database.get_instance().get_history()
    return [opt for opt in options if opt.score > threshold]

A developer on the team knows that config gets loaded from a YAML file at startup and the database accessor is a singleton that needs initialization. An agent sees a function that takes a list and returns a list. It writes tests against that contract, the tests pass in isolation, and the function fails in production because the global config wasn’t loaded.

The fix is forty years old

Functional programming solves these problems because it was designed to eliminate exactly the properties that make code hostile to automated reasoning.

• Pure functions return the same output for the same input.
• Explicit data flow means you can trace how inputs become outputs linearly.
• Side effects at the boundaries means I/O happens in a thin outer layer.
• Composition over coupling means small functions that snap together.

SUPER: five principles for agent-friendly code

SUPER is five constraints on how you write code:

• Side Effects at the Edge
• Uncoupled Logic
• Pure & Total Functions
• Explicit Data Flow
• Replaceable by Value

The practical effect: an agent working on SUPER-compliant code can modify any function by reading only that function and its type signature.