1. Library
  2. How Back-End Engineering Is Evolving in the Age of AI

How Back-End Engineering Is Evolving in the Age of AI

11 mins
Light Mode
  • Heavybit Photo
    HeavybitHeavybit
Where Back-End Systems Are Headed in the Age of AI
Repeating History: Front-End Complexity Moves to Back-End
A World Where Millions of Lines of Code Appear Every Moment
Is Mass Adoption of Agents Right Around the Corner?
What the Agentic Future Means for Back-End Teams

Where Back-End Systems Are Headed in the Age of AI

While much has been written about AI’s ability to dramatically speed up developer productivity by spinning up thousands of lines of code, far less has been written about the effects of AI on back-end engineering. But the practice of managing server-side, database, and APIs is also evolving, and not just due to code generation.

Gartner estimates that within a few years, 80% of API calls will not come from humans, but from AI agents that autonomously scuttle forth and mercilessly hammer endpoints with endless data requests. As a result, back-end systems may need to become significantly more durable, but also more flexible to accommodate the wider variety of interactions from many different species of AI agents and tools.

Mike Piccolo is the founder of the iii (formerly known as Motia), an open-source, language-agnostic orchestration engine that his team built to help back-end systems and teams adjust to this brave new world. Below, he shares his thoughts on how back-end architecture needs to evolve, and how teams should think about the future to come.

In the same way that MVC and React were needed to unify server-side data management and front end, respectively, back-end systems may also need a new core primitive.

Repeating History: Front-End Complexity Moves to Back-End

Piccolo suggests his project echoes the evolution of technology from the digital transformation era, when server-side applications, previously built and maintained on poorly-organized PHP spaghetti code, began evolving to model-view-controller (MVC) architecture. “Every company was taking a bespoke approach to [their digital transformation],” the founder notes, leading to an unsustainable level of complexity.

“This is what necessitated MVC, which was an abstraction that tells you how to properly build this type of server. Everybody just switched to it, almost immediately. It was Rails, then Django, then Laravel, then .Net MVC, then Spring. Basically all the programming languages implemented it.”

MVC being a universal framework temporarily solved the problem of orgs having to reinvent the wheel until teams began pushing the logic to the front end, making more-complex experiences that led to the front-end framework wars. “You have Angular, Ember, React, Vue, and others. This was the next paradigm shift, which React solved in the correct way.”

Piccolo compares React’s success to MVC: A framework that’s also now in use everywhere. “They took all the complexity of building inside of the Document Object Model, including event listeners, the event loop, and all of these things, and they compacted it into a single core primitive, the component. And it made both sides of the house really happy.”

The React component gave implementation engineers a mental model to build frontends as complex as they liked, but was good for library maintainers, framework developers, principals, and architects because “they got to use these low-level primitives that React provided to build this ecosystem, including Next.JS, Redux, and TanStack.”

The founder suggests that a similar paradigm shift is happening in back-end development, with complexity shifting from front end to back end. “What that looks like is tons of complexity going into a system that wasn't built for it, and the complexity reaching a threshold.”

The founder’s mission echoes that of MVC and the React component. “We are building a new set of core primitives that will handle all of the complexity to build a generically intelligent backend.” Piccolo confides that the task was larger than it seemed initially, requiring multiple API frameworks, such as Python Flask, Express.JS, or Next.JS, potentially used with a Java server.

“That’s your APIs covered. But now it gets more complex. You need background jobs and queuing.” After adding services like SQS, or BullMQ or RabbitMQ, the founder notes that teams often look to a workflow engine or durable execution frameworks such as Temporal or Apache Airflow to handle the durable execution.

“And then, you need to add agentic frameworks. So you’re adding shared-state concurrency with something like Redis, and streaming with a service like Pusher.” The founder notes that with so many disparate systems, builders need to wire them together, while also building observability over top, making for extremely complicated infrastructure with huge amounts of surface area.

“Each of these things has its own domain, its own SDKs, and its own APIs. The only thing in common across all of them is that there are functions, workers, and triggers you can combine.” Piccolo explains that carefully observing those common features led his team to create the core primitives of the iii project.

“You send events in, and they trigger a particular function inside the queue, and workflow engineers do something similar but with an ordered workflow. Agents also have this type of recursive loop, but those are really just triggers for the next instantiation of the agent call. That’s the basis of what we're building, this core set of primitives that will provide common observability, common shared resources, and services across this whole stack.”

A World Where Millions of Lines of Code Appear Every Moment

The founder suggests that AI tools have improved so much in recent months that they seem to be starting to outpace top-level coders. “I have several senior- or principal-level architects on my team, and they’re extremely fast, switching screens so quickly you can barely see what’s going on. Previously, it was faster for them to code manually.”

“And in the last few months of using tools like Claude Code and Cursor, even my team is starting to adopt them and see value.” The founder notes that a growing challenge for orgs may be a massive influx of PRs that make catching up on code reviews difficult. Teams stuck with mountains of AI-generated code are experiencing the shock of having a year’s worth of code pile up on their terminals in just a few days, if not faster.

Piccolo suggests that this challenge will also be solved, perhaps via agents shipping better code and/or being better at reviews themselves. “Part of the solution is to reduce the surface area that these things need to build. If you ask an agent to build a Web app, by default, it's going to use React because it's the right abstraction.”

“The agent is capable of writing all the event listeners and all the DOM manipulation manually. But it won’t. It uses the smaller surface area, which is the correct abstraction. So if we do succeed in creating these core primitives in this abstraction, it will reduce the total cognitive burden. You'll need fewer tokens, and the agent needs to think less about it.”

Part of the solution is to reduce the surface area that these things need to build.” - Mike Piccolo, Founder / iii

Is Mass Adoption of Agents Right Around the Corner?

On the topic of large-scale agentic adoption, and where and when it will happen, Piccolo is reflective. Will the world of software soon be dominated by millions of autonomous agents hammering APIs non-stop? “There are different ways to look at it. The technology may be getting there, but enterprise adoption is a different question.”

The founder suggests that enterprises are not likely to be running free-rein Clawdbot instances within the next year. “I could be wrong! Things are moving incredibly fast. But just in terms of security, compliance, and legal concerns, [widespread] adoption for enterprise users just seems too far fetched. I'm highly technical myself, and I'm not comfortable running Clawdbot without really thinking through what I'm doing. I'm not going to give it my credit card yet.”

Piccolo concedes that users on Twitter and other social media platforms seem to be making great progress on getting agentic systems to work, but isn’t convinced that a long-term solution has emerged yet. “The problem is that we need this other layer for things to work. If you have durable execution and queues spinning in the background, and then you bolt on agentic? That makes things much more complex. It seems insanely hard to manage and observe and have confidence in.”

“We need this base layer of core primitives that provide the visibility, the explainability, and the durableness at the base layer below anything else we do, whether it be agentic workflows or durable execution workflows. All these things need to sit on top of a new foundation, in my opinion.”

What the Agentic Future Means for Back-End Teams

A long-running narrative in the AI space is how it will, inevitably, reduce the need for human engineers, and potentially shrink the sizes of development teams, even for back end. But Piccolo is skeptical of any significant change happening soon, at least at larger orgs. “[For an enterprise], you need to have a sizable team that is managing what you're building and ensuring that it's built in the proper way.”

“I think that a lot of the focus will move to the context engineering space, where that becomes extremely important to manage the system. That's already happening.” The founder also suggests that many orgs might not realize the immediate importance of system integrity (which used to be treated as code quality).

Piccolo explains that system integrity and code quality essentially resolve into the patterns from which AI agents learn, which has larger ramifications for any business. “You’d want to meticulously say: This is not the correct pattern. We like this other pattern and we want to keep it consistent across our codebase. That's the same meticulousness you need in this context space, which applies not just to the engineering side, but also to the business side. What is your domain, what does your company do? Your IT sides describe the code quality and patterns, and your business side describes how that translates into business value.”