Proton's AI manifesto and what it means to lead coding agents

Proton’s CTO, Bart Butler, wrote an internal document called “AI @ Proton, Engineering Manifesto”. Joseph Cox of 404 Media obtained multiple copies and published it on October 29, 2026, as part of an investigation titled Manifestos, Fear, and ‘Loser Thinking’: Inside Proton’s AI Reckoning.

The line everyone is quoting is this one:

“Your job has fundamentally changed. It is no longer to write code, and LLMs are not here to help you write better code faster. Your job is to help the LLM write better code faster.”

Uncle Bob Martin shared his own version, which he described as paraphrasing and stealing: “Your job is not to use agents to help you write code. Your job is to lead the agents to help them write code.”

I think the idea is mostly right. I also think the way it was pushed inside Proton shows how to get it wrong.

What the manifesto says

Butler argues that writing great code by hand is “a core skill whose time has passed”, like memorizing phone numbers. He writes that “every engineer is now a team leader, a manager, and your direct reports are the models and agents you use.”

That leadership is concrete in the document. When the model can’t solve a problem, the engineer should help it solve the problem this time and better next time, “not just for you but for everyone”. He lists the tools for that: “repository-level context files, shared skills and prompts, and habit of ensuring that repeated failures trigger an investigation and a fix.”

He also says this is “not the death of expertise” and “not the death of good engineering practices”. Documentation and tests “remain crucial”. The engineer is described as “accountable to yourself, your teammates, and to Proton in a way a model can never be.”

Then he goes further. Writing code was only the first bottleneck. The next ones are CI capacity, design, approvals, specifications, and code review, with this in parentheses: “yes, we need to and will get to a point where most human code review will end.”

According to 404 Media’s reporting of meeting audio, Butler said AI wrote about 90% of Proton’s code in October, and employees said much of it came from Anthropic’s Claude (via The Next Web).

Where I think it’s right

The job has moved. If an agent writes most of the diff, the valuable work is everything around it. You decide what to build, describe it precisely, give the agent the context it lacks, and judge the result.

The best part of the manifesto is the idea that a failure should improve the system. If the agent keeps using the wrong test command, the fix is a line in AGENTS.md, so you don’t correct it again tomorrow. If it keeps misreading a module, that module probably needs documentation, or a clearer interface. You improve the conditions so the next attempt goes better.

I also agree that “you own how it gets done”. Speed comes from things that aren’t code. A slow test suite costs more when an agent runs it after every change, which is why fast tests for agents are worth the effort.

Where the pushback is fair

The manifesto is one document. The 404 Media investigation describes the environment it landed in, based on eight current and one former employee, Slack chats, and meeting recordings.

In the company’s security Slack channel, an employee asked for a few days to pentest newly written code before it went live. CEO Andy Yen replied: “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure.” He added: “Stop thinking always of how to be slower, and focus more on how to be faster.”

The article also reports that Proton installed software on employees’ computers to track how much AI code the company generates. It planned to “re-interview” staff about their AI use, with the implication that the result could affect their jobs.

My take is that this contradicts the manifesto’s own argument. Butler writes that humans are “much less prone to hallucination and being mislead by bad or malicious inputs” than models. That is the reason to keep a person in the loop. A security engineer asking for a pentest is that person doing the job. Calling it “loser thinking” in front of the team makes the next person less likely to speak up.

A leader of agents needs to hear about failures. The manifesto asks engineers to “flag and escalate needed improvements”. People only do that when raising a problem is safe. 404 Media describes employees who “feel unable to voice” security concerns. In that environment, a repeated failure is more likely to be worked around quietly than investigated.

Measuring the share of AI-written code has a similar problem. It counts the input. A team can push that number up and ship more bugs at the same time. What you care about is whether the change works, whether it’s secure, and whether someone can maintain it next month.

The goal of ending most human code review deserves caution too, especially at a company that sells encrypted email and a password manager. Review can change shape. You can rely on agent reviewers and automated checks for low risk changes. Removing the person from the risky ones is a different decision.

Proton’s response came quickly. A spokesperson told 404 Media: “In our determination to move fast, we have sometimes been too blunt or too slow in explaining ourselves to our people.”

The next day, 404 Media reported that Yen canceled the re-interviews at an all-hands meeting. He said: “Going forward, I’m still going to push.” Butler said: “Using AI effectively and pragmatically does not mean that we’ve given up on security, or good architecture, or sound software engineering principles.” One employee told 404 Media that the things the re-interviews would have measured would become part of performance reviews.

What leading agents looks like day to day

Put the company drama aside and the useful question remains: what do you do differently if your job is to lead the agents?

Here is what I would do on a product, whether you work alone or in a team.

1. Write the expected behavior before the prompt. Say what should happen, what shouldn’t, and how you will check it. “Fix password reset” leaves the important decisions to the agent.
2. Put recurring context in the repo. Commands, conventions, and files to leave alone belong in AGENTS.md, where every session reads them.
3. Treat a repeated mistake as a bug in your setup. The second time you correct the same thing, change the instructions, the tests, or the code that confuses the agent.
4. Give the agent fast checks. A focused test that runs in seconds lets it correct itself without waiting on you.
5. Review by risk. A copy change can go through automated checks. Authentication, payments, permissions, and anything touching user data need a person who reads the diff. I wrote a pull request workflow for agent-written code around this idea.
6. Keep security work on the schedule. If AI makes writing code cheaper, some of the saved time can go to the security review. It also means attackers get faster.
7. Measure outcomes. Track bugs, incidents, time to ship, and how often you revert a change. The percentage of AI-written lines tells you none of that.

These practices work without a company-wide mandate. They need someone who stays responsible for the result after the agent finishes, which is the part of Butler’s document I would keep.

If you want to practice that judgment on a real task, start with practicing engineering judgment with AI, then use AI to understand the code before you let it change anything important.

Want me to talk about your product? You can sponsor this site.