Hiring more gives you more hands. A real team gives you a unit that already knows how to work together, with someone who owns the output. Anyone who’s tried to fix a slow project by throwing more people at it knows how that ends: every new person is one more thing to coordinate, and the coordination cost grows faster than the actual extra output.

Now watch what happens when you hand Cursor or Claude Code to 40 engineers with no shared agreement on how the AI’s output enters your codebase.

You didn’t add 40 units of productivity. You added 40 prompt styles, 40 definitions of what the AI is allowed to own, 40 opinions on what gets reviewed and what gets waved through. The work of merging all that into one coherent system grows faster than the code the tools generate. It’s the oldest team-building mistake there is, just wearing new clothes: you added bodies, not a team.

The fix isn’t more access. It’s the contract first. Run the checklist most orgs skip: is there ONE written review standard every agent-written PR has to clear, or does each reviewer wing it? Does a fresh repo come pre-loaded with your team’s rules and known gotchas (a scaffolded .claude/, a shared PR-review skill), or does every engineer rediscover them? Is review tiered by risk, so a copy tweak and a payments change don’t get the same glance? Decide all of that first, THEN roll out the tools.

Ownership clarity and the right scaffolding beat tool access every time.

If you rolled out AI coding tools in the last six months, does your org have one written agreement for how agent code gets reviewed and merged, or one per team, or one per engineer?

That’s always been my workflow, even before the age of AI. But it’s the same mistake I keep seeing eng leaders make at team scale: they hand the shiny, might-not-work AI bets to the same people already on the hook for keeping production alive.

Boris Cherny (who leads Claude Code) put his finger on why. Looking at his own team, he saw five archetypes: prototypers who churn out ideas most of which never ship, builders, sweepers, growers, and maintainers who keep a mature system secure and reliable as it scales.

The prototyper and the maintainer are opposite wiring. One is at their best failing fast on things that might not pan out. The other is at their best making sure absolutely nothing breaks. Ask one person to be both and you get neither, because the “keep it alive” work is always more urgent, so it quietly eats every hour the exploring needed. It’s like asking the line cook in the middle of the dinner rush to also design next season’s menu. That’s a no-no.

So don’t hand your big bet to whoever’s already carrying the pager. Give it to someone whose actual job, this month, is to explore. Even if that’s just one person, or a two-person pod inside the same team, with its own goals and permission to fail. Protect the explorer from the maintenance, and the maintenance from the explorer. It’s time we rethink the way we structure engineering teams.

You’re not hiring different people. You’re pointing the right people at the right mode.

So which is it on your team: does your exploration work have someone who owns exploring it, or is it a side quest for whoever’s also keeping the lights on?

🧛

#EngineeringLeadership #AIStrategy #EngManagement #ClaudeCode

Last week I migrated my entire newsletter to Substack in one night. A custom email system I’d built by hand, gone in a few hours. And the part that still has me a little rattled: I barely touched the keyboard. Maybe 8 times total once it got going.

I ran the migration on Claude’s new Ultracode effort: extra-high reasoning combined with Workflows. It’s basically an orchestrated loop with checkpoints. You point it at the work and let it go.

And it was amazing. Like genuinely, watching-it-happen amazing.

But it was also extremely terrifying.

Because the thing I just watched get automated is, well, the bulk of my job for the last 6 years. A real chunk of what I do. Then you read the latest news coming out of Meta, real engineers, real teams, and it’s hard not to sit there and go: okay, what does this role even look like down the line? I’ll be honest with y’all, I don’t fully know. I chew on it a lot.

But here’s the part nobody tells you about running loops like this. It is NOT purely hands-off magic. The only times I had to step in the entire migration were when I screwed up the context. Either I forgot to give it something and it stopped and asked me, or I’d handed it wrong information, sometimes wrong info sitting in my own docs that I forgot to update.

For a migration like this, that was basically the whole job. Not typing. Context hygiene.

Never feed it the wrong context. Clean the docs it reads. When Boris recently talked about writing loops, I don’t think that was just hype. I think that’s genuinely where we’re heading.

But does every company get here by next quarter? No, of course not. Most are years behind, nowhere near loop engineering workflows yet. So whatever happens at the big labs like Anthropic is definitely not what happens everywhere else all at once.

But the role is certainly shifting under all of us. I felt it last week, working on my own brand, in real time.

What do you think an engineer’s job actually looks like a year from now? 🧛

(P.S. You’re reading this on the newsletter’s new home. Welcome to the house party.)

🎟️ 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

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 →

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?

🎛️

📣 📰 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 →.

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

1. Activate it using /config

2. Type "Output Style" in the search bar

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

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

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.

📣 📰 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 →.