COMMENTARY: A few years ago, if we wanted to understand what was happening inside a software project, we mostly could.
Don't get me wrong, applications were already complex. There were open-source dependencies, cloud services,
CI pipelines, and enough abstraction layers to make anyone nostalgic for simpler times. But most developers still carried a reasonable mental model of the environment around them. They understood the code they wrote, the tools they used, and the systems they depended on.
That's become much harder today.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Open Cursor and ask an AI agent to build a feature. Within seconds, code appears that nobody on the team wrote. Dependencies get pulled in automatically. Configuration files change. New connections appear between systems. The feature may work perfectly, but the amount of software that entered the environment during those few minutes is often larger than what a developer could realistically review.
It's remarkable how quickly this became normal. Most of us still talk about software development as if the primary job was to write code. In reality, developers increasingly spend their time supervising an ecosystem of software that creates, modifies, and moves other software on their behalf. AI assistants generate implementations. Package managers pull in third-party code. Agents perform work that previously required direct human involvement
. MCP servers create pathways between systems that never interacted before.
Now, software development depends on trusting far more software than any developer can fully inspect.
Developers are managing systems, not just writing code
One of the biggest changes in software development over the last few years has very little to do with programming languages, frameworks, or infrastructure. Developers increasingly spend their time supervising systems rather than directly controlling them.
A decade ago, a senior engineer might spend the day reviewing pull requests, debugging production issues, designing new features, and writing code. Those activities still matter, but they're now surrounded by layers of tooling that make decisions continuously. AI assistants generate code. Models suggest implementations. Package managers resolve dependencies. Agents execute tasks across multiple systems.
Each tool makes sense in isolation. Today, developers rarely encounter them in isolation. Generated code influences dependency choices. Dependencies influence model recommendations. MCP servers expose systems to one another. Automation layers act on information produced by all of them.
A developer working on a relatively simple feature may have generated code, dozens of dependencies, local services, cloud infrastructure, AI models, MCP servers, and third-party integrations all interacting at the same time. Understanding any one component remains manageable. Understanding how they behave collectively becomes much harder.
Software development increasingly resembles operating a machine rather than building one.
The volume exceeded our ability to inspect it
When something goes wrong, we often ask why nobody caught it. That question made a lot more sense when developers were primarily reviewing code written by other humans. It makes less sense in an environment where generated code, automated package updates, model outputs, and third-party integrations continuously enter the workflow faster than any individual can realistically inspect them.
The amount of software flowing through modern development environments has grown far faster than our ability to evaluate it. Developers can review the code they personally write. They can inspect a pull request before merging it. They can evaluate a dependency they intentionally choose to introduce.
But they can’t thoroughly analyze every generated function, every package update, every transitive dependency, every extension, every model interaction, and every new connection entering their environment throughout the day.
At some point, the problem stops being diligence and becomes arithmetic. The industry became extraordinarily good at generating software, but the amount of software entering the workflow now exceeds what humans can comfortably validate. Developers didn't suddenly become careless. The environment around them became dramatically more active.
Risk moved closer to the developer
As software creation accelerated, the development machine became one of the most important systems in the organization.
Developer laptops now hold repositories, cloud credentials, API keys, access tokens, internal documentation, local environments, and direct connections into production infrastructure. Increasingly, they also host the tools responsible for generating and modifying software.
For years, organizations concentrated their defenses around production environments because that's where the most valuable assets lived. Today, many of those same assets are already accessible from the developer machine. A compromised laptop can expose source code, infrastructure, internal systems, and the credentials needed to move between them.
The development environment became a high-value target because that's where software gets assembled, modified, and connected to everything else. Once developer machines became the center of software creation, they also became one of the most attractive places to attack.
No engineering organization could function if every developer personally audited every package, model, API, service, and dependency they relied on. The software industry stopped building everything from scratch decades ago.
What's changed is the scale of that trust.
Developers now rely on systems that are more powerful than anything they had access to five years ago. At the same time, many have less visibility into what those systems are doing, what they can access, what data they're sharing, and what new connections they're creating.
For years, software development rewarded abstraction. Every layer removed complexity and helped developers move faster. Modern software would be impossible to build without those abstractions.
But abstractions don't eliminate complexity, they hide it.
As layer after layer accumulates, developers lose visibility into the systems operating beneath them. The software ecosystem became dramatically more capable, but it also became much harder to reason about.
We need better visibility, not less automation
The answer isn't to reject AI, agents, automation, or the tools that have made developers dramatically more productive.
The productivity gains are real, and engineering teams have already embraced a development model that depends on software creating more software. That trend isn't reversing.
Most developers can say exactly what's in the code they wrote this morning. Far fewer can tell tell us what software entered their machine, what gained access to their data, what systems exchanged information behind the scenes, or what new connections were created while they were writing it.
For most of the history of software development, those questions were relatively easy to answer because the environment itself was smaller and slower-moving. Today they often aren't.
The industry spent the last decade making software creation faster. The challenge ahead: making it all understandable again.
Zaid Al Hamami, founder and CEO, Boost SecuritySC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
