Proton’s AI Manifesto Says Programming Is Dead

Proton CTO Bart Butler published an AI engineering manifesto on November 1, 2026, arguing that putting language models into existing development workflows is no longer enough. His proposed change reaches across the software development lifecycle, or SDLC: design, specifications, code generation, continuous integration, approvals, and review.

The document began as an internal memo roughly a month earlier. It was already circulating publicly before Proton published it, with Business Insider reporting on the memo on October 31.

Butler’s headline argument is deliberately sweeping:

“Programming” is dead. Engineering is not, nor is expertise.

That is a claim about how engineering work should be organized, not evidence that manual programming has disappeared. The substantive proposal is to make engineers responsible for directing agents, improving their working environment, and removing bottlenecks throughout delivery.

For engineering managers, the useful part is the distinction between producing code faster and shipping dependable software faster. Proton’s manifesto makes the case for reorganizing around that distinction, while leaving important implementation questions unanswered.

Engineers Become Responsible for the Agent Workflow

Butler frames the change in unusually direct terms: “Your job is to help the LLM write better code faster.”

In Proton’s manifesto, each engineer effectively becomes a team leader whose workers are models and agents. The expectation goes beyond prompting a chatbot, checking its answer, and copying code into an editor. Agents should be able to continue working autonomously, including while their human supervisor is occupied elsewhere.

That changes the unit of improvement. Fixing one generated function solves an immediate problem. Improving the instructions, context, or tooling that caused the mistake could prevent the same failure across many future tasks.

Butler identifies several concrete responsibilities:

• Maintain repository-level context files. Give agents persistent guidance about the codebase and its conventions.
• Share reusable skills and prompts. Make effective approaches available beyond the engineer who discovered them.
• Investigate repeated failures. Treat recurring mistakes as problems in the working system, instead of endlessly correcting individual outputs.
• Expand autonomy deliberately. Identify what agents can handle independently and where human intervention remains necessary.

My view is that the repeated-failure point is the strongest management advice in the document. If every engineer repeatedly explains the same architectural constraint to an agent, the organization has a shared-context problem. Better instructions may help, but enforceable checks or clearer module boundaries could be more durable fixes.

Butler also preserves a distinction between the model’s output and the engineer’s responsibility. Humans bring experience, judgment, and accountability to the work. His proposed redistribution of tasks does not transfer that accountability to the model.

Faster Coding Can Leave Delivery Almost Unchanged

The manifesto identifies three connected obstacles: engineering culture has not fully changed, teams remain focused on accelerating individual tasks inside existing workflows, and automation has not extended far enough across delivery.

These are organizational problems, not simply model-selection problems.

A team can generate an implementation quickly and still spend days waiting for an architectural decision, a test environment, or an approval. Increasing code production may then create a larger review queue without changing how quickly users receive reliable improvements.

Consider a deliberately simplified example, not a Proton measurement:

• A change takes two hours to implement.
• Testing, review, and waiting take another eight hours.
• AI cuts implementation time in half, while everything else stays unchanged.

The total falls from ten hours to nine: a 10% reduction, despite a 50% reduction in implementation time. Real delivery pipelines involve overlapping work, but the example shows why a large local gain can produce a modest overall result.

This is the practical force of Butler’s argument about moving beyond the first phase of adoption. Teams need to identify the constraint that actually determines delivery time. If review capacity is the constraint, generating more patches could increase unfinished work.

I would assess an agent rollout by whether it improves the path from an agreed requirement to a safe production change. Generated lines of code and agent activity can describe workload; they cannot, by themselves, demonstrate useful delivery.

What an Agent-Centered SDLC Would Change

Proton’s post calls for examining bottlenecks across design, specifications, continuous integration, approvals, and review. It does not supply a finished operating procedure for each stage.

The table below translates that direction into practical workflow choices. These are analytical recommendations, not a description of systems Proton has already deployed.

Continuous integration, or CI, is the automated build-and-test process that checks changes as they enter a shared codebase. It becomes especially consequential when agents can produce changes faster than people can inspect them. Slow checks delay feedback; unreliable checks make failures harder to interpret.

Specifications matter for a related reason. An agent can complete a task exactly as described while missing what the requester intended. Clear acceptance criteria give both the agent and the reviewer a more useful target than a loosely worded feature request.

The management challenge is deciding which friction to remove. A duplicated approval might be waste. An independent review of an authentication change may be a valuable control. Both consume time, but their purposes differ.

Cheaper Test Writing Changes Only Part of the Equation

Butler argues that engineering practices should evolve when their underlying costs change. His example is testing: if AI makes tests cheaper to write and maintain, teams may find it worthwhile to maintain more of them, including end-to-end tests.

That is a conditional economic argument, not a measured Proton result. End-to-end tests exercise a complete user journey across several components, so they can catch integration failures that narrower tests miss.

But cheaper generation addresses only part of their cost. A larger suite can still consume compute, lengthen CI runs, produce intermittent failures, and require investigation when something breaks. Those costs remain relevant even if an agent writes the initial test.

The useful response is to revisit the tradeoff with evidence. Teams could track test execution time, intermittent failure rates, maintenance effort, and the defects a suite catches. More tests are valuable when they improve confidence enough to justify their continuing cost.

This is a broader lesson in the manifesto: changing the cost of one activity can justify redesigning a process, but it does not automatically make every downstream activity cheaper.

Human Expertise Needs a Development Plan

Butler’s model depends on experienced engineers recognizing when an agent is wrong. That raises a workforce question: how do engineers acquire and maintain that judgment if they spend less time implementing software themselves?

In one Hacker News discussion, commenter rlvesco7 raised both skill atrophy and the development of junior engineers. Those are one participant’s concerns, not evidence that Proton’s engineers have lost expertise, but they expose a dependency in the proposal.

Repository guidance can preserve explicit rules. It cannot automatically reproduce the learning that comes from diagnosing a race condition, tracing a production failure, or discovering why an apparently clean abstraction becomes difficult to maintain.

An agent-centered organization would therefore need an intentional training path. Useful options include bounded implementation work, debugging exercises, design reviews, and incident analysis. The goal would be to develop engineers who can explain a system’s behavior and challenge a plausible but incorrect implementation.

I would treat that training as infrastructure for autonomy. Delegating more work safely requires people who can recognize when the delegation has failed.

Security Is the Missing Operational Layer

Butler explicitly says the manifesto is not an in-depth engineering document and leaves security, reliability, and infrastructure specifics outside its scope. The published material also provides no measured productivity results or rollout schedule. It supports analysis of Proton’s intended direction, not a verdict on the effectiveness or safety of its implementation.

For a privacy-focused software company, those missing details carry particular weight. Granting agents more autonomy changes what they can access, execute, modify, and submit for approval.

A workable implementation would need explicit answers about:

• Permissions: Which repositories, environments, and credentials can an agent access?
• Data handling: What source code, logs, or sensitive information may enter a model’s context?
• Untrusted input: How should agents handle instructions embedded in issues, documents, dependencies, or tool output?
• Release authority: Which actions require an accountable human decision?
• Traceability: What records connect a requirement, an agent’s actions, test results, approval, and the deployed change?

These are requirements suggested by the proposed workflow, not controls Proton documents in the manifesto.

The public response also shows why delivery speed alone is an incomplete objective. In the same Hacker News thread, commenter Dxtros emphasized paying Proton for privacy and security, questioning the value of faster development on its own. That comment represents its author, not Proton’s customer base as a whole.

For this kind of product, a useful outcome measure must include preserved security properties and operational reliability. Faster delivery matters when the changes are worth delivering.

How Teams Can Assess the Proposal

Engineering leaders can evaluate Butler’s workflow argument without accepting his claim that manual programming is obsolete.

A sensible starting point would be one bounded class of changes with clear acceptance criteria, limited permissions, and an existing review process. Measure the full path through delivery before expanding autonomy.

Useful measures include:

• Time from an accepted requirement to deployment.
• Time spent waiting for CI, review, or approval.
• Rework after an agent submits a change.
• Defects discovered after deployment.
• Human effort spent supervising and correcting agents.

The measurement challenge also connects with Zeniteq’s coverage of Larridin’s $30 million raise to measure enterprise AI ROI.

Proton’s most actionable proposition is that engineering teams should redesign their delivery system when its economics change. Applying that proposition responsibly means removing avoidable waiting, making requirements clearer, and automating repeatable work while preserving the controls and expertise that make a release trustworthy.