Proton's AI Manifesto for Engineers: "Programming Is Dead, Engineering Is Not"

Proton has published the memo its CTO wrote on AI for software engineers. The central line: "'Programming' is dead. Engineering is not, nor is expertise." Titled "Proton's AI manifesto for software engineering," the November 1 post is signed by CTO Bart Butler and sets out how the company wants its engineers to work with large language models.

It arrives days after 404 Media's report, "Manifestos, Fear, and 'Loser Thinking'", covered in our post on Proton's AI push that described pressure on staff and re-interviews. That earlier post covers what was reported. This one covers what the company itself now says in public, point by point, and what the memo leaves open.

TL;DR: the seven themes (our grouping; the memo does not number them)

What does the manifesto actually say?

Butler's memo, as published, makes a layered argument. The first claim is that models now write code well enough that manual coding is becoming obsolete for most tasks, in the way memorizing phone numbers did once phones stored them. Boilerplate, documentation and tests, which engineers often neglect, can be handled by models.

The second is competitive. Proton, the memo says, must adopt AI quickly to stay competitive and secure, and the change is already underway. The phrase "existential threat to the success of the mission itself" is the memo's own.

The third reframes the job: "Your job is to help the LLM write better code faster." Engineers become team leads, with models and agents as direct reports.

Importantly, the memo pushes back on a doom reading. It says this is "not the death of expertise" and "also not the death of good engineering practices." Humans bring experience, judgment and accountability, and are described as less prone to hallucination and manipulation than a model working alone.

What rules does it give engineers?

The memo is more practical than most manifestos. The concrete expectations, as we read them:

• Own the outcome and the process. You are responsible for the work and for how it gets done, including continuous automation.
• Build reusable context. Maintain repository-level context files and shared skills and prompts, so one person's improvement benefits everyone.
• Turn repeated failures into fixes. If the LLM fails the same way repeatedly, find the cause and fix it.
• Maximize AI autonomy. Push the model to work independently and step in only where it cannot succeed alone.
• Look across the lifecycle. Find bottlenecks in CI, reviews, approvals and specifications, not only in typing speed.
• Automate what was too expensive before.
• Share improvements, and escalate what needs company resources.
• Keep documentation and tests, but revisit how many you write.
• Experiment, but commit now.

Context files and shared skills are the same pattern readers see in public tools. Our guide to Karpathy-inspired Claude Code guidelines shows what a repository-level instruction file looks like in practice, and Karpathy's HackerTube build is a recent example of working almost entirely by conversation.

What does "phase 1" mean?

Theme six is the most interesting one for managers. The memo goes as far as saying "we need to and will get to a point where most human code review will end," a line that deserves more scrutiny than it has had. The memo calls using LLMs to speed up existing tasks only the first phase. The second phase is rethinking the entire software development lifecycle: continuous integration, design, approvals, specifications and code review.

The logic is a bottleneck argument. If code is cheap to produce, the slow parts become review, testing and sign-off. A team that only gives engineers a faster typist still waits on the same queues. That matches what other teams report: Epic Games told developers to go "AI first" per Bloomberg, and surveys on the verification tax suggest checking AI output eats a share of the saved time.

What does the memo leave out?

A manifesto is a statement of intent, not evidence. Reading the published text, these are the gaps:

The last row is notable: the memo itself says that company-wide change needs organization and investment Proton has not yet made. That is a candid admission, and it frames the text as the start of a program.

How does it connect to the 404 Media report?

Our earlier post summarizes a 404 Media report that described pressure on Proton staff to adopt AI, a claim that about 90% of code is AI-written, and re-interviews employees feared affected jobs. According to our post, Proton did not dispute that report. Proton has not said the memo is a response to it, and we do not claim it is.

We want to be precise about what the manifesto does and does not confirm. In the text we read, it does not state the 90% figure, does not address re-interviews, and does not describe job consequences. So the two documents should be read together, with the earlier one as reported claims and this one as the company's own account of its direction.

Why publish an internal memo at all?

Companies rarely release internal strategy memos, so the decision to publish is itself a signal. A public manifesto lets a company set the terms of its own story, recruit engineers who agree with it, and tell customers how the software they rely on is made. For a privacy-focused company, whose pitch rests on trust, explaining how code gets written is also a transparency move.

It carries a cost. Once published, the claims can be tested against practice. If the memo says engineers must own outcomes, readers will ask how bugs and security flaws in AI-written code get handled. If it says testing strategy should change as costs fall, someone will ask whether coverage fell. The memo does not give answers, so expect follow-up questions from users, security researchers and prospective hires, and watch whether Proton publishes measurements later.

What does this mean for teams deciding their own policy?

Few engineering leaders will copy a manifesto wholesale. A few parts travel well.

1. Put the context in the repo. A shared instruction file and a shared skills folder turn individual tricks into team assets. This is the most concrete advice in the memo.
2. Treat repeated model failures as bugs in your setup. Fix the cause, whether a missing doc, a flaky test or an unclear spec, instead of re-prompting.
3. Measure the whole pipeline. Track time from ticket to production, not lines produced. Phase two is about cycle time.
4. Write down accountability. If humans are accountable for AI-written code, say who reviews what.
5. Be honest about investment. Tooling, training and review capacity cost money. A mandate without budget produces the pressure stories that surface in the press.

For a view on how this fits the broader debate over AI and work, see our explainer on what vibe coding is.

What are people saying?

We did not find a Hacker News thread on the manifesto itself, so there are no hands-on reactions to cite yet. The earlier 404 Media story on Proton drew a large discussion that we summarize in our previous post. We will add reactions here if the manifesto thread develops.

Bottom line

Proton's manifesto is a clear, quotable statement of one company's AI direction: engineers lead models, hand-coding is no longer the core skill, and the whole lifecycle should change. It is also a mission statement without measurements, and by its own admission the organization has more to do. Read it as a position paper, compare it with the reported claims, and treat the practical advice on context files, failure analysis and lifecycle bottlenecks as the portable part.

Related reading

• Inside Proton's AI push: what 404 Media reports
• Epic Games goes "AI first": what Bloomberg reports
• The AI verification tax and how to cut it
• Karpathy-inspired Claude Code guidelines
• Karpathy's HackerTube build
• What is vibe coding?

Details are accurate as of November 2, 2026, from Proton's published memo. Check the original for edits.