Proton’s ‘loser thinking’ row: security culture meets AI-generated code
Somewhere in a busy Slack channel, an engineer asked for a few days to test new code before it shipped. That request is the part of the Proton story worth keeping.
At the end of August 2026, according to reporting by 404 Media, an employee at Proton, the Swiss company behind Proton Mail and Proton VPN, posted in the company’s security Slack channel. The request was modest. Before new code went out, could the team spend a few days pentesting it?
404 Media reports that chief executive Andy Yen replied: “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure.” In a follow-up message, the report says, he added: “only losers think like that.”
The exchange became the headline of a wider story about how Proton has been pushing AI-generated code through its engineering teams, and the reaction from staff and users has run for nearly two weeks. This journal is not the place to judge a company’s strategy or its products, and nothing in the reporting shows that any Proton product is insecure. We are interested in something narrower and more common. When the speed of AI-assisted development meets a person who asks for time to test, what happens next says a great deal about an organisation’s security culture.
The person who asked for those days is the one we want to write about.
What did Proton say in response?
Proton has acknowledged, more than once, that it handled the moment badly. A spokesperson told 404 Media: “It’s clear that some people at Proton are unhappy with our direction, or misunderstand it, and many people are anxious. In our determination to move fast, we have sometimes been too blunt or too slow in explaining ourselves to our people. We will work on that, as their questions are the ones we most need to answer.”
On 30 October the company went further in a public post on X. It said it “does not install tracking software on employees’ laptops to measure how much AI-generated code they produce”, and, as CyberInsider and IT-Connect reported, attributed that claim to a misunderstanding of how its device management software works. 404 Media’s original investigation had said Proton installed software on workers’ computers to track how much AI code the company generates; Proton’s denial stands against that account, and readers should weigh both. The statement also said Proton was not re-interviewing staff about AI usage, that no jobs would be lost as a result, and that its use of AI would “never come at the expense of security”. Proton said it had added security review layers over the past year and promised to publish how code reviews and security reviews are carried out, along with where AI is and is not permitted.
The company’s technology chief, Bart Butler, has made a related point in his own words. Decrypt reports that he stressed expertise and testing remain essential, and that engineers stay accountable for work models cannot reliably handle. “Programming is dead,” he told his team. “Engineering is not.”
That is the fair reading of the record as it stands on 9 November 2026: a sharp internal remark, reported by 404 Media from internal messages; a disputed claim about tracking, which Proton denies; a cancelled re-interview process; and a public commitment to show its review work. Decrypt, Cybernews, TechRadar and others have carried the story well beyond the technology press. Proton’s promised publication of its review process has not, as far as we can find, appeared yet.
Why did one Slack reply travel so far?
Proton’s users are an unusual audience. Many of them chose the company because it promised privacy and security first, and they read engineering culture as part of the product. Decrypt reported that a proposal on Proton’s own feedback forum calling for Yen to step down had 2,020 votes when it checked, and Cybernews reported users saying they had cancelled subscriptions.
The reaction makes more sense once you set the remark beside the rest of the reporting. 404 Media quotes Yen telling staff to “stop lovingly handcrafting all our code and use AI more”, and, in the follow-up report, to “stop thinking always of how to be slower, and focus more on how to be faster.” An internal document reviewed by 404 Media tied the pace of work to the company’s revenue targets. In that setting, a request for a pentest stopped being a routine step and became a question about which way the organisation leans when speed and assurance pull apart.
Security people recognised the scene at once, because most of them have stood in it.
Who is the hero of this story?
The engineer who asked. We do not know their name, and we should not try to find it. What we know is what they did: in a channel where the chief executive was present, during a push for speed, they asked for a few days to have someone try to break new code before customers depended on it.
That request is ordinary good practice. A penetration test exists to find what the author of the code did not imagine, and code generated quickly by a model needs that outside eye at least as much as code written slowly by hand. Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that the models chose an insecure implementation in 45% of cases, a rate that did not improve as the models got better at producing code that runs. The study measures tasks in a lab, not any one company’s codebase. It is still the clearest public evidence that AI output needs testing time, and it is the case that engineer was making in a single sentence.
Asking took a particular kind of nerve. 404 Media reports that some Proton employees had security concerns about building security products with AI and felt unable to voice them. The person in the security channel voiced theirs anyway, and they did it in the most constructive form available: a concrete, time-boxed proposal. Most security failures that reach the news began with a moment like this one, where someone saw the risk and either spoke or stayed quiet. The ones who speak are the reason many incidents never happen.
The other people worth naming here are the staff who kept raising concerns through the re-interview plan, the colleagues who asked the uncomfortable questions in meetings, and the users who held a security company to the standard it sets for itself. One employee told 404 Media that the cancellation came only after the plans became public, despite concerns raised by many staff. Whatever one makes of the outcome, people inside the organisation kept the security question on the table.
What does this say about security culture in the age of AI code?
Security culture is easiest to see at the moment someone asks for time. Policies, review gates and secure development standards all look the same on paper. The difference shows when an engineer says “not yet” and the people above them decide what that sentence costs.
AI coding assistants raise the stakes of that moment because they change the ratio. One engineer with a capable model can now produce far more code in a week than a reviewer can read or a tester can probe. If leaders measure success by output, the queue of untested code grows quietly, and every request for testing time looks like friction. If leaders measure what was reviewed and tested before release, the same request looks like the job being done.
The healthiest teams share one habit here. The person who pushes back is thanked in the same room where speed is celebrated. Their objection is written into the process, so the next engineer does not have to argue for it from scratch.
Why recognise the people who push back?
Organisations reward what they can see. Shipped features are visible; the vulnerability that a three-day pentest caught before release is not, because it never became an incident. The engineer who asked for those days rarely appears in a quarterly review, a launch announcement or an industry shortlist. Their best work is the absence of a headline.
That is why the panel reads nominations for exactly this kind of evidence. The Cyber Security Professional of the Year criteria ask for dedication shown through “a proactive approach to addressing challenges”, and for evidence of supporting colleagues. A tester who built review time into an AI-heavy pipeline, or an engineer who held a release until it was safe and then taught the team why, meets that standard squarely. Where a whole group made testing part of how they ship, the Security Team of the Year category is the better fit.
Every nomination is read in full, and none of it can be bought. If you have worked beside someone who asked for time to test when it was unpopular to ask, nominations for the 2027 Awards open on 1 December 2026. Their name belongs on a nomination form more than it belongs in a Slack thread.
Sources
- 404 Media: “Manifestos, Fear, and ‘Loser Thinking’: Inside Proton’s AI Reckoning”, Joseph Cox (29 October 2026). Source of the Slack exchange, the spokesperson statement and the tracking-software claim.
- 404 Media: Proton to re-interview staff about AI, Joseph Cox (26 October 2026).
- 404 Media: Proton’s CEO cancels AI re-interviews, Joseph Cox (30 October 2026).
- CyberInsider: Proton’s public statement on X, the tracking-software denial and the 4 to 11 November re-interview dates (31 October 2026).
- IT-Connect: Proton responds to AI criticism and promises more transparency (2 November 2026).
- Decrypt: Proton users revolt after CEO calls security caution “loser thinking” (2 November 2026). Source of the forum vote count and Bart Butler’s remarks.
- Cybernews: Proton users cancel subscriptions following CEO Andy Yen’s “loser thinking” remarks.
- TechRadar: Proton apologises to its community after the internal memo.
- Veracode: 2025 GenAI Code Security Report findings (30 July 2025).
The Proton row and security culture, answered
What was the Proton “loser thinking” row?
On 29 October 2026, 404 Media reported that a Proton employee had asked in the company’s security Slack channel, at the end of August, for a few days to pentest new code before release. According to the report, chief executive Andy Yen replied: “That’s bullshit and loser thinking. Of course it’s possible to be fast and secure,” and in a follow-up wrote that “only losers think like that.” The report was based on conversations with current and former staff, Slack messages, meeting recordings and an AI manifesto, and described a wider push for AI-assisted coding inside the company.
How did Proton respond to the reporting?
A Proton spokesperson told 404 Media that “in our determination to move fast, we have sometimes been too blunt or too slow in explaining ourselves to our people.” On 30 October Proton posted a public statement on X saying it “does not install tracking software on employees’ laptops to measure how much AI-generated code they produce”, attributing that claim to a misunderstanding of device management software. It said its use of AI would “never come at the expense of security”, that there would be no job losses from AI re-interviews, and that it would publish how its code reviews and security reviews are done.
Were Proton’s AI re-interviews cancelled?
Yes. 404 Media reported on 26 October 2026 that Proton planned to “re-interview” staff about their use of AI, in sessions an internal email described as “consequential”. CyberInsider reported the sessions were scheduled for 4 to 11 November. On Friday 30 October, according to 404 Media, Andy Yen cancelled them, acknowledged a failure of communication and said he would keep pushing staff to adopt AI.
Is AI-generated code less secure than human-written code?
It needs the same testing, and sometimes more. Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that the models chose an insecure way of writing the code in 45% of cases. Security performance did not improve as the models got better at producing working code. The figure describes tasks in a controlled study, not all AI-written code, but it is a strong argument for keeping review and testing time in any pipeline that uses AI assistants.
How can organisations build a security culture where people can ask for time to test?
Make the test a step of the pipeline rather than a favour someone has to ask for. Teams that budget review and penetration-testing time into each release, and that measure how much of the code shipped was reviewed and tested rather than how much was produced, remove the need for an engineer to argue for time in a public channel. Leaders also set the tone by thanking the people who raise risks before release, in the same places where they celebrate speed.
What a penetration test actually proves
A scan, a penetration test and a red team are not the same thing. What each proves, and the limits of a test.
AI and the defender: augmentation, not replacement
The work that keeps an organisation standing still runs through a person reading the screen at midnight.
Red-teaming an AI system: what actually breaks
Prompt injection, excessive agency and tool misuse, framed by the OWASP LLM Top 10 and the NIST AI RMF.