When I started using AI-assisted delivery in my recent project, I expected the biggest challenge would be learning how to get better results from models. Like many developers experimenting with AI, I was focused on the obvious questions: which model produces the best output, how detailed specifications should be, and how much of the delivery workflow could be accelerated through AI.
Around the same time, Microsoft’s changes to token billing made something that had previously felt invisible suddenly much more tangible. AI usage was no longer just about choosing a capable model; every decision around context, tooling, and workflow had an associated cost. That changed the way I looked at AI-assisted development.
The question was no longer only, “Can AI help me do this faster?” It became, “Am I using AI in the most effective way?”
Modern AI development feels incredibly powerful. Models can connect to repositories, design tools, project management systems, and documentation through MCP. They can reason over specifications, generate implementations, review code, and assist across almost every stage of delivery.
But every new capability introduces a trade-off. The more we try to make AI understand, the more we have to think about what we give it, how we give it, and whether the additional context is actually improving the outcome.
The Hidden Price of Context
MCP has been one of the most exciting developments in the AI ecosystem because it brings models closer to the tools we already use every day. Instead of manually moving information between systems, AI can interact directly with parts of the engineering workflow.
The natural instinct is to connect everything. If the model knows more about the project, shouldn’t it make better decisions? Often, yes.
But every connection also introduces additional context: tool definitions, schemas, instructions, permissions, and available resources that the model needs to understand before it can solve the actual problem. Individually, these additions seem small. In a real project with multiple integrations, they accumulate quickly.
The Figma MCP experience made this especially clear for me. Being able to ask questions directly about designs feels almost futuristic. Instead of manually searching through frames, components, and variants, the model can help navigate a design system and explain how different pieces fit together.
The challenge is that design files contain much more information than the final question usually requires. A simple question about one component may require understanding the broader design structure, naming conventions, relationships, and variations first. The answer might be small, but the context required to produce that answer can be significant.
The same trade-off appears with Atlassian MCP. Turning conversations into Jira tasks sounds like an obvious automation opportunity, and sometimes it is. AI can transform discussions into structured tickets, add acceptance criteria, and remove repetitive work.
But sometimes creating the ticket was never the difficult part. The difficult part was understanding what should become a task, what priority it deserved, what constraints mattered, and what details should intentionally be left out.
The same applies to GitHub MCP and AI-assisted pull request reviews. AI can quickly identify potential issues, suggest improvements, and highlight missing tests. However, understanding whether a change is actually correct often requires understanding why the change was made in the first place.
The lesson was not that MCP creates unnecessary complexity. The lesson was that context has become an engineering resource. Just like compute, memory, or infrastructure, it needs to be managed intentionally.
When the Cheaper Model Becomes the Expensive Choice
A common AI development pattern is to use high-end models for research, architecture, and complex reasoning, then switch to smaller and cheaper models for implementation.
This approach makes sense. A stronger model can help establish direction, understand unfamiliar problems, and identify risks. A smaller model can then execute well-defined work efficiently.
In many cases, this workflow works extremely well. The interesting moments are when the problem is not as clearly defined as we think.
I have seen lower-cost models produce answers that looked completely reasonable but were based on one incorrect assumption. The difficult hallucinations are not the obvious ones that immediately look wrong. They are the ones that sound convincing, generate working code, and only reveal themselves after hours of debugging.
By the time the issue becomes clear, the supposedly cheaper approach may have consumed more tokens through repeated attempts, more context through longer conversations, and more engineering time through investigation.
Below is an example where the model (Claude Sonnet 4.6) confidently hallucinated and fabricated information that didn’t even exist:
That made me question how we measure AI cost. We often focus on the cost per request or cost per million tokens, but that does not always represent the real cost of delivery. A more expensive model that reaches the right solution quickly may consume fewer resources overall than a cheaper model that takes the team down the wrong path. The cheapest model is not always the cheapest solution. The real metric is closer to the cost of reaching the correct outcome.
Specifications Help, But They Do Not Replace Thinking
Specification-driven development has become an important part of my AI-assisted workflow because it genuinely improves results.
Clear requirements, constraints, expected behaviours, and edge cases provide models with a much stronger foundation. They reduce ambiguity and create better alignment before implementation begins.
However, specifications are not magic. They cannot resolve unclear requirements. They cannot identify constraints that nobody has considered. They cannot replace conversations where teams are still figuring out what problem they are actually solving. A detailed specification can still describe the wrong problem very accurately.
I have seen AI generate implementations that were technically excellent, cleanly written, and completely aligned with the specification, only for us to realise later that the specification itself needed more thought.
The implementation was not the problem. The thinking before implementation was. AI is incredibly good at executing a clear direction. It is still up to humans to define the right direction.
The New Engineering Skill: Managing the AI Workflow
One of the most unexpected parts of AI-assisted delivery is that optimisation happens continuously while working. It is not just about choosing a model at the start of a task. It is about managing context, conversations, and cost throughout the entire workflow.
Long conversations accumulate information that may no longer be useful. Sometimes continuing the same chat helps because the model understands the history. Sometimes starting a fresh conversation produces better reasoning. Sometimes compaction preserves important context, while other times reducing context removes the noise that was affecting the response.
The same decisions appear throughout development. How much repository context is actually needed? Which files matter? Does this task require deeper reasoning? Is another MCP connection adding value or just increasing complexity? These decisions have quietly become part of everyday engineering.
AI Made Implementation Faster, Not Engineering Simpler
The more I use AI-assisted delivery, the more I realise that AI has not removed engineering complexity. It has simply moved it to different places. Previously, we spent most of our time thinking about infrastructure, databases, performance, and compute. Now we also think about models, tokens, context, and reasoning effort.
The best AI workflow is not the one with the most tools, the biggest context window, or the most powerful model. It is the one that uses the right amount of intelligence for the problem at hand. AI has definitely made building things faster.
But building faster is only part of the story. The hard part is still understanding the problem, working within constraints, and making good trade-offs. AI can help write the code, but deciding what to build and how to build it remains an engineering skill.
