Deep Engineering #53: Rick Spencer on Matching the Right AI to the Right Engineering Work
Running AI under strict compliance, sorting tools by the job, and keeping cost and control in the engineer’s hands
A Hands-On Workshop for the Next Generation of Engineers
A hands-on, build-along workshop where you build and run 10 production-inspired AI agents across finance, healthcare, and education. Walk away with a complete GitHub repo and implementations for OpenAI, Claude, Gemini, and local models.
🗓️ September 12th · 11:00 AM EDT onwards
Use code DEEPENG50 for 50% off the early bird price. First 10 sign-ups only.
✍️ From the editor’s desk,
Welcome to the 53rd issue of Deep Engineering!
At London Tech Week this month, NVIDIA made it exceedingly clear, showcasing a wave of UK companies building AI for environments where sovereignty is not optional. Building capable AI models is no longer the hardest problem. The real challenge is running them in environments where security, compliance, and cost aren’t negotiable. Organizations want AI they can trust, control, and operate on their own terms.
That’s exactly the challenge Rick Spencer has been solving at SUSE. As General Manager for Technology and Product at SUSE, he works with the teams behind its enterprise Linux and cloud native platforms for regulated organizations. His perspective is simple: engineers will use AI wherever it helps them move faster. But the real question isn’t whether teams should adopt AI; in fact, it is how to match the right model to the right kind of work.
In today’s issue, Spencer shares the framework his teams use to make those decisions. We discuss where agentic AI is delivering real value, why frontier models should be reserved for high-impact problems, and how SUSE keeps AI adoption practical without letting costs spiral.
You can read or watch the full Q&A interview here.
Let’s get started.
Featured Newsletter: AI Agents Simplified
AI Agents Simplified cuts through the noise with clear, actionable breakdowns of agents, automation, and what's actually worth your attention. Trusted by 58,000+ subscribers, with new issues every week and no hype.
→ Subscribe to AI Agents Simplified
Expert Insights
Not whether engineers use AI, but which AI for which work
by Srishty Goyal with Rick Spencer
Most engineering organizations start their AI adoption conversation with limits. Should engineers use it, and how much should they be allowed to? Rick Spencer sees that as the wrong question. As General Manager for Technology and Product at SUSE, he works with the teams building enterprise Linux and cloud native infrastructure for companies operating under strict compliance requirements. His starting point is practical: engineers will use AI wherever it helps them move faster.
“It’s not like, oh, don’t use AI,” he says. “That would just not be workable.”
For Spencer, the real question is not whether engineers should use AI. It is which AI belongs to which kind of work. Getting that decision right is what separates useful AI adoption from adoption that quietly burns money, trust, and control.
Three kinds of AI work, and why the distinction matters
SUSE breaks engineering use of AI into three categories, each calling for different tools, cost profiles, and levels of oversight. Spencer describes the first as daily work: statement completion and debugging that engineers rely on throughout the day. The second is agentics, where agents take care of repetitive work and interruptions that would otherwise consume engineering time. The third is what he calls curve jumping, and it is the most consequential of the three.
“That’s like when you’re just going from zero to infinity,” he explains. “You can do things with AI that you wouldn’t have tried before, like solve really deep problems in one big step.”
The value of this distinction is that it helps teams make more deliberate tooling and cost decisions instead of relying on guesswork. As Spencer puts it, the framework helps engineering managers pattern-match the right AI to the right kind of work. If a task only needs statement completion and debugging, that points to one set of tools. If it involves data sovereignty requirements, that points to another. Frontier models, the most capable and most expensive, are reserved for curve jumping, where their cost is justified by the scale and complexity of the problem.
“It sounds very organized now, but there was a lot of experimentation, a lot of really rapid innovation from the engineers,” Spencer says of how the framework came together.
The framework emerged from engineers first. Management then built structure around what those early adopters had learned so the approach could be shared across the organization. It’s a practical reminder that successful AI frameworks often evolve from experimentation before they become formal processes.
Frontier models are for curve jumping, not code completion
One of Spencer’s most practical observations is about matching model capability to the task at hand. Routing every request through the most capable model is both expensive and unnecessary, and he is clear about where the line sits.
“You do not need a frontier model to understand your Python module and give you code completion,” he says. “You just don’t need it for that.”
Frontier models earn their cost in the curve-jumping category, where the problems are strategic and complex.
“We have projects where we spend tens of thousands of dollars on frontier models, but they generated, who knows, a million or two million dollars in value,” he notes.
When the value is that high, the investment makes sense. The discipline is in not using frontier models for work that a much cheaper model can handle just as well. Spencer’s teams apply the same thinking in another way. They use frontier models to build agents that later run on much cheaper models.
“We use the frontier model to create an agent that can then be run on a much lower-cost model,” he explains.
The frontier model writes the Python scripts and prepares the context the agent needs. After that, a lower-cost model handles the repeated execution. The expensive model does the design work once, while the cheaper model runs the workflow repeatedly. For teams looking to bring frontier-level capabilities into production without paying frontier-level costs every time, it’s a practical approach that balances capability with efficiency.
Agentics is where the toil goes to die
The agentics category is where Spencer’s examples become most concrete. More importantly, they show what relieving engineering toil looks like in a production environment rather than a demo. His favorite example isn’t about writing code at all. After a series of software supply chain attacks, SUSE’s security team built an agent that scans for newly reported compromised packages every hour.
“It finds those, and then it scans all of our open source code to see if we’re using it anywhere,” he says. “If we are, it writes a report and notifies us on Slack.”
The benefit is immediate.
“If you see a report of a tool chain attack, our agent was on it before we even knew about it,” Spencer says.
Work that once required engineers to manually search through repositories now happens automatically, often before anyone has even seen the news.
His second example focuses on CVE triage, another task that has become increasingly difficult to manage manually at enterprise scale. CVEs arrive faster than teams can assess them, and many turn out not to be relevant.
“A lot of times the CVE comes in and the package is in the repo, but it is not being exposed in any way that it would matter,” Spencer says.
An agent reviews each CVE for applicability and helps generate the VEX file that documents whether the vulnerability actually affects the product. The result is that engineers spend less time sorting through reports and more time addressing the vulnerabilities that matter.
“We’re focusing our attention not on keeping up with the crush of CVE reports, but on the actual vulnerabilities,” he explains. “Our attention is reserved for actually keeping our customers safe.”
That’s the hallmark of a good agentic use case. It removes repetitive work without taking engineers away from the decisions that require human judgment.
The context that does not survive the session
As engineers move from AI-assisted coding to autonomous agents, Spencer points to a challenge his senior engineers have had to learn to manage. Context that isn’t made explicit often ends up buried in conversation history. When that history disappears, the agent’s behavior changes.
“Those history sessions can embed context which you have not made explicit in your markdown,” he says. “The next time you go and you don’t have all that history, you get different behavior than you were expecting.”
The lesson, Spencer says, is to make recurring context explicit instead of letting it live inside a session that will eventually disappear.
The challenge becomes even more significant once agents begin operating autonomously. Unlike traditional infrastructure tools, agents are not deterministic.
“This is a big change in infrastructure management,” he notes. “If I give this input, I know exactly what’s going to happen.”
With conventional tools, unexpected inputs usually produce predictable failures. Agents behave differently. When they encounter something unexpected, they try to solve the problem, and that often requires additional context, including organizational policies or guidance on how a situation should be handled.
This is where MCP servers become important. They give agents a way to retrieve the right context when they need it. At that point, context management is no longer just about writing better prompts; it becomes part of the infrastructure itself.
Cost control is a design decision, not an afterthought
Running AI at scale makes cost something teams have to design for, not react to later. Spencer sees this as part of the architecture.
At SUSE, part of the answer is structural. Self-hosted AI gives the organization a clearer cost ceiling. The question becomes how well the team can observe and use that fixed capacity, rather than whether a usage-based bill might suddenly run away.
Spencer connects this directly to sovereignty.
“Sometimes they call it cost sovereignty,” he says, “because no one can come back later and say, oh, by the way, we’re changing our model.”
He has seen suppliers move from seat-based pricing to usage-based pricing, leaving engineering teams with a cost model they did not control. Hosting your own AI infrastructure changes that equation. It gives teams more control over where AI runs, how it is governed, and what it can cost.
The governance side of that argument, including how SUSE keeps agents and their costs inside a boundary it can stand behind, is covered in the companion piece, How SUSE Runs AI Without Losing Control.
The more tactical layer is circuit breakers, which cap runaway agent spend in real time.
“We just noticed our Claude usage in the last minute was way too high,” he says, describing the trigger.
Spencer acknowledges the trade-off. Aggressive rate limiting can frustrate engineers who are trying to get work done, but it is a necessary safeguard when autonomous agents can generate costs without a human in the loop.
Like the three-tier framework, the goal is simple: match the cost of the tool to the value of the work and put clear limits around the situations where agents can spend without delivering value.
Ultimately, Spencer’s goal isn’t to slow engineers down. It’s to give them the confidence to use AI effectively without sacrificing governance or cost control.
“The penny drops for them that they’re in a new paradigm,” he says, describing the moment developers realize they can be ten or even a hundred times more productive.
The framework, the tooling, and the guardrails exist to support that shift, not to get in its way.
“You don’t want to stop them from getting that 100X improvement,” he says. “You need to give them the right tools for the job.”
For Spencer, that’s what successful AI adoption looks like: giving engineers the freedom to move faster while making sure the right tool is used for the right work.
The Packt Summer Sale is live through June 30. Get 8,000+ eBooks and videos across AI, programming, data, DevOps, and cloud for $9.99 each, including Clean Architecture with .NET, Python Illustrated, and the C++ STL Cookbook.
In case you missed
How SUSE Runs AI Without Losing Control
Rick Spencer, GM of Product and Engineering at SUSE, on how an open source enterprise runs AI at scale while keeping control of its data, its tooling, and its costs, treating sovereignty, MCP governance, and cost predictability as one connected problem.
Sovereign AI and Agentic Infrastructure with Rick Spencer
Interview with Rick Spencer on running AI disconnected from the internet, the three-tier framework SUSE uses to match tools to work, why output metrics are vanity metrics, and MCP as a control layer for enterprise infrastructure
🛠️ Tool of the Week
ToolHive is an open source platform from Stacklok for running and governing Model Context Protocol (MCP) servers in production.
Highlights
Secure isolation: Runs each MCP server in its own isolated container with minimal permissions.
Enterprise access control: Enforces per-request identity and access policies with OIDC integration.
Self-hosted deployment: Keeps the MCP registry, gateway, and servers on your own infrastructure.
Lower token usage: Uses semantic tool discovery to reduce token usage by up to 85%.
📎 Tech Briefs
Grok Build opens a plugin marketplace - New plugin marketplace featuring tools from MongoDB, Vercel, Sentry, and Cloudflare.
Gartner Forecasts Worldwide AI Spending - Enterprise spending is expected to grow 47% year-over-year to reach $2.59 trillion in 2026.
Anthropic study links AI coding success to domain understanding - Domain expertise proved a stronger predictor of success than coding ability.
Mastra npm supply chain attack disclosed - Over 144 packages were compromised through the easy-day-js typosquat dependency.
OpenAI Codex adds granular internet access controls - Users can now restrict internet access by domain and HTTP method.
That’s all for today. Thank you for reading this issue of Deep Engineering.
We’ll be back next week with more expert-led content.
Keep building,
Saqib Jan
Editor-in-Chief, Deep Engineering
If your company wants to reach senior developers, software engineers, and technical decision-makers, speak to us about partnering with Deep Engineering.
 | A guest post by
|