The Pragmatic Engineer AMA

The Pragmatic Engineer · email · 2026-07-08 Reader 🖥️

Agent-to-Agent Protocols Desirable Difficulty & Productive Struggle MCP (Model Context Protocol)

Orosz's authority and judgment — on his own editorial choices, on hiring, on technology standards, and on AI adoption — consistently rest on direct, ground-level evidence and deliberate, revisable tradeoffs rather than on assumption, hype, or a fixed ideological stance.

practical · mixed — Combines narrative memoir (three origin/editorial-policy stories about the newsletter) with argumentative opinion pieces (three claims about interviewing, protocol standards, and AI/skill atrophy) that each carry implicit advice for the reader's own practice.

Structure

Part	Role
Story #1 — origin of The Pragmatic Engineer	context
Story #2 — the Bunq exposé he chose not to publish	evidence
Story #3 — the Pollen investigation	evidence / counter-example
Opinion #1 — LeetCode-style interviews	argument
Opinion #2 — why MCP became a standard	argument
Opinion #3 — AI, effort, and skill atrophy	argument / conclusion
Antithesis sponsor endorsement	evidence (personal endorsement embedded in sponsor copy)

Key terms

deterministic simulation testing (running the whole system in a hostile simulation)
Running an entire system inside a fully deterministic, simulated environment designed to provoke and expose bugs, then using bug-probability analysis to 'rewind' to the point a bug was triggered.
LeetCode-style interviews
A filtering mechanism that selects for candidates who tolerate pointless, grind-heavy corporate work — largely decoupled from the skills the job actually requires.
skill atrophy
A deliberate, selectively-accepted tradeoff of letting a specific skill (e.g., hand-coding) degrade because AI now performs that task, while consciously protecting other skills (e.g., writing) from the same degradation by withholding AI from them.

Propositions

explicitThe Pragmatic Engineer's editorial policy is to write about what works inside companies rather than what seems broken, a policy adopted directly because of one engineer's counter-narrative message about working at Bunq.conf: high
explicitLeetCode-style (DSA) interviews persist at large tech companies because they self-select for candidates willing to tolerate pointless work, not because the skills tested are used on the job.conf: medium
explicitBecause AI can now solve DSA interview puzzles easily, larger companies are likely to move back toward in-person interviewing while still keeping DSA-style questions.conf: medium
explicitMCP became the industry-standard AI tool protocol partly because, at its November 2024 launch, Anthropic was not yet seen as the dominant AI lab, so competitors (OpenAI, Google, Microsoft) could adopt it without fearing lock-in.conf: medium
explicitGoogle's Agent2Agent protocol failed to gain broad adoption specifically because Google was perceived as a dominant player, unlike Anthropic at the time of MCP's launch.conf: medium
implicitIf MCP were launched today, under Anthropic's current position as the leading frontier lab, it would likely not achieve the same broad, fear-free adoption.conf: medium
explicitUsing AI does not make Orosz's own work easier; if AI is making your work substantially easier, that itself may signal you aren't pushing yourself hard enough.conf: high
explicitOrosz deliberately uses zero AI (and disables Grammarly) when writing for The Pragmatic Engineer to prevent his writing skill from degrading, while accepting that AI use in coding will let his hand-coding ability atrophy.conf: high
implicitSkill atrophy from AI use should be accepted selectively — for skills one doesn't personally need to keep sharp — rather than adopted as a blanket policy across all activities.conf: medium
explicitInvestigative journalism is not a role or activity Orosz wants to continue doing, despite having produced one notable investigative piece.conf: high
explicitVerifying a system's correctness by running the whole system inside a fully deterministic, hostile simulated environment to find bugs is a technique Orosz personally uses and rates as an impressive innovation in debugging tooling.conf: medium

Arguments

LeetCode-style (DSA) interviews will persist at large tech companies even though the tested skills are rarely used at work. strength: medium

Explicit premises:

DSA skills are rarely used at actual work.
A candidate willing to grind for weeks or months preparing for such interviews is likely someone who understands that pointless work is sometimes necessary.
Such candidates will probably fare better in Big Tech than someone who refuses to engage with meaningless tasks.

Implicit premises:

Interview formats function partly as an organizational-culture/compliance filter, not solely as a skill assessment.
Companies value and select for tolerance of bureaucratic or low-value work as an employee trait.

Inferences:

Because AI can now defeat DSA puzzles easily, the interview format alone no longer reliably signals grind-tolerance, which pushes companies toward in-person interviewing to preserve that filtering function while still keeping DSA questions.

Technology standards (like protocols) emerge somewhat coincidentally from a mix of technical merit and precarious external conditions — particularly whether the originating company is perceived as a non-threatening or dominant actor — rather than from predictable design. strength: medium

Explicit premises:

MCP was broadly adopted by OpenAI, Google, and Microsoft when Anthropic was not yet seen as the leading AI lab.
Google's Agent2Agent protocol was not adopted by major labs, attributed to Google's perceived dominant position.
Anthropic is now widely seen as the leading frontier lab.

Implicit premises:

Competing companies avoid ceding structural advantage or lock-in to a rival perceived as dominant, even when a technically comparable protocol is on offer.
Perceived relative competitive power, not protocol design quality alone, governs adoption decisions by rival companies.

Inferences:

A similarly strong protocol proposed today by Anthropic (now dominant) would likely meet the same structural adoption resistance that killed Agent2Agent.

One should use AI deliberately and selectively, based on which of one's own skills are worth preserving, rather than adopting a uniform AI-everywhere or AI-nowhere policy. strength: medium

Explicit premises:

Orosz uses zero AI in his own newsletter writing (and disables Grammarly) specifically to prevent his writing skill from degrading.
Orosz uses AI when coding and accepts that his hand-coding ability will degrade as a result.
AI use does not intrinsically make work easier if the person is pushing themselves hard.

Implicit premises:

Skill atrophy is a near-certain consequence of habitually delegating a task to AI.
Not all skills are equally worth preserving for a given individual's goals — some tradeoffs are acceptable, others are not.

Inferences:

Readers should individually audit which of their own skills they most value keeping sharp, and consciously withhold AI assistance from exactly those tasks, rather than following a single blanket AI policy.

Narratives

The COVID-19 pandemic triggered layoffs at Uber that disbanded Orosz's team; he used the resulting disruption to exit and try to finish 'The Software Engineer's Guidebook,' then wrote three more books and discovered he preferred writing over pursuing a VC-funded startup idea.
→ Origin story establishing that Orosz's authority as a writer/publisher grew out of direct industry disruption and iterative discovery, not a deliberate media career plan — grounding the unity's claim that his stances are built from lived experience.
During Pragmatic Engineer's first year, Orosz had a near-final, unpublished exposé on poor working conditions at Dutch neobank Bunq, but withheld it after an engineer explained that Bunq's willingness to sponsor a hard-to-get visa had been a genuine, career-changing opportunity for them despite the company being a tough place to work.
→ Directly supports the proposition that his 'write about what works' editorial policy was adopted because of a single piece of ground-level counter-evidence — illustrating a willingness to revise a near-final conclusion when confronted with a perspective he hadn't considered.
After Pollen's CEO publicly dismissed Orosz's reporting on the company's layoffs as the work of a 'nobody' with an anti-Pollen agenda, Orosz investigated further and uncovered unpaid salaries, silently cancelled US health insurance, and a CTO-triggered $3.2M customer double-charge with no postmortem; he published the findings and contributed to a BBC documentary, and Pollen has since (per Orosz) filed what he calls bogus DMCA takedowns to try to remove the piece from search results.
→ Serves as the explicit exception to the 'write about what works' policy, showing accountability journalism still happens when reporting is dismissed rather than engaged with — and supports his stated conclusion that investigative journalism 'is just not for me.'

Questions addressed

✅ Why do LeetCode-style (DSA) interviews persist at Big Tech despite testing skills rarely used on the job?
They function as a self-selection filter for tolerance of pointless corporate work, not as a genuine skill assessment.
✅ Why did MCP succeed in becoming an industry-standard protocol while Google's Agent2Agent did not?
MCP launched from a lab (Anthropic) not yet seen as dominant, so rivals could adopt it without fearing lock-in; Agent2Agent came from an already-dominant Google, which rivals avoided reinforcing.
✅ Does using AI make engineering or writing work easier?
Not for Orosz — he treats ease as a warning sign of insufficient effort, and instead manages a deliberate, per-skill tradeoff between AI use and skill preservation.
⭕ When does Orosz override his default 'write about what works' editorial policy to publish critical/investigative reporting instead?

Gaps

incompleteOrosz states his default editorial policy is to write about what works rather than what's broken, yet his most notable piece is precisely an exposé of what went badly wrong at Pollen. He never articulates the criteria or threshold (e.g., degree of misconduct, being publicly dismissed) that triggers an exception to the default policy.
Read next: Look for any explicit statement of The Pragmatic Engineer's editorial values/criteria beyond this one anecdote — e.g., an About page, a past newsletter issue on his editorial philosophy, or interviews where he discusses how he decides what to cover critically.
incompleteThe claim that standards adoption hinges on the originating company being perceived as non-dominant rests on a single supporting case (MCP) and a single contrasting case (Agent2Agent), with no broader survey of other protocol/standard adoptions to test the generality of the mechanism.
Read next: Compare against the adoption histories of other widely-adopted open protocols/standards (e.g., OAuth, gRPC, Kubernetes, USB-C) to test whether 'non-threatening originator' consistently predicts adoption, or whether technical merit and network effects dominate more often.
incompleteThe 'AI doesn't make work easier if you're pushing yourself hard enough' claim is a personal heuristic with no account of how it might vary by task type, seniority, or skill level — it's unclear whether it generalizes beyond an expert writer/engineer who has already optimized their own workflow.
Read next: Look for empirical research on AI's effect on productivity/effort across skill levels and task types (e.g., controlled studies of AI-assisted coding speed) to test whether the 'should still feel just as hard' framing holds broadly or mainly for already-expert practitioners.
uninformedThe deterministic-simulation/hostile-environment testing technique (via Antithesis) is presented through a sponsor endorsement with a screenshot and a one-line personal impression, not a technical account of how deterministic replay is achieved, what classes of bugs it does or doesn't catch, or its performance/adoption cost.
Read next: Read Antithesis's own technical documentation or independent write-ups on deterministic simulation testing (and compare with FoundationDB's well-documented deterministic-simulation approach) to evaluate the technique on its merits beyond the sponsored blurb.

The Pragmatic Engineer AMA

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents