How I Manage an ERP Project with AI: A Multi-Agent Software Development Methodology

Introduction

In my field experience spanning over two decades, I’ve repeatedly witnessed how a software project can slow down, become costly, and lose its flexibility in the face of special requests. The traditional model was quite clear: lengthy analysis, large development teams, know-how tied to a single individual, and iterations lasting months. Sometimes, adding a single feature required weeks of waiting because the person who wrote the code was on another project, the tester was on a different one, and the third person responsible for approval was on leave.

Over the past year, a new reality has completely transformed this picture: artificial intelligence is no longer just a “helper tool” but has become a layer that actively generates code, performs independent audits, and provides architectural recommendations. But here’s a critical question: Is it enough to have AI write code, or is managing AI a separate discipline? I will share my answer in this article, because I now manage an ERP project not alone, but with an AI team that I coordinate.

Using AI Tools or Managing Them?

The difference is as significant as that between being a “user” and an “orchestra conductor.” Asking ChatGPT a question and copying the output is a form of AI usage — yes, it’s valuable, but it’s not enough to run a project from start to finish. Because without knowing what a single AI model does well, what it does poorly, where it errs at which stage, or which task you should assign to which model, you cannot achieve a successful outcome.

I think of AI as a pipeline: a specific sequence, with agents possessing different areas of expertise, and a coordination layer that transforms each agent’s output into the next’s input. The name of this layer is “human architect” — that is, me. This distinction between using tools and coordinating tools is the primary factor determining whether a project finishes in two weeks or eight months.

When a client says, “So you’re having AI write code,” my correction is always the same: no, I’m coordinating multiple AIs simultaneously, and I don’t accept any of their outputs without auditing them. This is a critical distinction, because the quality assurance of projects depends on how meticulously this coordination is established.

The Multi-Agent Pipeline: How It Works

In an ERP customization project, the pipeline I run roughly consists of five roles; each is undertaken by a different AI or human.

• Large context language model — reads the project’s entire codebase, database schema, and existing integrations as a whole. Without this layer, which can “see” hundreds of thousands of lines of code simultaneously, it’s impossible to ascertain the current state of a system. I use this to generate topology reports, map dependencies, and find recurring patterns.
• Architectural consultant AI — the layer where I make high-level decisions. Where should a function be written, which common service should be utilized, which design pattern should apply, how should technical standards be defined? These questions are paramount for me. At the same time, I design the instructions — i.e., the prompts — to be given to the next agent at this layer.
• Development AI — the agent that performs the actual code writing. It creates files, modifies existing code, and iterates according to the specifications produced by the architectural consultant. Human intervention here is minimal; however, everything produced is audited before moving to the next stage.
• Audit AI — the quality assurance of the pipeline. It reads the generated code with an independent eye, searches for security vulnerabilities, checks for business logic errors, and reports where business rules have been violated. The agent that writes the code cannot audit the same code — auditing is always done with a second pair of eyes.
• Human architect (me) — the layer that manages the pipeline itself. I decide which task to assign to which AI, which output is acceptable, and which decision will be deployed to the live environment (prod). Full responsibility to the client rests with me, because none of the tools understand the business context as well as I do.

Why the Human Architect’s Role is Critical

AI is surprisingly good at writing code. But it still cannot do these five things:

• Understand business requirements. To understand what a client truly means when they say, “we want to optimize the warehouse,” requires having the context of hundreds of similar projects. AI cannot build this context on its own; I have built it over years, and I am the one who brings this knowledge to the pipeline.
• Make architectural trade-off decisions. Every technical choice has a cost: speed versus flexibility, standardization versus customization, short-term versus long-term. Matching these balances with the client’s priorities is an architect’s decision, not a model’s prediction.
• Approve deployment to the live environment. Transitioning to a production environment always carries responsibility. If something goes wrong, the person accountable is not an AI, it’s me. Therefore, approval always remains with a human.
• Take responsibility towards the client. Business relationships are built on trust. The client trusts a solution approved by me, not an AI’s output.
• Distribute the right tasks among tools. Which AI is good at which task, at which stage which model errs, which combination yields the most efficient result — this knowledge accumulates in someone who has run the pipeline for a long time and becomes the pipeline manager’s core expertise.

Quality Assurance: Every Line Audited

In traditional software projects, code review — meaning the written code being read and checked by another developer — often remains optional. If the team is small, the schedule tight, or priorities shift, this step is skipped. However, in my methodology, this option doesn’t exist: every function, every change, every new file undergoes an independent AI audit. Moreover, this audit report comes with line references, meaning the type of issue found on which line is clearly documented.

This prevents errors from reaching the live system. A security vulnerability, an incorrect business rule, or unnecessary code duplication is caught before it leaves the system. This is not a bonus for me, but a cornerstone of the methodology — because an ERP system runs critical business processes, and even the smallest error in these systems can halt production.

Which Projects Is This Suitable For?

This multi-agent pipeline approach stands out significantly in certain scenarios:

• Custom module development on ERP — when you want to extend an existing platform according to your business needs, tasks that traditional teams would take months to complete are reduced to weeks.
• Warehouse, production, and quality screens — tailor-made interfaces for operational processes, perfectly suited for areas requiring rapid iteration.
• Integration with existing systems — writing bridge code to enable two different systems to communicate is one of the strongest points of an AI-supported pipeline.
• Air-gap / closed network environments — even in environments without internet access and requiring special security, certain parts of the pipeline can operate offline.
• Critical sectors, including defense industry — areas requiring the highest audit discipline; paradoxically, multi-agent AI generates the most value here because every output is already subject to independent auditing.

Conclusion and Call to Action

This methodology democratizes software development. Previously, an SME needed to assemble a ten-person team, wait six months, and allocate a large budget for enterprise-quality custom software. Now, it’s possible to produce the same quality within a few weeks. But please don’t misunderstand: this isn’t about “letting AI do it, it will write itself.” It’s an approach that requires the coordination of the right architecture, the making of correct decisions, and the establishment of proper audit discipline.

If you have an ERP project and it seems like it could be solved with this method, let’s schedule a discovery call. Let’s discuss the system, your needs, and expectations — and if it’s truly suitable, let’s map out a roadmap together.