SFS | #2: Engineering Field Notes

A few months ago, one of our customers spoke to us about an application they needed to improve one of their workflows, and we agreed we would do it for them. Now, while it was useful to them, it was not core to what we do, so it kept getting pushed down the priority list.

When we finally sat down to talk about it, the engineering team suggested giving it to some interns working with us. The estimate was at least three months for their team of 5 to build it traditionally. Based on my experience with software development estimates, I knew it would likely take up to 1.5 times as long as promised.

I decided to build it myself using AI (Claude Code).

Be the smartest person in the room. 1440 navigates 100+ sources to deliver a comprehensive, unbiased news roundup — politics, business, culture, and more — in a quick, 5-minute read. Completely free, completely factual.

Sign up now!

One month later, the application was production-ready. That is not the interesting part of the story.

The interesting part is what happened in between. The core application itself was ready by the first week. But then it had to move through our normal development process.

Once we started the code review, QA testing, and user acceptance testing cycles, that is when things slowed down for three weeks. This was not because the team was doing anything wrong, but because the process was built for a different pace.

We already had a hybrid review setup, AI code review running alongside human review. We put that in place last year because we saw the AI evolution coming and wanted to keep up with it. But even with that, the volume of code I produced in a week was more than the review process could comfortably absorb, given other products constantly flowing through the same process.

Some of these other products were also being developed with AI assistance, further compounding the overall volume and speed of code production. The gate that used to work fine had become the constraint.

What I realised, standing there watching everything play out was something simple: when you make one part of the process faster, you do not make the whole thing faster. You make the next constraint visible. And then you have to go fix that too.

This is not a Seamfix-specific observation. I later came across an article from Agoda's engineering team describing exactly this pattern: faster coding at the individual level, but modest delivery gains at the project level, because coding was never where the time was actually going.

If you do some research, you will quickly realise that it is playing out the same way across the industry.

For us, it means QA has to move toward AI-assisted testing at the same pace that development has moved toward AI-assisted coding. Same thing for Product Management, DevOps, and all other aspects of the software delivery lifecycle. The whole pipeline has to evolve together and quickly, not just the part that was easiest to change first.

Going to the shop floor taught me that. You cannot see it from a meeting room.

How are you applying AI in your work today? Are you seeing real productivity from a results perspective?

Whenever you're ready, there are 3 ways I can help you: