Spec-driven development is not just a development topic. The critical point lies in analysis and documentation, at the very start: if the specification is not mature and standardized, the rest of the pipeline does not work, with or without a coding agent.
That is why the consulting starts with analysis, not with code. We design the process with your team, apply it on a real project and leave the method written down in the repository. The effect shows up where management can see it: more deliveries, fewer bugs coming back and less rework, measured before and after.
Licenses bought, everyone using them, and nobody can show how much the team gained. With no measured starting point, the gain stays an impression.
In practiceWe measure against the estimate: a portal planned for 3 months shipped in 1.
More code comes out in less time, and more bugs come back. When the specification arrives vague, the agent returns guesses, and rework grows.
In practiceThat same portal shipped 3x faster, with bugs below 1% per feature.
Deliveries run late and lead time does not drop, even with AI. One developer generates whole modules, another only autocompletes: with no common rule, delivery depends on who asked, not on the process.
In practiceAn ERP-sized system, planned for 8 months with 4 devs, shipped in 6 months with 3.
Everyone learns alone, by trial and error, and nobody knows which requests should go to AI and which should not.
We started using AI to generate code on simpler projects.
In the first months of Lovable we were already vibe coding. That is when we understood that quality and security would require an AI agent of our own.
As the models evolved, we expanded the use to every project, including complex ones, apps and legacy systems.
Several projects in production, 100% spec-driven, with proven quality and test coverage.
At DB1 Itênex, projects are developed spec-driven and with our own agents, whether web, app, legacy or complex.
The gain comes from people who know where the agent speeds things up, where it gets things wrong and where the decision has to be a person's, and who teach that to your team.
Since 2024 we have applied AI on real projects, from the simplest to legacy and complex ones. What worked became a method, and the people who lead it with your team are the ones who built it, in your repository, not in a lab.
The consulting has a defined timeline and deliverables at each stage, not allocated hours. What counts at the end is the progress measured against your team's starting point.
Cycle indicators and telemetry so your management can follow the team's performance: deliveries, lead time, returned bugs and rework. The result stops being an impression and becomes data.
Training on the real project, side by side: roles, rituals, documentation and specification standards. When the consulting leaves, your team runs the cycle.
The method works with the coding agent your team already uses. When it makes sense, we bring Clovis Agentic, our own tooling, to orchestrate the work.
Each stage has a defined format, duration and deliverables. The final schedule is set at kick-off, with the calendars of the key people on your team.
Tailored workloadOn site or live remote
What happens
What you keep
1 day with your team, delivered in 7 daysOn site recommended
What happens
What you keep
1 week2 days on site and 3 remote, in pair programming
What happens
What you keep
Within the total periodMeasurement and follow-up
What happens
What you keep
Between the Assessment and Put it to work there is a window for your team: adapting the documentation and specifying the pilot feature in the new standard. It can take 30 days or more and depends on your pace, not on the consulting.
It is the technique the consulting puts in place: each stage run by agents with their own context, producing the input for the next one, and nothing moves forward without the approval of whoever answers for the result.
Three real projects run with the same method, from a portal to an ERP-sized system. The estimate shrank because the way of working changed.
BRK is a named case. The other two are anonymized. Bars proportional to each project's duration.
The speed did not come from loosening supervision. It came from clearing away the context work, which is what eats up the time of the people who decide.
26 years of critical software engineering, with a process audited by outsiders.
A development cycle redesigned and working on your real project: stages, roles, human gates, documentation and specification standards, and the Harness for your context. All versioned in your repository, with your team trained to run it alone and the result measured against the baseline.
From 60 to 90 days, in four stages: Training (with a tailored workload), Assessment (1 day with your team, delivered in 7 days), Put it to work (1 week) and Results. Between the assessment and the pilot there is a window for your team to adapt the documentation, which can take 30 days or more. The final schedule is set at kick-off.
No. The consulting works on a delivery that is already in your backlog. The pilot is real work, done with the new method, side by side with our team.
Not to start. Many teams do not have a formal analysis stage, and that is exactly what the assessment shows. The action plan defines who takes on analysis and validation in each role, with the team you already have.
It is one of the most common scenarios. The drop usually comes from vague specifications and from each person using AI in a different way. The method puts the specification before the code, with test scenarios and human review at every stage, and we measure returned bugs before and after to show the difference. On a portal we delivered 3x faster than planned, bugs stayed below 1% per feature.
That is the goal, and it is measured. Low performance usually comes from specifications that arrive incomplete, from rework and from uneven use of AI. In the assessment we measure your team's deliveries per month and lead time; after the rollout we measure again and show the progress, without promising a number beforehand. As a reference: on an ERP-sized system, planned for 8 months with 4 devs, we delivered in 6 months with 3.
No. Not every request should move. In the assessment we separate the types of request that pay off with agents from those that remain better the current way, and we choose the pilot from there.
In the assessment we collect an indicator baseline: deliveries per month, open PRs, returned bugs and lead time. In the Results stage we measure the same indicators again and deliver the before-and-after comparison, with the new bottlenecks that showed up.
No. The method works with the coding agent your team already uses. When it makes sense, our team uses Clovis Agentic to orchestrate the work, and you decide whether it stays afterwards.
That is where the method pays off the most. Discovery reads the legacy code, separates business rules from defects and escalates to whoever decides anything the evidence cannot resolve, instead of copying or silently fixing it.
The agents operate within the Harness boundaries defined for your context, with SAST/DAST before every merge and an auditable trail up to the approver. Process certified CMMI DEV/3, ISO 9001 and ISO/IEC 27001.
