Proton's AI Manifesto Is Mostly Right. But the Real Engineering Revolution Goes Further.

The Controversy Is Obscuring an Important Argument

I follow a technology commentator who recently discussed Proton CTO Bart Butler's controversial internal AI engineering manifesto.

Rather than immediately condemning the document, he took a different approach in his TikTok video ↗.

He read several passages directly and offered a reaction that closely mirrors my own:

"I'm not sure I find the core argument that controversial."

He followed that with another observation:

"A lot of it actually makes sense."

I agree.

In fact, much of what Butler describes reflects how I already approach software development as a founder building multiple AI-driven products.

However, I think the manifesto leaves out some of the most important architectural and organizational implications of the transition.

And the controversy surrounding Proton's leadership illustrates why those omissions matter.

The challenge isn't simply getting engineers to use AI. It's fundamentally redesigning how engineering organizations create, evaluate, and deliver value.

That's a much bigger transformation than generating code faster.

What Proton's CTO Actually Got Right

Butler's internal manifesto, published in the October 29 investigation by 404 Media ↗, advances several arguments about the changing role of software engineers.

One particularly important statement is:

"Your job is to help the LLM write better code faster."

That reverses the conventional relationship between developer and development tool.

Traditionally, we think of AI as something that helps programmers perform their existing tasks.

But Butler is arguing for something fundamentally different.

The engineer increasingly becomes responsible for directing a workforce of AI models and agents.

Instead of manually performing every implementation step, the engineer defines objectives, supplies context, establishes constraints, evaluates results, and coordinates execution.

I agree with that direction.

I've experienced the productivity difference firsthand.

But the real advantage isn't simply that an LLM can produce code faster than I can type it.

It's that AI allows me to operate across disciplines and responsibilities that traditionally required multiple specialists, teams, and organizational boundaries.

That's where the productivity gains become substantial.

The Founder's Advantage: AI Across the Entire System

I've previously argued that founders who develop their own products with AI can sometimes achieve dramatically greater productivity than developers working within conventional organizational structures.

That isn't necessarily because founders are better programmers.

It's because their responsibilities are fundamentally different.

When I'm building a product, I am simultaneously considering its business model, architecture, data structures, user experience, security, deployment, operating costs, and future capabilities.

I don't need to stop at the boundary of a development ticket.

I can move directly from identifying a customer need to prototyping a solution, testing an architectural approach, evaluating its security implications, and integrating it into a larger product.

AI makes those transitions dramatically easier.

It allows one person to explore an extraordinary amount of technical and product territory.

A developer operating inside a traditional organization may use exactly the same AI tools but remain constrained by narrowly defined responsibilities, fragmented system knowledge, handoffs, and existing processes.

Consequently, two equally capable engineers may achieve vastly different results.

This isn't necessarily a failure of the individual developer.

It's a limitation of the organizational environment.

The productivity multiplier comes from combining AI capabilities with broad system understanding and the authority to act on that understanding.

That is why I think Butler is correct to argue that using AI within existing workflows is only the first stage of transformation.

If an organization simply accelerates programming while preserving all the surrounding bottlenecks, it may never realize the full opportunity.

AI Doesn't Just Change Who Writes Code. It Changes the Entire Workflow.

Consider a typical enterprise software delivery process.

A business requirement is gathered. Product management translates it into specifications. Architects review the design. Developers implement it. Other developers review the code. Security teams evaluate risks. QA tests the implementation. Operations eventually deploys it.

Each step serves a purpose.

But each step also creates potential delays, information loss, and coordination overhead.

Now imagine AI can substantially accelerate implementation.

What happens?

The bottleneck moves to the next slowest activity.

Perhaps requirements are ambiguous. Perhaps architecture review takes too long. Perhaps security testing or integration is consuming most of the delivery cycle.

Simply making developers produce code faster doesn't solve those problems.

It can make them more visible.

Butler's manifesto argues that organizations need to examine their processes holistically instead of treating AI as an incremental coding assistant.

That is exactly the right direction.

I would take it further.

The objective should be to create a development environment where requirements, architectural constraints, implementation, testing, security policies, and deployment decisions can participate in a coordinated process.

AI agents can work across those activities, but their actions need to be governed by explicit contracts, independent validation, and observable execution.

This is one of the ideas behind my work on Living Prompt Contracts and auditable AI workflows.

An AI agent shouldn't simply receive a prompt and produce something plausible.

It should understand what success means, what constraints apply, what evidence is required, and what happens when a validation fails.

The result is a much more capable engineering process than a collection of developers independently prompting coding assistants.

Every Engineer May Become an AI Team Leader. But Who Manages the Team?

One of the more interesting ideas in Butler's manifesto is his comparison between engineers and managers.

Models and agents effectively become the engineer's direct reports.

I think that's a useful metaphor.

But anyone who has managed a technical team knows that delegation alone does not guarantee productivity.

You need objectives, responsibilities, communication, standards, review mechanisms, and accountability.

AI agents are no different.

If anything, they make these requirements more important because they can execute tasks at a scale and speed that humans cannot continuously supervise.

Consider an autonomous coding agent with access to a repository, test environment, deployment pipeline, and external services.

It might be exceptionally productive.

But what prevents it from exceeding its authorized scope, introducing a security vulnerability, leaking sensitive information, or making an incorrect architectural assumption?

The answer cannot simply be that another model will review it.

AI-based review can be extremely useful, but the entire process should not depend on the judgment of models operating without independent constraints.

This is where I believe the next generation of engineering architecture needs to develop.

An AI-native development platform should support:

• Explicit contracts: What an agent is authorized and expected to accomplish.
• Scoped execution: Which tools, data, repositories, and external systems it can access.
• Independent validation: Deterministic checks alongside AI-assisted evaluation.
• Traceable decisions: Why changes were made, what evidence supported them, and who approved them.
• Human intervention: Clear escalation points when uncertainty, risk, or policy requires judgment.

This is not an argument against autonomous agents.

It's how we make greater autonomy practical.

The goal is not to keep a human in every loop. It is to build systems where autonomy can expand without surrendering accountability.

Expertise Becomes More Valuable, Not Less

Another point from the manifesto deserves more attention.

Butler acknowledges that AI models are fast, while experienced engineers bring judgment, contextual understanding, and lessons accumulated over years of building systems.

This distinction is critical.

A model can generate a convincing implementation without fully appreciating the implications of using that implementation in a particular environment.

It might produce something technically functional but architecturally inappropriate.

It might solve the immediate problem while introducing unnecessary complexity.

It might pass tests that fail to cover an important security or operational requirement.

Experienced engineers are often able to recognize these issues because they understand the broader system and have encountered similar problems before.

That experience doesn't suddenly become obsolete when AI writes the code.

It changes where the experience is applied.

Instead of spending most of their time producing implementation details, engineers can devote more attention to architecture, system behavior, constraints, verification, and design decisions.

I also believe AI allows that expertise to be applied more broadly.

An experienced architect can use AI to explore alternatives, challenge assumptions, prototype competing implementations, and evaluate systems far more rapidly than before.

The engineer's responsibility shifts toward directing and validating increasingly sophisticated work.

But expertise still determines whether that work is appropriate.

And there is an important caveat: we cannot assume that experience alone guarantees good judgment. Engineering expertise itself must remain open to questioning, measurement, and improvement.

Where Proton's Leadership Controversy Matters

This brings us to the uncomfortable part of the story.

404 Media reported that Proton CEO Andy Yen criticized an engineer who requested additional penetration-testing time before deploying code.

Yen characterized the concern as "loser thinking" and urged employees to focus on moving faster.

The investigation also described employees who reportedly felt reluctant to challenge leadership over engineering decisions.

These are serious concerns, although they should be distinguished from independently verified findings about Proton's actual product security.

And I think they reveal a fundamental contradiction.

If engineers are becoming managers of AI agents, then their judgment becomes more important, not less.

If leadership discourages engineers from challenging assumptions or identifying risk, it undermines precisely the expertise that an AI-native engineering organization needs.

There is nothing inherently wrong with challenging a request for additional testing time.

Perhaps the testing could be automated. Perhaps the existing controls were already sufficient. Perhaps a different approach could provide better security assurance faster.

Those are legitimate engineering questions.

But the correct response is to evaluate the risk and improve the process.

Not to discourage the engineer from raising the concern.

In an AI-native organization, the ability to challenge assumptions is essential.

Agents will generate solutions quickly. They will occasionally generate incorrect solutions just as quickly.

A culture that prioritizes visible velocity over informed technical disagreement risks accelerating mistakes.

Security Should Accelerate With AI, Not Be Sacrificed for It

I actually agree with the broader proposition that faster development and stronger security are not mutually exclusive.

The assumption that secure software must necessarily take longer to develop deserves to be challenged.

AI can assist with threat modeling, dependency analysis, fuzz testing, code review, vulnerability detection, and regression testing.

Some verification activities that previously required substantial manual effort can become dramatically faster.

But there is a major difference between accelerating verification and bypassing it.

For enterprise systems, I favor architectural security controls that don't rely exclusively on model behavior.

That includes sandboxed execution, constrained tool permissions, policy gates, data isolation, audited access, and deterministic enforcement.

In particularly sensitive environments, even a highly capable open-weight model should not automatically receive unrestricted access to external systems or confidential data.

The tools and execution environment should enforce the boundaries.

This approach can reduce the cost of security while making controls more consistent and easier to audit.

And it creates a foundation for granting AI agents greater autonomy as the evidence supports it.

If AI can generate software ten times faster, our verification architecture needs to evolve accordingly.

Otherwise, we're only moving the risk downstream.

Stop Measuring AI by How Much Code It Produces

According to 404 Media, Butler stated during an internal meeting that AI generated approximately 90% of Proton's code in October.

That's a remarkable figure if the measurement is accurate.

But what does it actually tell us?

We don't know from that percentage whether the resulting software was better, easier to maintain, more secure, or more valuable to customers.

We don't know how much generated code required rework or how much integration effort was involved.

And we don't know whether the volume of generated code translated into faster delivery of verified functionality.

These are the things I would want to measure.

In fact, I would prefer an AI system that eliminated 10,000 lines of unnecessary complexity over one that generated 100,000 lines of additional code.

The interesting metrics for AI-native engineering should include:

• Delivery — Time from requirement to verified production outcome
• Quality — Defects, regressions, reliability, and rework
• Security — Risk exposure, validation coverage, and remediation
• Architecture — Complexity, maintainability, and integration
• Economics — Total cost of producing and operating the system
• Value — Customer and business outcomes actually achieved

These measures are not always simple, and no single metric should dominate.

But they are much more informative than counting AI-generated lines of code or measuring how frequently employees use a particular model.

The objective is productive engineering, not AI activity for its own sake.

Proton's Response Is an Opportunity to Prove the Model

Following the reporting and public criticism, Proton canceled its proposed employee AI re-interviews on October 30.

Yen acknowledged communication failures while maintaining the company's commitment to AI adoption.

Butler also said that effective AI use did not mean abandoning security, architecture, or sound software-engineering principles.

In a subsequent public statement ↗, Proton disputed claims about employee-monitoring software, said it had added security-review layers, and committed to publishing more information about its internal AI development and review processes.

These are constructive commitments.

They create an opportunity for Proton to demonstrate how an established security-focused company can redesign engineering around AI while preserving the trust its customers expect.

I would be particularly interested in seeing how Proton separates autonomous code generation from independent security controls, how it audits agent actions, and how it measures the outcomes of its AI transformation.

The company could turn a difficult public controversy into a valuable engineering case study.

But the evidence will matter more than the rhetoric.

Programming May Be Dying. Engineering Is Expanding.

Butler closes his manifesto with a provocative distinction:

"Programming is dead."

He immediately makes clear that engineering and expertise are not.

I understand the point.

The mechanical process of translating requirements into source code is becoming less central to the value a software engineer provides.

But software engineering was never simply about typing code.

It has always involved understanding problems, designing systems, making tradeoffs, managing complexity, identifying risks, and producing solutions that work reliably.

AI doesn't eliminate those responsibilities.

It potentially allows us to perform them at an entirely different scale.

And I believe we are still early in understanding what that means.

The next generation of software organizations may not resemble traditional development teams.

They may operate more like coordinated networks of human experts and specialized AI agents, with shared context, explicit contracts, automated evaluation, and continuously observable systems.

Individual engineers may supervise entire collections of agents performing work across traditionally separate disciplines.

Small companies may build and maintain products that previously demanded much larger engineering organizations.

And experienced engineers may become capable of solving problems that were previously impractical because of time, cost, or organizational complexity.

This is the future I am exploring in my own development work.

But it requires more than enthusiasm for AI tools.

It requires rethinking the underlying architecture of how software is created.

My Conclusion: The Manifesto Is a Beginning, Not a Complete Blueprint

I agree with the creator I follow who questioned whether Proton's manifesto is really as controversial as the reaction suggests.

I agree with Butler that engineering roles are changing fundamentally.

I agree that simply adding AI assistants to existing workflows misses much of the opportunity.

And I agree that experienced engineers should increasingly direct and coordinate AI agents rather than manually implement every detail.

Where I go further is in what that transformation requires.

AI-native engineering needs more than autonomous agents.

It needs shared context, enforceable contracts, scalable validation, secure execution environments, observability, and clear accountability.

It needs organizational structures that let people work across traditional boundaries.

And it needs leaders who understand that constructive technical disagreement is part of engineering, not an obstacle to progress.

The controversy at Proton should not distract us from the larger transformation underway.

But neither should the promise of that transformation excuse poor management practices or weaker engineering controls.

The future isn't about replacing developers with models. It's about giving capable engineers leverage over entire systems of intelligent execution.

The winners won't necessarily be the companies generating the most code.

They will be the ones that redesign their organizations and technical architectures to turn AI's extraordinary capabilities into reliable, measurable results.

Programming is becoming a smaller part of engineering. The opportunity—and responsibility—of engineering is becoming much larger.