The shift down: When everyone builds software, guardrails must be built in

If you lead security, IT, or infrastructure in an organization, you’ve probably seen this more than once already.

An employee builds an internal application using Claude or ChatGPT. Maybe it’s a finance tool, an onboarding tracker, or an agent that automates a repetitive process. It works, their colleagues want to use it, and suddenly someone needs to figure out how to deploy it, who can access it, and whether it’s safe to connect to company systems.

A few weeks later, another employee shows up with something similar. Then another.

What’s changing isn’t just how easily software can be created. It’s how many people across the organization can now create it, often without involving technical teams until they’re ready to share what they’ve built.

And while building software has become dramatically easier, the responsibilities that come with running it haven’t disappeared.

Who owns these applications? What data can they access? Who maintains them? What happens when the employee who built one leaves?

These aren’t new questions. The software industry has spent decades developing ways to address them. What’s changing is who’s building the software, and whether we can reasonably expect them to take responsibility for everything that comes with it.

From shift left to shift down

For years, software engineering embraced the idea of shift left: moving security, testing, and quality checks earlier in the development process rather than discovering problems after the software was built.

The reasoning was sound. Developers were closest to the code, so involving them earlier could prevent problems before they reached production. But over time, more and more responsibilities accumulated around the people building software. Security, infrastructure, compliance, deployment, and monitoring increasingly became part of the development process.

In 2023, Richard Seroter of Google Cloud questioned how far this approach could go, opens in a new tab. Rather than continuously adding responsibilities to developers, he suggested moving more of that complexity into the platforms they already use.

The approach became known as shift down.

Instead of requiring every developer to understand and implement every security and infrastructure requirement, organizations embed those capabilities into the underlying platform. Google later described this in its guide to platform engineering, opens in a new tab as moving decisions and responsibilities into internal developer platforms.

It’s a useful idea for professional developers. But AI is making it relevant to a much broader population.

If engineers were already carrying too much responsibility, what happens when the person building an application is an analyst in finance?

Should that employee review generated code for vulnerabilities? Understand authentication and authorization? Decide how credentials are stored, which systems the application can connect to, or which colleagues should be allowed to see particular customer records?

And who takes responsibility when the application stops working or its creator leaves the company?

These are legitimate concerns. They’re just not questions we should expect every employee to answer.

Nobody expects someone preparing a PowerPoint presentation to build an access-control system before sharing it. The organization’s existing infrastructure handles identity, permissions, and storage. The employee focuses on creating the presentation.

Software built with AI needs something similar, although the consequences are considerably greater. An application can query databases, modify records, invoke APIs, and take actions on behalf of users. An agent might continue doing those things long after its creator has stopped paying attention.

The guardrails need to exist regardless of who built the software or which AI tool they used.

The problem isn’t that security says no

In conversations with organizations adopting AI, I’ve seen this tension from both sides.

At a manufacturing company, an employee built a training and certification tracker for hundreds of production workers. It addressed a real operational need, but getting it deployed meant navigating budget discussions and security reviews.

At a company operating in financial services software, security and legal teams were reluctant to allow employee-built AI tools to connect directly to systems containing personal data and regulated contracts.

Both positions make sense.

Employees see an opportunity to solve problems that previously required technical resources. Security teams see applications connecting to sensitive systems, built by people who may not understand the risks. Infrastructure teams see another collection of software they’ll eventually be expected to operate and maintain.

Blocking everything isn’t a particularly effective answer. But expecting security teams to review every application individually isn’t sustainable either, especially when the number of potential builders is no longer limited to engineering.

Some organizations respond by building internal platforms. Others route employee-built applications through existing development processes. And some allow employees to publish directly through the AI tools they’re already using, leaving applications scattered across different vendors and accounts.

Each approach addresses part of the problem, but the underlying challenge remains: software creation has become decentralized, while the infrastructure required to run software safely hasn’t.

This is where I think the shift-down approach becomes particularly relevant.

Instead of asking every employee to make their application secure, organizations can establish a common environment where security and operational requirements are enforced by default, regardless of which AI tool was used to build it.

An employee shares an application, but the people opening it authenticate with their company identities and access only the data they’re authorized to see. The organization knows which applications and agents are running, who owns them, and which systems they connect to. Security teams can establish policies and revoke access when necessary, without having to track down the original creator.

Autonomous agents and automations introduce additional considerations. Unlike applications that someone opens and uses, they can continue running in the background. Their identities, permissions, and lifecycles need to be managed even when nobody is actively interacting with them.

These controls don’t eliminate the need for security reviews, particularly for sensitive applications. But they can reduce the number of decisions that need to be made separately for every new tool.

More importantly, they change what employees need to know before they can make something useful available to their colleagues.

The person in finance can focus on solving a finance problem. The security and infrastructure teams can focus on establishing and maintaining the environment in which those solutions operate.

Neither needs to take over the other’s job.

When everyone builds, guardrails must be built in

There’s an important distinction between making software easier to create and making it easier for an organization to adopt.

AI has made the first dramatically more accessible. The second still depends on infrastructure, security, ownership, and ongoing management.

As more employees begin creating applications, agents, and automations, organizations will increasingly need to treat these as a new category of internal software. Not necessarily production systems built by engineering teams, but not disposable experiments living in personal AI accounts either.

They need somewhere to run, a way to be shared, and someone who can remain responsible for them over time.

The traditional approach of reviewing each application, configuring its infrastructure, and managing its security individually may work when software creation is limited to a relatively small group of developers. It becomes much harder when hundreds of employees can build something new whenever they need it.

And adding another approval process doesn’t fundamentally change that equation.

This is why I think security and infrastructure are becoming inseparable in the context of employee-built software. The ability to deploy something safely depends on the environment it runs in, the permissions it inherits, and the controls the organization maintains around it.

Those capabilities need to be part of the foundation, rather than requirements each employee must figure out independently.

Shift down was originally proposed to reduce the operational burden on professional developers. AI is making the same principle relevant to people who have never written software before.

The difference is that we’re no longer just trying to help developers move faster. We’re trying to make software creation and deployment accessible to an entirely new population of builders, without asking them to become experts in everything that happens underneath.

When everyone can build software, the responsibility for keeping it secure cannot rest with everyone.

The next challenge for organizations isn’t teaching every employee to think like a developer.

It’s building the platform underneath them, so they don’t have to.