Most teams «using AI» are still optimizing prompts, one at a time. I think that’s the wrong problem. Here is how I build and lead engineering teams where AI is part of how the work gets done, not a sidekick sitting next to it.
Why chat has a low ceiling
The industry has largely settled on the chat box as the way to work with AI. It feels productive: you ask, it answers. But as a way to run real engineering work, it has a low ceiling. It’s slow, it hallucinates when the context is thin, and it doesn’t scale to the multi-step, standards-bound work an enterprise team actually does. Worse, every engineer reinvents their own prompts and none of it is shared or repeatable. That’s not an operating model. It’s individual luck with extra steps.
From optimizing prompts to engineering context
The shift that changed everything for me was to stop optimizing prompts and start engineering context. The interesting question isn’t «what’s the perfect prompt for this task». It’s «what context would make thousands of those prompts unnecessary». When the AI already has the business rules, the constraints and the definition of done in front of it, the prompt almost writes itself, and the output is something you can trust without babysitting it.
Specs & Skills
I structure that context into two reusable assets.
Specs are the agreed definition of what «good» looks like: business rules, architectural constraints and acceptance criteria, captured before implementation and reviewed by a human. Written once, reused across features.
Skills are the reusable capabilities the AI executes with: modular, repeatable patterns for the recurring work of creating a PR, transitioning a ticket, scaffolding tests, reviewing code against our standards. Not one person’s clever trick, but a team asset anyone can invoke.
Together they turn AI-assisted delivery from «whoever is good with the tools» into how the team works by default.
What this means for how I lead
This is where the numbers show up. Working this way, we cut engineering cycle time from 4d 2h to 2d 6h, with no new hires and no crunch. But the deeper change is about leverage. When producing correct code gets cheap, the scarce skill moves up a level: knowing which problem is worth solving and what «good» even means. My job as a leader becomes less about unblocking and shipping, and more about engineering the systems, the specs, the skills, the standards, that the whole team operates inside.
Treat AI as reliable infrastructure rather than a chatbot, and it stops being a productivity trick for individuals and becomes how the organization runs.
That’s the shift I’m building for. If your team is thinking about the same thing, let’s talk.