Singapore Airlines: a website feature in five weeks, down from nine

Singapore Airlines shipped a new website feature in five weeks instead of nine after jacking GitHub Copilot into the software development lifecycle. Around 95% of the code, documentation, architecture diagrams, and infrastructure as code was AI-generated, build success passed 90% within three weeks, and effort and time cost fell by more than 60%. I was one of the fixers on the ground for this run, which the Microsoft megacorp later featured, and the part worth writing down is why it was repeatable rather than a lucky one-off. Preem numbers only matter if the crew can hit them twice.

What actually changed in the five weeks?

The headline is the timeline, but the timeline is a symptom. What changed was where the engineering effort went. Instead of the crew hand-writing boilerplate, scaffolding, and the first draft of documentation, AI generated those and the engineers spent their time reviewing, correcting, and deciding. The crew did not work faster by typing faster. They worked faster by moving up a level: from authoring to directing, like a netrunner steering the rig instead of soldering it.

That distinction matters because it is the difference between a productivity blip and a new operating model. A feature that used to take nine weeks compressed to five not because the crew cut corners, but because the slow, low-judgement parts of delivery stopped being done by hand. That is nova, and it holds.

Why was 95% AI-generated not a quality problem?

A number like 95% usually triggers a fair worry: if the machine wrote almost everything, who is accountable for it being correct? The answer is that build success crossing 90% inside three weeks was the quality signal, not a separate concern. The crew wired guardrails into the loop like ICE around a vault, so generated code had to pass the same gates as anything else: tests, build, review.

AI generation without those gates would have produced a fast pile of plausible code, a gonk move dressed up as speed. AI generation behind the ICE produced a fast pile of code that compiled, ran, and held up. The percentage is impressive, but the build success rate is the number that should keep an engineering leader from flatlining over risk.

What made it repeatable rather than a one-off?

Most flashy AI demos do not survive contact with the next crew. This one did, because the work was not a hero netrunner flexing chrome with a clever prompt. It was a method: role-specific practice on the team’s own codebase, guardrails wired into CI as standing ICE, and the lifecycle treated as one rig rather than a code-completion add-on. That is the same approach I cover in enablement and training and in how I think about AI deployment.

Three things made the result portable. First, the training used real Singapore Airlines work, not toy exercises, so the habits transferred straight into the crew. Second, the guardrails were crew-owned, so quality did not hang on any one choom remembering to check. Third, the whole lifecycle (docs, diagrams, infrastructure as code, application code) was in scope, so the gains were not bottlenecked by one slow manual stage downstream.

The full write-up of the engagement, including the figures and the Microsoft collaboration, is in this Singapore Airlines case study, and the talk itself sits on my speaking page. If you are weighing whether 2-3x is realistic for your own crews, the honest answer is that it depends less on the model and more on whether you rewire how delivery is structured. The model is the easy part, the cheap chrome. The method is the work, and it is where the eddies are.