With this post, I’ll wrap up my notes from the second Future of Software Development Retreat. But before I do, I should note that the full Thoughtworks report on the retreat is now available. They have five headline findings:

• Code generation is no longer the bottleneck — verification is.
• ‘Harness engineering’ is emerging as a distinct, ownable discipline.
• Organizations are colliding with a real apprenticeship crisis.
• The executive/engineer expectation gap is a bigger risk than any technical limitation.
• Legacy modernization is the clearest, most defensible near-term value pool.

 ❄                ❄

A session convened around the mismatch of views about using LLMs between engineers using it and the C-suite and boards that were calling for it. The concern is that boards are looking at promised productivity gains, and not concerned enough about the risks, particularly about security.

This was illustrated by one tale of a company that used ML-trained software to optimize the replacement of air filters on their field equipment. They were pleased to see that they were able to change the air filters less frequently, saving them $50 million. But the problem was the ML models were trained on equipment used in the desert, while their equipment was used in the arctic. Air filters in the desert deal with dust, but in the arctic the thing to remove is mosquitoes. There’s an important difference here, mosquitoes rot, and enough decaying mosquitoes is a serious fire risk. Fires from such dead mosquitoes around infrequently replaced air filters cost the company $100 billion.

Now such a tale could told of many situations without AI in the mix. Plenty of human situations have gone wrong when solutions are applied in a new context (which is why context is such a key word among pattern-writers). But the tale does remind us to be wary of an AI’s suggestions, and to always think of how to build sensors to provide rapid feedback.

Engineers particularly worry about the risks when citizen developers start vibe coding. In many ways, of course, this isn’t new. I.T. folks often worry about how many important business decisions are based on spreadsheets, that are built with little control, testing, or assessment of data quality. Vibe-coding amplifies these concerns, so companies need a range of controls to guard against security breaches. Some folks have made a point of raising issues at board level, running threat modeling session with board members to introduce them to the risks. Vibe-coded applications need to be put in separate infrastructure, which deterministic controls over data access to tame the lethal trifecta. One company encouraged widespread vibe-coding from citizen developers but recoiled from the problems of the huge shadow IT that emerged - they are now looking to build a platform to help control this work without stifling the useful tools that were produced.

Part of the problem here may be simple experience with LLMs. Many in management find LLMs do a decent job of preparing management reports. Or summarizing management reports prepared by other LLMs. Given this they naturally think LLMs must do a decent job of programming too. My anti-management self has to mention Kelsey Hightower’s observation:

The less busy work you have the less appealing these Al tools are

One possible antidote to this: get the legal department involved. They see LLMs doing a poor job, and appreciate the risks involved.

 ❄                ❄

Most folks I talk to, both at the retreat and outside, recognize we are in some form of bubble. Technological advances like this almost always come with economic bubbles, and in the future we will all look back at this, and shake our heads saying we knew there was so much froth. But while it’s easy to see that there is a bubble, it’s hard to see how long it will run or what will emerge after the pop. After all the dotcom bubble was clearly recognized as such… in 1995. We can happily point at those companies that failed (Webvan, pets.com) but need to then acknowledge those that survived (Amazon).

Most of those at the retreat were old enough to have lived through the dotcom bubble and crash, but one such grey-hair pointed out an interesting difference. Back then we were excited about what the future would bring, and we saw lots of new things being built. There’s much less of that, this time around. Most people are wary of what the AI bubble is creating. Partly this may stem from the reality that followed the dotcom hope. Social media may be everywhere, but do we think it’s actually improved our lives that much, even if (especially if?) we use so much of it?

We hear so much about the incredibly productive things we can do with agentic programming, but has anyone noticed a flood of wonderful applications built with it? Or have we noticed a significant improvement in common applications from the big AI boosters such as Google or Microsoft?

This may be another factor in the board-vs-engineer divide. Most of what’s driving adoption of AI at the moment is cost-cutting, and it mostly the boards that get excited by cost-cutting. Perhaps the increasing concerns about token costs will temper the eagerness.

 ❄                ❄

Folks are finding LLMs helpful in operations: with a good event stream from observability tools, an agent finds anomalies much faster. One of the problems with citizen-developer apps, is that they often don’t provide good observability, since the citizen-developers don’t think to ask for it. The agents ability to look at the event stream does pose governance questions, as often such event streams contain a lot of sensitive information.

Reinforcing what I’d heard in Utah, more people agreed that LLMs are valuable for operations folks to help them understand what the code does. Cross matching code and event traces helps them assist humans to find what happened when things go wrong. Agents are particularly handy with repeated incidents, as they can collate lots of information from different cases and present it to the human teams.

Getting agents to auto-remediate moves us to the next level of capabilities and concerns. It’s vital that agents carefully document all their actions when they do fixes. We also need to ensure there is feedback to the development team so they can learn. Agents don’t learn, the best they can do is update the context.

There was a sense that many people over-estimate the capability of agents to deal with incidents. Such people think of incident resolution as a simple, linear process. But it’s rarely that, instead there’s a lot of surprises and adaptation needed. Humans are good with that, but LLMs are not.

One of the perils of agent-developed code is their habit of inserting features that were never asked for. One team spent three days trying to figure out such an unrequested feature, trying to figure out who had requested it and if anyone wanted to keep it.

 ❄                ❄                ❄                ❄                ❄

A group of law professors carried an interesting experiment to judge how well an LLM can provide short answers to student questions. They created a batch of forty questions in contract law and asked the professors, plus a couple of LLMs, to provide answers. To evaluate the LLM answers they showed professors pairs of answers - one human, one LLM - and asked them which response they would prefer to deliver to a student.

Professors rated LLMs far higher than their peers (average win rate = 75.33%), with models performing similarly to the best instructor. LLM responses were also rarely flagged as harmful (3.53%, vs 12.06% for professors).

This reminds me of the distinction I mentioned in a recent fragment between interactional and contributory expertise.

 ❄                ❄                ❄                ❄                ❄

A few days ago Unmesh Joshi published an article here about his experiences using DSLs to enable more reliable use of LLMs. Responses to this included a pointer to an article by Spender Nelson that related similar impressions.

DSLs like this hit a lot of sweet spots for LLMs. You can make them extremely token efficient, and enforce hard security boundaries. You can translate high-level LLM intent into a ton of deterministic code, ensuring good behavior and guardrails at the (custom) compiler level.

And Large Language Models are very good at learning and working with DSLs. Maybe this shouldn’t come as a surprise; they are language models after all. A small bit of documentation generally is enough to set them off and running, and reasonable error messages let them course-correct even when they go wrong.

He describes a couple of examples from their use: a query language for data lakes that takes into account security and authorization issues, and a little expression language to make it easier to create safe SQL where clauses.

One of the biggest barriers to using DSLs, particularly external DSLs, is building a parser and tooling. LLMs make this much easier. That said, my sense is that it’s the semantic model that underpins the DSL is what really matters, and the DSL is one projection of that model. LLMs may help us explore other ways to project that model in interesting ways.

 ❄                ❄                ❄                ❄                ❄

In recent weeks I’ve been noticing the stench of LLM-speak more and more. It’s not just the common tells, it’s a sense of LLM miasma that pervades the prose. I’ve noticed it’s increasingly eliciting a visceral reaction, after a couple of paragraphs I just want to dismiss the entire article out of hand. For some of these, it was necessary for me to hold my nose and wade through the whole text, but it was with an intellectual nausea which obscured the content, even increasing my desire to indulge in such an awful distraction as checking social media.

I wonder - is this just me that’s reacting so negatively to LLM-speak? Or do other people have a reaction that leads them to toss aside any prose that sets off their LLM-alarm?

One indicator that it’s not just me is this post from Jason Koebler that I highlighted a couple of months ago, where he observed how AI was breaking his brain:

People think things that are fake are real, things that are real are fake. Much has been written about “AI psychosis,” the nonspecific, nonscientific diagnosis given to people who have lost themselves to AI. Less has been said about the cognitive load of what other people’s AI use is doing to the rest of us, and the insidious nature of having to navigate an internet and a world where lazy AI has infiltrated everything. Our brains are now performing untold numbers of calculations per day: Is this AI? Do I care if it’s AI? Why does this sound or look or read so weird? Does this person just write like this? Is this a person at all?

A while ago, I was thinking that it was reasonable for folks who aren’t as committed to writing as I am to use an AI to help polish their prose. Now I’m turning to encouraging writers to reject it. That pervasive LLM-voice is just so common now, my sense is that it discredits the writing even before the reader has a chance to try to understand what is being said. I don’t think it’s good enough to ask the LLM to write a first draft and then tweak it. I’m not sure writers can edit the LLM-ness out of prose once it’s in there. I even worry about asking an LLM to suggest improvements, I think it’s just too easy to accept an LLM’s suggestions, and in the process trigger your readers’ LLM-antibodies.

Of course like most problems, it’s also an opportunity. Those who can get a distinctive human voice will get more visibility and credibility. But the question remains of how we can coach people to let out their true personality into their writing. Academic and corporate writing both tended to stifle engaging prose, LLMs are good amplifiers, and they will amplify this stifling. This is an even greater challenge for those for whom English is their second language (or indeed for many of my colleagues, their third or fourth). It’s too easy for me to neglect to think about a difficulty that I’ve never been able to face.

The most immediate advice I can give something I learned many years ago and shared last year - Say Your Writing.

Once you’ve got a reasonable draft, read it out loud. By doing this you’ll find bits that don’t sound right, and need to fix.

I always suggested this to help people get past sluggish prose, especially if they had spent too much time around academic or corporate writing. But now I think the need to Say Your Writing is even more important, in order to combat the insidious impact of AI. For most people, their speech patterns get closer to their real self, so verbalizing writing is the way to fight those forces that try to smooth away a writer’s individuality.

We are releasing new patches for our self‑hosted product, Azure DevOps Server. We strongly recommend that all customers stay up to date with the latest, most secure version of Azure DevOps Server.

The most recent release, Azure DevOps Server, is available on the download page.

The following versions have been patched. For more details on these updates, see the release notes:

Azure DevOps Server Patch Download

Verifying Installation

To verify that the patch is installed, run the following command on the Azure DevOps Server machine using the patch installer you downloaded:

<patch-installer>.exe CheckInstall

Replace <patch-installer> with the name of the patch file you downloaded. The command output will indicate whether the patch is installed.

The post July Patches for Azure DevOps Server appeared first on Azure DevOps Blog.

My team runs a program where we spend a week with a customer taking a use case from idea to MVP. The team (and customer) came to San Diego this week so that I could be part of the exercise. It’s super cool to watch a group come together quickly to iterate, learn, and ship.

[blog] Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber. Big model release day at Google. These are good performers, well-priced, and quite efficient with tokens.

[blog] Reliability Is Not a Feature. It Is a Discipline. It’s also not a vague “non-functional requirement.” It’s a way of working, as this post calls out.

[blog] How do you stay familiar with the code when it’s written by an LLM? Great post. There are smart ways (necessary ways?) to stay involved in the code that you’re ultimately accountable for.

[blog] Guide to AI Tokenomics: Eleven Principles for Token Efficient Software Engineering. We’re all figuring out what works best in this world where tokens aren’t free. I liked this advice.

[blog] The LLM Critics Are Right. I Use LLMs Anyway. Most smart people I know aren’t ignorant of the complaints or problems with LLMs. But that doesn’t mean LLMs aren’t still useful.

[article] Are PMs becoming irrelevant? The old PM role is mostly irrelevant, I agree. The advice here is to become a strategic PM (not an “AI PM”).

[article] How do you go from junior to staff engineer when AI writes the code? Maybe mentoring got easier. Keep hiring juniors, and bring agents into the mix to get them productive.

[article] Frontline Workers Know How to Solve Your Organization’s Biggest Problems. It makes no sense to me to be a disconnected executive who only spends time with other execs. You should be talking with your employees multiple times per day.

[blog] How to structure a log. Maybe AI can help you even if your logs are a mess. But create good logs is the right hygeine regardless.

[blog] 13 hands-on demos to build on Gemini Enterprise Agent Platform. Great stuff. Here’s a list of tutorials you can run to learn how to build, scale, govern, and optimize agents. Each category matters.

[article] 2030-shaped software. Some good thoughts here about agents, UIs, and what we’ll be using in a few years.

[blog] In-House LLM Serving at Netflix. What breaks at scale? Those are some of the most interesting things to learn from others.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

Microsoft and Mistral are deepening their partnership with a multibillion-dollar agreement focused on enterprise AI infrastructure. The goal is to give organizations more flexibility over where they run frontier models and how those deployments are managed, particularly in regions with tight data residency and sovereignty requirements.

Under the deal, announced Tuesday, Microsoft will use Mistral’s expanding European compute infrastructure to increase regional capacity. Mistral, meanwhile, plans to deploy thousands of NVIDIA Vera Rubin GPUs to power everything from model training to multi-agent workloads. 

For engineering teams in regulated industries, the announcement emphasizes where enterprise AI is heading. Many organizations no longer want the public cloud to be the only place they can run AI models. They’re asking for deployments that fit into the infrastructure they already have, including on-premises and air-gapped environments.

Sovereign compute meets agentic AI 

At the compute layer, the agreement gives Microsoft access to European-operated infrastructure outside its traditional first-party data centers and leased facilities. The move builds on Microsoft’s European Digital Commitments, announced in 2025, which focus on keeping customer data in Europe and helping organizations meet regional regulatory requirements.

Crucially, Mistral will power this infrastructure with NVIDIA’s next-generation Vera Rubin rack-scale platform. Because sovereign environments support multi-step agentic workflows, this hardware pairing is essential. NVIDIA claims the platform delivers up to 10x the agent throughput at scale compared to its Grace Blackwell generation.

“Europe should have access to the world’s most capable AI without compromising control over their data, operations or digital future.”

Even though exact financial terms, capacity allocations, and rollout timelines have not been made public, the agreement positions Mistral as both an AI model supplier and an independent European compute vendor for Microsoft’s enterprise ecosystem. For European companies wary of the US CLOUD Act, the appeal is obvious — though whether a US-headquartered provider can fully place data beyond its reach remains legally contested.

“Europe should have access to the world’s most capable AI without compromising control over their data, operations or digital future,” said Microsoft Vice Chair and President Brad Smith in the announcement. 

The model layer

At the model and API tier, Microsoft announced that Mistral Medium 3.5 and Mistral OCR 4 are now live in Microsoft Foundry, with Medium 3.5 also integrated into Microsoft Copilot Studio.

Among the models coming to Azure AI Foundry is Mistral Medium 3.5, an open-weight model with 128 billion parameters and a 256,000-token context window, which could indicate it’s better suited for applications that need to work across large documents or extended conversations.

Microsoft is also adding Mistral OCR 4, which is designed for document-heavy AI workflows. The model can process documents in 170 languages and preserve information about page layout, including bounding boxes, document structure, and confidence levels.

The model can process documents in 170 languages and preserve information about page layout, including bounding boxes, document structure, and confidence levels

Air-gapped deployments go mainstream 

For developers, the primary technical win is architectural symmetry. Engineers can build, test, and fine-tune applications inside Microsoft Foundry and migrate those workloads across public Azure, Azure Local, or sovereign infrastructure operated by Mistral without having to refactor underlying workflows.

This hybrid portability targets industries bound by strict compliance regulations. The deployment options also include fully air-gapped environments, allowing organizations to run AI workloads on networks that remain completely isolated from the public internet.

Deployment flexibility drives decisions

The partnership indicates that deployment flexibility is becoming part of the buying decision. Many organizations want the freedom to run AI in the cloud, on-premises, or in regional infrastructure without being locked into a single approach. And that’s where Microsoft’s expanded relationship with Mistral fits so well.

The companies are betting that giving customers more deployment options will weigh just as much as offering competitive models. If the strategy works, Microsoft will be providing the control plane for how the world’s most regulated industries run it. 

If the strategy works, Microsoft will be providing the control plane for how the world’s most regulated industries run it. 

The post Microsoft is building an AI stack it doesn’t fully own — on purpose appeared first on The New Stack.

A few years ago, I wrote about using a Maturity Matrix to assess software engineering teams. The idea was simple - what does a great team look like, and how honestly can you measure yourself against that picture?

Since then, I've moved into the gaming industry. Anyone who has taken the leap from traditional software development and into game development knows how different it is. Reusing the old matrix just wouldn't work.

I know what some of you are already thinking - games are creative work, not an assembly line, and a maturity matrix sounds like corporate process creeping into art. I'd have said the same thing a couple of years ago. But the crunch numbers, the missed cert dates, and the launch-week crashes tell a different story. Creativity doesn't suffer because a team has good practices. It suffers when nobody has time to be creative because they're firefighting.

So here's the matrix I actually use now - rebuilt from scratch, with the lens I wish I'd had on day one.

What is a Maturity Matrix?

If you're new to the concept - a Maturity Matrix is a list of best practices, and you rate yourself honestly against each one. I like to keep it simple with a Red / Amber / Green system:

• 🔴 Red - this doesn't exist, or we barely think about it
• 🟡 Amber - we do this sometimes, or it's a work in progress
• 🟢 Green - this is something we actively do and do well

The point isn't to feel bad about the reds. It's to give you a clear, honest picture of where to focus your energy. A lot of reds in one area? That's your priority list right there.

I've trimmed this down to the nine that matter most, in my experience - the ones that separate studios that ship well from studios that ship exhausted.

Engineering Practices

Build Pipeline Health

In web development, a slow build is annoying. In game development, a broken build can block an entire team - artists, designers, QA, and engineers all depend on it. I once watched an entire studio lose a full day because nobody could get a playable build out, three days before a milestone review. Are your builds automated and reliable? Are you catching console certification failures early, or discovering them at submission time? A healthy build pipeline is the backbone of a productive studio.

Performance Profiling Culture

Every platform has hard limits - CPU budgets, GPU budgets, memory ceilings. Does your team profile regularly, or only when something starts to hitch two weeks before launch? The best studios treat performance as a first-class feature from the start, not an afterthought you bolt on once the fun is figured out.

Crash Reporting & Telemetry

When a live game crashes, your players notice before you do. Do you have crash reporting in place? Are you tracking telemetry on key gameplay events? Can you identify a root cause quickly, or are you hunting through logs hoping for a clue while your review score drops in real time?

Oh and if you are interested, I wrote an article on the XBOX Game dev blog entitled From Crash to Resolution: A Practical Guide for Xbox & Windows Developers about this very topic.

Game Dev-Specific Practices

These don't really come up on a traditional software team, but they're make-or-break in game development.

Content Pipeline Maturity

This is the game dev equivalent of CI/CD, and it's often overlooked. How quickly can an artist iterate on a texture or a level? How long before a designer's change shows up in a playable build? Slow content pipelines kill creativity and momentum quietly - nobody files a ticket for "iteration felt sluggish," but it shows up in the work. A fast feedback loop is imperative to game dev.

Platform Compliance Readiness

Shipping on console means going through certification, and failing it costs real time and real money. Are you running compliance checks throughout development, or only at submission? The studios that handle this well treat certification like a test suite - run it early, run it often, don't let it be a surprise.

Live Operations Readiness

If you're running a live service game, this one's non-negotiable. Do you have feature flags that let you toggle things without a full patch? Can you push a hotfix quickly without breaking everything else? Do you have a rollback plan, or is "cross our fingers" the plan? Live ops is a discipline in itself, and teams that treat it as an afterthought pay for it at 2am.

Milestone Discipline

Alpha, Beta, Gold (or similar) - do these mean something concrete in your studio, or are they just dates on a calendar? A mature team has clearly defined milestone criteria. Everyone knows what "alpha" means, and everyone knows what still needs to happen before "gold." Vague milestones are how you back into crunch without ever deciding to.

People Practices

This is the category I think studios most underinvest in. Technical excellence matters - but so does the health of the people doing the work.

Sustainable Pace & Crunch Awareness

Crunch is the elephant in the room in game development. Does your team track hours? Is crunch treated as a signal that planning went wrong, or just part of the job - the cost of doing business? The studios with the best long-term output have learned to treat unsustainable pace as a problem to solve, not a badge of honour to hand out at the wrap party.

Cross-Discipline Collaboration

Games are built by engineers, artists, designers, and audio teams, often working on the same systems at the same time. How well do those handoffs work? Are your tools built with non-engineers in mind, or do they assume everyone can read a stack trace? The friction between disciplines is often where time quietly disappears.

How to Use This

Grab a notebook or a spreadsheet and rate yourself honestly against each of these. Don't try to fix everything at once - pick your top two or three reds and make a plan around those first.

If you'd like to make a copy of this spreadsheet for yourself, please head over to this link.

The goal isn't perfection. It's awareness. You can't improve what you don't measure.

The point of this exercise is to have better data and context on how your team works, and what might be their needs. It's also worth mentioning that the list above is a light place to start, you can definitely expand and add more categories!

If you've done this kind of exercise with a software team before, some of these patterns will feel familiar. Teams get good at the things they talk about, and they neglect the things they don't. This matrix is just a way of making sure you're talking about the right things - before your players start talking about them for you. 🎮

The organizational roots of sprawl set the stage, but modern architecture is what turns a trickle of new APIs into a flood. In this third post of the series I want to look at the technical drivers–the shifts in how we build and deploy software that quietly multiply APIs and endpoints faster than anyone is documenting them. None of these shifts are mistakes. Each one earned its place for good reasons. But every one of them trades a single, legible system for many distributed pieces, and every piece speaks through an API.

Start with microservices and SaaS. Decomposing a monolith into many small, independent services buys you real things: faster code updates, language flexibility, and granular scaling. I am not here to argue against microservices. But the arithmetic is unavoidable–every service you carve out introduces new APIs so those services can talk to each other. A single application that used to have one internal boundary now has fifty, and each boundary is an interface someone has to document, secure, version, and eventually retire. Add the SaaS tools every team now wires in, each with its own API surface, and the count climbs again. Microservices did not create sprawl, but they industrialized the rate at which new interfaces appear, and documentation practices almost never keep pace with that rate.

Then there is the hybrid and multi-cloud reality. Applications, services, databases, and platforms now live spread across on-premises systems and multiple cloud providers, and the way all those pieces exchange data is–of course–APIs. There are excellent reasons to run this way: resilience, cost, avoiding lock-in, meeting data residency requirements. But distribution has a cost, and part of that cost is paid in APIs. The more places your workloads live, the more interfaces you need to move data between them, and the harder it becomes for any single team to hold the whole picture in their head. A monolith in one data center had a knowable surface. A workload smeared across three clouds and a data center does not, and the seams between environments are exactly where undocumented APIs like to hide.

The third technical root is rapid development cycles, and this is the sneaky one. Modern DevOps built on continuous integration and continuous delivery is designed to ship smaller changes faster, and it is one of the best things to happen to software delivery. But speed has a side effect I have watched play out again and again: version creep. Under pressure to ship, developers add a new API or a new version rather than evolving the existing one. It is faster in the moment–stand up v2 next to v1, ship, move on–and it is death by a thousand cuts over time. You accumulate undocumented, poorly governed interfaces because the pipeline optimized for velocity and nobody put a gate in front of “just add another version.”

Version creep compounds into endpoint proliferation. Each new version tends to introduce new endpoints, so you are not just multiplying whole APIs, you are multiplying the surface inside each one. v1 had twelve endpoints, v2 has fifteen, v3 has eighteen, and the first two never went away because deprecation is nobody’s job on a Friday afternoon. Now you are maintaining forty-five endpoints where a disciplined evolution of the original might have kept you at eighteen. Every one of those extra endpoints is a thing to secure, monitor, document, and pay for. This is what it looks like when an architecture optimized for short-term speed quietly mortgages your long-term coherence.

Here is the pattern that ties all three together: each of these shifts trades one legible thing for many distributed things, and distribution is inherently harder to see. A monolith is a single surface you can reason about. Microservices, multi-cloud, and rapid releases each shatter that single surface into many, and the shards are the APIs. The benefit is real and I would not give it back–but the tax is real too, and the tax is paid in visibility. You cannot casually keep track of what you have anymore, which means the informal, in-your-head inventory that used to be good enough is now dangerously incomplete. The architecture outgrew the manual approach to knowing your own estate.

This is exactly why I keep coming back to machine-readable descriptions of everything you operate. When new APIs and endpoints appear this fast, from this many places, the only sustainable answer is to make each one describe itself–an OpenAPI contract per API, an APIs.json index per collection, discovery that reads your traffic and your repositories rather than relying on someone to remember. You are not going to slow down microservices, un-distribute your clouds, or give up CI/CD, nor should you. What you can do is make the systems that generate the sprawl also generate the map of it, so that visibility scales at the same rate the interfaces do. That is the only way the map ever catches up to the territory.

In the next post I will get into the specific creatures that live in the gaps these technical shifts create: shadow, rogue, and zombie APIs–the undocumented, unauthorized, and abandoned interfaces that turn sprawl from an efficiency problem into a genuine security problem.