Should a PM know how to read code in 2026?

Executive summary

• Yes, but not to write. Both loud camps argue about identity, not the work. The floor is five reading capabilities, and none of them is writing production code.
• Why it changed. “Helpful but not required” was right when engineers were the only interface to the code. Now an agent answers confidently whether or not it’s right, and the only way to tell is to look at what it points to.
• The floor. Read a function; read a data model and know what the product can represent; read a query and name one way the number could be wrong; read an API request and response; notice when the agent’s answer doesn’t match the code.
• The ceiling. Read to decide, never write to ship. Internal scripts and prototypes are yours; anything a customer touches belongs to engineering.
• A month to get there. An hour a day for four weeks, with one real repo and one agent. The first fortnight feels like fraud, and that feeling, not the difficulty, is the real barrier.

Code literacy isn’t a virtue in itself. Your product’s logic now speaks through something fluent whether or not it’s correct, and the person deciding is the only one left who can check.

This question has two loud answers, and both are wrong in the same way: they’re about identity, not the work.

Neither camp tells you what to learn, because neither is making a claim about the work. They’re making a claim about what kind of person a product manager is.

So here is the boring, specific, middle answer. I hold it because I made the transition late and badly, and I can tell you exactly which parts mattered. Yes, you should be able to read code. The floor is five capabilities. It takes about a month. None of them is writing production code, and the boundary between reading and writing is the most important line in this piece.

Part one: why the old answer expired

The old answer was right

For most of the pre-AI era the honest answer was “helpful but not required,” and it was correct.

Here’s why. The codebase had one interface: engineers. If you wanted to know how something worked, you asked one. That conversation was cheap for you and mildly expensive for them. Product management’s whole operating model was built to keep such conversations to a minimum — which is what specs, refinement meetings, and technical design reviews were for.

In that world, learning to read code bought you little. You’d spend three months getting to where you could half-follow a pull request, only to get worse answers, more slowly, than the ten-second version an engineer could give you. The return wasn’t there, and the people who said so weren’t being lazy.

What changed is the interface, not the code

The codebase now has a second interface: a conversation with an agent that has read all of it.

That sounds like it should reduce the need for code literacy — the agent explains things in English, so why read anything? It’s the opposite, for one reason that took me a while to understand.

An agent will answer confidently whether or not it’s right. Ask it how the refund flow works and you’ll get a fluent, plausible explanation. Sometimes it’s correct. Sometimes it’s describing a code path that was deprecated eighteen months ago, or a file that handles a similar-sounding thing, or an inference it made from function names because the real logic lives somewhere it didn’t look.

You can’t tell the difference by reading the explanation; it’s equally good in both cases. You can only tell by looking at what it points to.

So the new requirement isn’t “write code.” It’s verify. The agent removed the friction of asking, and with it the human who used to catch the wrong answer. That is why the floor exists.

The second reason: you stopped needing permission

The other change: reading code is now the on-ramp to doing things. Pulling a number from the warehouse, building a small internal tool, checking whether the event you need is instrumented — you can now do each of these in an afternoon, and each makes you look at something that isn’t English.

Not to write it. To look at it and not panic.

Part two: the floor, precisely

Five capabilities. I’ve defined each one so you can test whether you have it, rather than leaving it as a vibe.

1. Read a function and say what it does

Given twenty or thirty lines of code, say in one sentence what goes in, what comes out, and roughly what happens in between. Not line by line. The shape.

The test: open any file in your product’s codebase, pick a function whose name you recognize, and write one sentence describing it. Then ask your agent to describe the same function. If the two sentences describe the same thing, you have this.

What you don’t need: to know the language’s idioms, what a decorator does, why they used a map instead of a loop, or whether the code is any good.

This is the foundation, because everything else is a special case of it.

2. Read a data model and know what the product can and can’t do

Find where the database tables or data structures are defined. Look at what fields exist, what’s required, what links to what.

This is the single highest-value item on the list, and almost nobody teaches it. The data model is the real product. It tells you, with total honesty and no politics, what the system can represent. If the schema says a user belongs to exactly one team, then “let users be in multiple teams” is not a small change, whatever anyone estimates in the meeting. You’ll see that in thirty seconds, before the conversation rather than after it.

The test: can you look at the schema and correctly answer “can a customer have two active subscriptions?” without asking anyone.

3. Read a SQL query and check its answer

You’ll increasingly get numbers from queries that an agent wrote. Generated SQL is confidently wrong more often than people expect, and it’s wrong in specific, recurring places: joins that silently multiply rows, date ranges that are off by a day or a timezone, filters that exclude nulls you wanted, and count(*) where you meant distinct users.

Human experts · BIRD93%

Best system · BIRD, 202682%

ChatGPT · BIRD, 202340%

o1-preview · Spider 2.0, 202417%

Sources: BIRD (Li et al., 2023, and its leaderboard); Spider 2.0 (Lei et al.). Scores have climbed fast: by 2026 the best system on Spider 2.0-Lite reached 76%, up from 17% in 2024. That still misses about one enterprise task in four, and leaderboard runs are vendors’ own, on a fixed test set, not your warehouse with its thousand columns and messy dates. Hence: read the query, and name one way the number could be wrong.

The numbers

System	Benchmark	Correct
Human experts	BIRD	92.96%
Best system, Sep 2026	BIRD	82.39%
ChatGPT + chain of thought	BIRD (2023)	40.08%
o1-preview	Spider 2.0 (2024)	17.1%

You need enough to read a query and ask: which table is this counting rows from, what’s it filtering, and could the join duplicate anything?

The test: given a query and a result, can you name one specific way the number could be wrong.

What you don’t need: to write complex SQL from scratch. The agent writes it. You check it.

4. Know what an API call is and read a request and response

What endpoint is called, what’s sent, what comes back, and what the status code means. Enough to open a browser’s network tab, watch what your own product does, and see the shape of the conversation between the front end and the back end.

This matters more than it looks. Most integration questions, most “why is this slow,” and most third-party dependency conversations get much easier the moment you can see the traffic itself instead of a description of it.

The test: open your product, do something, open the network tab, and explain what request that action produced.

5. Notice when the agent’s answer doesn’t match the code

The capstone, and the reason for the other four.

The agent tells you the refund flow does X. You open the file it cited and skim. Does the code seem to do X? Is the function it named called from where it says? Does the thing it called “recently added” have a comment from 2021?

You’re not auditing. You’re doing the thirty-second sniff test that catches the confident hallucination before it becomes a decision.

The test: the first time you catch the agent being wrong about your own codebase, you have this. Until then you don’t, and you should assume you’re being fooled sometimes.

What is explicitly not on the list

I’ll be as precise about the ceiling as about the floor, because vagueness here is how PMs end up doing badly-paid junior engineering.

The line is this: you read to decide, not to build. Everything on the floor list serves a decision. Everything on this list serves a build. The moment you cross it, you take on accountability for work you can’t own.

Part three: how to get there in a month

No course. No bootcamp. A real repo and a real agent, four weeks, an hour a day.

At the end of the month you won’t be able to write production code, and you shouldn’t want to. You’ll read well enough to check an answer, which is the whole point.

The part nobody warns you about

The first two weeks feel like fraud. You’re a senior person with a decade of experience, opening files you don’t understand, asking questions you assume are stupid, and playing dress-up as an engineer.

That feeling, not the difficulty, is the real barrier. The material isn’t hard, just unfamiliar. Unfamiliarity is far more uncomfortable at forty with a title than at twenty without one. It passes around the time the first small thing you built becomes something you use. Knowing it’s coming makes it survivable.

Part four: the objections, taken seriously

“PMs who code start doing engineering’s job, badly.”

The real risk on this list, and I’ve watched it happen. A PM learns enough to open a PR, opens one, and becomes an unreliable contributor to a codebase they don’t maintain, while nobody does product.

The defense is the boundary above, and it’s a bright line, not a judgment call: read to decide, never write to ship. Internal scripts and prototypes are yours. Anything a customer touches belongs to engineering. If you find yourself in a code review defending your own diff, you’ve crossed it.

“This is just the old ‘technical PM’ requirement in new clothes, and it excluded people.”

Partly fair, and worth a proper answer. The old technical-PM bar was implicitly “have a CS degree,” which excluded people by background, not capability. The floor I’m describing is a month of work, open to anyone with a repo and an agent, with no prerequisite. That’s a different bar — learnable, not inherited. The exclusion risk is real. The answer is to state the floor precisely, as this piece tries to, rather than leave it as an unwritten vibe about who “gets it.”

“My engineers will explain anything I ask.”

Mine did too, and they were generous about it. Two things changed. The number of questions went up, because cheap building means more options to weigh. And the cost of asking got weirder. Asking an engineer to explain something an agent could have explained now reads as not having tried, a social cost that didn’t exist in 2019.

More important: the engineer’s explanation was never the problem. The problem was the questions I didn’t know to ask, because I couldn’t see the shape of the thing.

“There isn’t time.”

An hour a day for four weeks, once. Against a career. This one doesn’t survive contact with arithmetic.

“AI will get good enough that none of this matters.”

Maybe. What would make this obsolete is an agent that’s reliably right about your codebase and reliably signals when it isn’t. The second half is the hard part, and there’s no sign it’s solved. Until a model can tell you accurately how confident it should be, someone has to check, and that someone is whoever is making the decision.

The short version

Should a product manager be able to read code in 2026? Yes, and here’s the entire floor:

1. Read a function and say what it does
2. Read a data model and know what the product can represent
3. Read a SQL query and name one way the number could be wrong
4. Read an API request and response
5. Notice when the agent’s explanation doesn’t match the code

Not on the list: writing production code, knowing a language properly, system design, debugging, code review, or estimating.

One month, one hour a day, one real repo, one agent. The uncomfortable part is the first fortnight, and it’s psychological, not technical.

Code literacy isn’t a virtue in itself. The interface to your product’s logic became a conversation with something fluent whether or not it’s correct — and the person making the decision is now the only one left who can check.

— Chris

Sources

Where the evidence comes from. Each row opens the document itself; the tag says which part of the argument it supports, and ↩︎ goes back to the sentence that uses it.

1. We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMsSpracklen, Wijewickrama, Sakib, Maiti, Viswanath, Jadliwala (USENIX Security 2025)Agent hallucinated packagesPaper202519.7% of recommended packages hallucinated (576,000 samples, 16 LLMs)↗︎Code models confidently cite things that don't exist
2. Tracing the thoughts of a large language modelAnthropic (interpretability team)Plausible confabulationReport2025-03-27↗︎Recognized name triggers plausible but untrue answer
3. Getting AI to write good SQL: Text-to-SQL techniques explainedPer Jacobsson, Google Cloud BlogLLMs guess on SQLWorking paper2025-05-16↗︎LLM gives an answer; ambiguity leads to hallucination
4. BIRD-SQL: A Big Bench for Large-Scale Database Grounded Text-to-SQLs (leaderboard)Li, Hui, Qu et al. (HKU / Alibaba DAMO)BIRD text-to-SQL gapDocs2023 (NeurIPS 2023); leaderboard live Sep 2026Human 92.96% EX vs best system 82.39% test (Sep 2026); ChatGPT 40.08% in 2023 paper↗︎Best text-to-SQL systems still trail human experts
5. Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL WorkflowsLei, Chen, Ye, Cao et al. (XLANG Lab, HKU)Enterprise SQL is harderDocs2024-11 (ICLR 2025 Oral); leaderboard live Sep 2026o1-preview 17.1%, GPT-4o 10.1% vs 86.6% on Spider 1.0 (2024); 2026 leaderboard: Spider 2.0-Lite top 76.23%↗︎Enterprise SQL: 2024 models mostly wrong, agents since climbed
6. Language Models (Mostly) Know What They KnowKadavath et al., AnthropicCalibration limitsPaper2022-07-11↗︎Self-knowledge calibration only partly transfers to new tasks