What I know about software, I built by reading. Documentation, source code, GitHub issues, changelogs, RFC threads that went nowhere, blog posts from 2014 that were half-wrong but made me think. No bootcamp. No structured curriculum. Just me, a browser, and the actual material.
When I was learning Cloudflare Workers, I didn't have a course. I had the Workers docs, the Wrangler changelog, and a broken deployment I had to debug at 1am. I read the binding configuration docs three times before I understood why my KV namespace wasn't resolving. I followed a GitHub issue thread from 2022 to understand a Wrangler behavior that was never in the official docs at all.
That's how I know what I know. Not from a summary. From sitting with the material until something clicked.
I'm watching that process disappear.
we're calling it productivity
The pattern I keep seeing: not "I read the docs and I'm confused about this section" but "give me the code for X." Not "I traced through the source and found this behavior" but "what does this function do."
Understanding is optional now. Just get the output.
We didn't just change how we find answers. We changed what we think the goal is. The goal used to be comprehension. Now it's output. And we're calling the shift efficiency.
It isn't. It's debt.
You can generate a working circuit breaker implementation without understanding what a half-open state is or why it exists. It works in your test environment. It fails in a specific edge case under load six weeks later, and you have nothing to reach for because you never built the mental model. You got the conclusion without the construction. The what without the why.
The why is the only part that matters.
Reading documentation builds a mental model through contact with the actual material — the tradeoffs the API design is managing, the edge cases in a footnote you almost skipped, the why behind the what. The confusion you feel reading a complex RFC is where the learning happens. Friction is where understanding gets built.
When I built Bookmark Brain — a RAG system on 55,000+ of my own X bookmarks — I had to actually understand how Cloudflare Vectorize works under the hood. Not just the API surface. The embedding dimensions, the index behavior, the query distance metrics and what they mean for retrieval quality. I read the HNSW paper. I read source-adjacent documentation. I sat with confusion long enough for it to become comprehension.
That comprehension is now load-bearing in production. If something breaks at 2am, I have a model to reach for.
If I had prompted my way to a working demo, I'd have a demo. I wouldn't have a system I can reason about.
the split already showing in codebases
Who still reads and who doesn't — that's the divide forming. Not senior vs junior, not experienced vs beginner.
It shows in code review. The developer who read the ORM documentation sees in thirty seconds why a query is going to cause N+1 issues. The developer who generated the code can't, because they never built the model that lets you see it.
It shows in architecture. The developer who read the Kafka docs actually understood consumer group behavior, partition assignment, offset management. When the system needs to scale, that developer has something to reach for. The one who learned Kafka from summaries has vocabulary but no structure underneath it.
It shows most brutally in debugging. Debugging is almost entirely a function of your mental model. Without one, you're just changing things and hoping.
AI cannot hold the architecture. It doesn't see the big picture across your codebase. I've watched an AI-generated caching layer get shipped clean, pass every test, and take down production three weeks later because nothing in the code — or in the person who merged it — understood what would happen when two requests raced to invalidate the same key. The human in the loop has to hold that. Which requires a mental model. Which comes from reading, not prompting.
what we're trading without noticing
I've watched developers ship auth systems they can't reason about. Caching layers they can't explain. Queue implementations that work until they don't, and when they don't, there's nothing to reach for except opening a new chat window.
That's not a tool problem. That's a reading problem.
Same tool, two developers. One uses it to understand — asks why the code works, what the tradeoffs are, what breaks under load. One uses it to avoid understanding — takes the output, ships it, moves on. Completely different results six months later when the system needs to change.
That's the line. Not whether you use AI. Whether you're using it to understand or to avoid understanding.
The developers I watch compound over time aren't moving fastest. They're the ones who still read. The actual changelog. The actual query planning documentation. The actual source when something doesn't make sense. They're building a compounding mental model that prompting cannot replicate.
The ones who stopped reading are building something too. API surface knowledge and output patterns, without structural understanding underneath. It doesn't show until the system needs to change.
for self-taught developers specifically
Documentation made self-taught viable. Open-source code you could read. Stack Overflow threads with timestamps, disagreements, edits that showed how understanding evolved. Blog posts from engineers explaining not just what they did but why.
That curriculum is still there. I still use it. I just don't know how many people coming up behind me are.
I built what I've built by reading things that confused me until they didn't. That's not a talent. It's a practice. One I watch developers trade away every day for the feeling of moving faster, without noticing that what they're trading is the actual skill.
The mental model you build from reading documentation at 1am, frustrated, reading the same section three times — that's not a tax on your productivity. That's the thing that makes you irreplaceable when the system breaks.
When you skip it, you skip the thinking. And you won't know you skipped it until you're in production with nothing to reach for.
AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.