Proton AI Interviews: What They Mean for Staff

The reported interview process

According to 404 Media, Proton plans to interview some staff about their use of AI. The interviews are scheduled for November 4 to 11. An internal email described to 404 Media reportedly calls the interviews "consequential" and says the results will feed into a wider review that could affect roles and continued employment. Not everyone is expected to be interviewed. 404 Media also reports that interviewers are leaders from outside each employee's team, chosen for their AI-related experience.

The reporting says CEO Andy Yen first interviewed more than 40 senior leaders in engineering and product. It also cites internal messages, Slack discussions, meeting recordings, and interviews with nine current and former employees. As with any single-source account, these are reported claims - not a complete, verified description of Proton's full process or every employee's experience.

Proton has denied that it's conducting layoffs under the cover of AI. In a response reported by TechRadar, the company said it faces a talent shortage, is hiring, and wants to understand where staff need more support. A spokesperson reportedly did not dispute 404 Media's reporting, but said Proton had sometimes been too blunt or too slow in explaining its decisions to employees.

So there's a real distinction to keep in mind: a company can say a review is meant to improve employees' AI skills while still using the results in employment decisions. The stated purpose doesn't remove the need for clear criteria, consistent assessments, and a fair process.

Why the surrounding comments matter

404 Media reports that Yen urged engineers in an August Slack discussion to stop hand-writing code and use AI more. In the same channel, he reportedly wrote, "This will be the last year that we hire engineers." The outlet also reports that an employee's request for time to run security tests was dismissed as "bullshit and loser thinking."

Those remarks, if accurate, change the tone of what might otherwise look like routine training. They suggest leadership may be linking AI use to expectations about engineering work and future hiring. But that still isn't proof that Proton has decided to replace engineers. Proton denies using AI as a pretext for layoffs, and the available reporting doesn't establish that any specific person lost a job because of these interviews.

Other reported context adds to the picture. Proton's chief technology officer, Bart Butler, reportedly said in an October meeting that AI wrote 90% of the company's code. Employees told 404 Media that they wrote much of it using Anthropic's Claude. The outlet also reports that software was installed on employees' computers to track how much code AI generates.

Separately, an internal document reportedly said Proton was not on track to meet its annual recurring revenue target and cited "insufficient velocity."

Taken together, these details raise reasonable questions about whether AI adoption is being treated as skill-building, a response to business pressure, or both. They don't, on their own, answer those questions. A careful account has to separate the claims, Proton's response, and any conclusions about motive.

Code volume is not product value

AI coding tools can generate boilerplate, tests, documentation, and multiple implementation paths quickly. That can reduce time spent on repetitive tasks and help engineers explore unfamiliar parts of a codebase. But the amount of code generated doesn't tell you whether the change is correct, secure, understandable, or actually useful to customers.

It's possible to generate more code and ship less value. Generated code may require heavy review, introduce vulnerabilities, duplicate functionality, or create maintenance work that lands on another team months later. In a privacy product, mistakes can have consequences beyond a bug report - they can affect how sensitive data is handled and erode user trust.

The same problem shows up with metrics like AI-generated lines, prompt counts, or the percentage of code attributed to a model. Those are measures of tool activity. They're not a reliable stand-in for delivery quality. If companies make them targets, employees will naturally optimize for what's visible rather than what reduces risk or improves the product.

Software engineering includes judgment and restraint

Engineering isn't just writing code. People decide what to build, how it fits into an existing system, which edge cases matter, how to test it, and when not to ship. AI can help with some of those tasks, but it doesn't carry responsibility for the consequences.

For instance, a developer might use an AI assistant to draft a change quickly, then spend additional time checking behavior against a security boundary or handling a tricky migration. Coding time drops; review time may rise. That can be a good trade if the total effort is still lower and the result remains safe. It's a bad trade if "performance" is judged only by how fast a first draft appears.

That's why a request for security testing shouldn't be treated automatically as resistance to AI. Sometimes extra review is avoidable friction. Other times it's exactly what prevents a risky release. The right decision depends on the system, the change, and the cost of failure - not on a blanket preference for manual work or AI generation.

Targets change behavior

Once a metric becomes part of performance review, people adjust to it. If leaders reward AI usage without checking outcomes, employees may use the tool on tasks where it adds little value. If leaders reward speed alone, they may push rushed reviews or defer maintenance.

This isn't unique to AI. It's the predictable result of measuring what's easy instead of what matters. A better approach is to evaluate outcomes alongside the process. That can include lead time for changes, escaped defects, security findings, rework, maintainability, and whether users or internal teams actually see improvements. None of these is perfect on its own. The value comes from looking at a set of evidence and considering the context behind it.

Separate capability checks from employment decisions

If an assessment is meant to identify training needs, the company should say so and make the next step explicit. If results might affect performance ratings or continued employment, employees should be told before the assessment begins. When those purposes are mixed without clear communication, trust erodes and people can't interpret results in the way the company probably intends.

A useful assessment should spell out:

• What is being evaluated: for example, choosing appropriate tasks for AI assistance, checking generated code, or explaining trade-offs.
• What is not being evaluated: raw prompt counts, model preferences, or a requirement to use AI even when it doesn't fit the task.
• How evidence will be collected: work samples, a structured discussion, or a practical exercise connected to real responsibilities.
• Who will review it: assessors with relevant expertise, using a shared rubric rather than personal preference.
• What happens next: coaching, a follow-up review, role changes, or employment decisions - and on what basis.

Using interviewers from outside an employee's team may reduce some local bias, but it can also come with blind spots. A rubric helps, as does access to relevant examples. Employees should also be allowed to explain why they used a particular workflow, including cases where they intentionally didn't use AI.

Measure the whole delivery system

Before setting a productivity goal, establish a baseline. Compare similar work before and after AI adoption, and track more than time to produce a first draft. Include review effort, rework, defects, and maintenance burden. Otherwise, work can quietly shift from implementation into review, and the total cost can stay flat - or rise - without anyone noticing.

One practical evaluation loop looks like this:

1. Choose a bounded use case. Start with tasks that are common, reviewable, and low enough risk to test safely.
2. Set a baseline. Record cycle time, quality issues, and review effort for comparable work.
3. Run a controlled trial. Give teams access to the tool and define how sensitive data and generated output should be handled.
4. Review outcomes. Compare delivery time and quality, including security and rework - not just generated code volume.
5. Adjust or stop. Keep the use case if it produces durable value; change the process or drop it if the benefits don't cover the costs.

This approach takes longer than announcing that everyone should start using AI immediately. It's also more likely to show where the technology actually helps. In a mature codebase, context gathering and validation can dominate the work. In a newer project with routine scaffolding, generation can save more time. The results will vary by team and by task type.

Make tracking proportionate and transparent

Tracking AI use can help a company understand adoption, but it can also slide into surveillance. Employees should know what data is collected, why it's collected, who can see it, and whether it will be used in individual performance decisions. If the intention is a team-level assessment, it shouldn't turn into a quiet individual ranking.

This matters even more when the company handles sensitive information or operates across jurisdictions. Data protection obligations - including GDPR where applicable - mean organizations should be careful about the purpose and scope of employee data collection. The exact legal details depend on where you are and how the system is implemented, so it's better to get qualified advice than assume a "default" productivity tool setup is fine.

For engineers: demonstrate judgment, not just tool usage

If your employer expects AI use, getting comfortable with the tools makes sense. But the lasting skill isn't just generating output. It's knowing which tasks fit the tool, providing enough context, spotting plausible errors, protecting sensitive information, and deciding when manual work (or extra review) is safer.

Keep a clear record of what you delivered. Be able to explain how AI affected your process, what you checked, and what trade-offs you made. If a tool saved time on repetitive work, connect that to a real outcome - like a faster release, better testing coverage, or time redirected toward a harder engineering problem. Don't treat "lots of generated code" as proof of impact.

If you're asked to complete an AI assessment, ask what it's for and how the results will be used. A fair evaluation shouldn't penalize you for declining AI on a task where it increases security, accuracy, or confidentiality risks. At the same time, refusing to evaluate AI tools that are relevant to your role may be hard to justify. The useful middle ground is informed, evidence-based adoption.

For employers: be precise about the business problem

The Proton reporting shows how quickly an AI rollout can become an employment and trust issue when the message focuses on speed, headcount, and individual tool use all at once. If the goal is delivery improvement, say which bottleneck you're trying to reduce. If the goal is building skills, fund training and make room for people to learn. If roles are expected to change, explain that plainly.

Leaders also need to resist treating employee caution as a cultural problem. Engineers often notice operational risks that don't show up in demos: incomplete understanding of the codebase, subtle security assumptions, or the future cost of maintaining a generated change. Those concerns may be wrong, but they should still be tested on their merits rather than dismissed because they slow down adoption.

There's also a wider market context. Companies are making different choices about AI and workforce expectations. The source report notes that Amazon has warned engineers not to chase AI usage metrics, and that an Anthropic manager has dropped coding interviews. Those examples don't prove a universal direction. What they do suggest is that firms are still figuring out how to assess AI-era capability - and that a crude productivity target is only one possible approach.