The fourth and fifth stack
Rolling LLMKIT out across the team, the real test wasn’t the first stack. It was the fourth and the fifth.
The easy version
It’s easy to build tooling that works beautifully for the stack you know best. You know its conventions, you know where it hurts, and you test it against the codebase you work in every day. The result feels finished — until someone on another stack tries it.
What five stacks actually means
COE UI’s three sub-teams work across Angular, Ionic, Flutter/FlutterFlow, native iOS and native Android. They differ in more than language:
- Different conventions — project structure, patterns and tooling vary stack by stack.
- Different pain points — what slows down a native Android engineer isn’t what slows down an Angular one.
- Different comfort levels with AI-assisted development in the first place.
The bar LLMKIT had to clear
Three requirements came out of that:
- Install cleanly on all five. Not “works on mine, mostly works elsewhere.”
- Respect each stack’s idioms. The kit adapts to the stack, not the other way round.
- Still feel like one system. Five bolted-together tools would defeat the point of sharing practices across the team.
How we got there
Getting that right meant a lot of back-and-forth with our sub-team leads — testing, breaking things, testing again — before LLMKIT felt like something the whole COE UI team would actually want to use, rather than something they would tolerate.
That distinction matters. Tooling people tolerate gets used when someone is watching. Tooling people want gets used on a deadline, which is the only time it really counts.