Daniele Ferrazzo turned a five-month roadmap item into shipped code in four weeks, using AI to move faster without lowering the review bar. Here's how he approached it, in his own words.
The project was scoped for five months, and you shipped it in four weeks. What was your mindset going in, and what did your day-to-day actually look like once you started?
Going in, I deliberately ignored the timeline and focused on the first concrete step: the analysis. I spent the first days understanding the feature, its impact on the existing flows, and breaking the work down into small, well-defined issues. That upfront investment shaped everything that followed, because from then on the question was never "what should I do next," only "how fast can I get through the list."
Once development started, a typical day was: pick the next issue, define the approach, implement it with Claude, verify it, open the pull request, and move to the next one while colleagues reviewed.
“That upfront investment shaped everything that followed.”
You used AI far more than usual during this project. Can you walk us through how it concretely changed the way you worked, not in theory, but what actually happened differently?
What AI really enables is working on more things in parallel, and what changed in this project was the scale of that. Over the past year I had already adapted and built workflows around AI, gradually becoming a sort of orchestrator and supervisor of what Claude produces. The speedrun was the first time I pushed that model to its limit.
After the initial analysis of the feature and its impact, I broke the work down into a tree of issues with explicit dependencies between them, structured so that as much of it as possible could run in parallel. Why not one big pull request? Because the work still had to be reviewed by colleagues, and many small PRs are far kinder to reviewers than a giant one. The workflow itself was an RPI loop, research, plan, implement, with two additions: quality gates, including a proper grilling of every plan before any code was written, and a human feedback loop, my own review.
In practice I would launch as many agents in parallel as the dependency tree allowed and keep giving them feedback until the output reached the quality bar. The result was that in a single sprint I opened around five times as many pull requests as I normally would.
“In a single sprint I opened around five times as many pull requests as I normally would.”
For four weeks you had one goal and nothing else. What does it feel like to work that way, and is it something you'd want to do again?
It was a really good way to work. Having one goal removes an invisible tax you only notice once it's gone: no switching between topics, no half-finished threads in your head, no "where was I?" every morning.
I would do it again, but I'd be honest about the cost, because it wasn't free for the team. My colleagues absorbed a significant extra review load on top of their normal work, and their own pull requests waited longer during those weeks. Until models can be trusted enough to remove the human feedback loop, there's a cost that gets absorbed by the reviewers, and that has to be part of the decision to work this way.
Looking back, what was the hardest moment of the four weeks, and how did you get past it?
There was no single dramatic moment, and that's almost the interesting part. The hardest part wasn't the coding. The pressure concentrated on the parts no tool can absorb: keeping quality high enough that pull requests would pass review, and getting everything to production. Development finished ahead of schedule, but a feature only counts when it's live, and the last stretch was spent getting everything released alongside what the rest of the team was shipping. The bottleneck of a speedrun isn't writing code, it's everything around it.
“The bottleneck of a speedrun isn't writing code, it's everything around it.”
Did you ever catch yourself trusting the AI a little too much, and what pulled you back?
Not really, because the workflow was built to keep me in control the whole time. Claude wrote a lot of the code, but I'm still the author of every pull request, and that responsibility doesn't transfer to a tool. I reviewed everything it produced before it went anywhere.
The system around me reinforced that. Every pull request still went through my colleagues' review, and the bar there stayed exactly where it always is. In payment flows there's no room for code nobody fully understands, so using AI heavily never meant trusting it blindly. It meant shifting my time from writing code to verifying it.
Can you give a sense of the technical environment you were working in at Satispay, the stack, the architecture, so someone reading this can picture what the project actually involved?
We run a microservices architecture on AWS. Compute is a mix of ECS, on its way to being decommissioned, and Kubernetes on EKS, with Lambda for serverless workloads and SNS and SQS for asynchronous communication between services. The services are built mainly in Java with Spring Boot, and on the data side we use PostgreSQL, DynamoDB, and Redis. The building blocks are very repeatable across services, which makes it easier to move fast once you understand the system.
The project involved reworking how two core payment flows are orchestrated. In practice that meant working across several services and changing how money-movement logic is coordinated, without anything breaking for users. That repeatability is also part of why AI worked so well: when services follow the same patterns, a well-instructed model can apply them reliably.
You joined Satispay straight from university in 2024. Would you say this project is representative of how engineers here are given responsibility, or was it an exception?
I'd say it's pretty representative. The work is definitely challenging, but that's exactly what makes it rewarding. From the start, you can have real impact and real ownership, you don't have to wait for it. What I find most satisfying is seeing how even a small change can have a significant effect on the end consumer. That's what makes it worth it.
