Over the last month, we’ve had lots of conversations with companies about their agentic engineering strategy. It’s clear that this has now entered the mainstream. The time for experiments and pilots is over.
To share some themes: the conversation has shifted from “is this even possible” to “how do I do this safely, without blowing the budget”. Whether it's achievable barely comes up anymore - it's taken as given.
The number one topic is token spend. For a short period of time, “tokenmaxxing” was worn as a badge of honour: “Look mum, I managed to spend $12,514 in tokens this month!”. Leaderboards were created to celebrate those who had spent the most.
This was, of course, ridiculous. Goodhart’s Law obviously applies, but even without that - rewarding effort and not outcomes is always a dangerous path. I can use more words than the next person - it doesn’t mean I’m right (much to my disappointment).
Ideally, we would be able to tie business outcomes - or at least productivity - to the AI spend. I expect this to become a core ask from management. Tooling and observability will need to evolve to match that demand.
In the meantime, here are some quick wins:
- Plan before you build. The plan is the map, not the territory. Use Plan Mode and Spec-Driven Development - agreeing a plan before you touch code. It's not just the ~50% token saving on reasoning-heavy work; a clear plan stops expensive vibe coding.
- Right-size the model. Default to a cheaper model like Sonnet, dropping to innovative open weight models for simple tasks - reserving the frontier models for genuinely hard problems. The cost difference isn't only around intelligence: models differ in how much code they emit for the same task, the tighter the model the better.
- Compact and clear deliberately. Run /compact at logical breakpoints and /clear between unrelated tasks so you're not dragging stale context (and its token cost) from one job into the next.
- Trim the context you carry into every prompt. Disable MCP servers you aren't using - each loads its full tool schema into every call (500–2,000 tokens), so a couple of idle ones quietly eat 5–10% of your window. (A .claudeignore helps here too in big repos, but it's a minor lever). Use markdown scratchpads for memory.
- Audit, don't guess. Use /context and /cost to see where tokens actually go, so spend tracks to work done rather than session length.
This stuff isn’t easy. Reach out to MISSION+ for specialist help.
Reflections On The Mission
When we ask a coding agent to start building, it will always generate something. Whether or not what is produced is what you actually intended is a different question.
Agentic engineering is essentially increasing the probability that what is produced is what you intended:
- Want to increase the probability it has the correct functionality? Ensure that functionality is well-specified with verification criteria.
- Want to increase the probability it matches your coding standards and quality gates? Ensure those standards are included in the specification.
- Want to increase the probability it aligns with your architecture, and doesn’t try to reinvent the wheel for existing services or components? You’ve guessed it - ensure the architecture diagrams and service descriptions are made available to the agents.
Imagine an application that needs to send a notification email or SMS, depending on user preferences. The agent will very happily start building an entire notification infrastructure from first principles if it thinks that is what is intended.
We can draw upon Andrej Karpathy’s analogy that LLMs are a new type of computer, and the contents of the context window are the programming language (Software 3.0 in his words). We add detailed specifications to ‘program’ the LLM into doing the correct thing.
A common use case for agentic engineering is an automated code migration. When we’re just bumping from version x to x+1, the agent will probably do the right thing. But if we’re trying to migrate from e.g. Delphi or PowerBuilder to a modern React application, things are more complicated.
The naive approach would be to just ask agents to examine the existing code and migrate. The issue with this is that the ‘programming’ for the LLM contains all sorts of legacy implementation details that will poison the context of the agent doing the heavy lifting.
Working, production code is, by definition, a perfect specification of what the application does - albeit in a formal language that is unnatural to us. We can use this code to extract a very detailed specification of expected behaviour, without copying implementation details. This can then become the basis for our migration agent, with the legacy code used to triangulate and verify success.
We’re only just scratching the surface of what Software 3.0 looks like, and it’s an exciting time to be an engineer, figuring this all out together.
Interesting Links
- Instagram Meta AI Vulnerability: How Hackers Bypassed 2FA with Prompt Injection - how the recent Instagram hack was carried out. Spoiler: it’s not complicated, and shows the very real risk of deceiving an AI with elevated permissions to carry out a compromised action.
- NVIDIA CEO Begs Execs to Stop Telling Workers They're Fired Because of AI - Jensen is correct, right now it’s a convenient excuse to correct for previous overhiring. But this will not be true forever…
- Anthropic Coding Workshops - material from Anthropic with hands-on workshops to become better at using Claude.
- The Tests We Skipped - neat article from local legend Ajey Gore. Totally agree that the current PR theatre is going to be an early casualty of the shift to agentic engineering (although we still need some kind of hook to trigger our security and code quality scans).
- Rewiring finance for AI, with Ned Lowe - some interesting points on agentic engineering, if I may say so myself!
This Is The Way
Feature A Fractional
We’re On A Mission
Until next month. Together, We Build {+}
Ned & the MISSION+ team
P.S. If you would like to bring the MISSION+ team into your organisation to help, please reach out to [email protected]!
