Proton's AI Reckoning: Is There Still IT for Engineers? Yes, With a Different Job

What happened at Proton

Proton sells privacy. Its customers pay for the promise that someone competent is worrying about their data. On 29 October, 404 Media published a report based on conversations with eight current employees and one former employee, plus Slack messages, meeting recordings and an AI manifesto written by Proton’s CTO.

What it reports, with the caveat that much rests on anonymous sources:

• In an August Slack thread, an employee urged a few days of pentesting before release. CEO Andy Yen replied that this was “bullshit and loser thinking”, adding “Of course it’s possible to be fast and secure” and telling staff to “stop lovingly handcrafting all our code and use AI more.”
• Yen also reportedly wrote “This will be the last year that we hire engineers”, and set up an email address so staff can flag anything blocking AI “velocity”.
• Proton installed software on employee computers to track how much code AI writes. According to The Next Web’s summary, the CTO said in a meeting that AI wrote 90% of Proton’s code in October. That figure is a statement from a meeting, not an audited measurement.
• A 26 October internal email announced “consequential” re-interviews about AI use, scheduled for 4 to 11 November, with outcomes feeding a review that could affect roles and “continued employment”.
• An internal document reportedly says Proton is off its ARR target “due to insufficient velocity”.

Proton’s spokesperson did not dispute the reporting. The statement said: “In our determination to move fast, we have sometimes been too blunt or too slow in explaining ourselves to our people.” On 30 October 404 Media reported that Yen cancelled the re-interviews, the day after the first story. Proton says it is not doing layoffs, is not using AI as an excuse, and is still hiring. Secondary reports say Yen told staff at an all-hands that it was a communication failure but that he is still going to push.

Allegation versus fact: the quotes, documents and Proton’s non-denial are the documented part. The “climate of fear” and the personal characterisations of the CEO are what anonymous employees told the reporter.

What Proton gets right

Strip out the tone and there is a real point. AI coding tools are now part of how software gets built, and a company that ignores them will be slower than one that does not. Handcrafting every line is not a virtue. Nobody is paid for typing.

But “use AI more” is an instruction, not a result. And the honest answer about speed is that nobody fully knows:

• In 2025, METR ran a randomised trial with 16 experienced open-source developers on their own repositories. They took 19% longer with AI tools, yet afterwards believed AI had made them about 20% faster.
• METR’s February 2026 follow-up, per summaries of its post, found some evidence of speedup with newer tools but said selection effects (developers declining tasks they could not do with AI) made the estimate unreliable. METR is moving away from the original design.

So: speed gains are plausible, vary by task and tool, and feel larger than they measure. That is exactly why you measure outcomes instead of mandating adjectives.

What Proton gets wrong

Velocity is not the goal. Working software is. Tracking how much code AI writes measures input, not value. It is a privacy company measuring how much of its code nobody wrote. The moment you reward the percentage, people will generate more code, and more code is more surface to defend. (Our opinion, and Goodhart’s law is on our side.)

Security testing is not “loser thinking”. Veracode’s 2025 study tested more than 100 models on 80 tasks and found AI introduced security flaws in 45% of cases. Models picked the insecure option in 45% of choices, and larger models did not do meaningfully better. Faster generation plus unchanged security quality equals more vulnerabilities per week. The only way to be fast and secure, as Yen said, is to test. Even Super Intelligence needs a pentest.

Fear is a bad monitoring system. If engineers are afraid to raise a security concern, your risk register is empty and your risk is full. The reported culture of hesitation is the real incident here, because the first person to find the bug will be the last person to say so.

Cutting engineer hiring confuses cost with value. If code generation gets cheaper, the code is not the product. The product is a system that works, is secure, and solves a problem someone pays for. Those are still staffed by people who understand the system.

So, is there still IT for us?

Yes. But split “IT” into two jobs, because AI treats them differently.

The pattern: AI lowers the cost of producing code and raises the value of everything around it. Specification, review, verification, operation and judgment are the work now. You still have to be an engineer to do those, because you cannot verify what you cannot read. A system that was generated and never understood is a system you are debugging at 3 a.m. with no map. We covered that cost in AI cleanup after vibe coding.

The drift toward tech product management

If producing code is the cheap part, the scarce skills are the ones that decide what gets produced and whether it worked:

• Define the problem. What outcome, for whom, and how will we know?
• Write the spec. Spec-driven development is just product management with a code-shaped output.
• Set acceptance criteria and evals. If you cannot say what correct looks like, an agent will happily generate something incorrect at speed.
• Own risk. Security, privacy, cost, vendor lock-in, reversibility.
• Connect to the business. Activation, retention, pricing, unit economics.

That is a tech product manager: someone who can read the diff and the P&L. It is also the technical-versus-business product manager split collapsing in the middle, and it is the shape of what many founders ask a fractional CTO to be. This is our view, not a measured trend. But the logic is hard to avoid. When the machine writes the code, the human’s job is to point it at the right problem and prove it worked.

A 90-day plan for engineers

1. Use agents on real work, daily, and keep a log. Track how long tasks actually take with and without AI. METR’s lesson is that your feelings are not data.
2. Write the spec before the prompt. One page: problem, constraints, acceptance criteria, non-goals. Then let the agent loose.
3. Own verification. Tests, evals, threat models, a security gate before release. Make it non-negotiable and boring.
4. Learn the business. Know your product’s activation, retention and cost per user. Ask what each feature is supposed to move.
5. Practise saying no. Write short one-pagers that kill features. The cheapest code is code you did not ship.
6. Show outcomes, not lines. Incidents prevented, lead time cut, revenue moved. Nobody will remember the percentage of AI-written code.

If you want to go deeper on the product side, our guide on how to become a product manager and the piece on product managers as mini-CEOs are good starting points.

For founders and CEOs: how to avoid a Proton moment

• Measure outcomes. Lead time, change failure rate, defects that reach customers, time to restore. Not “percentage of AI code”.
• Keep the security gate. Faster generation is a reason for stronger gates. Budget pentests and reviews as fixed cost, not as an obstacle to velocity.
• Make bad news cheap. If people are afraid to report problems, you will hear about them from journalists.
• Explain before you mandate. Proton’s own spokesperson conceded that some decisions were “too blunt or too slow” to explain. Tell people what changes, what does not, and what happens to their jobs.
• Hire for judgment. Engineers who can verify and think in product terms are more valuable now, not less. “No more engineers” is a slogan, not a staffing plan.
• Know your agent risks. Start with AI agent security and prompt injection.

Bottom line

The Proton story is not “AI bad” or “engineers doomed”. It is what happens when a real shift is managed with slogans: velocity as a metric, fear as a process, verification as an enemy.

You still have to be an engineer, because someone has to make sure the system works. But the job is moving from writing code to specifying it, verifying it and owning what it does for customers and the business. Embrace the new tools, move toward product thinking, and keep the pentest. That is the version of the future where there is still IT for us.