I didn't go to a university for computer science. I have a B.Tech in Geophysics.
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.
Top comments (10)
Wholly agree, and that's why, in my opinion (and I've been beating this drum more than once lately ...) it's a false dichotomy to state (as I often see):
"with AI coding tools, it's less about memorizing syntax, and more about system thinking and architecture"
Taken at face value, this is true - there's not that much value in memorizing facts (syntax etc) for the sake of it - but I'm still calling "false dichotomy", because one doesn't develop "system thinking" or "architecture" skills in a vacuum - it's developed by being "hands on" ...
The 'old way', where we were craftsmen/women meticulously putting solutions together, was typically the way to develop those skills ...
So I'm kind of concerned that we're losing that "craft" aspect that formed the foundation for the higher level skills ...
So I'm just saying: keep writing some of the code (especially the more 'interesting' parts) yourself!
leob — that's the part I left implicit: "system thinking" isn't a separate skill that replaces syntax-level grinding, it's what that grinding turns into once your hands have done it enough times you stop consciously tracking it...
Exactly - that's what I meant with "false dichotomy" ... and purely the syntax is indeed the low-level (and less interesting) part, but understanding the minutiae of how an ORM works and how to apply its best practices, or (on a higher level) understanding the principles of HTTP, databases, concurrency - you can't really review what AI has generated, or spot its flaws, without the background knowledge or insight ...
(actually I might have to qualify that last part a bit, because nowadays there are AI code review tools which are pretty amazing - but for now, "human" checks are still valuable, or else we're just completely navigating on auto pilot)
Leo even the good AI review tools are pattern-matching against known failure shapes not against your specific production traffic at 2am; the checks that catch a subtle N+1 or a race condition usually come from someone who's been paged for one before.
I believe you, but the really good ones (at least the one(s) I know) seem to have an uncanny ability to "grok" your complete codebase, and to "understand" the relations between the various parts - AND to spot pretty subtle "edge cases", like race conditions, N+1 issues, security issues, and various "non happy path" scenarios - I was pretty heavily blown away by what it was capable of ...
But, obviously "it all depends" - YMMV, and like I said a "human" check is still very valuable ...
leo, grokking relations across a whole codebase is a genuine leap, no argument there. But spotting a race condition and understanding why it matters aren't the same move: one's pattern recognition over a wider context window, the other requires knowing what actually breaks, and for whom, when it fires.
When it flagged one, did it tell you which invariant would fail, or just that concurrent access existed?
Assalamualaikum,
This is very relatable I’ve noticed the same thing when I stop reading docs and just rely on guesswork.
Did you find any good way to stay consistent with documentation?
Tahami — the only thing that's actually worked for me: read the section that's failing, not the whole page, and don't move on until you can explain why the code does what it does, not just that it works.
Yeah but the AI bros are aggressive in making you leave the understanding and give in everything to AI.
This misguides most of the beginners
Debajyati , the aggression's easy to spot; harder is that it works on beginners specifically because they don't yet have the mental model to know what they skipped.