After fifteen years of writing development tickets, I didn't expect the skill to become this relevant. But it turns out the craft that makes developers productive is the same craft that makes AI productive.
The Fifteen-Year Head Start I Didn't Know I Had
I've been a product manager for nearly fifteen years. In that time, the single most important skill I've developed isn't stakeholder management, roadmap prioritisation, or any of the things that make it onto LinkedIn profiles. It's the ability to distil a messy, ambiguous requirement into a clear, actionable ticket that a developer can pick up and run with.
A good ticket isn't a wishlist. It's context. It's the "why" behind the change, the constraints that matter, the edge cases that will bite you, the definition of done that everyone agrees on before the first line of code is written. Get the ticket right and the developer does great work. Get it wrong and you get technically correct code that solves the wrong problem.
I've been having this conversation a lot recently. Across disciplines. Marketers. Designers. Engineers. Product people. Some are getting remarkable results with AI. Others are struggling to get anything they'd call production-grade. And the more I listen, the more I think the gap isn't about which model they're using or how clever their prompts are.
It's about the context they're giving it. And more specifically, whether they have the craft to prepare that context in the first place.
The Greenfield Illusion
Here's the thing nobody talks about at AI conferences.
The demos are always greenfield. A blank canvas. "Watch me build an entire app from scratch in twenty minutes." And yes, that's genuinely impressive. AI is extraordinary at generating new code from a clean starting point with clear requirements.
But that's not where most of us work.
Most of us work on brownfield. Existing systems. Legacy code. Applications that have been running for years, accumulating technical debt, business rules encoded in obscure modules, and institutional knowledge buried in code comments from developers who left five years ago.
The moment you point AI at brownfield, everything changes. It doesn't know your coding conventions. It doesn't understand your architecture. It can't see the ripple effects of a change across a hundred interconnected modules. It doesn't know what your team considers a "good" function versus a pattern you've been actively trying to eliminate.
And if you just hand it a module and say "refactor this," you'll get something that looks clean but breaks assumptions that existed for very good reasons.
Where It Gets Really Hard
We have a product. A ten-year-old monolith. It's substantial: over a hundred modules, some with twenty thousand lines of code. It works. It serves customers. It makes money. And it's increasingly difficult to maintain.
This is the kind of codebase that makes AI adoption genuinely risky. Not because the AI isn't capable, but because the blast radius of a bad change is enormous. A refactored function that subtly changes behaviour in one module can cascade through dozens of others. The test coverage may not catch it. The developer reviewing the PR may not catch it either, because the original reason for the implementation might predate their time on the team.
For months, we'd been watching the AI conversation from the sidelines on this particular product. Too risky. Too complex. Too much context that only existed in people's heads.
Context Engineering in Practice
We decided to stop watching and start testing. But not by pointing an AI at the codebase and hoping for the best. We put the Context Engineering principle to work.
First, we reviewed our coding guidelines. Not the aspirational ones gathering dust in a Confluence page. The real ones. What does a well-structured function actually look like in this codebase? What patterns do we want to see? What patterns should never appear? What are the naming conventions, the error-handling expectations, the architectural principles that this specific team follows?
Then we codified them. Not as documentation for humans. As context for AI. Design principles. Code standards. Anti-patterns with explanations. Examples of good. Examples of bad. The accumulated wisdom of a decade of development, distilled into a form that an AI could use as its operating framework.
Then we pointed it at a single module.
It took over four hours to review. It consumed a significant number of tokens. But it produced something that was remarkably close to what we'd hoped for. Not perfect. But close enough that the gap between AI output and production-ready code was a fraction of what it would normally be.
Sixteen days of engineering time. Reduced to half a day.
The Number That Doesn't Matter (and Why It Matters Anyway)
Here's where I need to be honest. That module refactoring? No direct business value. The end user won't see a difference. The product won't gain a new feature. The sales team won't have a new talking point.
If you put this on a sprint board and asked "what's the ROI?", the honest answer is: there isn't one. Not immediately.
And yet it might be the most important piece of work we've done on that product in years.
Because what we proved isn't that AI can refactor code. We already knew that. What we proved is that with the right context, AI can work safely and effectively on a complex, legacy system that was previously considered too risky to touch.
That changes everything.
The Real Shift
The value isn't in the sixteen days we saved. It's in what we've unlocked.
Before this, our engineering team on that product was, like many teams working on legacy systems, largely in maintenance mode. Small, cautious changes. Incremental improvements. Careful not to break anything. Each sprint delivering modest value because the cost of change was so high.
With Context Engineering in place, the operating model shifts. The guidelines, the design principles, the codified understanding of what good looks like — once that context exists, it doesn't just work for one module. It works for all of them.
The team's role changes too. Instead of spending their time bashing out code and hoping it works, they become more clinical. They think about architecture. They think about design principles. They review AI output with an expert eye. They make the strategic decisions about what to change and why, while the AI handles the mechanical work of how.
That means the sprint goes from small incremental changes to genuinely powerful improvements every couple of weeks. Not because the team is working harder. Because the leverage has fundamentally changed.
Why Most People Struggle With This
Back to those conversations I've been having. The people who struggle with AI aren't struggling because the AI isn't good enough. They're struggling because they haven't developed the craft of context preparation.
Writing a good AI context document is remarkably similar to writing a good development ticket. You need to:
- Understand the domain deeply before describing it
- Be specific about constraints that aren't obvious
- Define what good looks like with concrete examples
- Anticipate edge cases the AI won't know about
- Provide the "why" not just the "what"
If you've spent fifteen years distilling messy requirements into clear tickets, you have a significant head start. If you haven't, it's a skill that can be learned. But it is a skill. It's not something you pick up by reading a blog post about prompt engineering.
This is why I think the emerging discipline of Context Engineering is real and important. It's not about fancy prompts. It's about deeply understanding the domain, the standards, the constraints, and the goals, and packaging that understanding in a way that makes AI genuinely productive.
Context as a Discipline
We wrote previously about Context-as-a-Service: the idea that the accumulated context within a system is becoming more valuable than the system's interface. This is the practical side of that argument.
Context Engineering is the discipline of building and maintaining that context layer. It's part product management, part technical writing, part architecture, part domain expertise. It requires the kind of person who can sit between the business and the technology and translate fluently in both directions.
It's not glamorous work. Nobody's going to do a TED talk about reviewing coding guidelines. But it's the work that makes the difference between AI that produces impressive demos and AI that produces production-grade results on real systems.
What We're Doing Next
That single module was the proof of concept. Now we're scaling the approach across the product.
Every module gets the same treatment. Guidelines reviewed and codified. Design principles established. Context prepared. Then AI-assisted refactoring, reviewed by engineers who understand the system and can validate the output.
The goal isn't to replace the engineering team. It's to change what the engineering team spends its time on. Less mechanical coding. More architectural thinking. Less "get the feature out the door." More "build something that's genuinely well-designed and maintainable."
Sixteen days to half a day was the headline number. But the real story is a team that's moving from reactive maintenance to proactive engineering, enabled by context that makes AI safe to use on the hardest kind of code.
Working with legacy systems and wondering how to make AI useful on real codebases? Let's talk about what Context Engineering could look like for your team.