Singapore Airlines: a website feature in five weeks, down from nine
Embedding GitHub Copilot across Singapore Airlines' delivery lifecycle cut a feature from nine weeks to five, with 95% of the work AI-generated and effort down 60%.
Singapore Airlines shipped a new website feature in five weeks instead of nine after embedding GitHub Copilot across 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 trainers on the ground for this work, which Microsoft later featured, and the part worth writing down is why it was repeatable rather than a lucky one-off.
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 people hand-writing boilerplate, scaffolding, and the first draft of documentation, AI generated those and engineers spent their time reviewing, correcting, and deciding. The team did not work faster by typing faster. They worked faster by moving up a level: from authoring to directing.
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 team cut corners, but because the slow, low-judgement parts of delivery stopped being done by hand.
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 team built guardrails into the loop so that 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. AI generation behind the gates 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 reassure an engineering leader.
What made it repeatable rather than a one-off?
Most impressive AI demos do not survive contact with the next team. This one did, because the work was not a hero engineer with a clever prompt. It was a method: role-specific practice on the team’s own codebase, guardrails wired into CI, and the lifecycle treated as one system 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 directly. Second, the guardrails were team-owned, so quality did not depend on any one person 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 teams, the honest answer is that it depends less on the model and more on whether you change how delivery is structured. The model is the easy part. The method is the work.