DEV Community: Alex Tong

AI Has No Taste: Why Everything Built With It Looks the Same

Alex Tong — Wed, 15 Jul 2026 13:00:00 +0000

🎟️ I walked past 10ish startup booths at Datadog's DASH 2026 last week. By the eighth one, I could basically predict the exact landing page before I got to it.

Same centered hero. Same two big gradient buttons. Same rounded cards with the same soft shadow. Same clean sans-serif font (iykyk). Same dark mode, same single accent color.

I could immediately tell that almost all of these products were built heavily with Claude Code or OpenAI's Codex. I use these tools every single day, so I can spot it the moment I see it. And don't get me wrong, these are super talented people shipping insanely fast. The velocity is real.

One of my managers put me onto a line she heard on Lenny's Newsletter this week: "AI has no taste." Walking that floor at DASH, it clicked.

Velocity !== taste. AI is REALLY good at giving you the "average" answer. The safe layout. The default component. The thing 10,000 repos did. You ask it to build a landing page and it builds you THE landing page, basically the average of everything it ever scraped on the internet.

And that's the trap. When everybody builds from the same model, everybody ships the same product. A product that looks like every other product is a product nobody remembers, I can guarantee it.

And to be clear, I do think it's totally fine for your actual codebase to lack taste. Code has a target: optimal complexity, the simplest thing that solves the problem, and once you hit both, you're done. Design and product though? They have different targets. There's no "optimal" accent color or "optimal" feature. That's where the taste lives, the SPICE: knowing which idea is even worth building (most aren't), killing that default gradient, making the one weird, opinionated call the model would never suggest on its own. That part you still can't automate (at least for now 😭).

So maybe the new senior engineering skill isn't just building fast. We can honestly all build fast now. It's being the one with the eye, for product and design, to spot the median answer and say: nope, not that one.

Genuinely curious where you land: is "taste" the real moat now? Or does good code have taste too, and I'm drawing the line in the wrong place? 🧛

P.S. Evidence this photo wasn't AI-generated: I'm caught mid-sentence asking the photographer to take it in landscape instead. 📸

Related: Building the eye to spot the default answer and steer against it is exactly what I coach, whether you're an engineer or a product manager. More here: alextong.me/services →

You're building on rented land: don't tie your work to a single AI model

Alex Tong — Tue, 14 Jul 2026 13:00:00 +0000

🏚️ What a crazy email to wake up to.

src="/notes/rented-land/fable-suspended-email.jpg"
alt='Email from the Claude team with the subject "Update: Claude Fable 5 access suspended"'
className="mx-auto block w-auto max-h-[40rem] rounded-lg border border-border/10"
/>

If you haven't been following the news: Fable was out for 72 hours before a letter from the US government forced Anthropic to pull the most powerful model it had ever shipped. Talk about a press release. 😬

If you spent this whole week wiring Fable into a new workflow, recording a tutorial on it, or building a side project that leaned on it, first off, sorry to hear that. 🥲

But hopefully this helps all of us realize something: frontier models are not stable primitives. Unlike past versions of software, these models aren't stable releases you can safely build on top of the minute they drop. A model can vanish over a security threat, a price change, a policy shift, or a single letter from the Commerce Department.

So the things you really want to build shouldn't be tied to one specific model or one company. They should be adaptable. The thing worth investing in is the muscle underneath it all: the judgment, the process, your ability to get close to the same result out of any model. And all of that lives in your workflows, not in the model.

As much of a Claude fanboy as I am, this is a great lesson. Whatever you build on top of a single frontier model, you're building on rented land. 🏚️

So don't fall in love with specific models. Work on the skills that let you stay model-agnostic, because those are the ones that survive the next letter from the government.

Related: Building that model-agnostic muscle is exactly what I help engineers and teams (and really anyone) do. If that's useful to you, it's all here: alextong.me/services →

Earn the right to optimize

Alex Tong — Thu, 09 Jul 2026 13:00:00 +0000

Your LinkedIn feed this week: "I built a second brain." "How I run 12 agents at once." "10 MCP servers you need." It's 10:30AM Tuesday and that's the 3rd one I've scrolled past.

I orchestrate agents daily. Use 2-3 MCPs and 10 skills regularly. The second brain on my computer? Gathering dust for months.

Last month I bought a 5-year-old M1 Max MacBook for $1,300 for my music project SUIMA. The latest maxed-out M5 Max next to it was $7,349 with 128GB of RAM. Ten years ago I'd have gone into debt for the M5 Max and only used a third of it.

Here's what I finally learned after 15 years of terrible purchases and too much time spent researching the best of the best: you don't earn the best gear by buying it. You earn it by needing it.

Same goes for Claude.

Half my LinkedIn feed is installing new repos, new frameworks, new wrappers. Trying to make Claude better, faster, smarter. Multi-agent boilerplate before they've tried one agent. Second-brain setups on their computers, but their projects haven't shipped a feature in months. Token-optimization playbooks for context windows they've never come close to filling.

Tuning the bike shed instead of practicing how to actually ride the dang thing.

Here's the thing, installing FEELS like work. It's measurable. It's debatable. It's safer than the actual hard part: shipping features with what Claude already gives you.

So they install.

Look, I'm not saying any of this is bad. Tools matter. Eventually. When the constraint is real and you can feel it in your builds, that's when you reach for sub-agents, custom MCP servers, that dang glorious second brain.

Multi-agent workflows? I earned those by hitting Claude's single-agent ceiling so often I felt it in my sleep. The second brain? I built it before I'd hit any limit at all. It's been gathering dust ever since. An artifact of FOMO, not need.

On your own projects, have you actually hit the ceiling of what Claude can do on its own? If not, you don't have a tooling problem. You have a shipping problem.

You need to earn the right to optimize first.

Third-party tools are a reward for hitting Claude's ceiling. Not a substitute for finding it.

What's something you "optimized" way before you'd earned it?

🎛️

Teaching CLAUDE.md to 500 engineers at EngX

Alex Tong — Wed, 08 Jul 2026 13:00:00 +0000

📣 📰 Just wrapped up EngX — The New York Times' annual engineering conference. Two days, 500 engineers, tons of special guests from the most amazing corners of the industries and workshops where our teams all shipped real work. 🧛

I presented "The Definitive Guide to CLAUDE(dot)md" — a 90-minute talk + workshop on teaching Claude what it can't learn from your code. Sarah Duncan presented it alongside me in a parallel room (500 engineers is a lot for one room in the heart of NYC).

Also may have gone a little overboard with the Game of Thrones references, no ragrets. 😏🐉

👷 Teaching this forced me to crystallize more than half a decade of engineering instincts into something tangible. There's a huge difference between knowing how to do something and being able to explain why it works. And teaching a room full of amazing engineers is the fastest way I've found to find gaps in your own thinking.

🫶 Grateful to the entire team that made EngX happen!

Earlier: Our internal AI training was the first run at this — What teaching AI taught me about my own thinking →.

Claude's session limits accidentally fixed my burnout

Alex Tong — Tue, 07 Jul 2026 13:00:00 +0000

Anthropic made a trade-off with your productivity last month and they didn't ask you first. 😬

I've been noticing two things happening in parallel as I use Claude now.

Number 1 — session limits are way tighter. I'm hitting caps way faster than I used to, especially during peak hours. On weekends I basically get stopped by lunchtime. We know this is true because they publicly announced it.

Number 2 — something about the reasoning feels off to me now? I always use Opus 4.6 with extended thinking on and high effort — but the output seems shallower lately. I find myself correcting more and more mistakes even though I know my internal Claude files have drastically improved over the months. And with the new auto dream mode on, I can only imagine my memories have also drastically improved. So there's no reason why my performance should be degrading out of nowhere... 🤔

We know that publicly, Anthropic quietly dropped the default thinking effort from high to medium back in early March. But what we haven't confirmed is if anything has actually changed with the model. Or at least I haven't personally confirmed — I'm sure somewhere on Reddit or on the interwebs, someone has already figured this out.

Here's where it gets super weird though...

The session limits are actually kind of saving me.

I wrote an entire newsletter a couple weeks ago about Claude Code burning me out. Because I haven't really felt able to stop working — the tool never stopped being available so I'm always available. But now Anthropic built the off-switch that I literally can't turn back on. Unless I upgrade my plan or pay for extra usage (which I don't think I'm gonna do...)

So I'm sitting in this uncomfortable spot where the same company simultaneously made my health better and my work worse? Although I do have them to thank for making my work drastically better to begin with. Didn't sign up for this trade...but I'm also not sure I'd trade it back either?

If you're paying for a Claude subscription and feeling these two new things too — are you feeling relieved or frustrated? Because somehow I'm feelin' both? 🤷

Claude won't kill junior engineering jobs

Alex Tong — Thu, 02 Jul 2026 13:00:00 +0000

"Claude is going to kill junior engineering jobs." 🤔

I keep hearing this and I heavily disagree.

But the juniors who don't adapt to what's ACTUALLY changing? They're going to get left behind.

Will it change the role of junior engineers? Of course. It's changing the role of every engineer.

Maybe it's the old model. Juniors aren't going to get assigned a bug, write the code, and wait for a senior to review it — because Claude is the one writing the implementation now.

Here's the critical problem with that shift. Mid-level and senior engineers spent YEARS building their pattern recognition before AI existed. They wrote bad code for years and had other seniors and staff engineers critique it.

Now that Claude is generating most of our code — how does a junior engineer learn?

Well, by asking Claude of course. Claude Code literally has a Learning mode that drops TODO(human) markers and asks YOU to implement the key pieces.

How?

Activate it using /config
Type "Output Style" in the search bar
Choose "Learning" for the hands-on approach or "Explanatory" for lecture-based.

It's like pair programming with a senior 24/7 who never gets tired (or annoyed at you).

But honestly — the biggest shift isn't even about code anymore. It's about turning vague tickets into crisp specs. Juniors who partner with their product managers and understand things on a high level perspective, instead of waiting for requirements to land in their lap are going to level up the fastest.

So no, I do not think Claude is going to kill junior engineering jobs. If anything, it's just shifting the role to something more like a junior builder. 🔨

Are juniors at your company adapting or still stuck in the old model?

When Claude starts hallucinating, kill the session

Alex Tong — Wed, 01 Jul 2026 13:00:00 +0000

🤌 I was 45 minutes into a Claude Code session when Claude just — started making stuff up.

Default values I never asked for. Constraints I'd set an hour earlier? Completely ignored. Like talking to someone who totally forgot the entire conversation.

So I did what felt natural. I started correcting it in the session. More instructions. More constraints. Spelling things out AGAIN from scratch.

This made everything insanely worse.

Here's the thing nobody tells you about context windows — every correction you make goes into the same context window that's already broken.

Think of your context window like SpongeBob. When he's fresh, he absorbs everything perfectly. But once he's soaked in dirty water — failed attempts, stale instructions, frustrated corrections — squeezing him harder doesn't clean him. You're just pushing the same dirty water around.

At that point your context window is basically SpongeBob rolling around in the mud singing "I'm a dirty boy."

It's a death spiral. And most people don't realize they're in one until they've burned 30 minutes arguing with an AI that stopped listening 20 minutes ago.

This is even more important now with Claude's usage limits. Every correction that makes things worse is burning through your session cap faster — and once you're out, you're out.

So here's a hard rule — stop adding once you notice the session has gone off course. Start terminating.

/clear wipes your conversation history but keeps the project context. Or just open a brand new terminal window entirely. Throw dirty SpongeBob away and grab a fresh sparkly clean one.

Claude will immediately go back to being the brilliant product that it is.

I do this like — a hundred times a day. The moment something starts to feel off, I don't investigate. I don't argue. I just end the session and start over. If I really need context from the old session, I'll ask Claude to summarize it and copy paste the important parts into the new one after reviewing.

Running /compact when things have already gone wrong is usually not the move — you're basically just squeezing a dirty sponge and re-dipping it in dirty water. You freed up space but the residue of bad context is still baked in.

Fresh sessions will produce better code in 3 minutes than 30 minutes of arguing will.

Stop squeezing dirty SpongeBob. Grab a fresh one. 🧛

Related: You're Wasting Your Best Engineering Skill → — the longer take on curating context strategically before Claude starts hallucinating in the first place.

Don't let Claude grade its own homework

Alex Tong — Tue, 30 Jun 2026 13:00:00 +0000

Most teams think of AI code review as something that happens after a PR is opened.

That's too late.

The Claude Code team at Anthropic does something I think more teams should straight up steal:

Claudey A (my pet name for Claude) writes the plan.
Claudey B reviews it as a "staff engineer" — skeptical, looking for edge cases, questioning assumptions.

Two agents. Different roles. The writer doesn't review its own work.

Think about why this matters. When you let the same agent that wrote the code also validate it, you're literally asking the student to grade their own test. Of course it looks correct — it was designed to look correct.

📝 The key insight that changed how I work: When it's time to review, I kill my session and start a brand new one — fresh context window, zero contamination from the implementation. It's like getting a second opinion from a completely different engineer. Issues that used to show up days later in PR review now get caught before a PR even exists.

Layer it: AI review during dev. AI review at the PR level via CI. Humans for judgment calls.

Don't let the agent grade its own homework, unless you're spidey. 🕷️

Related: Stop Reading Every Line of Code → — the full essay on rethinking code review for the AI era.

🗑️ Delete Your Claude Project Files

Alex Tong — Thu, 25 Jun 2026 13:00:00 +0000

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.

Two Prompts That Turn Notion into Your Claude Project's Brain

Alex Tong — Wed, 24 Jun 2026 13:00:00 +0000

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 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.

Teaching AI is the fastest way to sharpen your own thinking

Alex Tong — Tue, 23 Jun 2026 13:00:00 +0000

📣 📰 We just wrapped an Engineering-wide AI training — two days, hundreds of engineers, a curriculum months in the making.

The question driving it wasn't "how do you use this tool?" but "what does it mean to work agentically and how do you build the instincts for it?"

👷 Building my modules on decomposing problems and executing large-scale migrations using Claude Code forced me to crystallize my own thinking on this. There's a difference between knowing how to do something and knowing how to explain why it works, and teaching it turned out to be the most useful thing I've done to sharpen my own thinking here.

🫶 Proud of this team and grateful for the chance to contribute to something this substantive!

Follow-up: A month later I did it again, but for 500 engineers — Teaching CLAUDE.md at EngX →.

🔥 Claude Code Is (Seriously) Burning Me Out

Alex Tong — Thu, 18 Jun 2026 13:00:00 +0000

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.

📊 See the diagram on alextong.me →

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.