EngineeringOctober 27, 2026· 9 min read
The Maleus ADLC: our development lifecycle with agents, from the idea to production
How Maleus scopes, specifies, codes, tests, reviews and runs applications with agents, for teams who never read code.
Adrien MaretCTO
On this page
- The eleven phases of the Maleus ADLC
- 1. Scoping: digging into the need
- 2. Splitting into versions: a budget decision
- 3. Detailed specifications: spec-driven development
- 4. The implementation plan: deciding before coding
- 5. The front end first, with its tests
- 6. The back end: business logic and its tests
- 7. Reconciliation: wiring the front to the back
- 8. Running the tests and fixing
- 9. Three reviews before the version is approved
- 10. Acceptance testing: commenting out loud while browsing
- 11. Deployment and operations
- Where humans stay in control
- In summary
See how Maleus can accelerate your team.
Writing code with agents has become easy, but producing an application that is reliable, tested, secure and maintained in production is another matter, and it takes a lifecycle: an Agentic Development Lifecycle (ADLC). Here is the Maleus one, the Maleus Development Lifecycle, from the first expression of the need all the way to running the app.
Vibe engineering is the opposite of vibe coding. Vibe coding promises that anyone can build an application with a few prompts, but leaves the user with everything that makes software reliable: scoping, specifying, testing, reviewing, maintaining.
Without technical skills, there is no way to tell whether what was generated holds up. Vibe engineering flips the logic: the business user expresses the need and approves the result, and the engineering rigor is carried by the agents.
This lifecycle is what lets Maleus work in full autonomy on tasks that run for hundreds of hours: it delivers a complete, working application on the first try, with no bugs, nothing forgotten and no hallucinations, then evolves it without breaking what already exists.
The Maleus lifecycle is designed for non-technical people (project managers, business experts, executives), who are never asked to read code.
The eleven phases of the Maleus ADLC
The Maleus ADLC unfolds in three stages:
1. Scoping: digging into the need
Everything starts with a scoping workshop, where the user expresses the need. The goal is to dig deep into it: who the users are (the personas), which paths they follow through the application (the user flows), which business rules apply. The outcome is a functional and technical specification, along with a visual prototype.
The user needs no technical skills: they talk about their business, their rules, their pain points. The workshop is what turns that need into a functional and technical specification.
The user approves the specification and the prototype: this is the first human approval of the lifecycle, the one that sets what will be built.
2. Splitting into versions: a budget decision
Once the specification is approved, Maleus splits every feature to build into several versions, gathered in a roadmap.
Every version is priced before it is launched, so the split becomes a genuine budget decision, in the user's hands.
The cost of the project is known before anything is launched: each version is estimated in tokens and in time, and the user decides how far to go knowing the price.
The user approves the roadmap and decides to launch all or some of the versions: this is the second human approval of the lifecycle, the one that sets the budget.
This phase matters a great deal: splitting a project well gives the implementation its meaning, but above all it keeps the agents' context under control, since they work version by version on a narrow scope, which prevents hallucinations and bugs during implementation.
3. Detailed specifications: spec-driven development
For each version, Maleus enters its development cycle. The first step is to generate the detailed functional and technical specifications, in a specification format of Maleus's own:
These detailed specifications then frame all of the agents' work. This is spec-driven development: the agents implement what is specified, and the acceptance tests define what "done" means.
4. The implementation plan: deciding before coding
Before writing a single line of code, Maleus drafts a complete implementation plan, for the front end as well as the back end.
The plan describes everything that has to be built and, above all, every test that will have to be written. Tests are not added as an afterthought: they are planned from the start, based on the specifications and their acceptance tests.
5. The front end first, with its tests
From the specifications and the prototype approved during scoping, Maleus first builds the visible part of the application: every screen, every interaction. One agent writes the code, then a second agent writes every test planned in the plan.
These tests replay the users' journeys in a real browser, the way a person would: clicking a button, opening a window, filling in a form, sorting a table. Other, lighter tests check the logic behind each screen, so nearly all of the code is covered.
They are written before the back end even exists: the tests describe what the application must do before it knows how to do it.
6. The back end: business logic and its tests
An agent then writes the whole server side: the business rules, the data and how the application stores it.
Next, Maleus writes the back-end tests, which check every server function all the way to what actually gets stored, then every business rule, one by one.
In total, four families of tests cover the application, from the user's click down to the stored data, and all of them are planned from the implementation plan on.
7. Reconciliation: wiring the front to the back
The front end and the back end were built separately, so now they have to be connected. Maleus automatically generates, from the back end, the code that lets the front end talk to it, then checks that every action in the interface matches a function that really exists on the server, so no button can ever call a function that does not exist.
8. Running the tests and fixing
An agent then runs every test: first the front end's end-to-end tests, then all of the back-end tests. When a test fails, the agent does not simply make it pass: it goes back to the specifications, which are the source of truth, to decide whether the code or the test needs fixing. Once everything is green, the version's development phase is complete.
9. Three reviews before the version is approved
A review phase then begins, in three passes:
Maleus fixes the issues found, commits, and moves on to the next version once this one is implemented, all automatically.
10. Acceptance testing: commenting out loud while browsing
Once every version is implemented, the user runs acceptance testing. The application runs in a development environment, right inside Maleus.
They can leave comments and screenshots on the application, but above all they can simply talk: they browse the application while speaking, and their comments are attached to wherever they are. Maleus knows at which point in the navigation each comment was made, which makes acceptance testing much smoother.
All of these comments are sent to Maleus, which creates a version to fix them, through the same lifecycle described above.
11. Deployment and operations
Once acceptance testing is satisfactory, the latest version is deployed to two environments: staging, then production. These environments can be hosted directly in Maleus, or on the customer's side, in an external environment they manage. This is the run phase, and it is equipped too:
Every bug report and piece of user feedback lands in the Maleus project. There, it can be handled with the usual lifecycle: workshop, versions, and the full development cycle.
Where humans stay in control
Human interventions are designed for non-technical people (talking about the need, approving a roadmap, testing an application by commenting on it), while the whole technical side is automatic.
Between the split and acceptance testing, the specifications, the plan, the tests, the reconciliation and the three reviews are what frame the agents' work.
In summary
The Maleus Agentic Development Lifecycle is in-depth scoping, a split into priced versions, then for each version an automatic cycle of specifications, planning, development, testing and reviews. Acceptance testing and operations close the loop, since every piece of feedback can become a new version: this is our way of doing vibe engineering.
It is also what lets Maleus chain hundreds of hours of autonomous work without drifting, then iterate without breaking anything, since every new version goes back through the same specifications, the same tests and the same reviews.