How to plan a migration you cannot pause
The single, all-at-once cutover is popular because it is easy to describe and easy to schedule. It is also the version where you find out whether it worked at the moment you can least afford to be wrong.
AI software development consultancy
We write 100% of our code with AI, and a large eval suite has to prove every change before it is released. That suite is now graded by Jev, a decision model, and runs ten times faster than it did with a language model as the grader. Your product can launch in weeks instead of months, and the speed does not lower the quality. We use AI instead of hiring a bigger team, and that saving goes into your price.
Need engineers inside your own systems? Forward deployed engineersEvery line of code we deliver is written by AI. Every change has to pass a large eval suite before it is released, and since we made Jev the grader that suite runs ten times faster. We use AI instead of hiring more people, and the saving goes into your price. Those three sentences describe the whole company.
4-8weeks
A first version in front of real customers
2-5weeks
An internal tool that removes a manual step
6-10weeks
An AI agent handling live traffic
100%
Of released changes pass an eval suite first
These are the timelines we commit to when we plan a project. They are targets. Reveneau is new and has no past projects to average yet. We would rather say that than publish a number when we cannot show you how we calculated it.
AI writes the code in our projects. Most of the time goes into the two steps around it: deciding exactly what to build, and proving that the finished software works. Our five phases are planned around those two steps.
We write a detailed description of what the software must do, detailed enough for AI to write the code from it. It is longer than a normal requirements document. Every later step depends on it, so it gets the most time.
AI writes the code from that description, in small pieces you can open and try on the same day. This step is quick, so it no longer sets the length of the project.
Every change must pass a set of automated tests, written from the description, before it is added to your code. Code that no test has checked costs more to fix later than it saved when it was written.
We test load, security, monitoring, and what happens when parts of the system fail. AI usually gets the normal use of the software right on the first try and often misses the unusual cases, so we add those here.
We keep supporting the software after release. A fast first version has little value if it stops working in its second week in production.
On its own, no. The first draft is usually right about the main path and incomplete about everything else: the error cases, the race conditions, the input nobody expected. The evals exist to find those missing cases. We write the checks from the specification before the code exists, so a change either proves it does what was asked or it is not released. What changes is where the engineering time goes. Almost none of it is spent typing, and almost all of it is spent on the specification at the start and on the ways the code can fail afterwards.
Us, and you will get a direct answer from us. Every change we release has to pass an eval suite written from the specification, so the failures that can reach you at 2am are a smaller and better understood set than they would be otherwise. When one does, you call us and we fix it. You cannot send a complaint to an AI model, so our answer is never that the AI wrote it.
That is the point of working this way. A traditional agency goes faster by putting more people on your project, and you pay for every one of them. We go faster by generating the code, so the same build needs a small team instead of a large one. We price the work on what it actually takes us to deliver, so the saving goes to you instead of into our profit. Ask any supplier to explain their price the same way and see what you get back.
That is the goal we design for. The code follows your conventions, and we deliver it with the specification it was generated from, so your team can read what the code is meant to do as well as the code itself. If your engineers cannot take over a build, you would need us to keep running it, and we count that as a failure.
It is a fair question, and the honest answer is that it needs a clear process. We can run the output through provenance and licence scanning as part of the release checks, and we will tell you which models produced which parts of a build if you need that on record. If your legal position rules out generated code entirely, we are the wrong supplier and we will say so on the first call.
It will, at some point, because a check can only catch a rule someone thought to write down. That is why the suite is not the whole answer: when a gap reaches production, we treat it the same way any accountable team should, by fixing the defect, then writing the eval that would have caught it so the same fault cannot return. The suite gives no guarantee. Each fault we fix adds a check, so the suite only ever gets stricter.
Jev is a decision model from TypeSafe AI, released in September 2026. It does not write text. You give it the evidence and a set of yes-or-no or scored questions, and it returns a probability for each one in a fraction of a second. Our eval suite already had deterministic checks, and those still run as before. The checks that used to need a language model to read a change and judge it against an acceptance criterion are now Jev questions, with the rubric written into the criteria. That is why the same suite now runs ten times faster on every change. A grade in the uncertain band still goes to a person, and we keep that person's answer to re-check the grader.
How we grade evals with JevThe specification changes and the evals change with it, which is a smaller event here than in most delivery models. Because the checks describe the requirement rather than one particular piece of code, we can update a check and have the AI agent change the code until it passes again, and that is fast. What takes real time is still the conversation about what should change and why, so we count that discussion as part of the work itself.
Yes. That is our forward deployed engineering service. Senior engineers join your team and work in your own code, on your real data, and through your own release process. They stay until the system runs in production. Before we start, we agree two dates in the contract: the date it goes live for real users, and the date your engineers take it over from us. Every change still has to pass the eval suite first.
How forward deployed engineering worksWith scoping, before any code gets written. We spend the first part of an engagement turning your goal into a specification precise enough to test, because that is the step where most projects go wrong. Then we agree the checks that the first release must pass, and start building against them. You see working software early, and every version you see has already passed the checks that matter.
How to plan a migration you cannot pause
The single, all-at-once cutover is popular because it is easy to describe and easy to schedule. It is also the version where you find out whether it worked at the moment you can least afford to be wrong.
An AI agent that passes a test once can fail it on the next run
The same agent on the same task passes on some runs and fails on others, and the tau-bench paper of 2024 measured by how much. Run each test case several times and report the share of tasks that passed every run.
Why flaky tests are worse when agents write them
A flaky test used to cost a rerun and some irritation. When an agent is reading the result to decide whether it is finished, an unreliable check becomes an unreliable instruction.
What are you trying to build?
Tell us the problem and the deadline. We will tell you on the first call whether we are the right people for it.