How to Read Tech Articles: A Three-Pass Method

Opening

Developers read a staggering volume of tech articles (or anything else that demands close reading). Blog posts, official docs, RFCs, conference slides, newsletters. With this much pouring in every day, surprisingly few people actually know how to read efficiently. They start at the top and run out of steam halfway. They finish a piece and remember nothing. They burn an hour and miss the whole point.

There’s a well-known academic essay by S. Keshav called “How to Read a Paper.” It’s written for research papers, so it doesn’t transfer one-for-one, but its core idea (read in three passes) works just as well for tech blogs and articles. This post adapts that methodology for the kind of reading developers actually do.

One more thing. Since 2025, AI tools have become part of daily life, and the act of “reading” itself is under pressure. I want to address that too before we get to the method.

A Note on Reading in the AI Era

The trap of AI summaries

A lot of developers have made it a habit to throw an article at ChatGPT or Claude and ask for a summary. It’s convenient. It’s fast. But it has serious side effects.

• Reading comprehension atrophies. The muscle for finishing a long piece disappears. A 3,000-word post starts to feel “too long.”
• Judgment goes with it. An AI summary compresses the author’s claims; it doesn’t ask whether those claims hold up. If you only read the summary, critical thinking never gets a chance to engage.
• Context disappears. The value of a tech article often lives in the journey, not the conclusion. “Why did they pick this approach?” and “What trade-offs did they weigh?” both vanish in a summary.
• Illusion of understanding. Reading a summary feels like understanding. Then someone asks you to explain it and you can’t. Reading a summary is not the same as understanding the thing.
• Nuance evaporates. The author hedged with “this might be the case” or “in certain situations,” and the AI flattens it into “this is the case.”

It’s the difference between driving a car yourself and watching the GPS from the passenger seat. No matter how good the GPS is, if you never touch the wheel, the route never sticks.

Principle: don’t outsource the reading. You read; AI is just a tool.

When AI does help

So should you avoid AI entirely? No. You don’t have to cut it out. As long as you stay the reader, using AI as a sidekick can actually make you more efficient.

The key is to use it after you read, not before reading or instead of reading. I’ll cover how to apply AI at each pass below.

The Core Principle

Don’t read a tech article from start to finish in one go. Read it in up to three passes. Each pass has a different goal and builds on the one before it.

• Pass 1: Figure out what this is and whether it’s worth your time.
• Pass 2: Understand the core content well enough to explain it to someone else.
• Pass 3: Understand it deeply and make it your own.

Like stacking Lego blocks, each pass rests on the previous one. And not every article needs to reach Pass 3. Most get filtered out at Pass 1, and that’s exactly how it should work.

Pass 1: The Skim (5 minutes)

Goal: decide quickly whether this article is worth more of your time.

How to do it

1. Read the title and subtitle.
2. Read the intro (first 1-2 paragraphs): what the piece is about and why.
3. Skim only the headings (h2, h3) to get the skeleton.
4. Read the conclusion or final section for the author’s main claim.
5. Glance at code blocks, diagrams, images to gauge the technical depth.
6. Check who the author is. Domain expert? Which company or project?

Five minutes is enough. Ten at the outside. The whole point of this pass is to decide quickly whether to keep going. Can you really judge in five minutes? Yes. You don’t have time to read every article carefully, and you don’t need to.

What you should be able to answer after Pass 1: the five Cs

If you can give a rough answer to these five, Pass 1 has done its job.

When it’s fine to stop at Pass 1

• The article has nothing to do with what you’re working on or interested in right now.
• The title is bait but the content looks shallow.
• The level is way below or way above where you are.
• The author is asserting things with no evidence.

Stopping is a skill. Filtering quickly matters more than finishing every article you start.

I do Pass 1 on my RSS feed in the morning. Out of ten articles, maybe two or three move on to Pass 2. (Most end at Pass 1.) Once this filtering becomes habit, you actually end up with more time, not less.

A note from someone who also writes: most readers do Pass 1 and leave. Your headings need to be sharp, your intro needs to deliver the value of the piece, and you have five minutes to convince anyone to keep reading. Otherwise nobody finishes.

Using AI at Pass 1

Good uses:

• Translate only the title and intro of an English article, to speed up the Pass 1 decision.
• A newsletter dropped ten links on you? Paste just the title and first paragraph of each into AI and ask, “pick the ones related to my interests (e.g. backend, distributed systems).” That’s filtering aid.
• For an unfamiliar field, ask, “give me a one-line explanation each of the terms in this article like CRDT and vector clock.” That’s dictionary mode.

Bad uses:

• Pasting the whole article and asking for a summary. You haven’t even done Pass 1. This is where judgment starts to atrophy.
• Reading only the AI summary and going “ah, so that’s what it’s about.” All you’re stacking is illusion.

Pass 2: The Careful Read (15-30 minutes)

Goal: understand the core content well enough to summarize and explain it to someone else.

Only articles that survived Pass 1 reach this stage. Which means you’ve already decided this one is worth your attention.

How to do it

1. Read end to end, but skip implementation details and proofs.
2. Take notes on the key points as you go (Notion, or margins of the original).
3. Study the diagrams and architecture pictures carefully.
   • Are the relationships between components clear?
   • Does the data flow make sense?
   • Anything missing?
4. Read the code examples with your eyes (you’ll run them at Pass 3).
   • Do you understand what the code is meant to demonstrate?
   • Is error handling and edge-case behavior accounted for?
5. Mark the terms and concepts you don’t know (don’t look them up now; collect them for batch review).
6. Bookmark any linked references worth chasing.

The rule that matters here is: don’t stop to look things up the moment you hit something unfamiliar. It’s like pausing a movie to Google every actor that appears. You lose the plot. Once you break the flow, the context goes with it. Mark it, finish reading, then resolve the unknowns in a batch.

What “done with Pass 2” looks like

• You can summarize the article’s main argument in three lines.
• You can tell a colleague, “I read this thing, and here’s the core.”
• You have an early opinion on whether you agree, disagree, or whether it’s applicable to your project.

If you can’t do any of those three, you’re not done with Pass 2 yet.

When Pass 2 isn’t clicking

The cause is usually one of these:

• Background gap. You don’t know the underlying tech or pattern. Read foundational material first, then come back.
• Bad writing. The structure is a mess, or claims have no support. Find another article on the same topic.
• You’re tired. Sometimes you’re just tired. Read it tomorrow.

The third one matters more than people think. Forcing a tired read leaves you with nothing.

I take notes line by line in Obsidian as I do Pass 2. That alone changes how much I retain. (It works better than I expected.)

In hindsight, I used to skip notes (“I read it, that’s enough”) and a month later I couldn’t remember a single thing I’d read. That’s how the note habit started.

For most tech articles, Pass 2 is enough. If you’re tracking trends, comparing tech, or collecting ideas, you can stop here.

Using AI at Pass 2

Good uses:

• After you write your own three-line summary, ask AI for one too and compare against your read. It’s a check for “did I miss anything?”
• Batch the unfamiliar terms you marked in Pass 1: “explain in two lines each: eventual consistency, saga pattern, compensating transaction from this article.”
• If an architecture diagram isn’t clicking, screenshot it for the AI and ask, “walk me through the data flow in this diagram.”
• For an English article where one paragraph won’t parse, ask for a translation of just that paragraph (not the whole article).

Bad uses:

• Skipping the read and asking AI for a full summary. You’ve skipped Pass 2 entirely. That’s not your understanding; it’s the AI’s.
• Copy-pasting the AI summary straight into your notes. Notes you didn’t write don’t stick.
• “Analyze the pros and cons of this article.” You’ve handed off your critical thinking. Your own opinion disappears.

The core rule: AI comes after the read. Not before, not instead.

Pass 3: The Deep Dive (1-3 hours)

Goal: make the article’s content your own. You can do it yourself, and you can evaluate it critically.

Honestly, only a handful of articles a month earn a Pass 3. That’s how it should be.

Looking back, the articles I took to Pass 3 were almost always tied to a real situation: team architecture decisions, evaluating whether to adopt a technology, the kind of thing where I had to apply it directly.

How to do it

1. Run the code yourself. Not copy-paste; understand why it was written that way.
2. Solve the same problem the author solved. Before reading, think about how you’d approach it.
3. Compare your approach to the author’s.
   • Where is the author better than you?
   • What would you have done differently?
   • What did the author miss?
4. Challenge the assumptions.
   • “Does this only work at low traffic?”
   • “Would this architecture hold up at our scale?”
   • “Is this benchmark fair?”
5. Write your own notes.
   • Key takeaways
   • What you can apply to your own project
   • Things to look up further
   • Counterarguments and limitations

Step 4 matters most. You’re not just absorbing what’s on the page; you’re asking “does this actually fit our situation?” If you think about it, the better the tech article, the more it tends to describe an experience under specific conditions. Change the conditions and the conclusion can change too.

What “done with Pass 3” looks like

• You can reconstruct the article’s structure from memory.
• You can point to specific strengths and weaknesses.
• You can apply or adapt the technique or pattern in your own project.
• You can write a blog post or give a talk on the topic.

The real test of Pass 3 is “can I write something on this?” If you can, you understood it. If you can’t, you don’t have it yet.

Pass 3 isn’t for every article. Reserve it for tech you’ll actually apply at work, architectures you have to understand deeply, or important pieces you need to share with the team.

Using AI at Pass 3

Good uses:

• Use it as a Socratic sparring partner. Explain what you understood and ask, “is my read right? did I miss something?”
• Use it as a counterargument generator. Ask, “give me five weak points or failure scenarios for this architecture.” It surfaces angles you hadn’t considered.
• When you get stuck running the code, ask about just the specific error or concept: “in this code, how does CompletableFuture.thenCompose differ from thenApply?”
• “What might the author of this article have overlooked?” AI isn’t omniscient, but it can offer a different angle.
• After drafting your notes, ask AI “what’s missing?” as a review pass.
• Ask about alternatives or competing tech: “this article recommends Redis Streams; how would the same problem look with Kafka or RabbitMQ?”

Bad uses:

• “Take the gist of this article and write me a blog post.” You’ve erased the entire point of Pass 3. The result isn’t yours.
• Skipping running the code yourself and asking AI “what would happen if I ran this?” You learn by hitting walls.
• Outsourcing the “challenge the assumptions” step to AI. The critical-thinking muscle atrophies.

At Pass 3, AI is your sparring partner. You throw a punch, AI counters, and your understanding sharpens through the exchange. AI doesn’t fight the match for you.

Applying It to Tech-Trend Research

When you have to research a new technology or area (say, “should we adopt event sourcing in our service?”), you can apply the three-pass approach like this.

Step 1: Explore

• Search keywords on Google, Hacker News, dev.to, Medium.
• Find three to five recent articles.
• Run Pass 1 only on each, to get the lay of the land and gather their reference links.
• If a well-organized survey or overview exists, start there.

Step 2: Identify the core

• Spot the articles and authors cited repeatedly across multiple pieces. Those are the foundational references in the field.
• Find the official blog or talks of those core authors and companies.
• Look for conference talks (QCon, Strange Loop, KubeCon, etc.) on the topic.

After scanning enough articles, patterns emerge. You start to think, “ah, in this field everyone goes back to that one Martin Fowler post.” (That moment of recognition is the turning point in your research.)

Step 3: Go deep

• Take the core references and conference talks and run Pass 2 on them.
• If everyone keeps citing something you haven’t read yet, add it to the pile.
• Finally, write your own summary doc (a tech evaluation, an ADR, etc.).

The same AI rule applies. Use it to accelerate exploration and spot patterns, but don’t end research with “summarize the pros and cons of event sourcing.” That’s mistaking someone else’s opinion for your conclusion. And you have to verify that any article AI recommends actually exists. AI hallucinates references frequently.

Practical Tips

Habits that improve reading efficiency

• Use an RSS reader or newsletters to batch articles and run Pass 1 in one sitting. Sort “read” from “drop” up front.
• Use “read later” tools (Pocket, Instapaper, Obsidian clipping), but don’t let them pile up. Schedule a weekly review slot.
• Always take notes on anything you read at Pass 2 or beyond. If you read it and can’t remember, you didn’t really read it.
• For anything you took to Pass 3, explain it to someone or write a post about it. That’s how it actually becomes yours.

The last one matters most. The way I see it, the final pass of reading is writing. Writing is what reveals what you understood and what you didn’t.

From the writer’s side

• 80% of your readers leave at Pass 1. Title, headings, and intro are everything.
• One good diagram beats ten lines of text.
• Code examples should show only the core. Link to the full code on GitHub.
• The conclusion has to answer “so what should I do?”

If you read this post and also write, run your own work through the same lens. Is your Pass 1 compelling? Does the skeleton emerge from the headings alone? Just asking yourself those questions raises the quality of what you publish.

Closing

What changed most when I applied this method wasn’t how much I read, but how I approached reading.

You don’t need to take every article to Pass 3. Most get filtered at Pass 1, only the worthwhile ones move to Pass 2, and only the truly important ones reach Pass 3. The filtering itself is the heart of efficient reading.

The same logic applies to AI use. Aid, not substitute. Translate the unclear paragraph instead of the whole article, and check your notes for gaps after writing them instead of pasting an AI summary in as your notes.

What it comes down to is this. Reading “a lot” of tech articles isn’t the point. Reading them “properly” is. And reading properly means choosing the right depth at each pass and spending your time well.

And at any pass, the moment you hand the reading off to AI, that pass didn’t happen. You have to stay the reader.

“The more that you read, the more things you will know. The more that you learn, the more places you’ll go.”

— Dr. Seuss

This is what the three-pass method is really about. Not reading whatever lands in front of you, but choosing what to read.

Original: S. Keshav, “How to Read a Paper” (University of Waterloo) Adapted for tech blogs and articles + AI usage guide added