How we work

Spec-driven, not vibe-coded

Everyone uses AI now. The difference lies in where in the development process it is applied, and in what a human still owns. That determines both how fast it goes and whether the result holds.

Vibe coding applies AI where the writing happens. RAID applies AI where coverage is required, and concentrates human time on the one thing AI should not own: the decisions.

What RAID is

Process and principles, supported by AI

RAID stands for Rebtech AI Data Engineering. It is our own framework for building, migrating and maintaining data platforms with AI throughout the work, built on two decades of experience constructing data platforms.

We use AI for more than writing code: it runs through the whole of the work, from planning, requirements and architecture to testing, documentation and deployment.

Code development is one of twelve steps in a platform project. Vibe coding applies AI there and does the other eleven as before. We apply AI in eleven of twelve, with a human reviewing every step. The time sits in those eleven steps, and that is where coverage decides whether the platform holds.

01

The method comes with the engagement

RAID is how we carry out the engagement with the help of AI. What gets built is yours, and you can maintain it further on your own.

02

Spec-driven

Everything is mapped and specified before the code is written. The specification is what gets reviewed and approved; the code follows from it. That is why the result can be reviewed afterwards.

03

The human owns the decisions

AI does the work, an experienced developer reviews and approves every step. Every approval can be tied to a person who stood behind it.

04

Platform independent

Snowflake, Databricks and Microsoft Fabric. The method is the same; the platform is chosen for your goals, your architecture and your regulatory requirements.

What decides is where in the process AI is applied. The rest of this page shows exactly where.

One engagement, three methods

What the difference actually came to

We costed a real migration engagement three times over, with the same team of five and the same quality requirements. The only thing that varied was the method.

Traditional development
13.5 months
calendar time
8,050 h
human hours

All twelve steps are done by hand. The mapping therefore stretches to a sample.

Vibe coding
5.5 months
calendar time
4,200 h
human hours

AI writes code. The steps before and after the coding are done as before.

RAID, spec-driven AI
2.5 months
calendar time
900 h
human hours

AI throughout the process, reviewed at every step. The human owns the decisions.

16 source systems · 100% report correctness as a contractual requirement · the same team of five in all three scenarios

Twelve steps

Where AI is applied, step by step

A data platform project consists of twelve steps. The table shows who does what in each method. The difference lies in the coverage.

NoStepRAIDVibe codingTraditional
01Requirements and current-state analysisAI + reviewManual, shallowManual
02Architecture and target pictureAI + reviewManual, shallowManual
03Plan and work breakdownAI + reviewManual, shallowManual
04Test and validation designAI + reviewLate, improvisedManual
05Data migrationAI + reviewLate, improvisedManual
06Code developmentAIAIManual
07Code reviewAI + reviewManualManual
08Testing and validationAI + reviewLate, improvisedManual
09Documentation and decision logAILate, improvisedManual
10Approval gates and evidenceManualLate, improvisedManual
11Deployment and cutoverAI + reviewManualManual
12Handover and maintenanceAI + reviewLate, improvisedManual
1 of 12
steps where vibe coding uses AI
11 of 12
steps where we use AI, each time with a human reviewing and approving
The labels

What the five modes mean

AI + review
AI performs the step in full. An experienced developer reviews and approves the result before the next step begins. This is where both the speed and the quality come from.
AI
AI performs the step, and the result is reviewed in a later step rather than separately. This applies to code development and documentation, where the next step is the review.
Manual
A human does the whole step. With us that applies to one step out of twelve, and it is a deliberate choice.
Manual, shallow
The step is done by hand and therefore stretches to a sample within a reasonable budget. That is where the late surprises are born.
Late, improvised
The step arises when something goes wrong, and is then done under time pressure by whoever happens to be available. The cost shows up in the calendar rather than in the quote.
Why coverage decides

The time saving comes out of the coverage

Code development is the only step where vibe coding and RAID do the same thing. Yet more than three thousand hours separate the methods. The explanation lies in the other eleven steps.

A manual current-state analysis stretches to a sample within a reasonable budget. Outside that sample sit the pipelines that are dead but still deployed, the key that looks unique but holds duplicates, and the history that exists only in the old solution. Each of them surfaces later in the project, when it costs many times more to handle.

With AI, exhaustive becomes possible, because AI reads everything and the human reads the conclusion. The faults are found before they have time to cost anything, and it is that cost which disappears.

It is also why we can quote a fixed price. When the current state is known, the risk is known, and then it does not need to be priced with a margin.

Step 10

The one step a human always does alone

The approval gates and the evidence are entirely manual with us, and will remain so. Someone should be able to say that they approved this, for these reasons, on this basis. An approval belongs together with a person who stands behind it.

It is the same principle that makes the result reviewable in all the other steps. AI does the work, a human decides whether it is good enough.

Metadata
the work is based on code, configuration, schemas and run logs
Your environment
where data values need to be read, it happens in your environment, per what you approved at start-up
A basis
that your security function can take a position on, provided before the engagement starts
Next step

See the method used in a real engagement

The figures above come from an actual migration engagement. The case describes what really happened.

01

Read the migration case

16 source systems, 187 dead pipelines, and what the mapping revealed.

To the case →02

Download the whitepaper

The whole method described, step by step. No form.

Download →03

Book twenty minutes

A conversation about your situation. We listen more than we present.

Book a meeting →