Whether you're an engineer, a product manager, a designer, or literally anyone working in 2026 and probably staring at Claude / ChatGPT 24/7 — your eyes are probably taking a huuuuuuuuuge beating. And whether or not you've started to experience eye pain, I'm here to give you some relief.

Because I did.

About six months ago, between all of my infinite side projects plus the eight hours a day I was working, I started to notice really really sharp eye pain. I went to my eye doctor and he basically told me I was overstraining the muscles in my eye that help me view things close up — your ciliary muscles. These are the muscles that do all the focusing work when you're staring at a screen. And it was the kind of pressure that hurt so bad that I had to just close my eyes. I felt some relief by putting pressure on my eyes or putting a heat pad on them.

So I went down a rabbit hole on eye health, and that's what I'm writing about today. Eventually it also led me to build a free app for all of y'all to solve both my problem and hopefully what will not be your problem.

If you're staring at a screen for 8+ hours a day and NOT doing anything about it — this article is for you.

The 20-20-20 Rule — And Why It Might Not Be Enough

So you've probably heard of the 20-20-20 rule, and if you haven't, let me just break it down for you. Basically since the late 1990s when computer use got very common, eye doctors started to advise that every 20 minutes you should look at something at least 20 feet away for 20 seconds.

Now, the actual research behind these specific numbers is not great. While most researchers agree that the methodology is correct, what they don't agree on is how long you should be looking away and how far you should be looking away.

But what exactly is the science behind this? Well, your ciliary muscles — the ones helping you focus when you stare at a screen — basically need time to relax. If you think about it like working out:

Picture your eyes are biceps and you've been doing bicep curls for 8 hours without any breaks jacked up on pre work out. That's what you're doing to your eyes every single day. Yes, exactly that.

The American Optometric Association actually recommends you take a full 15-minute break every two hours of screen time on top of the 20-20-20 rule.

The point of all this is basically — you should be taking breaks from your screen regularly and you should be looking far away when you do that, because you need to rest the muscle in your eye that helps you see things up close.

*Count Tongula's Eye Break in action*

My Free Eye Break App

Now, how can you get better at doing this? Well, I built a free app called Count Tongula's Eye Break — which if you don't know, Count Tongula is my alias because I'm obsessed with vampires and I just love everything about them. 🧛

This is a free macOS menu bar app that helps enforce this rule for you. Because let's be honest — you're probably not going to remember every 20 minutes to do this. And what better way than to use the thing you're staring at all day to help you remember?

So what does it do? Every 20 minutes it will, with your permission, dim your screen with a beautiful Count Tongula-themed fog overlay and remind you to look away. It shows you a timer. And it also has that longer stretch break built in that the American Optometric Association recommended — which will trigger based on a set interval that you can customize.

Some other cool stuff I built in:

• If your screen is locked or your Mac sleeps, the timer pauses — so when you come back you're not automatically hit with an eye break reminder

• Multi-monitor support — if you're a coder like me or someone in tech who uses multiple monitors, this will make sure it dims all of them

• It automatically pauses during meetings and presentations — so you won't get a fog overlay popping up in the middle of a screen share

• And a lot more — streak tracking, stretch break reminders, 14 system sounds, fully customizable intervals, and a full Dracula-themed UI. Check out all the features here.

It's totally free and available on my website for download. Currently it's only available for Mac, but I am working on supporting Windows too because somebody emailed me and asked for it.

Download Eye Break → Free

Your Monitor Setup Matters More Than You Think

Now what else can you do about your monitor setup to improve your eye health besides taking breaks?

Distance

Super important — your monitor should always be at least an arm's length away from you. Now, if you are on a laptop, that might be different. But for the most part, try to put it a bit farther away from you and then increase the font size if it's way too tiny for you to see. That distance is going to help you a lot.

Your Monitor's Resolution

One more thing on monitors — I use an LG UltraFine 5K display and the reason is that higher pixel density will always result in sharper text. Sharper text means your eyes don't have to work as hard to focus. It's basically the same ciliary muscle thing we've been talking about this whole article — if the text on your screen is crisp, those muscles can relax a little more.

If you're still on a 1080p monitor, you should seriously consider upgrading to at least 4K or higher. It's probably one of the single best things you can do for your eye health besides taking breaks.

• ✅ What I use: LG UltraFine 5K

• 💵 Budget pick: Dell 27 Plus 4K Monitor (S2725QS)

Screen Height

The top of your screen should be at or slightly below your natural eye level when you're sitting down or standing. Angle it slightly upward so your neck stays neutral and you're looking very slightly down — this helps both your eyes and your posture.

The Lighting Setup Nobody Talks About

This one is super important — bias lighting. Bias lighting is light behind your monitor that illuminates the wall behind it. Now, if you have a desk with no wall behind it, you might want to move your desk or put some kind of panel behind it. You basically want to light the space behind your monitor.

The reason you want to do this is that when you're staring at a screen, your pupils decide how much to dilate based on the amount of light around the screen that you're looking at. So if you can lower the contrast between the amount of light radiating from the screen itself and get it to the same level of light that is behind the monitor, you can help your pupils reach a more stable level of dilation.

What I'd recommend is a dedicated bias light strip that goes directly behind your monitor — ideally covering the top edge at minimum, but preferably all 3-4 edges if you can afford it. Make sure you measure your monitor before you buy one — these strips come in different lengths and you want one that actually fits.

• ✅ What I use: MediaLight MK2 Flex 6500K — this is a proper bias light with CRI 98, not just a random LED strip from Amazon. It's worth it, trust bruv.

• 💵 Budget pick: Luminoodle by Power Practical — same 6500K color temp, USB-powered, under $20

My Screen Bar

I also have a BenQ ScreenBar sitting on top of my monitor. A screen bar is basically a light that mounts to the top of your display and lights your desk surface without creating glare on the screen. It's the best of both worlds — you get task lighting for your keyboard and desk area, but it doesn't mess with your screen contrast. If you're going to buy one thing from this list, I'd say bias lighting first, screen bar second.

• ✅ What I use: BenQ ScreenBar LED Monitor Light Bar

• 💵 Budget pick: Quntis Computer Monitor Lamp

• ⭐ Upgrade pick: BenQ ScreenBar Halo

Indirect Lighting — The Lamp

The other type of lighting you want is a lamp off to the side that bounces light off a wall. This is separate from the bias light behind your monitor — this is about filling the room with indirect light so your screen isn't the only bright thing in your field of vision.

I'd say put it to the left or right of your desk, angled vertically so the light bounces off your top left or top right wall if you have a wall in front of your desk.

• ✅ What I use: LED Desk Lamp with Clamp

Another tip — don't have too much overhead lighting. The reason is that overhead lighting creates glare because there's too much light coming from on top of you. When you have glare on your screen, it's causing your eyes to work harder to see what's actually on the screen. You want to avoid glare at all costs.

Also — watch out for where your windows are relative to your screen. If a window is directly in front of you — behind your monitor — and letting in a lot of sunlight, the massive brightness difference between the window and your screen forces your eyes to constantly adjust. Your pupils want to constrict for the bright window but dilate for the dimmer display, and that tug-of-war fatigues your eyes fast. Having a window directly behind you isn't great either, since sunlight will reflect off your screen and cause actual glare. Ideally, windows should be to your left or right — at a 90-degree angle to your monitor. If you can't move your desk, at least get some blackout curtains or blinds.

This is why it's basically impossible to use a computer on a sunny day at the beach — there's too much glare and you can't actually see what's on the screen.

The goal is: no single light source dominates. Your screen, the wall behind it, and the space around your desk should all be roughly the same brightness. That's what your eyes want.

The Blinking Problem

You probably know that you need to blink a lot, right? Another big thing here is eye moisture. What I do is I keep a bottle of eye drops at my desk at all times. Every desk — my desk at work, my desk at home. Because if you have to go find your eye drops, you're not going to use them. That's just how humans work.

Every time Count Tongula's Eye Break tells me to take one of those longer five-minute breaks, I'll put in some eye drops — pull down the bottom of my lower eyelid to create a pocket, let the drop settle in, and then close my eyes for about two minutes. That two minutes is about how long it takes for the drop to actually absorb into your eye.

Pro tip I learned way too late: while your eyes are closed, gently press your finger on the inner corner of your eye — right where your eyelid meets your nose. This is called punctal occlusion and it basically blocks the little drainage duct that would otherwise send your eye drop straight down into your nasal passages instead of letting it absorb into your eye. Without this, a lot of the drop just drains into your nose and you're basically wasting the entire eye drop. Two minutes, eyes closed, gentle pressure on the inner corner. That's the technique. Watch Dr. Sunny here do it for you live at 0:36.

Here are my picks:

• ✅ My pick: Refresh Tears — solid everyday eye drops that get the job done.

• ⭐ Upgrade pick: Refresh Plus (Preservative-Free) — single-use vials with no preservatives, perfect if you're using drops more than a few times a day.

ALSO, if you are going to put eye drops in more than four times a day, you should switch to a preservative-free drop. The reason is that when you're using regular eye drops with preservatives, it can actually irritate your eyes with too much use. Think of it like any medicine — if you use it too much, there are side effects. Same principle.

TL;DR — Your Eye Health Checklist

• Take breaks every 20 minutes and look at something 20 feet away for 20 seconds — download Count Tongula's Eye Break here to help you remember

• Consider longer breaks too — 5-15 minutes every 2 hours

• Monitor at arm's length away

• Top of screen at or slightly below eye level

• Upgrade to at least 4K — sharper text = less strain on your eyes

• Put a bias light strip behind your monitor

• Add an indirect lamp to the side — never let the screen be the only light source

• Get a screen bar for glare-free desk lighting

• Blink more + keep artificial tears on every desk — use them 2-4 times a day, eyes closed for 2 minutes after each drop!

  • If you're using drops more than 4x/day, switch to preservative-free!

My eyes don't hurt anymore. Yours shouldn't either.

Related: Claude Code Is (Seriously) Burning Me Out → — the productivity cycle that led me down this rabbit hole in the first place.

Notice

I'm not an eye doctor — I'm a software engineer who got really bad eye pain last year and went down a rabbit hole. Everything in this article is based on my personal experience and research, not medical advice. If you're experiencing severe eye problems, please go see an actual eye doctor. Some links in this article are affiliate links — if you buy something through them, I may earn a small commission at no extra cost to you. I only ever recommend products I actually use and alternatives I've researched.

I've been a software engineer for more than half a decade, previously at Amazon and The New York Times. These are observations from the trenches — not predictions. I also built Count Tongula's Eye Break — a free, open-source macOS app that enforces the 20-20-20 rule.

Update (June 2026). Since I wrote this, how I organize Claude projects has shifted, and I don’t run this exact Notion-hub setup day to day anymore. I’m keeping the piece up because the core idea still holds: Claude can read your project files but can’t update them, so a single source of truth it can point at beats a pile of static files. The prompts still work if you want to try it. Just read it as a snapshot of how I did things then, not my current workflow.

Ready to build? Jump to the companion article: Two Prompts That Turn Notion into Your Claude Project's Brain

If you use Claude Projects in the Claude app for non-code work — content strategy, product specs, brand guides, research — this is for you.

I had five files in my project. Strategy docs, published articles, reference material. Claude read them every conversation. Felt organized. Felt smart.

Then I deleted all of them.

Not because they were bad. Because Claude Projects has a gap that will drive you nuts the second you notice it: Claude can read your project files, but it can't update them. Read-only. Every single one. Desktop app, mobile app, web — doesn't matter. Same limitation everywhere.

So if you have anything that evolves — a content strategy, a spec, a reference that changes over time — you're stuck in this loop: download the file, manually delete the old version from the project, re-upload the new one. Every. Single. Time. It's brutal. On mobile it's genuinely painful.

I spent a month testing workarounds. Tried three different approaches. One of them not only fixed the problem — it turned into a better architecture than editable project files would've been anyway.

The Obvious Thing Didn't Work

My first instinct was to just move everything to Notion and delete the project files entirely. Makes sense, right? Claude has Notion access via MCP. It can read pages, edit pages, create new database entries. Problem solved.

Except — not really.

Without project files, Claude starts every conversation blind. It doesn't know what pages exist in Notion, doesn't know the database IDs, doesn't know the structure. You'd have to re-explain your whole setup every single time. "Go to my Content Hub, the database ID is cx532... look for the article called..."

That's not a workflow. That's a chore.

Some people suggested using a GitHub repo with Claude Code instead. And sure, that works great — if what you're managing is code. But these aren't code files. They're content strategies, brand guides, idea banks, reference docs with images, project trackers. A repo treats all of that like source code — raw text in a file tree. No formatting, no inline images, no tables you can actually look at without squinting.

Notion gives you an app. You open it on your phone, your laptop, wherever — and your docs look like docs. Tables look like tables. Images are right there. You're not opening a terminal or learning git commands to check your content calendar. Not everything belongs in a developer tool, and the people who need to touch these docs — PMs, designers, content leads — shouldn't need to learn version control to update a brand guide.

The Thing That Actually Works: One File That Knows Where Everything Lives

Here's what I landed on — and it's almost embarrassingly simple.

One markdown file. Lives in your Claude Project. Maybe 40 lines long. I called mine OVERVIEW.md.

It doesn't contain your actual content. It's a map. Think of it like a table of contents for a book you keep in a different building. The overview file tells Claude: here's where the Notion hub lives. Here's the database ID. Here's what properties exist. Here's what's been published. Here are the rules and guidelines for this project.

That's it.

Claude reads this file automatically every conversation — because it's a project file. Instantly knows the lay of the land. When it needs the actual content of an article or a doc, it fetches from Notion. One tool call. Takes a few seconds.

And here's the key — Claude can write back. Edit a draft? Update a status? Add a new entry to the database? It just does it. In Notion. Where the content actually lives.

The project file stays lightweight and stable. The Notion database stays current and editable. They work together.

If you're an engineer who uses Claude Code, you already know this pattern — it's exactly what a CLAUDE.md file does for a codebase. A small file that tells Claude "here's how this project works, here's where things live." Same architecture, just for non-code work. And unlike project files, this setup lets Claude write back — Notion stays fully editable while the overview file stays lightweight and read-only.

Why This Is Better Than You'd Think

The obvious win is editability. But there are a few things I didn't expect.

Your context window stops suffocating. When I had five project files loaded — three full articles, a strategy doc, a standalone post — that's a lot of tokens consumed before Claude even reads my first message. The overview file is maybe 50 lines. Everything else gets fetched on demand. My context window went from stuffed to breathing room.

It scales without bloating. Say you've got a dozen docs in your project — specs, briefs, meeting notes, whatever. You don't need their full text loaded every conversation. But you do need to know they exist, what they're called, and where they live — in case you want to reference or update them. The overview file handles that. When you add new docs, the overview grows by a couple lines. The old approach? More and more project files until the context window is packed with content you haven't touched in months.

Version history comes free. Notion tracks every edit. If Claude writes something wrong — edits an article intro badly, overwrites a section — you roll it back. Project files don't have that.

It works from your phone. I dictate all my prompts on Claude Desktop via SuperWhisper. The Notion setup works identically on mobile — Claude reads the overview file, fetches from Notion, writes back. No re-uploading files from your phone's file picker. That workflow was genuinely painful before.

How to Set This Up Yourself

Takes about 10 minutes.

Start a conversation in your Claude project and tell Claude to create a Notion hub page. Give it a name, tell it what database properties you need — type, status, tags, dates, whatever makes sense for your project. Have Claude migrate your existing project file content into Notion pages.

Then — the important part — have Claude generate an overview file. One markdown file. It should contain the Notion page URLs, the database ID so Claude can create new entries, a summary of what each page is, and any rules or guidelines for the project.

Download that overview file. Add it to your Claude project. Delete all the other project files. They live in Notion now.

That's it. Every conversation going forward, Claude reads the overview, knows where everything lives, fetches what it needs, writes directly to Notion.

I made two starter templates you can customize in less than a minute — grab them here

The Bigger Picture

This isn't really about Notion. Or project files. Or even Claude.

It's about a pattern that keeps showing up everywhere I look: the best AI workflows aren't the ones where you give the AI all the information upfront. They're the ones where you give it a map — and let it go find what it needs.

One lightweight file that says "here's what exists and where to find it." That's the whole move.

And honestly? If Anthropic eventually lets Claude edit project files directly, this setup still wins. Because the separation — stable map in the project, living docs in Notion — is just a better architecture for anything that changes over time. You want your persistent context to be small and stable. You want your working documents to be wherever gives you the most flexibility.

The map doesn't need to change every time the territory does.

I've been a software engineer for more than half a decade, previously at Amazon and The New York Times. These are observations from the trenches — not predictions.

Get the free toolkit

Update (June 2026). Since I wrote this, how I organize Claude projects has shifted, and I don’t run this exact Notion-hub setup day to day anymore. I’m keeping the piece up because the core idea still holds: Claude can read your project files but can’t update them, so a single source of truth it can point at beats a pile of static files. The prompts still work if you want to try it. Just read it as a snapshot of how I did things then, not my current workflow.

Read first: Delete Your Claude Project Files — it explains the architecture and why this setup works. Come back here when you're ready to build it.

By the end of this article, you'll have a single Notion hub that replaces all your scattered Claude project files — and Claude will read from it, write to it, and stay in sync automatically. All you do is copy one prompt, fill in a few details, and paste it into Claude.

Two prompts below. One for new projects, one for migrating existing ones. Pick the one that fits.

Before you start

You need a Claude Project. Everything below happens inside a Claude Project — not a regular conversation. If you don't have one yet, create a new project in the Claude app first. The overview file you'll generate gets added as a project file, which means every conversation in that project will automatically have it loaded as context. Without a project, there's nowhere to put it.

You need Notion connected to Claude. In the Claude app, click your name in the bottom left, go to Settings, then Connectors, and click Browse connectors. Find Notion and connect it. (Note: Anthropic is moving connectors under "Customize" — if you don't see a Connectors tab, check there instead.) Takes 30 seconds. Without this, Claude can't read or write to Notion and none of this works.

Template 1: Starting a new project

Use this if you're creating a new Claude Project from scratch and want to set up the Notion architecture from day one.

Step 1: Fill in the "My project details" section at the top of the prompt below. Everything in brackets needs your own values — delete any lines you don't need. You only need to fill in the top section; the rest of the prompt references it automatically.

Step 2: Start a conversation in your Claude project and paste the whole thing:

My project details:
- Project name: [your project name]
- Content types: [e.g., Blog Post, Tutorial, Guide]
- Statuses: [e.g., Idea, Draft, In Progress, Done]
- Additional database properties: [e.g., Priority, Due Date — or delete this line]
- Project rules: [e.g., "Use casual tone in all drafts" — or delete this line]

Using the project details above, set up this project with Notion as the source of truth:

1. Create a Notion parent page named after my project with "Hub" appended
2. Create a Notion database under it named after my project with "Library" appended, using the content types, statuses, and any additional properties I listed
3. Generate a single overview markdown file (OVERVIEW.md) that contains:
   - Links to the Notion parent page and database
   - The database's data source ID (so I can create new entries)
   - Instructions for how to read, edit, and create content
   - My project rules from above

Step 3: Claude will create everything in Notion and give you an OVERVIEW.md file.

Step 4: Download the OVERVIEW.md and add it to your Claude project as a project file. That's it.

Here's what the overview file should roughly look like:

# Project Name — Hub

All docs live in Notion. Claude reads and writes directly there. This file is a quick-reference map.

---

## Notion Locations

Hub Page: [Notion URL will go here]

Database: [Notion URL will go here]
- Data source ID: [ID will go here]
- Properties: Title, Type, Status, [your properties]

---

## Key Pages

| Page | Description | Notion URL |
|------|-------------|------------|
| Project Spec | what it contains | URL |
| Brand Guide | what it contains | URL |

---

## Project Rules
- Always check the spec before making changes
- Use casual tone in all drafts

## How Claude Should Use This
- To read content: Fetch the Notion URL directly
- To edit content: Use Notion update tools on the page
- To add new entries: Create a new page in the database (data source ID above)
- To check status: Search or fetch the database

Template 2: Migrating an existing project

Use this if you already have files in a Claude Project and want to migrate everything to Notion.

Step 1: Fill in the "My project details" section at the top of the prompt below. Everything in brackets needs your own values — delete any lines you don't need. You only need to fill in the top section; the rest of the prompt references it automatically.

Step 2: Start a conversation in your Claude project and paste the whole thing:

My project details:
- Project name: [your project name]
- Content types: [e.g., Blog Post, Tutorial, Guide]
- Statuses: [e.g., Idea, Draft, In Progress, Done]
- Additional database properties: [e.g., Priority, Due Date — or delete this line]
- Project rules: [e.g., "Always check the spec before making changes" — or delete this line]

Using the project details above, migrate this project to Notion as the source of truth:

1. Create a Notion parent page named after my project with "Hub" appended
2. Create a Notion database under it named after my project with "Library" appended, using the content types, statuses, and any additional properties I listed
3. Migrate all current project file content into Notion pages in that database
4. Generate a single overview markdown file (OVERVIEW.md) that contains:
   - Links to the Notion parent page and database
   - The database's data source ID (so I can create new entries)
   - A brief summary of what each migrated page contains
   - My project rules from above
   - Instructions for how to read, edit, and create content

Step 3: Claude will migrate everything to Notion and give you an OVERVIEW.md file.

Step 4: Download the OVERVIEW.md file and add it to your Claude project:

• Go to your project settings

• Add OVERVIEW.md as a project file

• Delete all other project files — they live in Notion now

Step 5: Done. Every new conversation in that project will:

• Instantly load the overview (links, rules, structure)

• Fetch full content from Notion only when needed

• Write edits directly to Notion

Tips for both templates

• Update the overview file when you add major new pages (just add a row to the table)

• Use database properties to track status so Claude can filter and search

• If you need Claude to reference a specific page, just paste the Notion URL in chat — Claude will fetch it

• Notion has version history — if Claude writes something wrong, you can roll it back

I've been a software engineer for more than half a decade, previously at Amazon and The New York Times. These are lessons from real production work, not theoretical predictions.

Grab the toolkit

Claude Gave Me a Productivity Problem

I'm more productive than I've ever been in my life, full stop.

I'm also more burned out than I've ever been in my life, full stop.

Those two things are not a coincidence. That's the whole point of this article.

The Loop Nobody Warned Me About

Here's what actually happens when Claude Code starts working for you:

You ship something fast. Like, embarrassingly fast. You see results. You see what's NEXT. You build that too. You see what's next after that. You build that too.

Ship fast → see results fast → see MORE to build → say yes to all of it → repeat.

It's not a bug. It's the design. Faster feedback loops make the backlog feel shrinkable. The backlog is never shrinkable. It's infinite. You just have a better view of it now.

I call it the Catch-22 of AI productivity. Claude Code doesn't give you more time. It gives you more visibility into everything you could build. And the gap between "what exists" and "what's possible" is bottomless.

What Actually Opened Up For Me

Let me be specific, because vague burnout talk is useless. In the last few months I have:

• Fully shipped Count Tongula's Eye Break — my free macOS app that enforces the 20-20-20 rule (Eye health is so important!)

• Completely rebuilt my personal portfolio website from scratch

• Setup my first OpenClaw

• Started creating my own soda

• Completely rebuilt 7 web development portfolio projects from half a decade ago

• Finished producing my next dance track — drops April 3rd

That's not a side project list. That's a whole creative life that Claude Code made feel simultaneously possible. Every single one of those things felt easy-ish. Low activation energy. Just spin up a session and go.

That's the trap.

When everything feels small and easy, you say yes to everything. And then you wake up and you're maintaining five projects, you have a 40-hour day job, and you haven't slept more than 4-5 hours a night in two weeks.

This Isn't Just Me

Steve Yegge — former engineer at Google and Amazon — wrote about what he called "sleep attacks." After long Claude Code sessions, he'd randomly fall asleep mid-day without warning. His colleagues were talking about installing nap pods.

A Harvard Business Review study tracked workers at a 200-person tech company for eight months. AI didn't reduce their work. It made them work faster, take on more tasks, and extend into more hours of the day — without being asked to. They specifically flagged "fatigue, burnout, and a growing sense that work is harder to step away from."

Bloomberg literally published a piece this month calling it "The Great Productivity Panic of 2026."

Vibe coding was supposed to be chill. The vibes are clearly off.

The Fix Isn't What You Think

Every burnout article tells you to take breaks, log off at 6pm, go touch grass. Cool. Not the answer.

The real answer: put friction back in the process. Because Claude Code removed all of it.

I actually ran this problem through five different expert perspectives — behavioral psychologist, stoic philosopher, systems designer, burnout researcher, real developers. All five landed in the same place. Not "do less." Something more specific:

Rule 1: Work in 2-week sprints. Ship something. Then don't touch anything new for 3 days.

That's it. When you ship — anything — you're locked out of starting new implementation work for 3 days. You can plan, document, think. No coding. No new sessions. No "just one quick thing."

Before AI, shipping felt like an ending because you were exhausted. You needed the break naturally. Now shipping feels like a green light — you close one terminal and open another. The 3-day lockout puts the ending back in artificially.

Rule 2: On top of that I also built a Kanban board in Notion. Hard rule — only 3 projects in "active" at any given time. Want to add something new? Something else has to move out first.

The Kanban tells me what I'm working on. The lockout tells me when to stop. Claude Code can't make either of those calls. That's the whole point.

The Real Thing Worth Saying

Claude Code didn't make me a more productive engineer. It made me a person who ships software, produces music, builds apps, brews soda — things I never in my life thought I would have the time or resources for.

That's genuinely incredible. I don't want to give that back.

But the expansion of what's possible is not the same as having more capacity. Your bandwidth as a human didn't 10x. Your output ceiling did. That gap — between what you can see and what you can actually sustain — that's where burnout lives.

The answer isn't to slow the tool down. It's to be more deliberate about what you point it at.

Three projects, three day breaks. Hard limit. Everything else waits.

How are you managing this? Drop your approach in the comments — genuinely curious what's working for other people.

Update: Anthropic's session limits accidentally became part of my fix — more here →.

I've been a software engineer for more than half a decade, previously at Amazon and The New York Times. These are observations from the trenches — not predictions.

The best engineers I know are spending their days doing something they're actually terrible at.

They're not bad at writing code — they're incredible at it. But they've stopped doing the thing they're best at, and nobody told them. They just... drifted into it. I did the same thing for way too long at work — using Claude Code heavily on a large-scale repo migration — and I didn't even notice until I stepped back and looked at how I was actually spending my time.

The preparation IS the work now. That's it.

Not writing the code. Not debugging the code. Not even reviewing. The thing that determines whether Claude one-shots your ticket or hallucinates straight AI garbage — is how well you set up the problem before the AI writes a single line.

If you prepare well, Claude will understand it and probably nail it first try. If you don't, you'll spend three hours fighting an AI that's over-confidently building the wrong thing. And that's three hours of your best engineering skill — your ability to think through problems — completely wasted on cleanup.

So What Did We Actually Become?

Here's what I realized halfway through our migration: we're not writing code anymore — we're curating context.

It's basically air traffic control, right? The controller doesn't fly the planes — but every plane in the sky depends on them to land safely. They're sequencing — which plane goes first, which one holds, which runway is clear. They have a constrained space (the airspace) and if they overload it, things collide. The skill isn't in the flying. It's in the coordination.

That's what we're doing now. The "flying" — the implementation — Claude handles that. But you're the one deciding what context to load, what files to point it at, what order to tackle things in, and what constraints to set. You're managing a constrained space and sequencing work so nothing collides. And if your sequencing is wrong? The whole thing falls apart — doesn't matter how capable the aircraft are.

You're not paid to write every line of code anymore. You're paid to know which 5% of context actually matters right now.

Here's the thing about AI coding tool best practices — they basically all boil down to one constraint: when you ask an AI to solve something complex, it needs to understand the whole picture. Give it fragments and it guesses. Give it noise and it drowns. Fill the context window wrong and Claude doesn't warn you — it just confidently builds the wrong thing. And you'll spend three hours debugging something that should have taken fifteen minutes.

So yeah, every technique I'm about to share? Managing that constraint. You're not writing prompts anymore — you're deciding what the AI actually needs to see.

Here's Where Most People Go Wrong

Everyone wants to give Claude the whole project at once. They all do. Like — "here's my codebase, migrate the thing, figure it out." Claude will hallucinate you into a brick wall.

Claude gets confused when tasks aren't EXTREMELY scoped. And I mean extremely. This is what kills you — hallucinated code that looks right but does absolutely nothing.

One task per prompt. One major change per PR. Build the skeleton first. One bone at a time. Sounds slow. It's way way faster — because each one lands clean.

This matters beyond just code quality too — PR reviewability, QA testing, debugging. When something breaks, you know exactly which change caused it. Smaller, targeted context = better results. The less noise the AI has to parse, the more accurate its output.

But here's the part nobody talks about: before you systematize anything, do one full task end-to-end manually. Just one. Start to finish. No shortcuts.

That first rep is where you learn everything. Where does Claude struggle? What context does it actually need? Where does it make assumptions? What does the "happy path" look like when it goes right?

For our repo migration, the first task we migrated was messy. Took way longer than it should have. But it taught us exactly what Claude needed to succeed — which files to reference, what order to build dependencies in, what instructions to put in our repo's CLAUDE.md. Every task after that was dramatically faster because we'd done the spike first. Once you've done one successfully, that becomes your reference pattern — and example-driven prompts produce way more consistent results than spec-driven ones. Every. Single. Time.

And here's a subtle one that bites people constantly — tell the AI which layer something belongs in. Explicitly. If your architecture has distinct layers, Claude needs to know which one it's working in, or it'll write duplicate logic across layers. "Should the system check if a user is authenticated in layer A itself, or layer B?" If you don't specify, Claude will guess. And it will guess wrong.

The Overlooked Part: Your Mistakes Are Worth More Than Your Wins

Once your first task works, lock it in as a reference pattern. Include the file path with line numbers so Claude can read the actual code rather than relying on your description.

But — and this is super important — don't just track what works. Track what went wrong. If you're doing repetitive work, record mistakes and how to avoid them. Counter-intuitive behaviors, one-off exceptions, anything that goes against the general architecture — document it. If you don't, Claude will follow the wrong pattern and you'll debug the same issue three times.

Here's the move: when Claude makes a mistake, tell it to update its own rules. Don't let it repeat it. Over time, your documentation becomes institutional memory — basically a compounding record of every lesson you've learned, locked in. That's the real competitive advantage. Not your prompting skill. Your playbook.

Traditional code-writing ability is becoming a commodity. The scarcity now is in setup — in knowing what to ask for.

When to Stop Preparing (And Just Ship It)

These techniques are for complex, multi-session, multi-file work. Don't over-apply them.

Separate thinking from doing — don't ask Claude to plan and implement in the same prompt. Ask it to plan first always — output a plan, not code. Review the plan. Then tell it to execute. And when things go sideways during implementation, don't keep pushing forward — go back to planning and re-plan from scratch. A fresh plan consistently beats incremental patching on a broken implementation.

Know when to reset — long sessions degrade in quality. When Claude starts doing weird stuff — inserting defaults you didn't ask for, ignoring constraints you set — it's cheaper to start a fresh session with a clean prompt than to keep fighting. This is another reason well-scoped tasks matter: if your prompts are self-contained, starting fresh is painless. (Tactical note on when to throw the session away →)

If the task fits in one prompt and one PR — a one-line bug fix, a simple function addition, a config change — just do it directly. Not every single task needs a dependency chain, a skeleton, and a reference pattern. The right question is: "Will the AI need more context than fits cleanly in one session?" If yes, prepare. If no, just ask.

The Bottom Line

You used to be measured by how much code you could write. Now you're measured by how well you prepare. And that's not a demotion — it's a promotion you didn't ask for. Most people still haven't realized they got it.

The engineers getting the best results with Claude aren't the ones writing the cleverest prompts. They're the ones who prepare so well that Claude has no room to fail. Break the problem down. Scope the task. Give Claude exactly what it needs — nothing more, nothing less. And when things get messy, kill the session and start fresh.

The code writes itself now. Your job is to make sure it's writing the right thing.

I've been a software engineer for more than half a decade, previously at Amazon and The New York Times. These are lessons from real production work, not theoretical predictions.

I've been using Claude Code HEAVY at work. Like, 8 hours a day speaking to 6 different robots at the same time, working on 6 tickets at the same time. So much so that our team cannot handle the amount of PRs that we're spitting out because we're just not able to keep up with the output. The more I use it, the more I'm convinced of this fact:

We're doing code review wrong.

And our process is already breaking in 2026. Our default assumption is outdated:

"A human wrote every line, so a human should read every line."

That world is quickly fading. If you keep reviewing things like it's 2016 in 2026, your process is going to break. Whether you're an engineer, a manager, or a product manager — this problem will affect how you do everything.

We Stopped Reading Assembly — But This Isn't Quite The Same Move

We've been in a similar situation before. When we moved from assembly to higher-level languages, nobody said "hey, we still need to review the entire assembly output." We trusted the abstraction. We were fine just reviewing the higher-level code. We shifted our focus. This AI-generated shift is similar, but a hundred times bigger — and it has one critical difference.

Here we go. We already tolerate a lot of black boxes constantly. You're not reading every npm package you install. Nobody reviews the JavaScript that TypeScript compiles down to. Nobody reads the server configs AWS provisions when you write in Terraform. You write a SQL query and you let the query planner decide how to execute.

So here's the critical difference. Compilers, like the examples I just gave, are deterministic and formally verified. LLMs are not. Two identical prompts fed to Claude can produce very different code. Worse, AI agents actively drift from their own instructions as context bloats. Your CLAUDE.md file might say "don't insert default values," but the agent might do it anyway 3,000 tokens in. I don't know if this will get fixed with better models because it seems very fundamental to how these models work to begin with.

So how can we fix our code review bottleneck problem? With better guardrails.

Review The Plan, Then Skim The Diff

If implementation is increasingly generated — and it is — the highest-leverage review shifts earlier in the process: plans, constraints, interfaces, architecture, risks, tests.

For most changes, when you're reading the PR summary, you're asking: Does this plan sound correct? Are the constraints right? Are there any edge cases? Do the tests on the PR prove the behavior? That's much higher leverage than reading every single line.

For things like auth, payments, or permission checks, you probably still want targeted line-by-line reading even when the plan looks solid. Why? Because agents will drift. Plans will not capture every single implementation error or nitpick. Critical code like this always deserves human eyes on every line. I'm not saying we should move to a no-review process — I'm saying not all code deserves the same depth of review. Some code gets a skim. Some code gets every line read. The skill is knowing which is which.

The Review Bottleneck Nobody Wants To Admit

Here's a dirty secret. Code is being written way WAY faster than it can possibly be reviewed by a human.

Teams with high AI adoption merged 98% more PRs, but PR review time increased 91%.

Faros AI analyzed telemetry across 10,000+ developers and confirmed this. You're producing 2x the output but reviews take 2x as long. And that's before parallelization — engineers running 3–5 sessions at once across worktrees are generating multiple streams at once.

Teams that used to push out 10 PRs a week are now staring at 50–100. If your code review stays as "carefully read everything line by line" while Claude turns every engineer into a PR production factory, your org becomes a firehose with a human-sized funnel. Something needs to change.

My Proposed Solution

Tiered review systems.

Tier 1: fully automated — linting, static analysis, unit tests, security scanning, type checking. No human involved.

Tier 2: peer review for behavior, correctness, and "does this match the intent?"

Tier 3: senior/security review for critical paths — auth, payments, PII, system boundaries. Most changes should never need Tier 3.

Every layer should have AI-assisted review. And here's the key insight — don't let your agent grade its own homework. A separate subagent will catch semantic issues before the code ever reaches human eyes — in under a minute. Always start a fresh session to review your code.

Guardrails Become The Product

So, if we stop reading everything line by line — and I'm saying that we should — then guardrails stop being nice-to-haves and start becoming must-haves. They become the actual real task that you need to do. AI in its current state has a lot of its faults. It can silently insert defaults, it can name things badly without proper context from you, it can drift from instructions, it can also hallucinate completely once your context is too bloated. So you're going to need guardrails to catch these.

When I say guardrails, I'm talking about tests. You're going to need way more test coverage than most production companies actually have. You need critical testing, integration testing, end-to-end testing, regression tests for every single bug that you find. Your tests become the contract of your task. But is there a problem with also using AI to generate tests too?

Why yes, of course. So test quality also needs close review, especially for critical ones. Using something like a coverage helper can totally be gamed by AI. What matters is that your tests prove that what could be a dangerous piece of code actually works correctly. You should probably create a test for every production incident that happens. Similar to Thoriq's advice — one of the principal engineers at Anthropic — you should always be telling Claude about your bugs that you run into and your gotchas. You probably should also be having security checks running on every PR in your GitHub workflows.

Architecture Decision Records also become super important. Your CLAUDE.md is kind of already a lightweight version of this. The teams that I've seen getting the most out of Claude treat CLAUDE.md as a living document. Every time a mistake is noticed, they update their CLAUDE.md file. That CLAUDE.md file becomes institutional memory — a compounding record of all lessons learned. Observability gets way more important too with this approach. Telling Claude how to read your logs, tracings, metrics, and alerts will just make this entire workflow work way smoother. If it's very well documented and it's clear what it's examining, you'll know when there are bugs and when to fix them and how to fix them.

This also changes how junior engineers learn — but that's a whole other conversation, and I've since written about it here. Short version: the apprenticeship isn't dead, it just looks different now.

TLDR: What I'd Actually Do Next Week

Cap your PRs at ~400 lines or so. Enforce this on GitHub. Only allow overrides if someone explicitly tries to override, which also alerts your team.

Create a risk tier rubric. Automate low-risk PRs. High-risk PRs — the ones that might modify user data or auth — require senior eyes and targeted diff reading.

Require a thorough PR summary. PR summaries are probably the most important artifact now. I'll be writing a separate article on this, so look out for it.

Make automated checks mandatory. Type checking, security scans, test coverage. All of this must be a requirement now. Not nice-to-have. No exceptions.

Set up AI review during development, not just after it hits GitHub. Get into the habit of spawning a new AI agent to review your code after you write it on your own terminal. Look into using Claude's new /simplify command. Don't ever let your agents grade their own homework.

Document your rules so Claude can read them. Put CLAUDE.md files in every single repo with more in-depth rules in the .claude/rules folder. When Claude makes a mistake, always update these files.

Track your PR review queue. Start putting metrics around how long PRs take to review. This is where the bottleneck shows up first — and you should have good observability on it.

The Bottom Line

The role is shifting from "write code, review code" to "design thorough Jira ticket work, translate tickets into concise yet thorough prompts, define your guardrails, and then verify the outcome."

This isn't a con — it's a huge upgrade. But only if you earn it with the correct infrastructure. So stop reading every line of code by default. But don't confuse that with trusting everything Claude says blindly. You need to trust the guardrails, the tests, the gates. Human judgment should come in for things that only humans can judge — like product requirements, for example — and make sure you're still applying human judgment at the boundaries where the real damage happens.

So don't stop reviewing. Just stop reviewing everything the same way you've been doing your whole life.

I've been a software engineer for more than half a decade at both Amazon and The New York Times, recently using Claude extensively in production workflows. These are observations from the trenches, not theoretical predictions. The shift is already happening — prepare yourselves!