Subscribe now

Does your vibe-coded app feel a little lifeless?

I think a lot of AI-built apps focus on getting the functionality working, but miss the taste and craft you expect from a really good app. Animations are one of the things that can make a big difference.

That last bit of polish is where you can bring a lot of delight. I’ve been working on a little side project, and when someone opens it, I want them to stop for a moment, and think, “Wow, this is really beautiful.”

AI makes building animations a lot easier, but just asking it to “add animations” usually isn’t enough. You still have to know what you’re going for and look at the result.

In this video, I walk through the different approaches and how I use Codex to build them, so you have a better sense of how to steer your AI.

I also made a visual cheat sheet you can keep around while you’re building. These approaches overlap, and you’ll often want to combine them. You can probably just send the picture to your Agent to give it a good seed of things to think through.

A few useful tradeoffs:

• Keyframes give you precise timing; springs are useful when motion needs to respond and settle.

• Gestures make motion follow the person; physics adds simulated momentum and collisions.

• SVG paths animate geometry; layout transitions connect two arrangements of your UI.

• Rive and Lottie let you author motion visually. Think about the interactions and runtime features you need.

• Rigs coordinate character parts. Flipbooks and video bake the motion ahead of time, so there’s less you can change during playback.

• Particles make a celebration out of lots of small pieces. Shaders change the rendered surface, but take more care to build and tune.

Knowing what these tools can do makes it easier to give your AI a useful direction. Try one small interaction in your app and see how it feels.

Cheers John

By now everyone has probably heard about Jev and its insane claims about being 400x faster and 200x cheaper than the state of the art AI models.

I recently made a video and I go over what Jev actually is, how to use it, and debunking the demos!

I also built a voice controller for World of Warcraft for fun to see how far I can push it.

Check it out!

Subscribe now

I made a video breaking down what the adoption data actually says and what I’d focus on instead of trying to keep up with every new tool. If you’ve been feeling overwhelmed by AI lately, this one’s for you.

Subscribe now

Cheers y’all!

A year ago, I would have said everyone should just be using Claude Code CLI or Codex CLI in the terminal. Going from a chatbot experience like ChatGPT to one of these agentic systems, the difference in what you could do was dramatic.

Learning the terminal felt worth it, even if you never seen a terminal before.

I don’t give everyone that recommendation anymore. There are enough options now that the right starting point depends a lot more on the person.

There are so many product offerings now that are all kind of labeled as agentic assistants.

Codex, Claude, Cursor, Pi, OpenCode, OpenClaw, Hermes, Muse, Grok Bot.

But anyone who’s using these things daily knows very quickly that certain things are better for different things. I want to break down my thoughts on these harnesses and what they’re useful for, because just telling someone to go use agents doesn’t really tell them where to start.

And the tool I’d recommend to another engineer is probably different from the one I’d recommend to a small business owner, or my mom.

I made a few Personas for this newletter.

We have engineers doing software engineering, who want to understand the code and have control over how things run. Then there are people in technical roles who can build a lot of things: data scientists, PMs, designers. They might be able to do UI work or build something useful without necessarily understanding everything that’s written in the code, or every optimization it needs.

Then there are the tinkerers and early adopters. People who don’t mind figuring things out. Some business owners fall into that group, but plenty are just working at some business, trying to make something easier. Then there’s the average person, or a less technical parent, who just wants some help.

For each of these groups where you should start in your AI journal I think is very different.

lets get into it.

Read more

Subscribe now

1. Where Do You See The Future Of Software Engineering Jobs?

Honestly, no one knows the future.

There is probably more safety in a physical job like dentistry, at least for a while. But maybe because I’m an optimist I still feel that Software Engineering will be important in the future. I believe there is a Jevons paradox happening with code. As coding agents get cheaper and easier to use, we’re going to create much more software. That code still needs to be reviewed, landed, and maintained.

Junior engineers are clearly having a hard time entering the field, and that problem needs to be solved. It’s hard for me to recommend this career 100% to someone who has not started yet because the entry point is rough right now.

But if you’re already an engineer, I think you should stick around. Keep learning, keep pushing, and adopt these tools. The latest models are geniuses and then somehow fall flat on their face doing the smallest thing. I think humans are still going to be needed for a while.

2. How Much Time Should Engineers Spend Improving Their AI Workflow?

There is a balancing act between always jumping to the newest thing and sticking with what works.

I like to build a workflow that works really well for me first. Then, when there is a meaningful model release or a product that changes the paradigm, I go into an exploration phase and give it a real try. I don’t rebuild my entire setup for every little launch.

Doing normal work will teach you a lot, but it only teaches you the features you happen to run into. I also read the docs. I try the small changes like hotkeys. I deliberately test all the features that I’d probably never discover during a normal workday.

You would be surprised how much one hidden feature can change your workflow. So my answer is: get very good at one setup, then create focused periods where you explore what is new.

3. How Do You Review AI-generated Code?

Code review is the topic I keep changing my mind on. Right now, I think of it as a gradient based on safety.

I imagine the codebase as a tree. If the change touches the trunk, e.a. shared infrastructure, a hotspot, or something with a lot of dependencies, then I increase both my effort and the agent’s effort. I look at safety and gating first, then architecture, quality, and cleanliness.

If it’s a leaf-node change, like a new component that’s not integrated anywhere, I don’t review it with the same intensity. The blast radius is tiny.

The old engineering practices still matter: small atomic diffs, one purpose per change, easy reverts, and strong tests. I also ask agents to provide proof: screenshots, videos, runtime data, logs, unit tests, or whatever actually demonstrates that the code works.

At the end of the day, you can’t go into a SEV review and say, “The AI wrote it. It’s not my fault.” You still have to stand by what you ship. I just tune the amount of review to the risk of the change.

4. How Can Someone Without Much Experience Judge AI Architecture Decisions?

Honestly, it’s hard because you don’t know what you don’t know.

You can ask another agent to do an adversarial review or use a skill that grills the architecture, but the goal should still be understanding. If the AI gives you a plan and you don’t understand a word or a term, slow down and ask about it.

I’ve been learning model scaling even though I’m not an ML engineer or AI researcher. Sometimes I read one paragraph, ask the AI questions about every part I don’t understand, and it takes me hours to get through one page. But afterward I understand it much more deeply than if I had just breezed through it.

If your goal is to ship something as fast as possible, slowing down like this may not help. But if your goal is to become a better engineer, use AI to teach you. Study the fundamentals, question the plan, and don’t let the agent’s confidence become your understanding.

5. Are You Making An Updated Coding Workflow Walkthrough?

Yes. The original video was my first major breakout on YouTube and is sitting around half a million views. I still think most of it holds up because it was not only a Claude Code tutorial. It covered the beginnings of agentic engineering.

But my workflow has changed a lot. I use the Codex app much more, and the ideas around context engineering, compound engineering, harnesses, goals, and agentic validation have all evolved.

So the short answer is that an update is in the works. The annoying answer is that these videos take months because I need to use the workflow every day before I feel comfortable teaching it.

6. How Much Code Do You Still Write By Hand?

The simple answer is none. I don’t manually write code by hand anymore.

I used to genuinely love coding. I don’t have a CS degree. I found coding as a hobby, spent about five years building random apps with friends, and eventually went through a boot camp and became an engineer. So when I stopped writing code manually, I mourned it for a while. It felt kind of bad.

But the workflow is different now. Agents can take longer goals and complete much larger tasks without the constant babysitting we had before.

I think manual coding is going away, as sad as that is. AI won’t write the exact perfect code you imagined every time, but with the right context and validation, it can usually do the coding part.

That doesn’t mean engineering is solved. Architecture, context, product judgment, validation, debugging, and responsibility are still there. The typing part is just becoming a much smaller part of the job.

7. If AI Lets Everyone Build, What Becomes The Competitive Advantage?

There are a few answers.

For companies, domain knowledge, proprietary data, distribution, and network effects still matter. AI doesn’t magically recreate a social graph or years of specialized operational data.

For individuals, I think there is still a massive gap in AI skill. I teach AI coding, and I see how different the knowledge level is between people. We live in this tiny bubble where everyone talks about models, harnesses, image generation, and token costs all day. Most normal people don’t give a shit about any of that. They use ChatGPT or Gemini and are happy.

My mom uses them and thinks they’re great. She doesn’t need to know what Codex can do.

So if you learn these coding tools deeply right now, that’s already an advantage. The fact that everyone technically has access doesn’t mean everyone knows how to use them well.

8. How Do You Stay Sharp If You’re No Longer Writing Code Manually?

I’m constantly learning.

When I see an architecture or pattern I don’t recognize during a diff review, I stop and ask questions. I also spend a lot of my own time digging into technologies that have nothing to do with the immediate task.

The biggest advantage I have is that I create content. If I want to teach something, I have to understand it. Once you try to explain an idea out loud, you immediately see the gaps in what you thought you knew.

That’s actually why I started YouTube eight years ago. I wanted an excuse to talk about the things I was learning. Teaching creates a flywheel: I learn something, try to teach it, discover the gaps, learn it more deeply, and sometimes change the way I work.

You don’t need to become a creator, but you do need focused time where the goal is learning rather than output.

9. What Should A Student Learn Now To Become Job-Ready?

I’d focus on two things at the same time.

First, learn one agentic coding tool really well. Codex, Claude Code, Cursor, OpenCode. It doesn’t matter as much as going deep. Understand memory, context, skills, MCP, subagents, agent teams, models, and validation. Use the tools enough that you develop a feel for where they’re strong and where they’re likely to fail.

I think interviews will eventually test some of this. Maybe not everywhere yet, but agentic engineering is becoming part of the job.

Second, keep learning the foundations: data structures, algorithms, design patterns, clean code, architecture, and debugging.

Agentic coding is another abstraction layer, and abstractions always leak. When the agent gets stuck, your fundamentals are what let you peel back the layers, understand the actual problem, and steer it somewhere useful.

10. Codex Or Claude Code? Which Coding Agent Do You Use?

I use both, although I’ve moved almost entirely from the terminal into the Codex app for my own work.

Two months before recording this, I’d have said there was no way I’d give up the CLI. It’s powerful and I had a lot of muscle memory there. But the app has rich rendering, voice control, prompt queues, easy diff review, and all these little interactions that are difficult to reproduce in a terminal.

I can also control my threads from my phone while my laptop is sitting at home running. That has changed how I work more than I expected.

On model quality, I preferred the OpenAI coding models when I recorded this. I thought the output was comparable, less verbose, and had a little more dog in it—it would just keep going until it found the answer. But this can change with the next model release. That’s the annoying thing about making permanent recommendations in this space.

The durable preference for me is the complete app workflow. It would be hard to give that up now.

11. How Do You Think About Permissions And Safeguards For Coding Agents?

I think we’re moving toward longer agent runs with fewer permission interruptions, but much stronger safeguards around the work.

The agent should be able to operate without asking you about every tiny action. At the same time, you need an agentic garden around it: boundaries that stop one failure from spreading across your codebase, database, or operating system.

More autonomy is fine if the output meets your quality bar and the system prevents the truly destructive stuff. The long-term answer is not endless approval prompts. It’s better models plus better containment and validation.

12. How Should Students Balance Fundamentals With Rapid Prototyping?

If you’re a student, I think you should focus on the fundamentals.

Why are you prototyping? At work, we prototype to answer a specific question. For a product, I might want to feel the UX before committing to it. For infrastructure, I may have several agents build different approaches so I can feel the API and discover missing abstractions.

I’m usually not studying the generated code in those situations because learning is not the purpose of the prototype. The prototype is there to answer a question.

So if your goal is learning, learn. If your goal is testing an idea, prototype. Don’t confuse the two and assume that producing more demos means you understand the system better.

13. Which AI Engineering Specialty Should Someone Focus On?

Serving models, training, reinforcement learning, AI infrastructure, security, memory—any one of these can become a great career. It depends on where you are and what you actually find interesting.

For me to switch into serious model research or kernel optimization would probably take years. I feel world-class at what I do now, but I’d be a novice again in that domain. There is a huge amount to learn before you can contribute at the frontier.

Try the basic version of the work first. Train a small model. Talk to people who do the job. See whether you enjoy sitting with the hard parts.

Chasing a specialty only because it pays well has never made sense to me. You usually quit because the work required to become good is too hard. Pick the difficult thing you’re interested enough to keep doing.

14. What Do You Think The Next Major Leap In AI Will Be?

I don’t know what the industry’s next leap will be, but I know what I want personally.

First, I want a much better mobile interface. Voice control is already good, but I need richer visual feedback so I can manage agents while walking around instead of sitting in front of a computer all day. Glasses may eventually be a good form factor. If I could do more of this job without being attached to a desk, it would genuinely change my quality of life.

Second, I want native video understanding. Current workflows often break video into frames and try to piece together what happened. I use that for debugging animations, and it’s slow and unreliable. A model that can understand video directly would be really useful.

15. Will Agents Become Portable Across Models And Coding Tools?

I think agents that operate for people will eventually have their own identity.

An agent may need its own payment method, permissions, reputation, communication accounts, and other things required to act on your behalf. I think agent traffic will eventually be larger than human traffic on the internet, so some concept of an agent as a real entity has to emerge.

I’m less sure that all of the memory and behavior will move cleanly between Claude Code, Codex, Cursor, and every other harness. But the identity and permission layer feels inevitable to me. Someone will build it. I wouldn’t be surprised if a payments company plays a major role, but we will see.

16. Is It Safe To Upload Confidential Documents To AI Tools?

If you work with regulated or highly confidential data, I wouldn’t casually upload it to a consumer tool and hope that turning off a setting is enough.

Use a deployment that actually matches your company’s security requirements. That may be an approved enterprise product, or it may mean hosting open-weight models inside your own environment. Local models are good enough now that a company with the right budget and people can get a lot done without sending everything to an outside provider.

The exact answer depends on your company, your compliance requirements, and the data. But “the training toggle is off” should not be the entire security strategy.

17. What Happens When Open Models Become Powerful Enough For Cyberwarfare?

Honestly, this is scary, and I think it’s a legitimate thing to worry about.

The underlying capability is already moving in that direction. Closed providers can add post-training safeguards and reject certain requests, but open models make those controls much easier to remove or bypass.

People sometimes hear AI labs talk about slowing down or security risks and assume it’s all marketing. I don’t think every concern is hype. These models are powerful, cybersecurity already has a huge number of unknown vulnerabilities, and more capable open models make that situation harder.

I try not to be pessimistic about every AI development, but in this case I think the risk is real. I don’t have a clean answer for it.

18. What Advice Would You Give Someone Trying To Get Into Meta Or Another Big Tech Company?

I wish I had gotten better grades and gone to a better school. That would have made the first door easier to open.

But I didn’t have that path. I worked at Capital One for about four years. Around my third year, companies like Meta and Netflix finally started reaching out. Before that, I sent resumes and barely got interviews. Experience gave me the credibility that school didn’t.

Once you get the interview, you need the fundamentals. Big Tech interviews are a fairly known problem, but the hard part is committing enough time to become good at them. You should recognize common data-structure and algorithm patterns while you’re still reading the question.

The first time I interviewed, I got my ass kicked. I failed basically everywhere. That showed me the gaps. The next time, I studied four hours a day for about a month and a half and got offers from Meta and Netflix.

I’d also learn agentic engineering and build in public. Posting useful work online is one of the most even playing fields I’ve seen. Good content creates relationships and opens doors that you didn’t know existed. Maybe somebody even gives you a job. I don’t know.

19. What Does It Take To Grow From Senior To Staff Or Senior Staff?

At a company with a very high engineering bar, technical excellence is the minimum. Everyone is smart. You also need EQ. People need to like working with you. You need to be easy to work with without becoming a pushover.

From junior through senior, the progression is mostly doing the job with more independence and scope. You go from landing code, to owning a project end to end, to mentoring people and taking on more complicated projects.

Senior to staff is different. It’s almost a different job.

My bar for staff is that you have so many ideas and so many things you want to execute that you can’t do all of them yourself anymore. You need other people to help. That naturally creates scope, which is why the tech-lead archetype is so common at staff.

Your impact starts scaling beyond your own output. At senior staff and above, that influence expands across teams and eventually across an organization. The biggest difference is not that you type dramatically better code. It’s how you create scope and move people toward it.

20. What Is Your Favorite Use Of Agents Outside Coding?

I use agents for almost everything: taxes, research, and all the normal ChatGPT use cases.

But my favorite is probably my content pipeline. I run most of it through Codex. There was a period where I was using Codex more for content than coding because I didn’t have an active side project.

It helps me research, organize ideas, repurpose work, and run the boring parts of being a one-person content operation.

21. How Is AI Changing Product, Design, And Data Roles?

The roles are blending.

I’ve worked with designers who can now make UI changes directly instead of asking an engineer to move this pixel or fix that component. That brings them closer to the code and gives them more empathy for the engineering side.

The reverse is happening too. I can run more of my own queries, do analysis, and estimate product impact without waiting for every question to pass through a specialist.

People will still have specialties, but product management, design, engineering, data science, and data engineering are starting to overlap in interesting ways. I don’t think the industry has figured out what the final roles look like. The “member of technical staff” title spreading through AI companies is probably one sign of that uncertainty.

22. What Were The Most Interesting Products You Worked On At Meta?

Working on Reels was a dream project for me at the time. I joined near the tail end of the original creation, moved from full-stack web into mobile because I wanted to work on it, and grew to senior during that period.

It was also much more technically interesting than people may realize. Reels is heavily organized around music, and that affects how the product and its content are structured.

I also worked on the original Meta AI launch in Messenger during the Llama 3 era. That was interesting for a completely different reason: nobody really knew what interacting with AI should look like. The industry was inventing the UX patterns while building the product.

I really enjoyed being in that state where the answer was not already known and we had to imagine what the client experience should become.

23. How Should A New Creator Grow The Reach Of Their Content?

Don’t rely on one platform.

People live in different places. Some people only use X. Some stay on Threads or LinkedIn. Some only watch YouTube. They rarely see everything you make, so reuse and repurpose your work instead of assuming every post needs to be a brand-new idea.

I use agent pipelines and Ferryman.io, which my friend Kevin built, to post in one place and distribute the content elsewhere. That has helped me go viral on platforms where I didn’t even realize a post was taking off.

Every large creator already does this. They just have a team. I’m by myself, so I use agents and software.

That’s everything I could reasonably deduplicate from the AMA. I’m sure I missed a few questions, so reply and send me the ones I should answer next.

I genuinely love doing these. I can talk about AI, software, and career stuff all day. My wife doesn’t want to talk about any of this. She wants to talk about Korean mom dramas.

So it’s nice to have all of you.

Substack started to role out a AI detector. I never cared that much about this topic before because everyone knows that I use AI a lot in all of my work flows. However, it got me thinking about the process of AI writing and what it means for ai detection.

It seemed like a technical challenge that I wanted to see if I can solve. So I got to work.

After a few hours of working through a new pipeline, I beat the detector and I was able to get a 100 percent AI generated writing of my essay to be 100% Human written. At least based on Substacks detector.

I’ll get into how I did it and how you can do it too in this newsletter.

BTW, this is not a newsletter on whether or not you should do this. That is a moral discussion that I have my own thoughts on but I won’t get too into it here.

I mention this because I’ve been seeing people use these detection software to virtue signal and “win” arguments. Below is a random post I found and the most hilarious things is that the author posting the Pangram has a fully AI generated Youtube video on the top of his website. LOL

Read more

I kept thinking there was one paragraph about model training that confused me. That isn’t accurate. It wasn’t a single paragraph. It was the entire topic.

There was a lot of math and a lot of equations I didn’t understand. It felt like I had to read it over and over. Every single time, there was some word I needed to look up just to understand what I was reading.

To be honest, I don’t quite remember the equation that stopped me. I remember the feeling much more clearly. I could get maybe 50 percent of it, but I couldn’t get through it. I kept coming back and trying to finish because I had this huge desire to understand it.

The videos were blackboard lectures with Reiner Pope and Dwarkesh Patel. One went through the math behind how large language models are trained and served. Another built up chip design from basic logic gates. They were exactly the kind of thing I wanted to understand and couldn’t.

That annoyed the hell out of me.

Most engineering problems don’t make me feel completely out of my depth anymore. I’ve dealt with them for more than ten years. They’re hard for most people, but I’ve done them so much that they are not necessarily hard for me. There are still hard problems to solve, but I usually recognize the shape of them.

With these lectures, I kept having to look things up, and I still only had maybe 50 percent real understanding. My reaction was basically: I could fucking learn this. And I wanted to.

Read more

I get a lot of comments asking “what should I study”, “what should I do”. So I made a video with 50 tips on what I would do if I was in my twenties or early thirties again and didn’t already have a major career I could lean off of. Because the numbers clearly show the jobs getting automated right now are the tasks junior engineers used to do earlier in their careers. Moreover, Claude Code, Codex, and these agentic tools are getting better and better, and buisnesses might be too aggressive and replace a bunch of people they still need.

This is not a doom and gloom newsletter. This is about how we can adapt and put our best foot forward. I switched careers at 28. I quit my job and did a bootcamp right when I got married, felt really behind the whole time, and somehow went from PM to staff software engineer at Meta. So this is really just advice I would give to myself back in the day.

This is the newsletter version of all 50, but if you want to watch the video here it is!

Subscribe now

Level Set First

1. Your Feed Is Not The Marketplace

The thing about your feed is that negative sentiment always sells. All the doom and gloom posts, the hundred applications with nothing back, there’s definitely validity to that pain. But those posts are written by people who are still looking, still angry, still deep in the trenches. The people who got hired went quiet.

So instead of relying on doom scrolling, do your own deep dives into the actual data. What jobs are actually being posted, which companies are hiring. Your feed is definitely not the actual marketplace. Don’t let it be your map.

2. Never Ask The Barber For A Haircut

Every AI company has a major incentive to hype the progress, AGI, self-improving AI, “I don’t code anymore,” so the gravy train keeps going. There’s probably a lot of truth in these statements, and I genuinely believe learning tools like Claude Code or Codex is the best thing you can do for your career. But take the predictions with a grain of salt, do your own research, and get your own feel for how these tools are evolving.

3. Demos Lie, Production Tells The Truth

MIT found that 95% of AI adoption at major companies had failed so far (the study’s a little old, before the November Claude Opus 4.5 release, so things have probably changed). PMs and grifters posting that they built something in one shot are posting demos. Look for the things that survived in production with wide usage, like Codex and Claude Code, and forget the rest.

4. Don’t Judge Your Insides By Someone Else’s Outsides

Everyone on LinkedIn and X is posting the shiny stuff, everyone and their mom has a new skill that’s changing their world. The reality is they’re spending a ton of time iterating and prompting, and those skills are flaky. GitHub stars are just marketing now. Focus on yourself, focus on getting better.

5. You Are Not Behind

I did a bootcamp at 28, right when I got married, and I remember feeling really behind, especially at my first company where everyone at my level was a new grad. That was about ten years ago and it worked out fine.

And honestly, if you’re worried AI takes over everything: if AI can truly get rid of 100% of engineering jobs, what other job is actually safe? Not many. So why not do the thing that teaches you these tools? Software engineers are the best at them because they inherently understand what’s going on under the hood.

6. Fear Is A Crowded Trade

This is probably my favorite tip in the whole video. Buffett famously said you want to be greedy when others are afraid, and afraid when others are greedy. Right now people are quitting CS, avoiding tech, fearing every white collar job gets automated away. That’s the crowded trade.

With the current architecture, I just don’t see it happening. AI is essentially a super genius and also very stupid at the same time. It needs constant guidance, it needs good validations to know when something’s right, it has no taste in the matter. A really good engineer can 10x or 20x their output with these tools, but it’s just not realistic for non-technical people to get very far with them. So right now is the best time to learn the foundations, while everyone else is scared off.

The New Job

7. Own The Problem, Not The Code

Code is losing value, but the domain knowledge and expert problem understanding are still going to be extremely valuable. When code becomes cheap, good ideas become even more valuable. Steve Jobs said it’s just as important, maybe more important, to learn which ideas not to pursue.

So if you want to become irreplaceable, deep dive into a specific domain and start owning that problem space. Understand it to the root, and be the person who knows which code is worth generating.

8. Taste Is The Moat

There’s a reason it’s so obvious when something is fully AI generated, whether that’s writing or an image. The most human part left is taste. How do you encode your taste so the machine can understand it? That’s the real work now.

Study the greats, study the work that inspires you, and slowly start building your own taste, whether that’s about code, design, or how things should feel. That’s where the real moat is going to be.

9. Learn Agentic Engineering

Karpathy talks about learning to use these tools effectively as a skill gap. At a high level it’s context engineering, agentic validations, building tools for the agent, compound engineering and much more. As the models get better, the meta work of getting agents to do more on your behalf is going to be the real leverage and the real work.

10. Ship Things That Last

Because AI coding is cheap, people ship a lot of code without double checking it, then blame the AI when it’s garbage. You can’t blame the AI. You own your own code. Buffett said reputation takes twenty years to build and five minutes to lose, so ship things that last and don’t ship slog.

11. Follow The Cost Of Being Wrong

Here’s a filter for picking your problem space: the more expensive it is to be wrong, the higher the bar AI has to clear before that work gets fully replaced. It’s why doctors and lawyers still haven’t seen deep AI penetration, the cost of getting a decision wrong is extremely high.

AI is really good at making frontend code these days, landing pages and things like that, so that’s not where you should be focusing. Focus on things that are hard for the AI to do, where being wrong is expensive. That’s your longest runway.

Build The Moat

12. Be So Good That You’re Undeniable

CEOs are somewhat disconnected from reality. There are people like Jensen, who famously said he’d rather torture you to greatness than fire you, and then there’s a bunch of companies not named that just lay people off for whatever reason. The only way through all these turmoils and ups and downs is to just be so good that you’re undeniable.

Aim for the top 10% of whatever you do. Top 1% if you can. Easier said than done, but if you’re doing well, keep doing well. Don’t take it easy.

13. Learn The Layer Below

These agentic tools are new abstraction layers, and all abstractions are inherently leaky. If you can’t go in and debug the layers underneath when something breaks, you’re going to lose control of your project, and it happens all the time to people who skip the foundations. Be curious as a default stance and dig in whenever you don’t understand how something works.

14. Read More Code

People will tell you to read less code because the AI reviews better and writes too much of it. I still spend more time reading code than writing it. Read the hard stuff, the patterns and system designs you wouldn’t figure out on your own (want to build an agentic tool? go deep dive how OpenCode does its loop), and let the AI handle the how-to-center-a-div stuff you can verify with tests.

15. Ignore Titles, Focus On Shipping

When I first became an engineer I just tried to ship a lot of things, and that helped me move up very quickly. The best ideas will always win, so if you’re new somewhere, don’t let your position hold you back.

16. Learn Where The AI Fails

Use these tools enough and you develop a second sense of what the AI can and cannot do. Someone asks “can we automate this,” and you immediately know what’s realistic and where it breaks. That’s a skill in itself.

The funny thing is, all LLMs can really do is hallucinate. The useful ones just happen to be useful hallucinations. So push the systems as far as you can, start a log of where they fail, and build the intuition most people never bother getting.

17. Have A T-Shaped Portfolio

You want breadth of knowledge on various things so you know what’s possible and can orchestrate multiple agentic tools at a higher level of abstraction, plus at least one deep understanding of a tech stack to be competitive. That combination is what recruiters are currently looking for.

18. Master AI Tools

You have to learn Claude Code or Codex like the back of your hand. How it loads memory, how it manages context, skills, subagents, agent teams, scheduling loops. I know that’s a lot, and yes, you need to know it, the same way a professional woodworker knows every tool in the shop well enough to make complex joinery. Invest in learning these tools.

19. The World’s Best Tutor Is An AI

I can learn basically anything I want with AI now, Blender, Photoshop, deep dives into a codebase, TPUs versus GPUs. The important thing is that you develop the desire to want to learn.

20. Push It To Prod

A little shout out to this newsletter. The number one thing that happens when people start building with AI tools is they chase the red dress, a little of this shiny thing, a little of that, and never ship anything to production. You learn the most shipping something from zero all the way to the end and then maintaining it.

21. Communication Is Your Biggest Leverage

Being able to properly articulate your ideas is still the killer skill most people lack, unless you’re Carmack and can build the next graphics layer the whole industry adopts. YouTube for me started from a place of trying to get better at speaking (go look at my first video if you want to see someone suck at communicating), and now I’m never afraid of a presentation. In the age of AI noise, the soft skills are where AI can’t really interject.

22. Become Worth Vouching For

The industry is a lot smaller than you think, people cycle between the same companies. I worked incredibly hard to earn the trust of every manager I’ve had, and I still chat with my first one. Build the reputation, because referrals are always the best way to get hired.

Place Your Bets

23. Do What Feels Like Play

When I’m juggling multiple Claude Code instances across panes, it kind of feels like StarCraft, and I get genuine joy from it. That’s not everyone’s fun, to each their own, but find the version that is play for you. Steve Jobs said the people who succeed long term are the ones passionate enough to stick through the hard and frustrating parts. Without passion and fun you will just end up quiting.

24. Follow The Money

If the major AI labs or FAANG are out of reach right now, look at where AI is actually being leveraged hard: traditionally boring industries, finance, farming, some bespoke place. You want to be where demand for AI is super high and there’s just not a lot of people looking in uncrowded places.

25. Take The Risk Before You Can’t

I quit my job at 28 and went to a bootcamp without much money, and it paid off. Now, with two kids and a good paying job, doing something else is a huge risk financially. When you get older you don’t regret the failures, you regret the risks you didn’t take. So take them while you’re young and you can.

26. Optimize For Slope, Not Salary

When I was starting out I agonized between two offers over about 20 grand, and I’m so glad I took the better learning opportunity, because it elevated me further faster. At my level now, my end-of-year bonus is multiple times that difference. Maximize the slope of your learning; the salary catches up.

27. Own The Ugly Work

The shiny projects are crowded, and most of the credit goes to the leads and senior folks. Instead, own an ugly piece of work that’s still critical to the org, insights, a migration, some core piece of technology nobody picked up, and do it consistently well. Two caveats: it has to actually be important, and you have to be vocal about it.

28. Be The Bridge From AI To The Business

Companies everywhere are doing AI native transformations, and almost universally, engineers at every level, principal engineers included, aren’t sure what’s actually possible with these tools. They’re in meetings all day; they don’t have ten hours a day to live in Claude Code or Codex. If you invest that time, you can end up leading efforts a principal engineer would usually lead. That’s what happened to me.

People, And Getting Seen

29. Network Before You Need It

Opportunities are attached to people, not job boards; you can see it in referral versus cold apply. The best network is genuine work colleagues over time (a few years at a big tech company and one day you wake up with an amazing network), and pro tip, making content works too for building great networks. Build it before you need it, because that’s when it’s easiest and most genuine.

30. Win The New Interview

Interviewing sucks, but it’s a skill you need to learn. Has AI changed it? Yes and no. LeetCode-style coding is still around, system design is still a large portion and I think it gets graded even heavier from here, and I could almost guarantee AI-assisted interviews on agentic engineering are coming in a year or two. Nail the fundamentals, then brush up on each company’s new process.

31. Pick The Manager, Not The Logo

A good manager fights for you in rooms you’re not part of, protects your time, and guides you to the right projects. You have to pick the right horse though: look at your manager, their manager, and their manager, check how long they’ve worked together, and count how many strong ICs want to work for them. Getting on the bench of a good manager pays dividends for a long, long time.

32. Find Great Mentors

My mentors have saved me years, technical ones, career ones, even YouTube ones. There’s a limit to what AI can teach you. “I know I just said I can learn anything from AI haha”, and when there are too many choices the AI may glaze you. You need a human to course correct you along the way.

33. Teach To Learn It

You don’t really know something until you teach it to a beginner. I’ve trained hundreds of engineers on Claude Code and Codex, at my company and in a course I do on the side, and the flywheel is real: teaching forces me to deep dive every new feature, which creates more opportunities to teach. Give it a try, and let your students’ questions challenge your understanding.

34. Pick One Direction And Stick With It

If you start too many things and never finish, you mistake motion for progress. It’s like climbing: hit a hard peak, hop to a new mountain, re-climb the easy part, feel productive, learn nothing new. Pick one thing, mobile, an agentic tool, whatever, and see it from zero to end.

35. Build And Learn In Public

It takes courage to share things that aren’t quite ready, and that’s the point: tough skin, pressure to actually finish, and easy networking with people interested in your work. Sometimes you straight up get a job off it, and sometimes an open source project goes crazy, like OpenClaw, and now you’re one of the staple developers in the ecosystem.

Your Base, And The Long Game

36. Audit Your Expenses

You’d be surprised how many subscriptions you have that you don’t need. Focus on the core things, learning, surviving, eating, and save the rest. Get your house in order. I know finance tips doesn’t seem relevant but unless you are free from financial burden you can’t really do the things you need when opportunity comes knocking.

37. Your First $100K Is The Hardest

The first 100K is extremely difficult, then the first million is too, and then it gets easier to make money. Saving that first 100K buys you safety and wiggle room, and studies say once you’ve saved it you’re much more likely to hit a million later.

38. Set It And Forget It

Pick a good index like the S&P 500, put money in every month, make it part of your fixed expenses, and let compounding do the work. We don’t know what’s coming, so save for a rainy day. This is not investment advice :).

39. Pay For Your Own AI Tools

Don’t be stingy here. The max plan is like $200. I pay for it myself even though I get a bunch of tokens at work, because it’s learning. These are the single most important tools to learn in the next few years, and in my opinion this $200 plan with the current usage limits is not going to last forever. Leverage it now.

40. Rest Is Non-Negotiable

It’s kind of funny, you’d assume AI means less work, but I find myself working even more, because builders want to build (I have a whole video on being addicted to Claude Code). There are times to push and times to rest, and if you don’t build the habit of working out and relaxing, you’re not going to make it very long. It’s a marathon.

41. Build Your Escape Hatch

Work is just one of my income streams. YouTube is one, the newsletter is one, the course is one, and I’m always looking for more. Nobody knows if the K-shaped economy talk is right, and honestly it’s a little unsettling, so have multiple sources of income just in case something happens to one of them.

42. Train Like Your Life Depends On It

I’m getting close to my 40s and this desk job has caught up with me: my wrists hurt, my lower back hurts, I’m tight everywhere. I wish I’d stretched more and used the standing desk when I was younger. Don’t let your body be the limiting factor on your growth.

43. Be An Early Adopter

When Opus 4.5 came out in November, I tried it right away, something clicked, and I switched all my workflows to it. By the time usage exploded at our company around February, I’d been on it for months and was ready to teach while everyone else was struggling to learn. Being early lets you live in the future a little bit.

44. Follow The Leaders In The AI Arena

I follow Boris Cherny, Karpathy, Steinberger, obviously Dario and Sam, also Elon. When Jensen says something ridiculous, like being deeply concerned about a $500K engineer who doesn’t spend $250K in tokens, a lot of people clown on it, but I really try to think about it. The leaders’ headspace gives you signs and clues about where things are going. Just be careful and test the things they are saying yourself. Remember Tip number 2.

45. Bet On Yourself

I bet on myself at every step, quitting for the bootcamp, helped me go from PM to staff engineer at Meta. If you’ve built your base and you’re able to make moves, this is a great time to bet on yourself, while most people are still sleeping on these tools.

46. Ship It Slightly Embarrassed

If you’re not embarrassed by the first version you ship, you probably waited a little too long. I’ve met a lot of perfectionists who always talk about shipping things and never end up shipping anything, because they worry about all the little details before anyone has seen the thing.

Once you ship, you get a ton of feedback and ideas you never would have found on your own. The people way at the top have shipped a ton of things and have the scars to prove it.

47. Luck Is Preparation Meets Opportunity

One of my favorite sayings (I probably picked it up from the movie Serendipity). With AI booming there are going to be opportunities everywhere, funding, interviews, chance meetings, but if you haven’t been training, preparing, and building, you won’t be able to seize them when they show up.

48. First Job, Not Final Job

A job is just a job. Take the best one you can get, do the best you can, and seize the next opportunity when it comes. You’ll have many jobs in your career, sometimes across totally different industries, so don’t treat the first one like a life sentence, just keep moving forward.

49. Build For Future Models

The best advice I heard from Boris at a talk: build for the models of the future, and that’s essentially what Claude Code was, built assuming the models would catch up. Every model generation makes something newly possible, and if you only build for the current level, you’re easier to copy and your thinking stays limited to what’s possible today.

50. Don’t Let AI Atrophy You

When you go deep on AI tooling, you just stop coding manually, and honestly I don’t think manual coding matters that much anymore. But keep studying system design, keep the foundations sharp, don’t forget space-time complexity, don’t stop reading code. Skills atrophy faster than you think, and at least for now, interviews will still make you code by hand.

Part I Actually Want You To Remember

This is not a doom and gloom take. I know it can feel like nothing is working out, especially when you’re young and starting out. I was 28 and felt completely behind, but I just went head into it and pushed towards my goals. It somehow worked out.

Work hard enough where it is unreasonable for you to not be successful.

I keep seeing the same kind of meme posts these days.

Someone posts a bad AI generation. A broken image with multiple hands. A confidently dumb answer. A code change that obviously did not get reviewed.

The caption says some version of “AI slop,” and the replies pile on.

I get why it feels good.
It almost feel cathartic.

Until pretty recently, it was exactly the opposite. Most people were glazing about how amazing Codex and Claude Code was.

Coding was solved. Prompting was dead.

Every company had to become AI native immediately or get left behind by someone with more tokens.

Then the pendulum swung the other way, and the hype went too far. Now there are a large group of people that wants to hear that AI is fake, the output is slop, and anyone excited about this stuff is either naive or selling something.

I get where this perspective is coming from. A lot of the marketing has been ridiculous, and some of the loudest voices are hard to relate to.

The leaders in this space are operating with unreleased models with infinite tokens. How could an average 200$ plan relate to that? I feel this disconnection is where the hate is coming from.

But I think hating AI is becoming the easy way out.

If I choose to hate AI and skip the hard work of learning these new tools and patterns, I’ll fall behind on what our works.

AI is here to stay whether you hate it or not.

Read more

The overall team shape that I’ve been used to for my entire engineering career was built around one assumption: engineering is expensive

That sounds obvious, but I think it explains a lot of changes that we are seeing in the industry around roles due to AI.

Engineering being expensive is why PMs spent so much time on alignment. Why designers mocked various options before anything touched the codebase. Why data scientists sized the opportunity before the team committed. Why engineers were protected from half-baked ideas as much as possible.

The whole system was designed around not wasting engineering time.

Now that coding itself is getting cheaper, and the roles around the codebase are starting to blur. It feels like everyone is being encouraged to do everything. PMs being Designers / DS / Eng and Designers being PMs / Eng / DS and etc. Personally I think the concept that everyone can do everyone’s jobs using AI is a little ridiculous but I can’t deny how I think about my own work is changing because writing the code is becoming cheaper.

Engineering gets more important when the bottleneck moves from “can we make this” to “is this worth making at all.”

Read more

However there are tradeoffs with each strategy, and I’m going to walk through those too, because knowing when to turn each of these off matters just as much as turning them on.

I made a video version of this newsletter for those that prefer watching over reading :)

Subscribe now

Index The Code

The first strategy is to index your code, so Claude stops reading your codebase file by file.

If you’ve never thought about indexing, the most familiar version of it is search. What Google does behind the scenes, as a dumbed-down example, is to build a map of keywords that point to different websites. Instead of reading every page to find what you want, you build that map ahead of time and jump straight to the answer. We’re going to do the same thing for your codebase, except the map is a graph of how your code connects.

By default, Claude finds code the pretty sequentially via grep. You ask about your auth setup, and it greps and reads files one at a time until it stumbles onto the right one, loading a bunch of stuff it never needed along the way. And every one of those reads sticks around in the context window for the rest of the session.

The tool I used is called codegraph. It’s free, and it runs entirely on your machine. It parses your repo into a queryable graph of your functions, classes, imports, and how they all call each other, and then Claude queries that graph in plain language instead of scanning.

You index once, and Claude queries it under the hood.

Now the tradeoff.

The moment you index, you’ve got two sources of truth: your actual code, and codegraph’s picture of your code. And that picture drifts. The repo gives you a way to re-sync, but if you forget, or you just haven’t synced since you started coding this morning, the graph goes stale and Claude gets confidently wrong. It’ll swear a function exists when you deleted it an hour ago, or miss one you just wrote.

Its extra complexity that you will need to juggle

Compress The Output

The second strategy is to compress what your tools hand back to Claude.

If you’ve been coding for a while, you already know server logs, test output, and CLI dumps are noisy. Most of it is stuff Claude doesn’t actually need to see, but by default that whole wall of text lands in the context window anyway.

There’s an open source tool for this called RTK, short for Rust Token Killer. You install it (I just used Homebrew), and it sits in front of your commands and compresses their output before it ever reaches Claude.

RTK shrinks the noise before Claude ever reads it.

So instead of dumping all 43 test results, it tells Claude “43 test paths” and moves on. Instead of every single warning, it bundles them.

The tradeoff here is obvious: the compression is lossy. RTK does its best to drop only the noise, but its best isn’t perfect, and every now and then it tosses the one log line you actually needed. So when I’m debugging server logs, or I want Claude to read the full output so it can self-correct step by step, that’s exactly when I turn it off. You learn to feel when a task wants the full firehose instead.

Make Claude Talk Less

The third strategy is my favorite, and honestly I think they named it wrong.

It’s a tool called caveman. You install it over npm, and it sets your session into one of a few modes, light, full, or ultra, that strip the filler out of Claude’s replies while keeping the actual content. Less padding, same answer.

The best way to explain it is a clip from the Office:

I waste time say lot word when few word do track.

which is why I think caveman should have just been called Kevin.

Roughly half the output, about the same quality.

I tested it with the same prompt twice, “tell me about this project,” once normal and once on ultra. The ultra answer was about half the length, and the quality was basically the same. It’s per session, so you can flip it off the second you need full detail. I keep it on ultra most of the time and only bump it up when a task asks for more.

The tradeoff is correctness. Claude uses the back and forth of its own messages to keep track of what it’s been doing across a session, and that message history is basically its memory. When you shrink those outputs too aggressively, you’re thinning out that memory, and on a long multi-step task, a thinner memory can mean worse answers. On a quick question, ultra costs you nothing. On a hard plan-mode build where the history is doing real work, the over-trimming can bite you, so I keep it off for that.

Manage Your Session

The fourth strategy is the boring but good one, and it might matter most, because it’s free, built in, and always there.

Start with /context. It shows you exactly what’s eating your window, and that’s how you catch the stuff you’d never notice otherwise. The classic one is a giant CLAUDE.md. I’ve seen a 50k-token CLAUDE.md quietly burn about 4% of the window every single time you open a session, before you’ve even typed anything. You won’t know until you look.

From there it’s mostly habits. /clear wipes the context between unrelated tasks so you’re not dragging old junk into new work. /compact summarizes and lets you keep going when you do need the history. Plan mode before you let Claude start editing kills the expensive trial-and-error loops. And for actual building, I usually sketch the thing in pencil or Figma first instead of having Claude code it cold.

The free layer: /context, /clear, /compact, /model, plan mode, and a lean CLAUDE.md.

The other half is picking the right model with /model. People ask me if Haiku or Sonnet is ever worth it, and my answer is 100% yes. Haiku is great for driving Chrome, where the speed is the whole point. And I run Sonnet on repeatable scheduled jobs, like a /schedule that looks at my desktop every morning and files everything into folders, because I already know that task works fine on it.

For real planning and deep dives, stay on the most capable model. Dropping to a cheaper one to save a few tokens, getting a worse result, and redoing the work costs you more than you saved. The good model can save tokens in the long run.

So Should You Use All Of These?

Yes. I use all four, because the savings are real and worth the little bit of babysitting they ask for.

But every layer you add is one more thing that can break. codegraph goes stale. RTK drops messages. caveman over-trims. Stack them all and you can absolutely get past 90%, but now you’ve got four moving parts sitting between you and a correct answer, and the real tradeoff across the whole stack is cost versus quality versus complexity.

So the skill isn’t installing these. It’s knowing which one to turn on for the task in front of you, and which to leave off.

I hope this newsletter saved you a ton of tokens!

I watched Code with Claude, Anthropic’s first developer conference recently, and every talk kept circling the same question. What does it actually mean to be a AI native builder in 2026.

What stuck with me was that everyone on stage had stopped behaving like the role on their badge. Designers were shipping their own UI fixes in code. PMs were building their own dashboards and running their own experiments. Engineers were shipping product copy and doing DS work to figure out opportunity sizing. Nobody was waiting on anybody for the next handoff. The team makeup that I have been used to for the past 11 years, the one I assumed was the natural shape of software development, didn’t look like the natural shape anymore.

Basically everyone is “Technical Staff” but why is the world going towards this direction in the world of AI?

I did the math to figure it out.

What Engineering Actually Costs

The traditional software team has the shape it does for one reason. Engineering is expensive.

If you draw the impact equation on a napkin, it looks roughly like this.

Read more

I’ve been watching this one AI video for a few weeks now, in chunks, and I’m still only about halfway through it.

Not because it’s long. But because I’m only following maybe half of it on a generous day, and the rest of the time I’m pausing to look stuff up, rewinding the same two minutes, closing the laptop annoyed, and then opening it again a few days later to try again.

I’ve been trying to figure out why this video, of all things, keeps pulling me back. The answer I keep landing on is that I think I need to be obsessed again.

The video in question:

What Obsession Used To Look Like

The first time I was really obsessed with anything, I was switching careers into software with no CS degree and no real backup plan.

Every free hour went into coding, learning, solving problems, going to meetups, cornering engineers at events to ask questions I probably should have been embarrassed to ask. I wasn’t talented. I was just unwilling to think about anything else, and that turned out to be the whole game. The lever I had was sheer volume of effort and I pulled it constantly, and that obsession is what made me a real engineer faster than my background should have allowed.

When I got the job, the obsession didn’t end, it just changed shape. The new fuel was being great at the work, shipping the things, getting the promotions, being the engineer people pulled into the hard rooms. Same fire, different shape. That carried me from bootcamp grad to staff at Meta in just 6 years.

Then It Faded

I still love being an engineer. I still love building things. But the obsession is gone, and I’ve noticed it more than I expected to.

At this point I’ve seen almost every kind of problem that lands on my plate. After enough years of shipping, the shapes start repeating. New product, new team, new tech stack, but the codebases tend to have similar shapes and the same handful of design patterns underneath, and the problem on top is usually a variant of something I’ve already worked through two or three times. I know the tradeoffs. I know which patterns hold up and which ones quietly rot. And when a new problem shows up, I have pretty high confidence I can find an optimal solution.

I can count on one hand the times in the past few years I’ve felt genuinely out of my depth at work, the kind of out of my depth that forces you to dive deep and grow yourself before you can even see the solution.

And that turns out to be the actual problem, even though it sounds like the opposite. The obsession was always tied to being out of my depth, to having something to prove, to standing at the bottom of a mountain I wasn’t sure I could climb. Once you’re not at the bottom of a mountain anymore, the engine that got you up the last one doesn’t really have anything to do.

So my interests have spread out. YouTube has become a huge part of my life. Family time is the baseline underneath everything. I’ve been sneaking in hours on Slay the Spire 2, climbing ascensions like that’s somehow important. I have ten interesting things instead of one all consuming thing, and on paper that sounds like the good version of a life. It probably is.

The obsession is missing, and I’ve been quietly mourning it for longer than I want to admit.

Back To The Video

Then this chalkboard talk, and I keep coming back to it.

The thing is, I actually want to understand this stuff. It isn’t a video I’m watching out of obligation or because someone told me I should. AI training, how these models actually learn, the math under the hood, it’s a topic I’m genuinely interested in and want to learn. So when I keep bouncing off it, it isn’t boredom pushing me away, it’s just that I’m in over my head.

It was the first time in years I sat with something I couldn’t muscle through. Not in the “I could figure this out in a weekend” way. In the “this would take me years to really understand” way.

And there I realized this is the feeling I’ve been missing. The wall I can’t climb yet, the thing that’s hard enough that I can’t sandbag my way through on pattern recognition alone.

I started peeling the onion on what’s actually pulling me toward AI research, because this isn’t the first time the thought has come up. It comes back every few months. I look into what the path actually requires, get scared off by the cost, drop it, and then a few months later it’s back again. The fact that it keeps returning is starting to feel like the answer.

Read more

I hit my Metaversary this month, which is what we call your work anniversary at Meta, and mine just turned six.

Six is a kind of useless number to celebrate, because it isn’t five and it isn’t ten, and there’s no plaque or email or recognition attached to it, just a bot that pings you in the morning while you’re refilling coffee. I almost let mine pass without thinking about it, the way I let the previous two pass, except that this time the number sat on me a little.

Six years at Meta is enough time to feel like you’ve worked at six different companies. Every year, something major shifts. The product, the strategy, the org chart, the office culture, the technology under everything. The Meta I joined six years ago looks very different today.

What I Signed Up For

I joined Meta as a rotational engineer, which is a polite name for a tryout, in the sense that you do two rotations of six months each and you have to hit E4 by the end of the year or you’re out. The program is officially designed for people with non-traditional backgrounds but real industry experience. However, underneath the framing it’s mostly a way for the company to hire fast and fire fast on a stopwatch, which is why most people I knew at the time told me to take the safer offer.

I came into it with five years at a hardware company as a program manager and four years at Capital One as an full stack engineer, and Capital One was a great place to grow because I got promoted multiple times there, including a year where I got promoted twice, so by the time I was looking at Meta I had the swagger of someone who basically thought he couldn’t lose. I had an offer from Netflix sitting next to the Meta one, and the Netflix one was senior engineer, with a big jump in pay and no probation and no stopwatch, the kind of offer most people would have signed right away.

I turned it down. Meta was my dream company, the one I’d been trying to get into since I was a bootcamp student crashing hackathons on this campus, and honestly I would have taken almost anything to get in. So I took the smaller offer, took the title cut, took the probation, and showed up.

But then on my start day, they told me to go home.

Read more

Anthrophic Keeps Making Me Work

My entire Feed this weekend was around Anthropic’s new Claude Design. The usual doom and gloom of “Figma is dead” and “Rip Adobe” was everywhere and honestly justified based on their stock prices. Whenever their is this my hype I just can’t help myself so I deep dived into Claude Design.

I told myself I’d just take a quick look. Maybe click around for ten minutes and move on. Five hours later, I learned basically everything that the tool had to offer from quick designs, importing a Figma design systems, generating animations for my YouTube channel, and much more.

This is everything I found after systematically testing out all of the features. No speculation, no guessing. Just what’s actually there right now.

Subscribe now

The Layout

The first thing you notice is the layout. The chat moves to the left side, and the canvas takes up the right. This is different from other Claude interfaces I’ve used, where the chat Is the product and everything else is secondary. Its similar to focused canvas modes for writing though.

Here, the design is the main event. The chat is just how you talk to it. You describe what you want, Claude generates it on the canvas, and you iterate from there. It sounds simple, but the shift in spatial hierarchy changes how you think about the interaction. You stop thinking “let me prompt the AI” and start thinking “let me adjust this design.”

Four Starting Points

When you create a new project, you pick from four templates. Prototype, Slide Deck, From Template, or Other.

Prototype is the main one. It gives you a choice between Wireframe and High Fidelity. Wireframe is rough sketches for exploring ideas fast. High Fidelity uses your design system and gives you polished mockups with real brand assets. Same prompt, completely different output. The gap between the two is worth seeing yourself.

Slide Deck mode has a toggle I really like: “Use speaker notes.” Turn it on and Claude moves the detail into speaker notes instead of cramming everything onto the slide itself. The slides I made for this video used this mode, and honestly, it changed how I think about making presentations. I’ve been doing HTML slides with reveal.js for a while, but Claude Design takes the fidelity to another level.

From Template lets you start from reusable patterns. Right now there’s one built-in template for animation. But the interesting part is you can create your own templates from any project. Just go to Share, then Duplicate as Template. That’s the kind of workflow that compounds over time.

Other is a blank canvas sandbox. Good for experiments that don’t fit the other categories. I image these templates will be like skills and grow organically overtime from the community.

The Wizard Approach

One thing that surprised me: Claude Design doesn’t just drop you into a blank canvas and wait for instructions. Every time I started a new project, it launched a wizard. A short set of questions to narrow down what I was building before generating anything.

It asked about style preferences, color direction, layout density. You don’t need any of it, technically. You can skip straight through. But the effect is that Claude doesn’t have to guess as much, and the first output is usually closer to what you want.

This is the same principle behind good context engineering in Claude Code. The more context upfront, the less iteration later. They just built the context-gathering into the UI.

Nine Built-In Demos

Anthropic shipped nine example projects with the preview. You can find them in the Examples tab on the right panel. Each one has a “Use this prompt” button that lets you run it instantly.

The shader wallpapers are the showstopper. Five interactive wallpapers that react to your mouse. Genuinely impressive for something generated through conversation.

But the one that caught my attention as a YouTube creator was the animation examples. I could see a world where I generate transitions and motion graphics for my videos directly in this tool. I tested it with my Pomodoro design system and it actually applied the Mac OS aesthetic to the animation. It uses web technologies behind the scenes, so everything runs natively in the browser.

The other demos range from a globe loader with real country outlines to text particle effects where words dissolve into fire and smoke. Some are more impressive than others, but they all show the range of what’s possible.

Six Ways to Edit

After Claude generates something, you need to refine it. The canvas toolbar has four or so modes for this.

Tweaks is the one that surprised me most. Claude embeds actual sliders and color pickers directly into your prototype. Toggle Tweaks on and suddenly there are controls for theme color, accent color, timing values, whatever Claude decided was adjustable. You can fiddle with these live without going back to chat. Toggle Tweaks off and the controls disappear, leaving a clean design. For engineers this is pretty normal variables wrapped in UI but it stills feels like magic.

Edit mode opens a property inspector on the right side. You can change the background color, font family, base font size, and click on any element to edit its properties directly. It’s basically inspecting the HTML, which as an engineer, I appreciate. But I can also see why a designer might want more control here. Designers will definately miss the power controls you get from Figma.

Comments is where the collaboration story lives. You pin comments on specific elements, and here’s the non-obvious part: each comment gets a checkbox labeled “Select for Send to Claude.” You can check multiple comments and send them all in one batch. Claude resolves everything in a single turn. This mirrors how engineers and designers actually work. You don’t fix one thing at a time. You batch your feedback.

Draw mode lets you sketch annotations directly on the canvas. It has a queue system where you can mark up multiple things before sending. It even has mic input if you want to narrate your changes instead of typing them.

Below are some non editing controls but useful.

Zoom changes your canvas and goes from 50% to 200%.

Present has three options to view the canvas: in the current tab, fullscreen, or a new tab.

Feed It Everything

The import menu is where the context engineering lives. Six ways to pull external context into a project.

You can upload a .fig file directly from Figma. Connect a GitHub repo so Claude reads your components and styling patterns. Grab a live web element from any URL. Link a local code folder. Reference another Claude Design project. Or just drag and drop images, docs, and folders into the drop zone.

The Figma import is the one I used most. I also think this and Github combo will be the most important. To test I had a Mac OS design system as a .fig file, and once I imported it, every new design picked up the visual language automatically. Liquid glass, the macOS typography, all of it. This is where Claude Design stops being a toy and starts being useful for real work.

Design Systems

This is what I think makes the whole thing work for teams.

You go to Organization Settings, create a design system, and upload your brand assets. Codebases, slide decks, PDFs, logos, color palettes, type specimens. Claude extracts colors, typography, components, and layout patterns from whatever you give it.

Each design system has a Published/Draft toggle. Set one as Default and every new project automatically inherits it. Create templates from any project via the Share menu.

I spent a lot of time on this part because I think it’s the single most important feature. Without a design system, every project starts from zero. With one, you get consistency across everything. It’s the same reason companies invest in design systems in Figma. Claude Design just does the extraction for you.

You can also connect your codebase directly. Point it at your component library and Claude uses those patterns when generating new designs. This is the bridge between design and engineering that most tools get wrong.

Six Models

You have access to six Claude models and can switch between them mid-conversation without losing context. Opus 4.7 is the default. Haiku 4.5 is the fastest but weakest. Sonnet 4.6 sits in the middle.

For quick experiments, use Haiku. For anything that needs to look polished, stick with Opus. Its really a trade off between quality, cost, and speed.

Export and the Killer Feature

You can export your designs as .zip, PDF, PPTX, standalone HTML, or send them directly to Canva. Share links support view, comment, and edit permissions.

But the my favorite export feature is at the bottom of the export menu: Handoff to Claude Code.

One click and your visual prototype becomes a Claude Code session. The design gets transported into your coding environment and Claude starts implementing it as real, working code. This is the direction I’m most excited about. Design something visually, then hand it off to be built.

I think this pattern is a more releastic workflow for most tech workers. You stop choosing between “design tool” and “coding tool.” They become one pipeline. Personally I would just love to control all of Claude Design in Claude Code.

My Honest Take

I don’t think Claude Design kills Figma or Adobe. Not yet anyways.

The output quality is genuinely impressive. Zero to design, this is the best I’ve seen. The slides alone changed my workflow permanently for Youtube content creation. I’ll probably use Claude Design for every presentation from now on, then move them into Claude Code for final polish.

But for serious design work, it’s not there yet. The editing controls feel like Squarespace with AI attached. A real designer who needs layers, transparencies, precise control over every element is not going to switch off Figma for this. The collaboration story exists (comments, permissions, batch sending) but it’s early. Its missing a ton of features that would make it hard for Designers to leave Figma.

What I do think is that for engineers who need to prototype ideas quickly, for tech workers making presentations and animations, for anyone who needs “good enough” design without learning a design tool, this is already incredibly useful. It fits perfectly into my workflow for side projects and YouTube content.

And the design system + Claude Code handoff pipeline? That’s the thing to watch. If they keep pushing on that loop, this stops being a demo and starts being how things get built. Why build figma at all if you can just build a prototype? Right now its really the complexity, token cost and speed, but one day that may not be the case.

Get the Slides

Below are the full slide deck from this video. Same ones you saw at the beginning, built entirely in Claude Design.

Read more

I’ve talked a ton about Claude Code on this channel. And I think it’s great. But I also think it’s really important to not be in some echo chamber where everyone’s just saying how good their tool is.

Understanding the differences between these tools helps you choose the right one for the job. So I spent time learning Codex app, and I wanted to share everything you need to know so you can be effective and start building with it.

I also made a video version of this newsletter in case you prefer to learn visually!

Subscribe now

It’s Codex CLI wrapped in an IDE

The first thing you notice about Codex app is that it looks and feels like an IDE. It’s an Electron app with a project sidebar, threads, a built-in terminal, and a code review panel.

Claude Code’s desktop app has some of these elements too. But Codex leans harder into the visual experience. Rich rendering. Image previews. Downloadable plans. Inline diffing. The kind of stuff that’s impossible in a terminal UI.

If you’ve ever tried to review a massive diff in a TUI and thought “this would be so much easier with a proper interface,” Codex is what that looks like.

There are four ways to use Codex overall: the desktop app, the VS Code extension, the CLI, and Codex Cloud (which runs on OpenAI’s infrastructure using their Agent SDK). We’re focused on the desktop app here.

Three Ways To Execute: Local, Cloud, And Worktrees

• Local mode: is what you’d expect. You’re in a project, tasks run on your machine. Simple.

• Cloud mode: sends execution to OpenAI’s servers. You kick off a task, close your laptop, come back later, and pick up where it left off. It needs GitHub connected. And you’ll notice a lot of Codex’s workflows are oriented around pushing to GitHub and doing work virtually. It’s a different philosophy from “everything happens on my machine.”

• Worktree: Codex clones your current branch into a separate Git worktree, giving you two parallel local environments. You can run two agents on the same codebase without them stepping on each other’s files. The app has native support for this. You see different worktrees in the sidebar, create threads inside each one, and manage them visually.

Project Sidebar

Every top-level item is a project. Inside each project, you create threads. Each thread is one agent instance. If you use Claude Code in the terminal, think of each claude command you run as one of these threads.

The big difference is persistence. Hard-close Codex, reopen it, and your sessions are still there. Every thread you built up, every context you accumulated, cached and waiting for you.

In the terminal, closing a session means that context is gone.

If you think about context engineering, about how context is king, this matters. You’re investing effort to build up context for a specific task. Losing that because you closed a terminal tab is wasteful.

I can also see at a glance which threads are local, which are cloud executions, which are worktrees. That organizational clarity is valuable when you’re juggling multiple streams.

I still prefer the terminal personally. I’ve mapped out my workflow to a tee, like a Vim user with shortcuts for everything. But I can see why this wins for most people.

Models: It’s All About Trade-offs

Claude Code gives you Haiku, Sonnet, and Opus. Most people use Sonnet or Opus.

Codex has more options. GPT 5.4, Mini, the Codex model, and Spark (Max plan only, extremely fast). Type /models to see them all.

The two variables that matter are cost and speed.

But Codex adds another dimension: reasoning levels. For any model, you can set reasoning to low, medium, or high. Default is medium, which works for most tasks.

When I have a gnarly bug in a massive codebase, I crank reasoning to high. For simple file operations or boilerplate tasks, low is fine. Using high reasoning for everything is like driving in first gear on the highway. Technically it works. It’s also wasteful and slow.

There’s also /fast mode which pushes GPT 5.4 into a faster output mode at higher token cost. Worth it when you’re on a deadline. Not worth it for casual exploration.

Sub-agents doing research can use Mini. Your main planning thread should use the full model. Match the tool to the task.

Prompting: Four Pillars

Codex’s docs recommend structuring prompts around four elements:

• Goal - What are you trying to accomplish? Be specific.

• Context - Relevant files, folders, docs. You can use @ to reference files, but honestly I think you can just describe what you need in natural language and let the AI build its own context.

• Constraints - Framework, architecture, conventions. Anything not obvious from the code itself.

• Done When - Their version of agentic validation. Tell the agent how to know it succeeded. “Done when all tests pass.” “Done when the migration runs without errors.” Without it, you’re the only verification layer. With it, the agent can self-heal.

And always start in plan mode (Shift+Tab). Plan first, execute second.

Making It Yours: Agents.md, Skills, And Mcps

agents.md

This is Codex’s version of CLAUDE.md. It’s the open source standard name, and it’s where you put everything the model needs to know about your project that it can’t figure out on its own.

Build commands. PR conventions. Architecture decisions. Things you keep telling the AI over and over. If you’re re-prompting the same rules, that’s a signal to put them in agents.md instead.

Skills

Reusable workflows. Codex has a built-in skill creator. Describe what you want, and it generates the skill. They also have a marketplace with third-party skills and plugins: Sora, image gen, docs, Playwright, and more.

The distinction between skills and plugins: plugins bundle more than just prompts. They probably include MCPs and deeper integrations.

MCPs

Model Context Protocol is how you give the agent access to external tools and services. Things like Figma, databases, Slack, browser automation with Playwright. If you’ve used MCPs in Claude Code or Cursor, it works the same way here. You can install them from the marketplace or just tell Codex to set one up for you.

Sub-agents: Parallel Work And Context Protection

Sub-agents serve two purposes.

Parallel processing.Run multiple tasks simultaneously.Context protection.If a task is noisy and would pollute your main thread, offload it to a sub-agent. They call this “context rot.” Keep your main thread clean, let the sub-agent do the messy work, and report back with just the results.

This is also where model selection gets practical. Your main thread might need GPT 5.4 with high reasoning. A sub-agent doing a color palette investigation can use Mini with low reasoning. Match compute to complexity.

Sandboxing works per environment. You can configure read-only, default permissions, or full access. Settings are per-project or global.

Fine-grained permission rules let you pre-approve common commands (GitHub CLI, specific bash commands) so the agent doesn’t pause for approval on things that are obviously safe. The longer the agent can run autonomously, the more leverage you get.

Hooks trigger on lifecycle events: session start, pre-tool use, post-tool use, prompt submission, agent stop. You can ask Codex to build hooks for you. “Write me a post-tool hook that lints after every code change.” Let the agent manage its own environment.

Power User Features

Code Review Panel

Toggle it with Cmd+Option+B. You get inline diffs, selective staging, revert buttons, and the ability to request changes that the agent iterates on. Click a specific line, say “this is wrong, fix it,” and watch it iterate.

In Claude Code you need to jump to Vim or VS Code for proper diffing. Having review built into the agent workflow is really nice.

Automations

Cron jobs for your AI agent. Pick a project, set a schedule, and let it run. Templates include things like weekly code review summaries and repo maintenance.

The benefit of running automations inside Codex is that they leverage all the skills and context you’ve built for that project. Part of me thinks workflow tools like n8n are partially dead because of this.

Caveat: local automations need your computer running. Cloud automations exist for the set-and-forget use case.

Built-in Git

Git actions are first-class. Commit with auto-generated messages, create PRs, stage changes, review diffs. All from the app. These small things add up when you’re not constantly alt-tabbing between terminal, browser, and editor.

Best Practices

• One thread, one task. Scoped work produces clean results.

• Use /compact when threads get long. Context degradation is real. Keep it tight.

• Use /fork to branch conversations. Explore tangents without polluting the main thread.

• Put repeated instructions in agents.md. If you’re saying it twice, it should be in the file.

• Always include validation criteria. “Done when” or equivalent. Without it, you’re the only quality gate.

• Don’t skip plan mode. Most tasks worth doing need upfront planning.

• Set granular permissions. The less babysitting, the more leverage.

• Use worktrees for parallel file edits. Don’t have two threads editing the same files on the same branch.

• Perfect skills before automating them. Spend cycles getting the skill right, then put it on a schedule.

Closing Thoughts

More people are going to build software. Not because everyone will become an engineer, but because tools like Codex make the barrier lower. Some people see that as a threat. I see it as Jevons paradox: making coding more efficient doesn’t reduce demand for it. It increases demand.

The terminal is for engineers. Apps like Codex are for everyone who wants to build things. Both will coexist. But if I had to bet on which one grows the user base faster, it’s the one with buttons and previews.

Whether you’re a Claude Code loyalist (like me) or purely on the OpenAI side, learning both tools makes you more effective with either. The fundamentals are the same: context engineering, validation, plan before execute, and let agents run long.

The interface is just the surface. The principles underneath are the same.

I’ve won maybe seven or eight hackathons. Close to a 90% win rate. About forty thousand in total prizes, split with teammates. I won TechCrunch Disrupt. I’ve won with AI, and I’ve won without it.

Last month I went to an AI robotics hackathon in San Francisco and won the grand prize! I’m going to walk you through exactly how I did it, and how you can win these yourself.

I hadn’t been to a hackathon since joining Meta. You kind of stop going to meetups and hackathons when you’re working full-time. You lose that fire. But I took the train into the city, walked into the venue, and immediately felt it come back. One flat open space, people everywhere, my friend Juni already there. We’ve done a bunch of these together and we have a 100% win rate as a team. Kids were already hooked into robots, controlling them before the event even started. I was getting fired up.

Subscribe now

If you would prefer to watch the vlog version of this newsletter check it out here!

Hackathons Are Marketing

The best way to win hackathons is recognizing what a hackathon actually is. In my opinion, a hackathon is just marketing. The sponsors are paying to be there. They want developers using their tools, creating demos, generating content that makes them look good. The organizers want a story. If you understand that, you can work backwards from it.

Look at Anthropic’s last hackathon. A bunch of non-engineers won. People who’d never written code used Claude Code to build things and took home prizes. I’m not taking anything away from those hackers. But if I was organizing that event, I know exactly what story I’d want to tell. “Even non-engineers can build with Claude Code.” That’s a much bigger audience than just developers.

Every hackathon I’ve been to works this way. The sponsors want to see their tools used well. The judges want a compelling demo. The organizers want a narrative they can promote. If you understand who wants what, you build for the audience instead of building for yourself.

This particular hackathon was an AI robotics hackathon. They had robot arms, a robot dog, and claws you could control. The main prize was for the best robotics hack, but there were also a bunch of sponsor tracks on top of that. So the first thing I did was walk the sponsor tables and start figuring out how to make them all look good.

Talk To Sponsors, Stack The Tracks

Most teams pick one sponsor track and build for it. But you can qualify for more than one at a time, and most people don’t think to do this.

I started looking at the tracks. The main robotics prize was obvious. Everyone would target that. But then there was Smallest AI doing phone agents, Toolhouse doing agents as a service, Cyberware for the robotics control, and Jade Hosting for deployment. Most teams would pick one. I wanted to hit as many as possible. The more sponsors you use, the more chances you have of winning a specific sponsor prize.

So Juni and I split up. I researched the sponsor tools and started figuring out how they could all connect into a single product. He went deep on the Cyberware robotics stuff. And then we started talking to the sponsors.

This is probably the most underrated thing you can do at a hackathon. Build rapport with the sponsors. Not too often, but enough that they know you, they know you’re actually hacking, they know you’re using their stuff. They’re also great resources for their own products. They’ll give you hints on what they’re looking for. You pitch ideas, gauge their reaction. If they light up, you’re on the right track. If they give you a flat “oh yeah, that’s cool,” pivot.

I learned this years ago at TechCrunch Disrupt. The Esri booth had this incredible demo. A pulsing, animated map with city data flowing in real time, built on their JavaScript framework. I asked if they had the same thing on iOS. They said no. Said they’d been trying to figure it out but hadn’t cracked it yet.

I looked at the guy and said, “If we build that for you tonight, do we win your prize?”

He stared at me for a second. “Yeah. You guys pull that off, it’s yours.”

I went back to my team and told them to scrap everything. Six hours of work, gone. We pivoted the entire project around that single conversation. And we won. The code was a mess. Half the features were not fully working but that didn’t matter. During the announcement, the Esri sponsor basically said it himself. He gave it to us because we built the thing he wanted to exist.

The sponsors are the judges. They’re in the room. Use them.

Back at the robotics hackathon, we landed on a project that hit all four tracks. A voice-controlled robot butler called Alfred. You call a phone number (Smallest AI), that connects to a voice agent, which routes through an agent framework (Toolhouse), and that controls the actual robots (Cyberware). We hosted the MCP server through Jade. One project, four sponsor categories. Now we needed to build it.

Team

Later in the day my friend Kevin joined us too. He was actually my manager for the past five years at Meta. We’ve jumped from multiple projects and teams together. Reels, Meta AI, Threads. I’ve worked with him long enough to know exactly what he’s good at. And that matters more than most people realize.

A lot of people show up to hackathons solo and join a random team. You burn the first few hours just figuring out how strangers communicate. Go with people you know. People whose strengths you already trust.

Every hackathon team needs at least three roles. Not three people necessarily, but three roles covered.

You need someone to PM and present. That’s the person talking to sponsors, locking down the product direction, keeping the clock in mind. If your hackathon is seven hours long, you cannot spend an hour debating ideas. Someone has to take the inputs, make a call, and get people moving. That was me.

You need a deep diver. Someone who can disappear into the hardest technical problem for four hours and come out with something that works. That was Juni. He went deep on the robotic arm movement code and didn’t surface until it was done.

And you need a generalist. Someone who wires everything together, handles integrations, fills gaps. That was Kevin. Toolhouse agent routing, the robot dog, all the glue work.

We had our roles, we had our plan, and we started building.

Build For The Demo

You’re not building a product. You’re not even building a prototype. You’re building a demo.

This is where most teams lose. They spend 95% of their time building and 5% on the pitch. That ratio should be reversed. The happy path needs to work. The hardest thing you claim to do needs to actually function. Everything else can be mocked, static, held together with duct tape. Rough edges are fine. But the core thing has to be real.

We scoped ruthlessly. No edge cases. No error handling beyond “try again.” One happy path, polished until it looked intentional. Every feature we cut was a feature that couldn’t break during the demo.

With about two hours left, we started making the demo video. Most teams were still deep in code. Always have a video ready if the rules allow it. Live demos are usually the best option, but things can go wrong. And this time they did. The organizers announced everyone had to show pre-recorded videos because of technical difficulties with the robots.

Half the teams scrambled, but we were ready for it.

Presentation

Lead with the problem your hack solves and tell a good story. The tech stack matters, but it’s not your opening line. Start with what the thing does and why it’s cool. Then walk them through how you built it, making sure the sponsor tools are front and center. They want to hear their product name on stage. The feeding arm was the crowd favorite. Alfred tells you to get ready, activates the arm, says “just say stop whenever you need.” People laughed. That’s what sticks. The technical details land better after the audience already cares.

Show the hardest thing working. If you claim your hack does something impressive, that thing needs to actually function on stage. Everything else can be rough. But the one wow moment has to be real.

When judges ask about features you didn’t build, frame them as design choices, not gaps. “We scoped that out intentionally to focus on the core experience” sounds a lot better than “we ran out of time.” Missing features become roadmap items. Limitations become deliberate tradeoffs. You’re not lying. You’re presenting like someone who made intentional decisions, because you did.

The team with the best code almost never wins. The team with the best demo does.

We won. Grand prize. Alfred Robot Butler.

Go To Hackathons

After the awards, I ended up back at the robot table with a screwdriver, unscrewing a panel so I could plug in a USB cable. And I was having so much fun just doing that. Tinkering with something physical, something AI can’t autocomplete for me. It reminded me why I got into building things in the first place.

Go to hackathons. Especially right now with AI. Before, they were stressful. Now it’s basically vibe coding all day with zero thought about maintenance. You just need to get it to work. That’s the perfect use case for vibe coding. No production code, no tech debt, just “does it work for three minutes on stage?” It’s genuinely fun.

And if you want to win: remember that hackathons are marketing. Talk to sponsors. Stack the tracks. Go with people you trust. Build for the demo, not the product. And present like the demo is the product.

Keep the hacker sprit alive!

Can’t Help Thinking…

We were at a Korean BBQ place near his office. My friend was flipping galbi and telling me about his Tuesdays. Every week, the same routine. Download bank statements from four accounts as PDFs, open Excel, categorize each transaction line by line, merge the statements, cross-reference totals against each statement’s closing balance, feed everything into a master template, and generate a report.

Three to four hours. Every single week.

I just kept grilling. But driving home, I couldn’t stop decomposing his workflow. Four PDF sources with consistent formatting. Rule-based categorization he’s been doing by hand for years. Closing balances right there on each statement to validate against.

This is an afternoon with Claude Code. You describe the workflow, point it at a few sample statements, and it writes the script for you. It parses the PDFs, categorizes transactions using the same rules he’s been applying manually, checks the totals against each statement’s closing balance, merges everything, and spits out the report. One command, runs while he makes coffee.

He doesn’t need to learn to code. He just needs to know that a tool exists that can write the code for him, test it against his own data, and turn a weekly grind into something that runs in minutes.

I didn’t say any of this at dinner. Nobody wants to hear “actually, your job could be automated” over galbi.

Thing That Bothered Me

It wasn’t pity. I don’t pity the guy. He’s smart, makes good money, has a career he’s proud of. What bothered me was the gap. Not between him and me, but between what he knows exists and what actually exists now.

His mental model for AI is ChatGPT. A box you type into, a box that types back. You paste a document, you ask a question, you get an answer. Maybe it’s right, maybe it’s not. You copy the output, fix the parts that are wrong, and move on. That’s what AI means to him, and honestly, that’s what it means to most people.

But the tools have already moved past that. The difference between ChatGPT and something like Claude Code or Codex isn’t incremental. It’s structural. One gives you information. The other does the work. It reads your files, writes code, runs tests, catches its own mistakes, and builds things that persist after the conversation ends. My friend doesn’t need to learn how to code. He needs to learn that tools exist now that can build the code for him, test it against his own data, and turn a weekly ritual into something that runs while he sleeps.

I struggle to explain this to people outside of tech. Something seismic is happening in software engineering right now, and the hardest part isn’t the technology. It’s that the shift is invisible to anyone who isn’t living in it. My non-technical friends hear “AI is changing everything” and they think of chatbots still giving wrong answers. They have no frame of reference for what’s actually happening. And I don’t know how to bridge that gap over dinner without sounding like I’m either selling something or threatening their livelihood.

Flood

There’s an old idea that every tool you create to solve a problem creates new problems of its own. I’m watching that happen in real time, and I’ve been thinking about it a lot.

When coding was expensive, it was a bottleneck. You had an idea, you needed an engineer, the engineer had a backlog, so your idea waited. That constraint shaped everything. Product roadmaps, hiring plans, how fast companies could move. Coding was the speed limit.

That speed limit is gone now. Or at least, it’s moving so fast that it’s no longer the binding constraint. Engineers with agentic tools are shipping at three, five, ten times their previous rate. Teams are running multiple agent instances in parallel, each one churning out code on different tasks simultaneously.

So what happens when you flood a system with code?

It reminds me of my macroeconomics class. What happens when you flood a system with money? Everything downstream changes. New bottlenecks appear that nobody planned for.

PRs explode. Your team used to merge maybe ten a week. Now it’s fifty. Who reviews them? The agents aren’t reliable enough yet for full code review at most companies, so humans still need to look. But the humans haven’t multiplied. You’ve got the same five engineers now drowning in review requests.

So you try hybrid review. Let the AI handle some, humans handle the rest. But which ones? How do you decide what the AI reviews versus what a human reviews? That question didn’t exist a year ago. Now someone has to answer it.

And that’s just PR review. Pull the thread further.

Multiple agents running at once. How do you verify they’re all producing coherent work? How do you keep them from stepping on each other? Who manages the rules and context files they share? What happens when one agent’s changes break another agent’s assumptions? How do you govern who can modify the shared configuration? How do you prevent prompt injection through skills? What happens when an AI-generated change causes a production incident, who owns it?

Every one of these is a new problem. Not hypothetical. Right now, today, teams are scrambling to figure these out in real time.

Scary Part Nobody Wants To Say Out Loud

I’m going to be honest about something that most people in my position dance around.

Read more

There are a lot of orchestration solutions out there. But I always prefer the ones built into the tooling itself. Agent teams is Claude Code’s native multi-agent system, and I’ve been having a lot of fun using it for work and for my personal projects.

This is everything I’ve learned so far. 30 tips covering what agent teams are, how to set them up, how to control them, and where they actually shine.

Subscribe now

Before we get started, if you prefer to watch a video, I also made one!

What & Why

1 One lead, many teammates.

At a high level, an agent team is an orchestrator of subagents. You have one leader who is the orchestrator, and you have many different teammates. The leader holds all the tasks, spawns the teammates, and the teammates do individual work. You can have any composition of teammates you want. I have one team for coding with architecture, frontend, and backend agents. I have another for writing with a context gatherer, a writer, and an editor. The possibilities are basically unlimited.

2 Teammates talk to each other.

This is the most important difference between agent teams and regular subagents. The teammates message each other directly. They share a task list, claim work, and coordinate on their own. In my writing pipeline, the context gatherer, the editor, and the writer are all talking to each other. The context gatherer finds something relevant and sends it to the writer. The editor scores a draft and sends feedback back. That loop happens without me managing every message.

The sharing isn’t full context, though. They communicate through messages, not by reading each other’s full conversation history. So if you ever feel like a teammate doesn’t have enough context, you need to ask the main agent to send additional context, or you need to add more detail into the tasks you create.

3 You can talk to any teammate.

You’re not locked to the lead. You can navigate to any teammate and give them extra instructions, ask follow-up questions, or redirect their approach mid-task. It’s basically the same as if you had opened another Claude Code instance. You just go down, hit enter, and you’re talking directly to that agent.

4 Subagents for results. Teams for collaboration.

If you just need some quick results, use a subagent. If you need collaboration, coordination, agents sharing findings and challenging each other, use an agent team. The key difference is that a subagent’s context is completely isolated from the main agent. The subagent doesn’t know anything the main agent knows unless it was explicitly included in the initial prompt. Its only job is to do some side effect or send information back. Agent teams share a common task list, talk to each other, and the orchestrator can control any of them.

5 Teams cost more tokens.

Each teammate has its own context window. Token usage scales linearly with team size. If you’re not already running multiple Claude Code instances in parallel, the usage might outpace what you’re used to. For research and review, the extra tokens are worth it. For routine tasks, stick to single sessions.

6 Best for parallel exploration.

The best use case for agent teams has been when I need to accomplish tasks across various different domains. A really obvious example for full stack: one frontend agent, one backend agent, one architecture agent. It recognized that the frontend work could be split further and created multiple frontend agents because they were in different places. It really speeds up execution.

Another great use case is writing. My context gatherer, writer, and editor used to run sequentially. Now with agent teams, they all run at once. And they actually help each other, because sometimes the writer needs context for a specific part, and the context gatherer just goes and grabs it.

7 Skip teams for sequential work.

If your tasks have heavy dependencies, or you’re working on the same pages, you probably don’t want multiple agents because they could conflict with each other. Unless you use worktrees or something like that. Same-file edits, tasks that must happen in order, agent teams is not the right tool. The coordination overhead isn’t worth it.

Getting Started

8 Enable in settings.json.

Depending on when you’re reading this, agent teams might still be experimental. You need to add "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" to the env section of your settings. Then restart Claude Code. If you don’t want to figure out where to put it, just paste the docs page into Claude Code and ask it to set it up for you. Then restart.

9 Just describe the team you want.

You use natural language to define your team. Something like: “I want you to create a performance agent team. One specializing in UI performance, looking for jank. Another specializing in debugging and deep diving into errors. Claude handles the rest. It creates the teammates, assigns the roles, and starts coordinating.

10 Specify models per teammate.

This is a really good tip if you’re cost-sensitive. You can tell the orchestrator which model each teammate should run. For example: the debugger runs on Opus, the UI perf agent on Sonnet, and the UX quality agent on Haiku. The lead will shut down the agents and recreate them with the new models. Not every task needs the most expensive model.

11 In-process mode, all in one terminal.

The default display mode shows everything in a single terminal panel. You navigate between agents by hitting down arrow, then enter. You can see the different agents and guide them individually. It works, but it’s not the easiest way to see what everyone is doing at once.

12 Split panes, see everyone at once.

The other display mode splits each agent into its own tmux pane. If you have a big monitor, this is incredible. You can see all your agents working simultaneously. Each one has its own pane with its own color. I have a 32-inch monitor and it looks really nice spread out.

13 Set “tmux” in settings.json.

To get split panes, you need to set your display mode to tmux in your settings. You also need to actually be running inside tmux. They say it works on iTerm too, but personally I haven’t been able to get that working even after installing everything. Tmux is the reliable option.

Controlling Your Team

14 Shared task list coordinates work.

Every time an agent team starts working, the orchestrator creates a task list. You can see it by hitting Ctrl+T. These tasks are what drive the coordination. The orchestrator creates them, assigns them to teammates, and teammates claim and complete them. For a writing project, it might be “research the GPT-5.4 release” assigned to the context gatherer and “review the essay” assigned to the editor.

15 Assign or let them self-claim.

You can be very prescriptive about how you want things done, or you can let the orchestrator figure it out. If you have a really good idea of how the work should be split, work with the main agent to create a detailed plan first. I like to spend time planning ahead, save that task list locally, and then whenever I come back I just tell the agent team to pick up the next set of tasks.

16 Messages arrive automatically.

You don’t have to manage any of the messaging. There’s no polling. Teammates automatically receive messages and automatically report back when they’re done. The lead gets notified when a task completes. So technically you don’t need to go into the individual agents. You should mainly be looking at the lead. The split pane makes it easier to monitor, but the lead handles the coordination.

17 Require plans before implementation.

If you like to use Claude Code without plan mode and just straight execution, agent teams is probably not for you. You need a plan before implementation. The orchestrator needs to understand the full scope before spawning teammates and assigning work. Without that, agents go off in random directions and you waste tokens.

18 Guide the lead’s approval criteria.

Tell the orchestrator what quality bar you expect. Something like “make sure you have a very high quality bar for all of the code, tell all the subagents to maintain this standard.” Those instructions trickle down into the agent teams. The lead passes your criteria to each teammate. This is your main lever for controlling output quality without micromanaging each agent.

19 Graceful shutdown via the lead.

Agents have lifecycles. When they’re idle for a certain amount of time, they kill themselves. You can see them gray out in the interface when they go idle. After enough idle time, the main orchestrator turns them off automatically. You don’t have to go in and individually shut down each one.

20 Always clean up through the lead.

If you feel like a teammate is unnecessary, tell the orchestrator to clean it up. Don’t try to manually kill individual agents. The docs say you can get into a really weird state, potentially with memory leaks, if you don’t let the main orchestrator handle the shutdown. Let the lead manage the lifecycle.

21 Hooks enforce quality gates.

If you’re used to hooks, there are additional hook events for teammate_idle and task_complete. You can trigger actions when these lifecycle events happen. I haven’t found a ton of interesting uses for this yet, but someone is going to figure out something cool. Maybe on task complete, you send something to Notion, or trigger a Slack message, or update Jira. The hooks are there.

Best Practices

22 Give teammates enough context.

Each teammate loads your CLAUDE.md and your MCP servers, same as any Claude Code instance. But it does not get your main agent’s conversation history. Whatever context you built up before starting the agent swarm, the teammates won’t have it. If you want that context in your agent teams, the best way is to ask the orchestrator to embed the important details into the task descriptions. Something like “start the next set of tasks, but can you include all the important code pointers I’ve gathered so far into the tasks so my teammates have good context.”

23 Start with 3-5 teammates.

I actually found anything more than three feels like overkill. The tokens scale linearly with how many agents you’re running. Three, maybe four agents is the sweet spot. You’ll find use cases for more, but start small.

24 5-6 tasks per teammate.

Don’t give a teammate 20 things to do at once. Plan out a lot of subtasks if you want, but then kick them off to do one concise thing, bring them back, and start the next thing. This is so much like real project management. You’re literally orchestrating a team of engineers, and a lot of the best practices for managing real teams apply here.

25 Avoid file conflicts.

Don’t let agents touch the same files. I showed this earlier with the frontend-1, frontend-2, frontend-3 example. If they’re all working on the same pages, they’ll conflict with each other. Agent teams work best when you can cleanly separate domains. Frontend agent stays in the frontend directory. Backend agent stays in the backend directory. No overlap.

26 Tell the lead to wait.

Sometimes the leader will just start implementing stuff instead of delegating. You have to guide it and tell it to stop. “Delegate this to your teammates” or “wait for your teams to complete their tasks before starting.” This is just an artifact of the feature being experimental. Keep an eye on the lead and redirect when needed.

27 Parallel code review.

This is one of the best use cases I’ve found. You tell the agent team: “Do a code review on the latest changes. One agent focused on security. One focused on performance. One focused on test coverage. Combine the results into one review.” The reason this works so well with agent teams is bias isolation. If you try to do security, performance, and test coverage all in the same context, the agent gets biased by whatever it finds first. With separate agents, each one investigates independently with fresh eyes. Then the orchestrator synthesizes the findings into a holistic picture.

28 Competing hypotheses for debugging.

Say you’re investigating a bug and you come up with five theories. Instead of going through them one by one, you spawn five agents and let them each pursue a theory independently. This is really important because of context bias. As soon as an agent gets some evidence that supports one theory, it leans toward thinking it’s correct. By splitting the investigation into separate agents, you protect each theory from being contaminated by evidence for the others. When they come back and share notes, the main agent has all the findings and can form a holistic picture. I’ve found this incredibly useful at work for debugging.

29 Start with read-only tasks.

If you’re just getting started with agent teams, lean toward read-only tasks first. Investigations, research, code review, context gathering. This goes back to the file conflict issue. If agents are only reading, you don’t have to worry about collisions. My context gatherer and researcher are both read-only agents. They’re essential for my writer, but they never create conflicts because they’re not editing files.

Another good example: if you’re doing Android and you have an iOS counterpart with shared architecture, you can have a parity agent that reads the iOS code and creates tasks based on the differences. Then an executing agent implements them. It’s probably one of the most efficient ways to do feature parity work, as long as the architecture is similar.

30 Monitor and steer.

My final tip. Don’t set it and forget it. If you let these agents run too long unguided, they can go off the rails and you end up wasting a lot of tokens. Constantly monitor them. Check in on what they’re doing. Redirect when something looks wrong. The split pane view makes this a lot easier, which is why I recommend the tmux setup if your screen supports it.

Agent teams are still experimental. There are rough edges, there are bugs, and the tmux display can be finicky. But when it clicks, when you have three agents all working in parallel on different parts of your problem and coordinating with each other, it genuinely feels like the future.

The same context engineering principles from regular Claude Code still apply. Context is king. Context is best served fresh and condensed. But now you’re managing context across a team, not just a single agent. And a lot of the best practices that work for managing real engineering teams, clear task scoping, domain separation, quality criteria, they apply here too.

If you want more on this, I made a 50 tips video for Claude Code that covers the fundamentals. And my agentic engineering video covers the higher-level principles behind all of this. Agent teams is just one piece of the puzzle, but it’s a powerful one.