tech, developers, and the code underneath

issue 032· essay·

Shopify's memo and the new hiring question

"Prove AI can't do this job" as a requirement before headcount. A reasonable policy with an unreasonable failure mode.

Tobi Lütke published an internal memo this month stating that Shopify teams must demonstrate why AI cannot do a job before requesting headcount, and that "reflexive AI usage" is now a baseline expectation in performance reviews.

The memo is better written and more reasonable than the headlines about it. It is also going to be misapplied everywhere it gets copied, and it is going to get copied everywhere.

the defensible core#

Two claims in the memo are correct.

"Try the AI first" is good engineering hygiene. Before you build the internal tool, before you write the script, before you file the ticket — spend ten minutes seeing whether an existing model handles it. Often it does. The cost of checking is near zero and the expected value is high.

Stagnation is a choice. A team that has not changed how it works in two years during a period of rapid tooling change is not being careful, it is being incurious. That is a fair thing to name.

the failure mode#

"Prove AI cannot do it" is an unfalsifiable standard, and unfalsifiable standards in an organization become political tools.

You cannot prove a negative about a capability that changes monthly. Any manager who wants to deny headcount now has an infinitely flexible reason, and any manager who wants to grant it will produce a document explaining why AI cannot do it. The document is not evidence. It is theater. Every organization that has ever required a justification memo for headcount has produced a genre of justification-memo prose, and this is just the newest style.

The real question — "what is the highest-leverage use of an additional engineer" — was always the question. Adding an AI framing does not make it easier to answer, it makes it easier to obscure.

the second-order effect nobody plans for#

If teams are evaluated on AI usage, teams will use AI, including in places where it is worse. This is Goodhart's law with a new coat of paint. You will get:

  • Code review comments generated by a model that read fine and check nothing.
  • Documentation nobody reads, generated because generating it is cheap.
  • Test suites with impressive coverage numbers and no assertions that would fail.
  • Postmortems written by a model that faithfully summarize the incident and identify no real cause.

All of that is measurable AI adoption. None of it is value.

what a better version looks like#

If you want the outcome the memo is aiming at, ask for the outcome directly:

  • Cycle time, not tool adoption. If the team ships faster with the same quality, they are using their tools well, and it does not matter which ones.
  • Toil reduction as a named goal, with a quarterly review of what got automated. That surfaces the same opportunities without the unfalsifiable test.
  • A budget and permission, not a mandate. The blocker in most organizations is not enthusiasm, it is that the good tools are not approved and the data policy is unclear. Fix that and adoption happens without a memo.

the part I actually agree with#

The memo says learning to use these tools well is now part of the job. That is true and it is not controversial in the way people are treating it.

Getting good output from a model is a skill — knowing what context to provide, how to decompose a task, when the answer is wrong in a way that looks right. It is closer to being a good technical lead than to typing a search query. People who have developed it are meaningfully more effective, and people who dismissed the whole category in 2023 and never revisited it are falling behind in a way that is going to be uncomfortable to talk about at review time.

That is worth saying out loud. It just does not require a headcount policy.

get README in your inbox

One dispatch, no noise. Tech and developer news, plus the occasional long piece on the craft.

subscribe →