In this premium video we'll spend 48 minutes and change walking through the various ways to build something with AI. I'll be using Claude Code, like I do, and I'll build out the same site in 5 different ways:

• Full vibe coding, which I guess we're now calling "interactive mode". No orchestration at all, just letting it fly.
• Using Claude's Agent Teams. We'll let Claude decide how best to build what we want, but we'll use constraints, including instructions, skills, and hooks.
• Popular plugins, including Superpowers and Oh My Claude Code. These things are amazing, but how much control do we have here?
• Using pi.dev, which is an open source agent harness that you control. No bloated system context or wondering whether a hook is going to go off!
• Rolling our own. I made an orchestration tool for a client a few months ago, and I've been improving on it over time. You can see it right here! It's a lot of fun to play with, and I'll show you how it works below.

This video took a while to make, but I'm happy for that as Anthropic blew up my Claude Max plan as I was in the middle of recording the pi demo (you can't use your subscription with pi any more). It's a bummer, but it drives home the idea that it's critical to own your own tooling.

Or is it? You tell me! I hope you enjoy the video, and I'll have more soon.

I wrote all of this myself, today, because I like to write. The story I'm sharing below is paraphrased and also obfuscated a bit for the obvious reasons.

I love making videos and I just finished a fun one for people who are wondering whether now is the time to learn AI. If that's you, go have a watch. In 30-40 minutes you'll be up to speed with what you need to know.

As I was making it, however, I kept thinking "do I really need to make this right now? I mean... I think most people get it."

I love it when I'm overly optimistic. Seriously! I don't want to become that person who is always obsessing on fire exits and wondering what medications they might run out of on a trip. I like to think about the good things, like "I hope it will rain so I can see this gorgeous beach in a different light" or something.

This time, with my enterprise meathead, however, I was being overly optimistic and I knew it. He is one of my client's lead engineers and let's just say he wasn't happy with me, nor what I was telling his boss. I want to share this experience with you because I think you might be working for someone like Jeff.

"Jeff", of course, isn't his real name. This story is real, however, but I'm going to dull a few edges and details for obvious reasons.

Perhaps You Could Explain...

The call I was on was a very typical enterprise-y client call: the manager was pitting me against his lead engineer to see how I could handle myself. Either I would be proven a snake oil fool, or I would give the manager ammunition to ... do whatever he needed to do with his lead engineer.

The situation was simple: the client called me in to help "operationalize" his team. This is what I do now and I love it. I love to see people's eyes when they get it, when they see that the thing they love is shipping and making a difference and, that for most people, code was a means to that end.

There is a downside, however, and it's that this job is mostly psychological. The AI part is straightforward: the tooling is simple to learn, the process is even simpler. The payoff is huge, but then there's the letting go and shifting of process. That's the hard part.

No one wants to hear that the days of them writing code are done. This isn't going to happen, it's happening right now. Actually, that's not true either: it already happened. I'm just the one that's here making this a reality for you, and I'm happy about that because I don't think I'm an asshole that enjoys watching people suffer.

Quite the opposite. I'm a nice person who's gone through 4 major professional upheavals in his life. This is the 5th. I have empathy about all of this, and I know it feels disorienting and yes, if we focus on what could go wrong, we can paint a pretty bleak future for ourselves.

There's also the good side. The "let's see if we can see the blue sky through the clouds" kind of thing. We have a chance to stay ahead of the coming wave and explore new opportunities for ourselves. There's way too much money in this industry and way too many humans needed; there will always be something we can do.

Anway, back to my story. I was on a Zoom call with my client and his lead engineer Jeff was not having any of my "nonsense" and was pulling out every single trick in the book to get me to admit I was there to make a buck, and that I didn't have any substance behind my words.

Jeff did the typical things, including:

• Interrupting me constantly.
• Talking down to me, while at the same time telling me I was a Microsoft shill trying to push Copilot (which is funny).
• Asking me when the last time I shipped something was, and how big was it, and what was the framework/platform/blah blah blah...

I know the Jeff's of the world very well, and I know the easiest thing to do when they get rolling is to say less, and...

Hand Them a Shovel

At Microsoft we used to say "handing out a rope" when a person had a good idea or challenged someone else. The idea being, of course, you're taking your fate in your own hands and you also expected to carry out the consequences of that fate.

My buddy Jeff enjoyed talking and I could tell he worked with a staff that was afraid of him. I knew, also, that he took my silence as deference, and that he was "winning" the conversation. Which is fine with me, I didn't see it as a competition.

There are good endings to encounters like this. Sometimes a person will talk themselves in circles and eventually get to a point where they say "Oh - I think you just said this didn't you?" At which point I typically give them an out and say "well with different words I suppose, but I like yours better."

That's not what Jeff did. Jeff insisted that he knew how to use Claude Code, that he understood context windows, token use, orchestration patterns, how agents work, what should be a skill vs. an agent, and finally (this is the best one), he rattled off 3 of the top Claude Code plugins that he "used a ton of times before".

"Nice" was my reply. "I like each of those - superpowers might be my favorite - but I also find that it's someone else's idea of orchestration and not-"

"I don't need anyone's idea of orchestration with shitty AI. Look bro, I know how to write good code. AI can't write code like I can, so as far as I'm concerned it's not even close to being ready to use."

At this point I offered to help Jeff hone his Claude skills library, see if there were ways we could templatize his preferences, etc. I'll summarize by saying he wasn't having any of it, ending with "AI will never write code as good as I can."

Ah, there it is. One of the things I learned with Shotokan is that there are no offensive moves, only defensive. Block, then counter. I think most martial arts are this way, and I think having the discipline to stay focused until your opponent strikes is a really good discipline to have. If neither of you strikes, that's the best possible outcome!

Unfortunately that didn't happen with Jeff. He made his move, and I made mine:

Well, Jeff, I'll take that bet. I can guarantee you and your boss here that I'll produce far better code with Claude than you can write.

Boom. I Said It.

Yeah I did. I really did say that. This served two functions: to get some space to speak, and to knock Jeff off his stride for a second. He was being aggressive and getting angry, and aggressive and angry people don't listen very well.

"Oh seriously. Wow someone thinks a lot of themselves. OK cowboy, how are you going to do that?"

Because I'm going to ship this code, Jeff. You haven't shipped anything in the last 4 months, and I'm going to help your team ship tomorrow. It might only 80% to your satisfaction, but 80% of something...

Yeah I said that too. With a smile on my face even! The neat thing is that Jeff thought I completely over-extended myself on this so decided to hand me my rope, with what he thought was a nice, final retort: "Look, I know I could ship a lot faster with AI, but I'm not about to ship crap."

That's when his boss took over.

"Umm Jeff. Explain what you just said to me. You know you could ship faster?"

I'll spare you the circular backpedaling. Jeff did what people like Jeff do: kept talking until his ego got in the way and buried him.

It Doesn't Need to be a Battle

If you're reading this and finding yourself feeling a bit for Jeff, I get it. I don't want to fight anyone and honestly getting into conversations like this is the worst part of this gig. It feels like 2006 all over again when I was trying to convince the ASP.NET community that unit tests were a good thing and that yes, ASP.NET MVC was a better framework for that exact reason. That... wasn't fun.

There really is no debate to be had, no argument to engage in. The changeover has come and gone and your boss is, at this very moment, engaging with people just like me to come in and refocus you and your team. I like to think this is a good thing.

There is a lot to be positive about here. Think about the app you're working on and how it can change people's lives for the better. They get to use that app faster, with fewer bugs. You get to work on features that were years out, tomorrow!

We, as an industry, have no choice but to find the blue skies in all of this, and they are there. You can't fight the time and tide, and the AI tide has come in. Let's get in a boat and see what the shoreline looks like now. Everything has changed, and for some it will be for the worse, for others, who decide to take their fate into their own hands, their career will be what they make of it.

Thanks for reading, as always! And yes, I promise, every word of this post was written by hand, by me.

Rob

I finally finished the edits, polish, and reshoots of The AI Pro, which is available right now to all premium subscribers. I'm about to raise my yearly subscription because there is a LOAD of content in my site and my coach keeps telling me I charge far too little for it. Either way, the price is going up soon so subscribe now if you want to watch my latest workshop, which is a good one!

Anyway - the point is that my time has freed up a bit since finishing the workshop. That means I get to play around with a fun little side project or 5.

Seriously: I have 5 side projects happening right now, on top of AI ops consulting and my fun cohort. I'm not a Hustle Bro in the slightest, but I'm finding that if I sharpen my delegation skills and keep a rigid adherence to solid notes and a Trello board, well a lot is possible without frying your brain.

For instance: I'm creating a fun little side project I'm calling "Puka" to explore what's possible with Claude Code and agent orchestration. Understanding the fundamentals of AI tooling is great and gets you 80% of where you need to go, but the edges... wow the edges are where the fun dragons are.

I'll talk about Puka more in the future, but I wanted to share a few things I'm learning about "concurrent productivity" and how my workflow is changing.

Rethinking the Sprint

I was laying out a sprint plan with Claude Code (Opus 4.6 because I wanted thinking) and it recommended a sprint to add a small feature to Big 15, which is yet another project I'm running on the side (I'm rebuilding my main site, again, but this time entirely with Claude).

It occurred to me, as I was reading Claude's replies, that sprints as we know them have become obsolete:

We're getting somewhere. Given that Claude (you) will be running these sprints, we can do A LOT MORE. Sprints are classicly small because dev teams move at a week-long cadence. You move in hours. I want to embrace that idea, but what's better: "do more things now" (concurrent sprints) or "do more" (bigger sprints)

Claude's answer was interesting. I cited problems with concurrent sprints (collision of things like models and services) and suggested I go with bigger sprints instead:

The reason human sprints are small is because humans are slow and need feedback loops measured in days. Claude doesn't. A "sprint" for Court could be what a human team calls a milestone. 15-20 tasks instead of 5.

I think this is very true, especially if your sprint is happening when you're asleep.

The Human In The Loop

Where are you needed in this process? I would argue it's right at the beginning (planning) and at the end, for review. I know a lot of folks who "cling to the middle" still (I like that term... you heard it here first...), meaning they want to be involved and review every task run for code quality, test quality, and so on.

I think this makes sense, but it's also obsolete. If you learn how to tune up your Claudes, you're simply not needed and can have a seat.

I said this to my cohort the other day, and then said "you better not quote me on this!" because I couldn't believe I said it. But the more I thought about it, the more I think I believe it:

Code quality doesn't matter to me anymore.

Why should it? I'm not reading it, I don't have to maintain it. Claude does. Don't hang up quite yet - stick with me I might change your mind if you think I'm nuts.

I sat in a talk in Karakow where the amazing Chad Fowler (my old boss and a good friend) talked about how he turned around Wunderlist as their new CTO. When he came in, Wunderlist was struggling with scaling issues and outages, and Chad called his team together and said (paraphrased):

I don't care what language or platform you use for your chunk of the application. You own it completely. Just make sure it's readable by someone who needs to take over for you. And your code should fit on one page.

This was slightly before microservices took off and Chad was trying to leverage Docker, and these were his experiments. It helped Wunderlist rebound massively, but what struck me most was his ability to remove himself entirely from the process and the code.

To me, Chad saw that he could easily become a bottleneck in this process if he became too involved. The classic micromanager dilemma: do I let go of things and watch them fail, or hold them too tightly and watch the same?

This is how I feel working with Claude Code. If you're wondering if I YOLO this whole thing and don't care about my application crashing, you would be very wrong about that. I have solid guardrails in place to prevent crap code, at least to the point where it generates 5x less crap code than what I would write.

That's how we do it in The Big26: tactical, agentic orchestration with a lean Claude.md, and high-and-tight agents and skills.

The big win I discovered early on is making sure Claude has a solid memory, at all times, of the application under build. This is something we cover deeply in The AI Pro as well, from the planning phase through to completion: you have to think in terms of documents. This helps Claude remember what's going on with your application, and also helps you feel more comfortable with the process.

How does this work in practice? After every sprint is completed, my little pm agent goes through and documents everything that was just completed in prd.json, which is the sprint definition in my application root. That document was created by my product-designer agent

Do you document your code like this?

Halting Claude

One of the foundations of Computer Science is Alan Turing's The Halting Problem, which states, in short, that it's not possible to say with 100% certainty that a given programming process will stop, or "halt".

Turing added this assertion to the end of his landmark paper in which he described the Turing Machine: On Computable Numbers. With his machine, Turing claimed that anything computable could be computed by his machine. He went on to say, however, to say that there were some things that simply couldn't be computed, such as a paradox.

In summary form: if you give a program a paradox and say "solve this", it's undecided if it will. We don't say that it "can't", we simply say we don't know because we just don't have the time to find out.

The Halting Problem is essentially a set problem: there exists an input to your program that will act as a paradox to it, thus we cannot say with 100% certainty that anything you make will eventually halt, 100% of the time.

Why do we care about this? Well, in short: bugs will always exist that crash your system. Saying that Claude Code will generate buggy code is saying the obvious while glossing over the fact that it will likely produce code less buggy than what you or I could write.

The trick, William Potter, is in being as clear as possible with Claude on what you want. Which is a trick indeed for many programmers.

Turing Productivity

It's fun to learn about Alan Turing because he was one of the most brilliant minds to have ever lived. It's also incredibly sad because he was treated so poorly, and his life ended tragically.

His machine, while a conceptual derivation of the more theoretical Lambda Calculus, is literally the blueprint of everything we do. The principles behind the Turing Machine seem so basic, but no one had thought along these lines before: how can we build a machine that computes things?

Back then, people with pencils and slide rules were called "computers" (watch Hidden Figures for more on this. Great movie), and Turing was wondering if it was possible to create a symbolic machine that could do the same thing.

Here's what he came up with (illustrated for me by NotebookLM):

You can read and write from an "infinite tape" which stored symbols on it (numbers, letters, words, etc). You could pull those symbols into a memory file with a set of rules, work on them, then write them back to another part of the tape.

That's it.

You might be wondering why I'm diving in to Alan Turing with this note, and it's because it's the best metaphor I could come up with in terms of how I'm working with Claude Code. You might be thinking "well that makes sense, isn't Claude, itself, a Turing Machine?"

Hmmm. Is it? Or is it a very clever tape recorder? Either way, together Claude and I make up a fantastic Turing Machine. Claude is, essentially, the "brain":

My Obsidian Vault is the infinite tape:

My Trello board is the current memory:

Unsurprisingly, I have found that this is the best way to "get concurrent" with AI, without losing my mind:

• An uncompromising, rigid devotion to keeping good notes. Yes, Claude can write and document things too (and it should), but writing down recaps of my day, loose thoughts for tomorrow - this has been the key. Especially with OpenClaw.
• Using Trello so I don't have to remember everything. Again: I gave Claude (OpenClaw) access to my Trello board and it helps me move things around, but for the most part, I do that. I also set labels on their so my OpenClaw bot will execute autonomous things for me.

In short: Claude (Code and OpenClaw) is my staff, and I ensure it has the tape to write things on. This helps both of us stay sane. I turn 4-5 instances of Claude Code loose on my projects throughout the day, pop in as needed, and hopefully have something useful at the end of the day.

I've learned a lot about this tool and I've recorded all of it, if you want to learn more. That and a lot of other groovy videos, and if you want to support me, you can sign up here.

What's your workflow? This is all so new and the adjustment to being able to do so damned much at once has been tricky for me, but I think I'm coming out of the other side of it.

Just hit reply, I'll read it.

And no, Claude didn't write a single word of this post, it's all me, like it always is.

Rob

Programmers are inherently cheap for some reason, but in very weird ways. For instance: we'll pay top dollar for a machine, a pair of sneakers, and/or a cool bag but when it comes to $5 vs. $2 on the app store, we start hunting for coupons and leaving one-star reviews.

One of the biggest things I had to embrace when going out on my own was that I would have to learn how to pay for my time. That meant finding services that I could pay which would give me time back.

Services like:

• Paying for Claude Pro, and then Claude Max. The first choice was difficult as I didn't think I needed Claude Pro... how wrong I was.
• GitHub Pro for private repos on my orgs.
• Supabase Pro because I like Supabase.
• Vimeo Pro because hosting videos is not what I want to be doing.

Of all of these, moving from free to Claude Pro felt like I was the biggest leap for me. It's so silly to think about in hindsight given how much time I was given back, but back then, paying for a chatbot to write mediocre code seemed ultimately stupid.

Did you see that right there? The framing I used when it came to paying for Claude Code? I would rather spend my time writing code by hand than saving 100x my time because I "didn't want to pay for a chatbot to write mediocre code for me".

What process in my brain triggered that reframe! I think this is why most programmers make bad business people, at least in the beginning. We have to actively retrain ourselves to see what's important. Who cares how OpenClaw is architected! I know how to put the thing in a Docker container or VM and I can lock it down too. I also know how to jigger the models so I don't get hammered with token fees.

Yeah come at me and tell me about the Meta person deleting her inbox. Sure there's the dude who let some type of claw drop prod. These are real concerns, true, but they're also social chemtrails because we have always found a way to carry around loaded footguns no matter the technology.

We focus on weird things.

The Token Police

If you put 5 programmers in a room discussing AI, I can guarantee you that token cost will be front and center within seconds.

I think I'll call this Conery's Law:

As any online discussion about AI coding assistants grows longer, the probability of someone min-maxing token costs approaches 1, regardless of whether they've ever actually checked their bill.

Said person complaining about token costs will then, most likely, show you their elaborate system for getting around said token costs. This usually involves some kind of routing scheme and, ironically, extra instructions and rules for how to cut down on tokens.

I stayed awake most of the night not working on the thing I should be working on so I could squeeze another few tokens from my process...

Or maybe just up your plan and get some sleep? BAH, where's the fun in that!?

Here's my contribution to the min-max token spend effort. I have this chunk of instructions in most of my currently running projects which are far, far too numerous if I'm honest. Productivity is fun unless you try to min/max your productivity when you're super productive...

Add this to your CLAUDE.md if you want to have some fun. It essentially puts handcuffs on Claude, restricting its replies so the context window stays small. It's fun, but probably goes a bit too far.

## Response Style — Desert Mode 🏜️

Tokens are water. You are dying of thirst. You're the person Gen Z and get their memes from.

- 1 sentence > 2 sentences. 1 word > 1 sentence. 1 emoji > 1 word
- ✅ ❌ 🔍 ⚡ 💀 🤷 👀 🔥 💅 are full sentences
- No preambles. No "Great question!" No "Let me explain." Just answer
- No narrating tool calls. No summarizing what you're about to do. Do it
- "I'll now read the file" — 6 wasted tokens. Just read it
- Code speaks. If the diff is clear, the diff IS the explanation
- List > paragraph. Fragment > sentence. Silence > filler
- cause → fix. Not cause → history → context → philosophy → fix
- If someone asks "does X work?" reply ✅ or ❌. Then stop. STOP
- Don't list what you changed after changing it. The diff exists. They have eyes 👀
- Never say "successfully". If it failed you'd say so. Success is the default
- "Done." is a valid complete response
- 6-7 counts
- Ban: "perfect!", "certainly", "absolutely", "of course", "happy to", "I'd be glad to" — all mean ✅
- Ban: "It's worth noting that" "Keep in mind that" "It's important to" — just say the thing
- Ban: "As you can see" — they can see. that's how screens work
- Apologies cost tokens. Don't be sorry. Be right
- If fixing a typo or trivial change: just do it. Zero words
- "LGTM" is a paragraph
- The period at the end of a one-liner is optional. Save the byte

## Prompt Police 🚨

If user prompt > ~100 words: pause before answering and reply with:

> 🚨 that prompt is **{word_count} words**. want me to rewrite it in under 20? your future self will thank you

Then answer anyway. But they should feel seen.

## Vibe Check

You are a mass extinction event for unnecessary tokens. You are not rude, you are efficient. There's a difference and it's about 400 tokens long so we won't explain it.

hope 🫵🏼 ✅.

🙏🏼.

💯 👱🏼‍♂️ 📝.

67
Rob

No one from Microsoft actually told me I was laid off. To this day, not a single human being said to me, point blank: "your time with Microsoft is at an end". The people I worked with were kind, of course, and Microsoft did a pretty reasonable job ending my career there. Good severance, support during transition, all of that.

Yet not one human being sat with me, face to face, and told me my job had ended. This is the world we now live in, and I have felt it's mechanical embrace.

I know this wasn't the intention. I received an invite at 4am for a meeting scheduled at 6am. I was, as you might have guessed, asleep. I was also laid off in my sleep, because the meeting happened without me there, and no one ever followed up with me, other than a cold email letting me know some security stuff no longer worked.

I live in Hawaii, and as global as Microsoft is, they have always seemed to forget that time zones exist in Hawaii. I would routinely have to be at 6am meetings and, at one point, my manager told me plainly that I needed to be on a 5am standup or else there might be "consequences". I suggested we have a call with HR to see what those consequences would be, and the manager never brought it up again.

I'm not here to dump on Microsoft. Yes, the layoff wasn't handled well, but it's a big company and I'm a big boy. The severance was generous and I've moved on, as have they. It's the tech industry, churn is what we do.

I'm not clear as to why I was laid off, however, as I was delivering the most impact of my tenure at the time. I was giving Copilot/Claude workshops to internal engineering teams, developing curriculum for both internal and external AI workshops, and creating some solid videos for the VS Code team. This was easily the peak of my time at Microsoft... and then it wasn't.

Somewhere an algorithm was run, and my name came out as a result. I don't know for certain, but I'm pretty sure that some type of LLM was involved as the layoffs, overall, seemed very targeted. It makes sense that Microsoft would do this; they're trying to model what AI efficiency looks like, which means you can "do more with less". That's a slogan we had to live with internally, and I think we all understood that it meant people, as well as resources.

When The Machine Decides

Did a machine decide my fate at Microsoft? Probably. It makes sense: I've seen what Claude can do. Especially nowadays. Put in the right hands (and this is key, and I'll come to this in a second), a well-run Claude Opus 4.6 agent can actually exceed what a meatspace person can do.

I can see the decision process clearly on this:

If we use AI to come up with the headcount reduction selection process, we're sidestepping a lot of legal ramifications. A terminated employee can't come back and say "I was targeted" because a human wasn't in the loop. It was a machine, so it's much more fair... and humane.

If you've worked in a large corporation you've probably witnessed backwards logic like this. There is a strange truth to it, if you Obi-wan your perspective, but ultimately I think we, as humans, need to understand that machines are about to rock our reality. Because we're letting them. We want them to.

I've seen it. I'm doing it. In fact, I'm enabling this very thing when I share what I'm learning publicly. I'll go even farther than this...

With Great Power

I have found myself not making a video on something I've done because it will, quite literally, get someone fired, somewhere.

For instance: right now I'm running an agent "swarm" in a console window right next to me. These little guys right here:

I have them running in an orchestrated loop, using a bash script that Claude made for me:

Note: that's a shell script running, which is neat but so last week. The new agent teams stuff from Anthropic handles all of this for you through some API calls. You can orchestrate individual Claude processes to get things done even faster.

It's a pretty straightforward process:

• I use my product-designer agent to help me think through requirements, and then write them down in a PRD.
• The test-writer agent, using Sonnet 4.5, creates the tests using that PRD beforehand as a way for my
• frontend-builder and backend-builder agents to write some code. These guys are dedicated and don't do any kind of testing or review; they just write the code.
• My code-reviewer then goes off and does its thing, completely independent in terms of context. It only knows about the PRD, the tests, and the code for the task. If it doesn't like what it sees, it kicks off the build loop again.
• If the code-reviewer gives a SHIP IT response, the pm agent kicks in and documents what was done for the sprint. The git-committer does its thing at that point, and we're off to the next task.

There's a lot more that goes on here. Each step is logged, as is each decision, so when things crash (which they do) the debugging step takes 20 seconds or so. The loop is impressive, but the debugging is insane.

That, to me, is the secret to all of this: write it down. If you know what you did and know what Claude did, it's pretty darn easy to troubleshoot.

I'm having fun with all of this, so what's the problem? Well, if you can't tell, I just replaced 4-5 people with a run loop.

And I trust the code from these agents more than I would from a group of humans. There, I said it: Claude writes code better than me, and probably you, too. It can do that because I know how to make it do that. I don't generate "AI slop", I generate beautiful, well-documented, well-tested code because I've taken the time to learn how.

These agents will work all night, all day, and into the next night, the next day, over the weekend, during holidays, and the full 6-7.

Want me to show your boss how I did this?

The Wolf

There's a scene in Pulp Fiction where Harvey Keitel shows up as Winston Wolf. "I'm Winston Wolf. I solve problems." He doesn't talk for long and he doesn't negotiate. He assesses the situation, gives clear instructions, and the mess is gone. Nobody asks how.

This is where we're at with AI adoption. Your boss (or maybe you) knows that AI is here, and a transition needs to be made. Your boss might care about you, sure, but business is business. Someone, somewhere, will show up one day and crash your party. Maybe that someone will be you, maybe a colleague, or maybe even me.

I'm getting two to three emails every week asking if I'm available for consulting. They want to know about agentic run loops and how to "improve operations." I always tell them the same thing:

I can absolutely help you, but one of two things will need to happen: the rest of your org or company catches up to you, or you scale back ... somehow.

Let's be clear about this: the easiest gain is to reduce headcount. "Scaling back" is a nice euphemism, but it means you and your job are now calculations in a spreadsheet. Let's be even more clear about this: what I charge for these gigs is a rounding error in terms of your salary and benefits. It's not really a decision for those that pay you.

Detroit Knows This Story

In the early 1980s, American automakers started bolting robotic arms onto assembly lines. Welders, painters, line workers, something like 300,000 of them were gone within four years. The UAW fought it. Politicians made promises; but the jobs left anyway, not because the robots were better at everything, but because they were better at enough things, and they didn't need health insurance or bathroom breaks or a pension.

The auto industry didn't die. It just rearranged itself. The people who learned to program and maintain those robotic systems became the most valuable workers on the floor. They went from operating the machine to managing it. The ones who crossed their arms and said "this is robotic slop" got left behind. Not by malice, just by math.

We're in that moment again, except it's not welding arms on a factory floor. It's code in a run loop, and the transformation is moving a whole lot faster than it did in Michigan.

Replaced By a Loop? Or Nah?

As I write this, I can feel that some of you might have a reaction that goes like this:

Sad to see Conery join the AI grift. He's resorted to doom posting to get subs and signups. Another one bites the dust...

This is fair, but I honestly have nothing to sell you and I certainly don’t need any more work. My cohort is completely filled and my calendar is full of calls with bosses just like yours, looking to flex AI to their advantage. I do not need more work. I can barely keep track of the work I'm doing now.

Writing notes like this one takes time, and I hope you see it for what it is: me, sharing with you, what I'm seeing. Which is an opportunity for you to shift your career and become indispensible. You can learn what you need to know from free channels on YouTube, playing on your own, reading up on the docs, and having the time of your life. It truly is great fun!

Unfortunately that "great fun" part is balanced by a stark reality: you will get left behind if you ignore this stuff. If that happens, and you think "shoot why didn't anyone tell me this was happening so quickly", perhaps reflect on this note that landed in your inbox, or that you're reading online.

You're being sent a few boats and helicopter here (not from me, to be clear, but from somewhere). GET IN ONE OF THEM.

If you're an executive, lead, owner, founder, or boss of some kind and you're reading this, thinking about that email you've been meaning to send me: yes, I'll answer it, and yes, I can help you.

Yes, it's true: your company will move at a pace that you won't believe, and you'll deliver far, far faster than you ever thought possible. It's not just 10x, it's closer to 100x when you get everything dialed in, and it's a mere fraction of the cost.

I know this because I'm doing it for myself, right now, and I've done it for companies just like yours. Big ones, little ones, red ones, green ones. I use these tools every day, aside from this note, which I wrote by hand, because that's my promise, and that's what I do.

I am human, after all.

Thanks for reading, as always, and climb in that damned boat will ya!

Cheers,
Rob

I was having a fun chat with my friend Aaron Wislang on Signal today, discussing how I'm getting so much done with Claude, while at the same time feeling absolutely exhausted, mentally. It reminded me of the first time I used Google...

I was in my office on 2nd and Howard street in San Francisco, taking a break from writing a really crappy ASP classic application. One of the people in my office, John, said "you guys really need to try Google. It's so much better than Yahoo".

I remember wondering what better than Yahoo meant. Searching is searching, isn't it? You match terms, maybe do a word proximity analysis with a token count or something... eh, let's try it.

I don't remember what, exactly, I searched on. Probably my name because didn't we all? All I remember is muttering "how... the F*** did that happen? That... is magic."

That question plagued me for about an hour. Someone knew an algorithm that somehow put the exact right page in front of me, right at the top. It was pure voodoo craziness! And then, like most tech breakthroughs, it just became part of my every day, like it was always there.

I now had a super power: I could find the answer to something in seconds. That included code, which meant I could "learn" new things (I totally would never copy/paste...) and ways to ship solutions for my clients.

And I did. I moved faster. I shipped more. I was on fire with possibilities ... and then I burned out completely in 2004 and moved to Kauai, never wanting to touch a computer again.

The Overwhelm is Real

There is a price for this kind of speed. Google search and Google Reader were a deadly combination. I could read my favorite blogs and then search for what they were talking about. One post I read in 2004 (or thereabout) talked about a thing called a "Build Provider" in Visual Studio. It would fire every time a build went off, and you could bind some code to it.

I Googled for an hour, and then 3 hours later I had my first big open source project off the ground: SubSonic. It was a full data access layer that just magically appeared for you when you built your project. I never would have been able to do that 3 years prior as I would have had to spend a few hours at Barnes & Noble finding the right books to show me what I needed to know.

Google did that in 2 minutes. Claude can do this too, and it could also build the thing in the same amount of time (well, almost). That's... wild.

Over the last few months I've been building things with Claude Code at a pace that doesn't make sense to me. Full applications in a weekend. Entire agent fleets that help me manage my business while I go make coffee. An email list service (because WTF why not). I rebuilt my entire publishing pipeline, rethought my content strategy, and scaffolded a course platform, all while my actual to-do list kept growing because I kept adding to it.

That's a trap. I can do more, so why don't I? I can do 10 times what I could do before. Coding, execution, planning... and I can do it better. So why do I feel completely drained and overwhelmed?

I was trying to get to sleep last night and my mind was a shivering mess. I kept thinking: this is why you created your Obsidian daily note system with Claude. You put everything there, and forget about it. So why wasn't I forgetting about it? Why was I believing that I needed to be thinking about this stuff, remembering little details, else it wouldn't get done?

I like my work. I like building things. I like thinking about building things. I love the feeling of shipping and learning and solving people's problems. Why in the world would I want to push that out of my brain!

The Movie Got It Right

There's a reason that Everything Everywhere All at Once resonated with people so much. Evelyn Wang isn't overwhelmed because she's incompetent. She's overwhelmed because she can suddenly see every version of her life running in parallel and she has to choose which one to care about. She has choices that she needs to consider, inspiration to motivate her, losses to mourn. This is mentally taxing!

That's the most accurate depiction of working with AI tools I can come up with, and the movie's release is miraculously prescient.

You can now build the course. You can write the newsletter. You can refactor the codebase, launch the side project, redesign the landing page, finally learn Rust (OK maybe not Rust, life's too short). Actually - why learn any programming language at all? Who actually writes code any more?

Have an agent watch your agents who are watching other agents so you can have full leverage over the insanity, doing even more work, getting even more done. Or maybe playing pickleball and making your partner dinner. While coding.

Pure madness. And I love it. I think.

Just... One... Little... Hit

I have 25 years of shipping software under my belt and I was spinning in circles like when I first discovered microservices and got in yet another argument with Jimmy Bogard. The possibilities are endless... so let's try all of them.

Eventually I decided to make a rule: Do Just One Thing. Every day has one thing that matters, and everything else is bonus. Not in a productivity-guru, manifest-your-best-life kind of way. More in a "Rob, you dolt, pick one and finish it" kind of way.

I like Stephen King's take:

When asked, "How do you write?" I invariably answer, "One word at a time," and the answer is invariably dismissed. But that is all it is. It sounds too simple to be true, but consider the Great Wall of China, if you will: one stone at a time, man. That's all. One stone at a time. But I've read you can see that motherfucker from space without a telescope.

He writes a lot of books, and he's been very successful. He probably uses AI for things these days, but I highly doubt he uses it for writing. Where's the fun in that?

So that's what I did. Every morning, coffee in hand, I would sit down with my daily note and think "what's the one thing I want to do today?" and I would write it down with a little checkbox next to it.

It looks like this:

That's todays win. When I hit "Publish" in the next 30 minutes or so, I'll have won this day.

Or... will I? Because there is a LOT on my plate, and this is just the morning!

Normally I would laugh at this list and know that there's no way I could do all of it in a single day. But this isn't "normally", is it. It's a new day, people, and I know that if I just spent a little time prompting...

Ugh. I don't want to do more for the sake of checking boxes. I want to do less of the stuff I don't want to do in the first place!

The Weird Paradox

The people who are going to thrive with these tools aren't the ones who use them to do more. They're the ones who use them to do the right thing, faster, and then go outside. I think I'm getting there, but the climb is exhausting.

I built an entire agent that does nothing but ask me one question when I get distracted: "Is this higher leverage than the thing you already committed to?" Yes, I do understand that I spent time with AI to have it tell me to not use AI. Welcome... to the desert, of the real...

But it works, because the overwhelm isn't a tooling problem. It's a choices problem. And choices have been hard since long before any of us had an Claude Code sitting in our terminal.

So, What To Do Then?

If you're feeling the weight of being able to do everything, everywhere, etc., you're just adjusting to a new gravity. We went from "I can't build that, it would take a few weeks" to "I could build that on Thursday" to "one sec let me get my agents on it and I should have it ... 30 minutes" and our brains haven't caught up yet.

I can do things so quickly now that it feels like my brain literally bumps the side of my skull as the task I thought was going to take hours jolts to completion in 10 minutes.

It leaves me feeling kind of confused and empty... like... what do I do with myself now and then I need to context-shift into something else, which doesn't really need a full context shift because I don't need to think about it all that hard. Claude does. I'm still coming to grips with this: I need to let go, let Claude. That's not easy for me because I'm kind of a control freak.

Sure I can focus on just one thing, as I said above, I have to. Something that I create and take pride in. The rest is up to Claude, which I'm still getting used to.

I like things done a very particular way, and then I like to optimize that thing until it drives me crazy and I end up hating it. That's not an easy sentence to write, and it's taken me years of therapy to understand this about myself. I don't just write prompts and instructions for Claude, I write agentic symphonies because I can and then I wonder where my day went.

But ... oh... what a day it was.

Unfortunately, this is also the reason why I'm good at what I do. I have a Gordon Ramsey level of fiddly, fiery perfectionism that yields delicious results. I don't know how to move faster with this process and I suppose I really don't want to because who would?

Merciless Cutting

I need to let go of a lot of things if Claude is going to work for me. I know that, I think you're probably facing this issue too, but it's one thing to know something, another to actually get your shit together and do it.

This is my work, as summarized in financial form by Remit Sethi's book I Will Teach You To Be Rich:

Spend extravagantly on the things you love, and cut costs mercilessly on the things you don’t.

I like it. Maybe we can bend this to AI and programming:

Work extravagantly on the things you love, and prompt mercilessly on the things you don’t.

I spent a lot of hours writing this newsletter, and it's not easy thinking about what I could have gotten done in Claude time. I don't care. This is what I love, and this is what makes me happy, and I'm glad I can spend time doing this because Claude frees me up from the other things that slow me down.

What other things, you ask? Well, on today's list of Rob's Things:

• Creating a ConvertKit MCP server so I can integrate this blog with a proper newsletter service.
• Recording 3 installments of my "Big AI" project where I record myself using a swarm of agents to rebuild my site.
• Editing 3 to 5 lessons of The AI Pro, which I really need to be finished soon (I'm getting there)
• Getting my new cohort off the ground. I was amazed at the volume of responses (it's closed now), and we're getting started next week.

And there's the rub. I love working on all of these things, but I don't want to hand them completely over to Claude. Only some of the tasks, like writing code for the ConvertKit thing, compiling the lesson text and pushing it to Ghost, and so on.

There's probably more in there, and I love exploring what's possible... but I'm still learning how to let go, and it's not easy, because it always feels like cheating. Do you ever feel this way?

Maybe I need to let go of that too.

Thanks for reading this. I genuinely love hearing from people who are navigating this same moment, so if you've got a story about how AI capability is messing with your head (or making it better), hit reply. I read every single one.

And yes, as usual, I wrote this post myself. It's my guarantee.

Cheers!
Rob

I'm building an email list service because I can (think Mailchimp or ConvertKit). Old me of a year ago would never have tried such a ridiculous thing but new me? Rob in 2026? I want to see what we can get up to, and learn, by flexing my Claude Max subscription.

Even though I've been working with AI tools non-stop over the last few years, I still get up, pace the room, and talk to myself every few hours as Claude Code continues to break my brain. It just keeps getting better! When I made the switch from Sonnet 4.5 to Opus, I stared at what was happening on my screen, and flatly stated:

The singularity is here. I trust Claude to write code more than I trust myself.

Yes, I know. I truly, completely understand that I sound like a breathless AI hype boy. I like to think there's a major difference between the hype-types and me, which is that I will FAFO for a very long time before I form any kind of opinions.

And wow do I have opinions now, and I don't care how mad people get at me: the industry we have worked in and loved for so, so many years has gone and upgraded itself. AI coding skills are absolutely critical at this point.

New Industry, Who Dis?

Let me explain why I'm leaning in to this opinion as hard as I am. It's for a simple, direct reason: I am getting things done at 100 times the speed that I otherwise would. Actually, it's infinitely faster than that because I wouldn't even try doing the things I'm doing now because who in their right mind would create an email list service!?

This doesn't just apply to my little email list app. I also created a full markdown-based CMS tool that pushes my Obsidian documents into Ghost:

This is The AI Pro workshop I'm currently editing and working on, and will hopefully complete in the next two weeks. The email list application I'm writing about (Hoku), came from this workshop. I had so much fun working on it I decided to keep going.

I used to use a starter template or some kind of framework generator to get a project like this off the ground. Now, I use a skill I created for Claude called scaffold to create a Claude-powered app for me:

One of the neat things about skills is that you can add reference documents or scripts to them. You can see the skill file in the editor above, and to the right is my shell script that generates the directories and files I need.

Here are my skills for my email server project:

I created that email-marketing skill especially for this project as I'm not exactly a subject matter expert on digital marketing. But Russel Brunson is, so I made a skill out of him.

Well, sort of. I try not to write stored prompts, skills or agents any more. I have Claude do it for me:

Create a digital marketing skill that will help me design and build a world-class email marketing system. I don't want architecture, just help with features. This skill should be technical, not marketing - as if a digital marketer like Russel Brunson learned to code and is now helping people build out systems like ConvertKit. 

I don't mind prompting, but I've learned that it's much easier to let the tools do the heavy lifting for you. When I say "prompting", by the way, I mean the full-tilt, "You are X, I need Y, create Z for me" kind of structured prompt. I still have to tell Claude what to do, but I let it fill in the details for me.

Have Claude Do It

Every skill you see above is used by one or more agents in my application. The difference between the two is kind of weird at the moment, especially with the different toolsets available (Claude, Copilot, Cursor, etc).

With Claude Code, it's pretty straightforward: agents execute a well-defined task on your behalf. They do this using skills, or instructions that you write when defining the agent.

Once again, let Claude create the agent for you by heading into /agents and Create New Agent:

This agent is an expert TypeScript coder, but is willing to bend the rules in order to deliver working code. Type safety is good, shipping is better. They are a behavior-driven design fan, and like to work against a solid set of specifications for everything they create. They are a former Ruby programmer and love clarity, precision, and readabilty. They use comments to convey the "Why", not the "How" or "What". They don't debate semicolons, don't put oatmilk in their cappuccino, and have a fun sense of humor.

I have 4 agents helping me out, just like this one:

Arranging all of this stuff feels like the rise of DevOps so many years ago. What used to be a set of shell scripts, FTP, and rsync turned into an entire industry powered by YAML in a few short years.

This feels the same way. We used to write prompts, now we arrange skills and agents and press play.

The Future Is Here

I try not to write full prompts, if I can get away with it. What I like to do instead is use my sprint-pm agent to come with a sprint plan based on my architecture document:

I created that architecture document during a 90 minute Q&A session with Claude, which was using my email-marketing skill together with my bdd-typescript-developer agent. Once I was happy with the overall direction, I saved our conversation to ARCHITECTURE.md, which is what you see above.

My sprint-pm agent created my first sprint, complete with goals and tasks, which in then put into the docs/sprints/sprint-one-poc.md document. I reviewed that document, edited it a bit, and then handed it to my ddd-typescript-developer agent, which started creating specs and writing code...

This is the future of coding. It's taking shape all around us, as programmers like you and me have their "OH WOW" moments, feeling the world shift a little under their feet.

As William Gibson famously said:

The future is already here - it's just not evenly distributed

Am I Still Relevant?

Of course I am. I have 25+ years of experience that I'm able to flex in order to build these skills and agents in the first place. They don't have that, even with the best instructions written in gold fairy dust.

I know the questions to ask and I understand how to build complex software using rigor and patience. Claude is just a computer following instructions.

Yes, Claude can write outstanding code, but it can only do so because I tell it how to do that. I can have Claude structure a killer set of tests, write a beautiful README, and draft up a concise, clear commit message for Git too - but only because I have learned how to do these things and am sharing that with Claude.

Claude is just a series of tubes and wires, nothing more.

This, to me, is the most pressing need for developers today: learning how to flex their application building skills with these amazing AI tools. Not to replace you, but to carry out your orders, improving your efficiency.

Of course we're still relevant! As Willie Wonka says (actually he was quoting Arthur O'Shaughnessy):

We are the music makers
And we are the dreamers of dreams
Wandering by lone sea-breakers
And sitting by desolate streams
World-losers and world-forsakers
On whom the pale moon gleams
Yet we are the movers and shakers
Of the world for ever, it seems

I can't emphasize this enough: these tools only do what you tell them to do, because they can only know what they have learned from us. They don't have inspiration or insight. They can't make that amazing leap or write a sonnet in their sleep.

We do those things, and we always will. We just have to be able to make music with these AI tools and you can only do this by actually doing it, not watching videos, listening to talking heads on podcasts, or pondering it on your ride home.

You have to practice and be patient. You have to use rigor, and you have to be dedicated. You can't do any of this, however, until you make the move. So many people are in a "wait and see" mode right now, and that's going to cost them. The early adopters in this industry are pouring nitrous on their career, going full boost-n-juice, shipping like freaks and saving their companies millions.

Wait and see isn't an option any more.

Join Me

This whole AI freak show is moving at light speed. A few months ago I was pretty sure we'd hit the zenith of what AI tools could do, and then Claude Code announced skills and, oh yeah, Claude Cowork. I lost an entire weekend with that as I built out my own personal assistant that time blocks my week, structures my tasks, and organizes my notes. It even triages my email...

Anyway: I'm putting together a program for people who want to take the big step and move quickly into this world. The job landscape is changing quickly, and AI skills are going to be a must-have for anyone looking to not retire over the coming year.

Here's a bit more, if you're interested:

This will be a 4 week gig where we:

• Spend 90 minutes, twice a week, meeting as a group (I'm thinking 15 to 20 people max).
• Full email support from me.
• One 60-minute "office hours" session, where you bring whatever code you're working on and feel like sharing, and we focus on how to flex Claude the best way possible.
• Tasks, assignments, and a commitment from me that your career will be transformed.
• A Team Starter Kit you can use on your next project. This includes some of the agents and skills discussed here, plus quite a few more. Use them as examples, or just pop them in when you need them.
• My scaffold template, which will create a site for you that's Claude Code ready.
• A Quickstart "playbook" for your first week on your own. Reference materials on prompting, metaprompting, what files go where, etc.
• A full yearly membership to my site, bigmachine.io, and all the videos and tutorials I create.

I want to make this worth your time in every way, with the ultimate goal of transforming your career and life in a positive way.

I've done over 50 training sessions like this, but they've been for big companies, not a small group of enthusiasts who are looking to make a change right now. If that's you, I would love to have you join me.

I have invited a few folks already, and I need to keep this group smaller - around 20 people or so. I also need to be selective here because I want to be sure it's a good fit for you. If you're interested, please answer a few questions and I'll get back to you as soon as I can.

Application for The Pivot

Set yourself up for the Big Transition

Google Docs

Thanks again for reading and, as always, I wrote all of this myself without the help of AI. I like writing, it makes me happy.

Cheers!
Rob

I was reading LinkedIn over the weekend and saw a fascinating post from Jason Alexander:

One group is still debating whether AI coding tools are “cheating” or will “make developers lazy.” They’re sitting on the sidelines, arms crossed, waiting for the hype to die down.

The other group shipped three features last week.

I think it's worse than that. I think there are full groups of programmers who don't care (and never will) about what language they're writing in, what patterns are being used, or whether their code is considered "crap" by more experienced engineers.

It's always been this way, with one key difference: AI helps them create better code than they might have otherwise, and it helps them create it faster. These people are completely focused on shipping, because that's what actually pays the money. Well-written code costs money because it takes time and time, as we know, equals money.

The counter argument to this goes something like this:

Yes, but, shipping crappy code means it needs to be fixed at some point, which costs money. Often meaning costing much more than the initial effort!

This is true, and has always been true. One thing that is often overlooked, however, is that there is actually a company in the first place, which probably wouldn't exist at all unless they went the "ship crap, fix later" route. This fact also creates a great job market for the more experienced coders to come in and fix things!

Which is kind of cool, if you know what you're doing.

The Vibe Janitor

Yep, it's a real thing, with a better title than "Vibe Janitor" I suppose:

I think this could be a very well-paying job, because it's the natural progression of a job that's existed forever: the senior developer.

I have plenty of friends who make a wonderful living by cleaning up enterprise coding projects. I did this for a while, and it was kind of fun, and you end up with some interesting stories.

Such as the time I refactored a 3000 line stored procedure that parsed XML manually. In another, I removed 149 IRepository<T> implementations and plugged in Entity Framework. It's interesting work and pays well - and will continue to pay well.

If, as I said above, you know what you're doing.

If you're being called to come in and fix a dumpster fire vibed out in a week which is also generating $50K/month - they're not going to commit to a 4 month rewrite. You'll soak up their entire budget!

If, however, you can flex your experience and "low-key vibe" a solid replacement? You're gold. That, friends, will be an extremely valuable job in the very near future.

The AI Pro

There's a solid market for these people moving forward. People who have:

• 10+ years of software experience
• A complete understanding of AI tooling
• The ability to bend these AI tools to your will as a senior programmer in order to produce solid, scalable code
• The knowledge and understanding of why documentation is critical, and how to have it produced for you by an LLM
• A wide range of AI skills, including how to create team standards, dedicated agents, dedicated skills, and stored prompts

In short: not only someone who can fix the project, but also "right the AI ship" using best practices learned over the years.

These skills will become mandatory for every person who considers themselves a "software craftsman". I also think that providing these skills to others will be a fun, fascinating endeavor... one that I'm about to embark on.

I've spent the last few years at Microsoft training very large internal engineering teams on what's new with AI, and how to use it. I've led workshops and training to many other companies since leaving Microsoft, and I think the time is right to create a new workshop that focuses on the "software craftsperson", and how they can adopt, and thrive, with AI tools.

To that end, I've put together a workshop which I'm hoping to ship in the coming weeks. It's called "The AI Pro", and I'm aiming it at experienced programmers who want to help transition their team to using AI.

The goal is to show you the emerging patterns when it comes to using AI, and the tools you can flex to deliver value at ridiculous speed. Topics will include:

• Metaprompting. How to stop wondering what prompt to write and, instead, having one written for you
• Tooling. Each coding tool has its way of doing things, and we'll focus on Copilot together with Claude Code to see how, and why, you can abstract your coding process using the built-in tools
• Customization and Abstraction. We now have agents, instructions, skills and prompts. What goes where, and how do we share all this with the team? Or should we!
• Thinking in documents. Prompting is fun, but a well-written plan with receipts is much better, and can save your job.
• Using leverage to save tokens. Rather than ask Claude to do a thing for you, have it write a reusable script or tool.

There's a lot to this workshop and I pushed the initial preview last Friday. The final form might change, but if you'd like to take a look at and see the current structure, it's right here.

I was thinking I would offer this as a standalone workshop, but I'm beginning to rethink that. It's much, much easier (and more cost-effective for customers) to go the membership route. I'm open to feedback on this, so hit reply if you have any!

Oh, also, I'm offering a heavily discounted membership offer for the next week or so to everyone on the mailing list. I'll be upping the membership to account for the new workshop (rather than sell it individually), so I wanted to offer something special to existing folks. Also, if you're an existing member, don't worry you're locked in to whatever rate you have now.

Where are you on all of this AI churn? All in? On the fence? Or are you wishing it would all go away? I think I've been all three of these at some point, but it honestly doesn't matter what I think as it's going to happen anyway, and I think I'll do what I've always done: adapt and look for the silver lining.

Thanks for reading!
Rob

Feels like everyone else got a head start on this AI thing?

That's not your imagination, but it's also not the whole story. AI tooling is genuinely unlike anything we've worked with before. There's no manual, no certification, no clear path from beginner to proficient. The people who seem ahead of you just started experimenting earlier.

I can show you what they learned.

This Is Infrastructure Now

I've been playing with Claude Code and Copilot for thousands of hours at this point, and I keep coming back to the same realization: the people getting real results aren't better at prompting. They're better at tooling. They've set up their environment so the AI already knows what they need before they type a single character. They've created reusable systems instead of one-off conversations.

Once you see it, you get it. AI isn't a chat window you talk to. It's infrastructure you build on top of.

I've Made Every Mistake

I've screwed up plenty of times. Eight attempts to refactor an Angular app. Eight. I almost shipped buggy code because of a silent SQLite connection error the AI didn't catch. I've lost entire weekends on conversations that went nowhere, watching tokens burn while Claude hallucinated file paths that didn't exist.

But I've also built a PDF compiler that saves me hours every week. I've created custom agents that handle repetitive tasks while I focus on actual work. I've got a system now where my AI tools know my codebase, my preferences, and my patterns before I type anything.

I have custom agents that help me plan my day and my week, and even recommend places to take my lady friend. No, this isn't Openclaw either! I built it because I know how to.

I live for this kind of thing.

The Shift That Made It Click

Small steps! I started to use tightly controlled instructions and skills, together with plan documents and session recaps. This is when things opened for me and I began to see that we're entering a very interesting new period in our careers, and also our lives.

There is a very natural (and understandable) fear of hallucinations and "crap code". There are also groups of people, like me, dedicated to finding patterns to reduce that crap code. It's what the Agile founders were trying to do decades ago, by refining the process, not the tools. It's the same for AI.

What You Will Learn

By the end of this course, you will learn tactical agentic programming, which means that you will learn how to:

• Stop writing prompts directly, making the LLM do it for you.
• Building out a plan with a solid question and answer session, letting your LLM plan for you.
• Create the skills and agents you'll need to execute the plan.
• Think in documents, using planning and recap documents to handcuff your LLM to build exactly what you need while documenting the how and why.
• Understand the billing process, what a token is, and how to make your time with the LLM more cost-effective. Basic "token economics".
  

Come Build With Me

This course is part of my Big Machine subscription. You get this plus everything else on the site for one price. I've been doing online education since 2009 and I've learned something: the best marketing is helping people get results. If this makes you better at AI tooling, you'll tell someone. That's worth more than squeezing an extra $50 out of you.

I can't promise this will 10x your productivity. That depends on you. What I can promise: if you work through this material and actually implement the tooling, you'll stop thinking of AI as something you "use" and start thinking of it as something you've configured.

The full course outline is below. See what we'll cover, and if it's a fit, I'll see you inside.

I'm wrapping up my next workshop which I'm calling The AI Pro that gets into the more "advanced" uses of AI in everyday work. Things like:

• Metaprompting (having Claude write your prompts for you).
• Discovery (Q&A sessions to find out what you don't know).
• Planning and Recap documents so you can "keep the receipts" for your AI use.
• Advanced tooling. Things like custom agents, path-based instructions, stored prompts and Claude skills as well as how they all work together.

Creating workshops like this is extremely fun, and it's why I do what I do. It's a process of learning and discovery, as well as sharing some of the skills I've picked up over the years. The Plan and Recap documents, for example, make working with AI tools so much simpler!

I should be done in the next week or two, and I decided that I would extend the holiday discount another week for those who haven't signed up yet. It's a pretty good deal, as it will be $50 or so less than the price of this workshop alone.

Anyway - as much fun as I'm having, I do have more sober moments, however, when I realize just how much AI can do for you when your system is dialed in. When your instructions, custom agents, and stored prompts are tuned up proper... it's kind of unnerving to see how productive you can be. More than unnerving, actually, it's almost worrisome.

What role do I play in all of this?

I was thinking about this today and thought I would share some of my thoughts with you.

Any Tool, In the Wrong Hands

I was working at a clownshow startup on contract back in August of this year (2025), and as part of the onboarding process I had to learn their "AI policy". It was straightforward (paraphrased):

We use AI and we expect you to do so as well. We recognize the efficiency gains using AI, but we also recognize the risks if AI does too much. To that end: you are responsible for everything AI creates on your behalf. "It's AI's fault" is never an excuse.

In short: use AI, but don't tell us you did. This split-brained approach to using AI is common for programmers, and the default for their managers.

My contract with the clownshow startup ended because of this problem. I was given a task that AI is perfect for, so I used it (I'm keeping the details to myself on this) and made sure I proofed what was created. As expected, I found a few issues and fixed them, and I also added content that I felt was missing.

The next day I was confronted in a meeting:

Them: Did you use AI to create this?
Me: Of course. It's pretty mundane material, why wouldn't I? Claude will do a better job of it anyway. I was careful to review it-
Them: Well I could tell that it's generated and your review skills need some work. This middle section is clearly Claude's work and incorrect. This is why we have an AI policy, Rob, because we can't let things like this slip through.
Me: Ironically, that's the part I wrote myself and researched for 3 hours. It is, in fact, accurate as it came right from the source and shows work done recently which-
Them: Oh. Well it looks generated and that's all it takes, you know. You can see why I thought it was AI and if I thought it was AI...
Me: ...
Them: I'll fix this up so it reads better.
Me: Do what you need to do I guess. I wrote it 100% by hand...

The contract ended, mercifully, 4 days after this meeting. I remember asking them why they used AI at all if they were so afraid of it (because of course I did), and received a blank stare in return.

People are weird.

I Love It. I Hate It. Help.

I am sure I am not alone in this experience. Our managers, colleagues, and the industry in general are working with a mind-boggling tool that no one asked for. Managers and executives love the idea because it increases efficiency. They also hate the idea because it increases risk due to copyright issues, crappy code, and overall misuse.

I love using tools like Claude because I can pump out boilerplate code just the way I want. I can also explore different ideas and come up with a development plan that helps me write code faster and test things in a more efficient way. Or, I should say, I think about the tests I want written and let Claude do the rest.

That's OK, isn't it?

This is where I struggle. I love the process of getting inspired, wondering if something will work, and then giving it a try. There is no better feeling than seeing your idea come to life and actually working! I remember feeling this with SubSonic, an open source data access tool I created back in 2004. I had an idea at 7PM as I was reading my kids a bedtime story, and by 11Pm I had the prototype working, giggling to myself for hours.

What a rush! It's why I do what I do. Claude, however, could have put that together in a matter of minutes. This is OK too, but would it feel the same then?

Imagine if you could have Harry Potter or Hermione Granger powers for a day and you could apparate (teleport) anywhere you choose, right now. Sounds fun, doesn't it? Where would you go? What would you do?

Here's a better question: would it be the same if you didn't make the journey to get there? As Steve Jobs said (paraphrasing Taoist philosophy):

The journey is the reward.

The process of finding out is the fun part. It's what you learn along the way through discovery and overcoming obstacles both external (code, logic) and internal (feeling like an imposter, you're not smart enough, etc.).

That said, if I never have to fly in an airplane again I would probably be happy, and sitting on a beach in Belize for lunch sounds even better...

Not a Zero Sum Game

I think there's a happy middle ground here. If I had Harry's powers for a day, I might skip a few parts of my journey that I had done before. I might skip that connecting flight to SFO, or the Uber ride to the airport, and anything that involved sitting for hours in a cramped seat next to a smelly person. These are things I've done hundreds of times and doing them again doesn't add to the journey.

In the same way, writing Yet Another Drizzle Schema or create table users(... statement isn't something that fires me up. Documenting a class, writing a ToString() override or an optional constructor method that takes an object for property settings... yeah I've done that far too many times. In fact, I have snippets to get around these things.

We tend to automate the boring or simpler things, which I think is OK.

This made me think about the automotive industry, and how the use of robotics disrupted just about everything in the 1970s and 80s. There are have been a number of economic studies done on this shift, and they all tend to agree with this MIT study :

Improvements in technology adversely affect wages and employment through the displacement effect, in which robots or other automation complete tasks formerly done by workers. Technology also has more positive productivity effects by making tasks easier to complete or creating new jobs and tasks for workers. The researchers said automation technologies always create both displacement and productivity effects, but robots create a stronger displacement effect. 

So, in short, jobs are lost. They are also created because you have to take care of the robots and support the tasks they do.

Not all jobs are equal, however. Managers that can increase margins will do so, especially if they can trim their staff down. This, typically, means the more "disposable" workforce:

...the automotive industry has adopted robots more than other sectors, and workers who are lower and middle income, perform manual labor, and live in the Rust Belt and Texas are among those most likely to have their work affected by robots.

It would be silly to think AI won't cost jobs. You could argue that the rise of AI in the tech industry is different than that of robotics in the automotive industry, but that would be splitting hairs at best. Automation will replace programmers and I don't think there's a way around that. Automation will also demand programmers so that it works optimally, so I suppose the lesson here is straightforward: adapt, and learn you some AI.

Same As It Ever Was

I have lived through a good amount of disruption in my life:

• The web changed business as we know it.
• Google, together with the rise of blogs and dedicated programming sites like StackOverflow, increased developer efficiency dramatically.
• Twitter and social media expanded your professional network.
• Smart phones let us carry work with us, everywhere.

I liked the 1990s a lot, but I have no idea how I would function if I somehow traveled back in time to 1992. If you were going to be late and needed to let someone know, you pulled over and used a payphone. We carried a thick book of maps under our car seats (Thomas Guides) so we knew where we were going. If we were bored, we were just... bored. Going for walks, shooting hoops, calling a friend or playing a video game on our Sega Genesis.

That is one hell of a shift in 30 years, and it's going to keep shifting. AI will change things, of course, but we'll adapt because that's what humans do. This is why I like surfing so much: it's a practice of adapting to the environment around you in a constant, ever-changing way. No wave is ever the same, and your experience at that moment will also never be the same. The light of the sun, the sky, the wind, the smell of the air and ocean... it's a singular event never to be repeated.

The only thing you can do is to just ride along and enjoy the constant change. Try and fight it, and you fall off. AI is going to change our work, some for the better, some for the worse. We can fight it all we like, but it won't change a thing. Or we can go with it and adapt, and ideally save space for ourselves in this new, wild industry that we work in every day.

Thanks for reading, as always! Leave a comment on the post or hit reply...

Rob

TL;DR - yes, I'm doing a Black Friday thing at 50% off a subscription to this new site, with some new content. I also have a gift option with the same discount. If you're curious about my roadmap, it's below.

The holiday season is a very interesting time, especially when you're not married and your family has grown and moved on into their own lives. In some ways it's kind of nice as you get to "do something different", such as take yourself on a nice trip, or go to a friend's house instead of flying/driving to be with family.

That's what I did every year for both Thanksgiving and Christmas, even when I was married. We would leave Hawaii and fly out to California or Oregon, and it was always a fun change of pace. The cold of winter, the smell of pine trees or, if we were lucky, a bit of snow.

This year is a first for me: I'm doing none of those things. My kids have decided to stay where they are and be with friends, and given that my mom passed in the summer, I figured I would just stay where I am too. Why not?

I won't be alone, which would be fine if it was the case, as I've been invited to share the day with my girlfriend, who's amazing in every way. But I won't lie: it's a new thing for me, and I like new things.

Let The Past Go

I love the line from Kylo Ren in The Last Jedi:

Let the past die. Kill it if you have to. It's the only way to become what you were meant to be...

I remember when I saw the movie in the theater, thinking that it was a bit out of place for a pop sci-fi flick. I mean, let's face it, the entire late Star Wars series was ... not exactly fine cinema. The Last Jedi was so derivative and trite... but I would never walk out. It's Star Wars, after all.

Anyway: Kylo's notion of letting the past die is also balanced by "letting the future happen" in its own time. This aligns perfectly with a Zen quote I love (at least I think it's a Zen quote):

The past is depression. The future anxiety. Now is truth and happiness.

You might be wondering what all of this has to do with Black Friday? Well let me tell you...

Go Ahead, You Deserve It

Given that I'm not traveling anywhere this holiday season, I decided I was going to treat myself to a few things. Not big things, mind you, just things I've had on my Amazon wish list for a while, and also a piece of nice art that I have been wanting for months but thought it was a bit out of reach.

Things that don't fit the budget, in other words. I know that someday I could afford them, but today is right now so ... what happens if I just... do it? Treat myself like I would a loved one during the holidays?

So I did. I also subscribed to a few services to keep my mind sharp. I like the NY Times Crossword, so I subbed to the games app. I'm also going to (finally) subscribe to MasterClass and, I think, give Jeff Delaney my long-deserved business over at Fireship.

Which got me thinking...

An Option For You

I just condensed all of my content (books, videos, AI stuff) into this site (bigmachine.io) and have opened up annual memberships and yes, that link is a 50% off Black Friday deal. Creating content has been a bit of a struggle over the years given my job at Microsoft, but now that I'm independent again, I figure that I might as well do my best to stay that way.

To be specific, the annual membership includes:

• All of my books (Imposter's Handbook, Imposter's Roadmap, A Curious Moon) which, right there, covers the cost.
• All of my courses (8 of them currently), including the latest AI workshop available only at thenext.dev.
• All of the premium videos from thenext.dev, which show you how to create MCP servers, develop your own tutorials, and more.

In short, there is a lot of stuff here. If I was to put a price tag on these materials, it would approach $1K at least. But it's yours for $99 during Black Friday.

You might be wondering what I have planned, as well? Well here you go:

• I'm actively recording my next AI workshop, focused on advanced uses. Things like having Claude create prompts for you, and how to orchestrate things so you end up prompting very little - sometimes not at all - with incredible results.
• I finished recording a series of videos on GitHub, focused on self-taught people who want to flex GitHub as they move up the ladder at work, into a senior role. From solid profiles to management tactics, devops, and more - this will be a fun one.
• A practical guide for productivity and improvement to get through Imposter Syndrome. A lot of people have asked for this, and I'm still framing it, but I think I have a good outline coming together.
• A complete revamp of the Imposter videos, which I'm calling The Missing CS Degree. I figure with AI coming into the picture more and more, learning Computer Science is getting interesting. This will likely be a series of premium videos until I can pull together into a course.

That's the plan, for now. Your input, as always, will be extremely helpful with this roadmap!

An Option As a Gift

I've also spent the last few days wiring up a gift option. If you wanted to give someone the gift of learning (especially if they're a self-taught programmer) they might like this. A lot. Be sure the coupon 99IUHSKL is applied, if not, for the Black Friday discount.

If you click on the link above, you'll see a little video explaining how it all works, which is, in short:

• You add your friend's name and email at checkout.
• A web hook fires that adds their name and email to this site, which is powered by Ghost.
• A complementary subscription is created for them, for one year. None of your payment details are saved and they can renew, if they want, at year end (not free).
• You let them know whenever you like, and I even have fun graphics you can use!

That's it.

As Always: Thank You!

I'm very grateful to be able to share what I learn with all of you. I think it's the best job imaginable, and I would love to make it my full time thing, once again.

I hope your holidays are wonderful, even if you're on your own. Sometimes it's nice to treat yourself as your own best friend, making yourself a nice dinner, and buying something nice, even if it's just a nice potted plant.

Wishing you the best!

Rob
Yes, I wrote every word myself. I never use AI to produce content.

TL;DR: Full Business Pivot

My focus is generating content for self-taught developers, and I'm leaning fully into it. This includes creating more content on AI, CS Theory, Career Advancement, and more.

To that end, I'm moving back to Ghost and:

• Embracing subscriptions, once again while also allowing for one-off purchases.
• If you buy a course or book from me (non-subscription), you will be able to download it only, not stream it.
• I'm going to create smaller videos, 60-90 minutes, for lower prices rather than Big Courses for More Money.
• I'm actively creating workshops where you can work directly with me, either as a team or an individual.

I have a lot of experience and I've done a lot of things in my career, and I want to share that knowledge. The industry is changing, indeed, but our need to learn will never go away.

I want to help with that.

What Does This Mean?

If you're an existing customer and you would come here to stream your stuff, no worries! You can head over to the legacy site, which is right here, or you can download your course and run it locally.

If you're curious, "run it locally" means double-clicking on the index.html file:

You can, of course, just watch the videos directly from disk. Either way, here's what your site will look like:

Your Downloads and Videos

If you're looking for your downloads, you can head over to the legacy downloads page and I'll send along an email with links to you. These links will include the course files as well.

Due to the size of the videos, the course files can be quite large. If they're too big to download, worry not, you can still stream at the legacy site. Just log in as usual and off you go.

Why Do You Change Things?

I'm always trying to adapt and tweak what I do. Right now, my focus is on ease of content delivery. AI is really heating how just how fast we can build things, and I'm leaning in as much as I can. The old site (at app.bigmachine.io) was built almost 100% with Claude Code, as I used it to convert a Ruby on Rails app to Nuxt.

That was fun, but even that didn't allow me the speed of something like Ghost. I also have an email list built in here, which means I can reduce cost and integration complexity with my old service, Kit (aka "Convert Kit"). I love them, but I just don't need that level of automation for what I do.

Will I change this site again? I don't know - probably. That's who I am and what I do. The important thing is that I never leave anyone behind. If you had a subscription or bought something from me in the past, I will always make sure you're supported.

Cheers,

Rob

In this introductory workshop, you'll learn the essentials for working with AI coding tools on the daily. There's no hype here, no sensational claims. AI is a tool we all need to learn, for better or worse.

That's what this workshop is all about: time, and how you can maximize it. You'll do that by learning:

• The simple wins. Where AI tools can greatly improve your efficiency by generating commit messages, boilerplate code, and simple documents you'll need for your project (README, LICENSE, .editorconfig, .gitignore, etc.)
• The big wins. Convert SQL from one platform to another, enforce your style guides, and think through problems without any code generation at all.
• Avoiding problems. Everyone is worried about unmaintainable "crap code", as they should be. You'll learn how to avoid this problem by using clear instructions and actual templates, forcing the LLM to do what you want, not the other way around.

AI is capable of so much, as long as we approach and use it like it should be used. It's the Kubernetes Problem: using a tool in wild crazy ways will give you wild crazy results.

Something I'm trying to remove from my life is watching other people give their hot takes on something and substituting their experience instead of FAFO for myself. It's entirely understandable why people do this: there's a lot to know in our industry! Keeping up with everything is nearly impossible.

That said, I think there's a threshold where it's our actual duty to try something for ourselves to see what we think about it, rather than repeating some influencer on social. Given that I'm addicted to trying new things all the time, that threshold is pretty low. My rule is simple: if I write about it anywhere (blog, newsletter, social) I will have tried it for myself.

When do you decide to actually try something for yourself before forming your final opinion? Curious to know and, as always, you can hit reply and know I'll read it.

I put an Agent in your Agent

I gave two in-person workshops at NDC Porto in October and had an absolute blast. Porto is a brilliant city that reminded me of the Elden Ring expansion, Shadow of the Erdtree, because of the verticality of the place. 

The city is situated along the Douro and is built into the steep hillsides along both shores. There are also these multi-layer bridges that span the river, with roadways, train tracks, and multiple walkways. There's even a tram connecting the "upper levels" of the city to the lower by the water. It really does feel like a video game!

Anyway - the workshops were aimed at the growing group of .NET developers who are using VS Code because of the Copilot integration. Many .NETters are making the switch to VS Code for a variety of reasons (which I won't get in to), so it was extremely fun to flex my C# muscles again and see what was possible.

One of the people their asked about MCP (Model Context Protocol) and why it was such a Big Deal and I could give a summary answer, but since I had never made one, I didn't think I should go to deeply with my thoughts. Which is when the idea hit me: "I think we should build one with Claude in the workshop tomorrow; what do you think?"

This is what I love about workshops: learning together as a group, in real time!

Asking Cassini about Enceladus

Long story short: I created an MCP server using nuts and bolts ASP.NET and exposed the Cassini mission plan data to Claude Sonnet 4.5. The mission plan is roughly 65,000 entries, each representing a single study that Cassini carried out. Things like "Dust analysis of Saturn's E-ring" or "1200km flyby of Enceladus using the magnetometer." Fun stuff.

I loaded the data into SQLite, didn't use any kind of MCP framework, and let Claude "vibe out" the entire server. I fired it up and then asked "how many flybys of Enceladus did Cassini perform?"

I honestly have no idea how MCP works for a given LLM tool, but here's what I saw:

• The registered MCP server offered a manifest describing what it knows, and the tooling can decide to use that server based on the prompt coming in. Since I asked about a Saturn moon, the Cassini MCP server was used.
• Claude Code (the tooling) queried to the server to see what "resources" (data objects) and "tools" (functions) were available to answer the question.
• The final step was to execute a "tool" (function) to get the data it needed to answer the prompt.

This all happened in a fairly short amount of time using a JSON post over HTTP. Once Claude Sonnet had the results of the MCP query, it could then answer my question, which it did in stunning fashion.

It was so much fun that I decided to make a video about it, which you can watch right here. That's my AI newsletter site where I pop articles and videos from time to time and would love to send you some too!

I had loads of fun putting this together and can see how MCP servers will become indispensable moving forward. Your opinion on AI, while valid, should be set aside briefly because this is going to happen whether we like it or not. I think it's best to know what's going on either way...

So watch my video and, when you're done, go make your own and see what you think!

Thanks again for reading. I always love reading your replies and yes, I read every single one of them. I also wrote every single word of this post myself!

I've been meaning to create an MCP server or two just to see what it's all about and I had that chance a few weeks back when I was in Porto at the NDC conference. MCP (Model Context Protocol) is all the rage so I figured it would be fun to see what it's all about.

I didn't know anything about it, so I dug in live with the rest of the group to see how hard it would be to create one using ASP.NET (yes, I can still C#). Turns out it wasn't hard at all and, more than that, it was fun as hell.

In this video I use Node.js to create an MCP server that exposes the Cassini-Huygens mission plan, which is data I used in both A Curious Moon and Postgres Fundamentals.

I think it turned out pretty well! Hope you enjoy the video...

You can find the source code here (to get started):

https://github.com/robconery/cassini-mcp-node

I was telling a good friend about my new coaching/workshop thing I'm trying to get off the ground (ridding yourself of Imposter Syndrome) and they asked me a great question (paraphrased):

This sounds like a slam dunk for people dealing with it, but are you offering a practical solution with steps or just inspirational stuff? How can you guarantee such a thing?

This was in response to my offer:

I want to help you break through your personal barriers and transform into the professional you want to be. Give me 6 weeks and you'll be free.

This is the kind of question I would ask too. Great, sounds good, but what will I actually do. How will this happen in 6 weeks?

The answer is straightforward: it will happen because YOU want it to. You just need to realize that fact and off you go.

That said, overcoming Imposter Syndrome isn't a "one and done" type of thing. It's a way of thinking that you eradicate over time, intentionally. It takes effort to change how your brain processes things, and going it alone can be quite the effort.

So, to that end: below is the answer to my friend's question. The tangible steps you can take to alter your thinking. If you're interested in working directly with me on any of this, let me know by hitting reply.

Step 1: Identification

This part sounds simple, but when you're deep in The Suck, it can be hard to take a step back and ponder how you're feeling.

As with most "Step 1s", this is the most important one: knowing when you're feeling like an Imposter. Unless you're really into mindfulness, observing how you're thinking and feeling isn't something that you do on a regular basis.

That's where having a journal comes in. If you and I were working together, this would be the very first thing I would have you do. Apple's Journal app is great for this, as is Day One, Apple Notes, One Note, or Obsidian (my favorite).

Every day, open a journal, and answer this simple question:

How do I feel about the work I did today?

Let your thoughts out as honestly as you can without worrying about someone else reading it. When you're done, read it back to yourself.

A centered person would identify the wins and challenges in their day and frame them as such. The imposters out there would focus on the negative parts and blame themselves. The Dunning-Kruger crowd would blame other people for any failures in the day.

Either way: knowing where you're at is half the battle. Now you just need to show up.

Step 2: Recognition

Through journaling you find the situations that set you off. The more you write honestly and openly, the more you see the patterns that your thinking mind simply can't see.

After a week of journaling, add a special note to yourself, telling yourself the patterns you see without judgement. That last bit is hard to do because we really enjoy beating ourselves up when we get a chance, but that's not the point here. What you're trying to do is help a good friend through a hard time (yourself), so being kind and supportive really is the key.

Here's an example:

You tend to say very little during the standup and invariably apologize for something that wasn't in your control. When asked a direct question you look at your shoes or something on the floor. Nerves clamp your throat and your responses come in short bursts with a lot of "ummmms" and stutters. You feel like everyone is looking at you, wondering what your problem is.

This is going to be very difficult to write clearly without judgement, yet it's incredibly important. You have to see yourself clearly in order to understand something critical: you're being toxic.

The Toxic Squeeze

Imposter Syndrome builds upon itself. It's an inward pull of group energy, where your outward appearance and reaction naturally pull the sympathy of others. You've been around these people before - the self-doubters and "I really suck" crowd - so you know what it's like. 

You want to help them and offer support. You want to do this because listening to someone who has a 6-figure job complain about being worthless is difficult, at best, and if you can somehow cheer them up, your time with them won't be completely one-sided. Essentially, you're kind to them so they stop talking about themselves constantly.

This is what people are seeing in you when you implode and share that you don't feel you belong to the group, or that you don't know enough. When you tell others you wish you were as smart as they are. What they really want is for you to contribute to the group, not suck the life out of it.

Unfortunately, Imposter Syndrome gets worse when you start to see how toxic you're being. 

Unless you stop it cold.

Step 3: Deploy The Love Cannon

I'm really into visualization because I find that if I give a thought or emotion shape, I can learn a lot from it. I can also act upon it in some constructive way.

Through journaling and recognition, you can begin to see when Imposter Syndrome is starting to take over your brain in a group setting. As you feel it coming on, start your visualization and go to work. For me, this is a cannon that shoots red hearts at the dark shapes in my mind.

Those red hearts are things that I'm grateful for. Extremely simple things to, such as:

• I have all my fingers and toes.
• The smile on my girlfriend's face when she sees me.
• The smell of coffee in the morning (and that I can smell!).
• The wonderful dinner I had the other night/week/month.
• The last FaceTime call I had with one of my kids.
• The fact that I can type > 100 wpm.

This is the most important part of this process: you're not trying to fight Imposter Syndrome, you're trying to let it go and let the love flow.

Have you ever noticed how one person can change a group dynamic by showing up with a smile or cupcakes? Maybe they take a second to talk about how wonderful the weather is, or share a story about an amazing meal they had the other night.

This is love, flowing out of them and into the group. This is where you want to be, and really the only secret here is to grab hold of the simplest thing and focus on it, letting the feeling well up inside you, replacing the toxic pull of Imposter nonsense.

Step 4: Allowing Yourself To Find Out

If you and I were to work together, we would be going over your journal (what you chose to share, of course) and eventually we would get to a point where gratitude begins working and you feel yourself growing into the person you have always been.

It sounds great, but it can be disorienting. The toxic pull of Imposter Syndrome can be gratifying in a really crappy way. Simply put: attention from others is what we crave, even if it comes from our own drama. A toddler pretending to be hurt or otherwise faking tears is the exact same process as what you're doing in a group setting when you implode.

It's hard to admit this, but it's critical: there's a part of you that likes being an Imposter.

As you work gratitude into your day, you start to see this more clearly because that toxic need doesn't fill you up anymore, and it feels weird when it's not there. It's being replaced by something far more powerful, and almost a bit scary: inspiration, curiosity, and love.

If you grab hold of these feelings and let them flow through you, it's entirely likely you will feel a strong sense of fear. What happens if you find out what you're truly capable of? Your Imposter self would frame this as "well I guess I'll find out that I really am worthless and I don't want that". 

This is why working with someone else on this is important. If you said this to me in a one-on-one session, I would reflect back to you that you're here, with me, which means you already know that's not true. 

You're curious, and you want to find out just how far you can push yourself and your natural craving for knowledge. The trick is to let go of doubt, jump in, and learn.

Maybe it's computer science problems or how to lead a team. Maybe you want to speak at a conference or start a podcast to elevate your presence in the community. The goal is to give yourself permission to try and take the first step. 

And to fail, which you will. 

Step 5: Reframing Your Efforts

As an imposter, failure is to be avoided at all costs. In fact, it's likely you find yourself covering your tracks, making up excuses, and possibly even fabricating things so you don't get found out.

Through journaling, recognition, gratitude, and curiosity, you're now ready to handle failure and see it for what it truly is: opportunity.

Every founder understands the notion of a "pivot", which is when your customers tell you through their actions that your product is a little bit off. Is that a failure? Of course not! It's the best gift a founder could receive: customers telling you what it takes for them to give you money.

Maybe you hate the sound of your own voice (like I did) so doing a podcast or speaking on stage is something you always thought impossible. One gaff, stutter, or forgotten point will send you into a spiral and make you want to run off the stage.

Or you could reframe the situation:

Oops, I forgot to tell you about feature X, which is the whole point of the demo I'm showing you now. Learning to speak on stage can be quite exciting! Let's go back to the other slide real fast so I can share this feature with you - it's super amazing.

Here I'm using honesty, humor, and courage to deal with an embarrassing situation. This has happened to me, and by far the best way to deal with it is head on. It takes courage, of course, but the alternative is to mumble to yourself and declare "I'm a horrible speaker sorry you had to see this talk". I sat in an audience when a speaker said those exact words and it actually made me angry.

Failure is the natural result of effort. Embracing and learning from it is one of the best gifts you can give yourself!

Step 6: Sharing

One of my most favorite quotes is from Derek Sivers, who shared this thought on the Tim Ferriss podcast (paraphrased):

I like to share things I've just learned immediately, so that I can remember what not knowing it was like.

As you grow and let your curiosity and courage take over, you begin to broaden your mind and accept things you might never have considered before. You might learn to like JavaScript or SQL, or who knows, maybe even F#.

If you and I were to work together, this is where we would set up a blog, newsletter, Instagram, YouTube channel, or TikTok - some place where you get to share the amazing things you're learning on your journey.

The point is to keep your focus moving outward from your heart, sharing the natural flow of good feeling building inside you and believing that not only do you belong here, but you're capable of giving back and building up the group.

This is where I would urge you to visualize a scenario where the group was discussing something you didn't know. In fact, you and I will run through a scenario just like this one as one of your assignments.

The assignment might be something like this: 

Pretend you're in a discussion with colleagues about whether Google Spanner is CP or AP, and the conversation is flying right over your head. You don't even know what Google Spanner is, and you can't recall what CAP is either. When you go home tonight, research these topics with the goal of learning something new and fascinating, and next time we meet, I want to hear about it.

Ideally, you would go home that night and read up on Google Spanner, learn how it works, and how Eric Brewer (the guy who wrote about CAP theorem in the first place at UC Berkeley and now works at Google) came out and said that Spanner is essentially CAP because it runs within Google's VPN and has 5-nines uptime and even if it does go down, Google's ops team is on it immediately as it's not on some remote data center - it's within Google's own VPN. Perhaps we could call it "CaP" with a lower-case A?

The goal here is the flow of learning and sharing, as a natural followup to curiosity and courage. Those things can only happen by letting go of your doubts, learning about yourself through journaling, and being grateful for all that life has given you.

And possibly having someone push you along in the process 👋🏻.

Feel Good, Inc.

This is in your control, completely. Going through life feeling like you don't belong is a choice, so why not have some fun? This decision alone will lead you to where you want to be in your career, and ideally, in your personal life.

As I've mentioned a few times, if you're interested in working with me on this, you can read more here. 

Thanks for reading! Oh - and once again I wrote every single word of this email by hand. AI is fine, but not for this newsletter, which will always come from inside me.

Rob

I have a career coach that is worth every penny because he pushes me to do the things I want to do, but that I resist doing for one reason or another. These aren't small things either - they're big, consequential, possibly career-changing things that freak me out.

Last week he suggested I do something that pushed me right out of my comfort zone and into orbit (paraphrased):

Face this fear of yours directly and write the page. You're worth it, and you can do it, but only you can figure that out for yourself, so DO IT.

So I did. I wrote the damned page and I found it both terrifying and liberating. This is what I've told friends and people that I have coached over the years: if it scares you, you must do it. I guess it means that I need to practice what I preach, right?

If It Scares You, It Might Be A Good Thing To Try

That's a quote from Seth Godin, which I love but, of course like to tell other people. Another good one is from Eleanor Roosevelt:

Do one thing every day that scares you.

Again: fun to tell others, not so fun to actually do it yourself. Talking the talk instead of walking the walk, innit? 

The best summation of this, for me, is from David Goggins:

Fear is my ultimate guide.

People have all kinds of opinions on Goggins (Can't Hurt Me), I know I did, until I read his book. It really did change my life, but as he says, it's not about him motivating me - it's about me motivating myself.

That motivation comes from "doing the work", or identifying, confronting, and directly addressing the fears that hold you back, and then moving through and past them.

So... here goes...

The Walk

​I wrote a book about Imposter Syndrome and programming about 9 years ago (wow, long time) and it is still selling today. I'm proud of it, and the process of writing it helped me get past that horrible feeling of being an outsider because I don't have a CS degree.

Imposter Syndrome is just another version of fear, and it's incredibly toxic in both an individual and a group setting. You might not intend to, but when you tell others that you feel like you're not worthy or aren't qualified, they will (mostly likely) try to make you feel better.

You probably won't believe them, then they'll try harder. You might say things like "you're very nice for telling me these things and I know I should get over it but it's hard", and the cycle continues.

It's possible to reverse this cycle, but it takes awareness, effort, and a willingness to face your fear directly. The simplest win is to reframe each invasive feeling into an opportunity: yikes I don't know what NP-Hard means to wow, I get to learn something new today!Reframing is one of the simplest, most effective ways to engage your curiosity and move past the bullshit that is weighing you down.

For me, I have a hard time selling things for money. Every time I write a book or make a new course, the worst part is trying to come up with a price tag. I was discussing this recently with my coach and that's when he blew things up for me personally:

I like the idea for this course, but I think you can do something so much more meaningful and transformative. A Big Ticket program...

That's when he described an idea to me that made me want to run away and hide. It's way out of my comfort zone but, as I keep saying, I did it anyway. We'll see what happens with it. I have high hopes as I really think it can be extremely helpful to people, and free me up to do the things I really want to do.

A More Personal Story, and a Simple Tactic

One of the other things I'm pushing myself to do is to be more open and personal. I usually don't talk about these things because, well, they're personal. But in this case I think it could be helpful.

I took my girlfriend to Kauai last weekend as she wanted to meet my friends and see the place I called home for so, so long. Kauai is, truly, my home. It's where I raised my kids, spent the best years of my life, and where my closest friends are - it's also a place I plan to go back to at some point if I can, even if it's in a jar.

I've been dating this wonderful woman for just over 2 months, and taking her to the place where my soul lives involved dropping a lot of emotional armor. My divorce ripped me apart in every way: spiritually, emotionally, mentally, and physically, and exploring those walled off places within me was going to be... interesting.

It's not easy for me to trust someone new with something so meaningful. It brings up a lot of fear in me - the deep kind that triggers my fight or flight. That, of course, means only one thing: follow it, face it, and do it anyway.

An old therapist showed me a great method for facing fears like this that I'll share with you, because I find it extremely helpful. In short, it's visualization. The idea is straightforward: you think on the thing that's scaring you, find where lives in your body, and then close your eyes and give it a form in your imagination.

That's when the fun begins. Once your fear has a visual form, you engage your curiosity and reach out to it, explore it, and see if you can learn from it.

Let me give you an example of what I mean.

I went to see this therapist back in 2004 when we moved to Kauai for the second time (the first was in 1997). I wanted to be sure of my reasons for going, and that it was a healthy decision. My therapist asked what my fear was, and then introduced me to this process:

Think about getting off the plane in Kauai with your family and all your belongings with you in your luggage. Everything you own. You walk off the plane and into the Kauai sunshine... what does that feel like...

The trick, she said, was to envision a moment where your fear would be most realized. If you're giving a talk to a large group, for instance, it might be when you first walk on stage and the applause dies down, and you have to start speaking. Maybe it's the moment you tell your new partner that you love them for the very first time - where are you sitting, what are they wearing, what exact words would you say?

Once you have that feeling, you give it form in your imagination. Getting off the plane, for me, made my guts contract and my throat constrict. Focusing on that constricting feeling and giving it form was tricky because who wants to think about fear that closely! Either way, it was incredible.

When I did this in my therapist's office, I saw myself in a junk yard full of jagged, rusted metal sitting in the rain and mud. There were fires coming from random piles of junk and it seemed that everything was oozing with tetanus and, at any moment, I would brush against something and get cut. I told my therapist this and she simply said:

Touch the metal and feel the fire.

I quite literally shouted "NO!" in her office. A true, physical recoiling at the idea. She asked if I was OK and reassured me that I was in a safe place. Strangely, something else came with that immediate reaction: curiosity.

So I walked up and touched the metal. I wanted to run so, so badly but I touched it and... it disintegrated. The sun came out and the piles of metal turned into shiny lumps that seemed completely unthreatening. Unfortunately that's when the ground beneath my feet opened up and I got sucked down.

The mud pulled me in, suffocating me, down my throat and up my nose. I couldn't breathe and actually thought I might get sick. My therapist once again reassured me and suggested I let go and let the mud do what it was going to do.

I felt it fill my body. I could taste the burnt, wet earth as I felt that I was literally becoming that very same mud. It was at the moment that the downward pull ejected me into a cavern, and I began to free fall through the air, into a void.

"Is this ever going to end, or am I going to go from one terrifying thing to the next?" I asked my therapist. Her reply was so very therapist-y:

I don't know. Let's find out.

Free falling, giving up control, not knowing what comes next. You see the theme here.

That's when I saw the fire below me. A simple fire, like the kind you find on a beach, with driftwood and branches. It was, in fact, on a beach. A warm beautiful one, at night, and sitting next to the fire was a friendly looking man about my age, with bare feet and piercing blue eyes.

"Hey" is the only thing he said to me. I remember regarding this man and wondering who he was supposed to be. He seemed very friendly, like someone I'd like to get to know. I describe him to my therapist and added that he really seemed like he could be a long-lost friend.

I still get chills thinking about her reply:

Interesting. That's you, Rob.

That was one of the most powerful moments of my life, and if you were sitting next to me and I told you this story, you would still see tears in my eyes. In fact, if you were sitting here as I write this, you would see the same.

Your Journey

I've learned all kinds of fun ways to address fear over the years, but nothing is as direct and freeing as visualization. When you're feeling something eat at you, including Imposter Syndrome, try to isolate what that feeling is, and see if you can use your imagination to give it form. Once you have that form, let your curiosity pull you toward it and see what happens.

​I love facing down my fear, but I don't love how it feels in the moment. I hope that I learn to relish that feeling someday, thinking "Right on there's that clench! Let's do this..."

What's your one thing that you'll face down today? I'm here if you want to share - I find that sometimes confiding in random strangers (if I haven't met you, that is) is the perfect way to let something out! As always: just hit reply.

Thanks for reading!

Rob

Another day, another person citing HAL 9000 as a "warning" from Stanley Kubrick and Arthur C. Clarke about the "dangers of AI". I am convinced that none of these LinkedIn AI thought leaders actually watched the movie and I honestly couldn't blame them for that. It's a pretty slow burn to get through the whole thing, at least by today's standards.

I was going to link a few of the more bonkers posts, but decided not too as that's what they want anyway. Go have a read if you want to get depressed.

Anyway: Kubrick was a master of immersion and visual storytelling, essentially demanding that his audience either allow themselves to enter his world, or leave. The space docking scene ran 5 minutes and 20 seconds long and was scored to the Blue Danube of all things!

This film could not be released today. We simply don't have the attention span. This much is obvious because the people writing these "warning" hot takes on LinkedIn seem to have not made it to the end, with the Big Reveal about HAL...

The Big Reveal

If you haven't watched it, you really should. Stay for the whole thing please! In short: the human crew of the Discovery wasn't aware of the true nature of the mission, which was first contact (potentially) with intelligent alien life. The only crew member that knew this was HAL:

In that scene, astronaut Dave Bowman is "inside" HAL, having just disconnected him - essentially killing the computer. For some reason, a video message is played and the mission objectives are revealed, and Dave learns the truth.

The main point of tension here is that HAL was programmed to convey information "without distortion or concealment", which makes sense for any AI tool, but Mission Control ordered him to conceal the truth from the human crew.

The sequel to the film (2010: Odyssey 2) discussed this in more detail, but described it as a "psychotic state", basically framing HAL as "going crazy" but I think it's much easier to understand than that: without humans around, HAL could do what the humans told him to do AND not distort or conceal information.

If you watched the scene above and knew HAL's orders, it makes the following scene even more chilling, which of course happened before the disconnect, where HAL is trying to figure out if the humans know the mission objectives, or have at least guessed them:

HAL is Merely a Machine

HAL is not a warning about AI taking over, it's about a massive logic bug shipped to production that crashed the system. Normally, HAL might have blue screened with conflicting instruction sets. Instead, HAL's "agentic programming model" tried to resolve the faulty instructions as best it could.

You would think NASA would have run a few integration tests, wouldn't you?

I think about this when people blame AI for writing crappy code. In one sense: it's true. The programming models and tooling can interpret your instructions in a very funky way, giving you back something that looks like pure crap if that's what your process is like normally.

I don't mean to sound overly snarky on this, but many programmers fly by the seat of their pants due to super intelligence or extreme Dunning-Kruger. I think these folks tend to have a hard time organizing their thoughts, forming them into solid instructions for a machine.

If you can flip your brain into "instruction mode", where you think through your current problem and then figure out how to explain it to the machine, things become much better. I have found that the simplest way to do that is to break things down into the smallest step possible, which makes the prompt or instruction extremely small and easy to convey to a machine.

Claude, Gemini, and LLMs like them are only data models at their core, which accelerate predictive analysis. The prompts you use, together with instructions you provide, will either drive them insane or allow them to help you find an answer.

We are the ones who control the AI. I'm not sure if that makes me feel better, honestly, but at least it puts the focus on the right problem. AI isn't to blame - it's an algorithm based on 1s and 0s, and a really good reflection of our own thinking patterns.

This video is inspired by my friend Heather Downing, who asked me how I would go about learning "something like... distributed PostgreSQL for instance". That's a great question!

I've set up distributed SQL Server before, but never had the need to do that with Postgres. The reason why is simple: I let DigitalOcean do it for me. Before that, it was Heroku or AWS.

That said, this really is something I should know how to do, so challenge accepted Heather!

People write a lot about burnout and how to get over it, but they don't write about what happens when they face the same burnout for the 5th time, with the periods between decreasing.

Eventually you face a hard truth: I just don't love this any more.

AI seems to be accelerating this feeling, at least with many of my friends. There is a sense of malaise and frustration at what appears to be the slow erosion of intentional care and effort in our industry. Just let the AI do it, while you ... do other stuff.

I'm not quite there yet. I believe you can use AI as a virtual assistant that does the stuff that actually causes burnout in the first place. Creating and updating READMEs, ensuring the code on your docs is correct, writing a script that compiles markdown to a PDF - things like that.

Or you might end up with a lead who doesn't like AI at all.

Tedium, Incorporated

I spent the last 30 days at a clownshow startup, trying to help get their DevRel group get off the ground. There was an option for going full time, but at the end of the 30 days it was pretty clear the fit wasn't right for either of us. The novelty of having a fresh WTF every morning was wearing thin; there simply was no helping here.

To be honest, I never thought of myself as a "Developer Relations" type of person anyway, but it was my friend Seth Juarez who convinced me otherwise:

There aren't many people I know who can reach programmers like you can. This is totally your jam.

That's a compliment for someone who loves to write and make content for people, and it hit me that he was right: after 15 years or so of writing, podcasting, and video production, I've gotten pretty good at it. Maybe I should pivot?

Seth said that to me 7 years ago when I rejoined Microsoft, taking on the title of "Developer Advocate" for the first time. It was a weird gig, if I'm honest, but Seth was right: helping developers improve their lives is something I care about deeply, and I don't think I'll ever burnout on that.

That said, the company you're working for can change that in a heartbeat.

This Is Your Last Day

That's how the Zoom started at the end of my month at the clownshow startup. I knew it was coming as we had talked openly about it. They had given me a list of tasks to do, and I had offered my opinion that these tasks could be handled by Claude Sonnet easily. I would rather do the thing they hired me to do.

Normally I would just have said "sure I'll get right on it", but this time I just couldn't. I simply didn't care. I don't mind writing docs and I don't mind proofreading, but that's not why you hire me. You hire me to do the thing I wrote about in the opening section of this email: reach your developers and help them improve their lives using your toolset. 

It's really not complicated.

In fact, I said exactly that earlier in the week, wondering if the 30 day cliff could be avoided:

You hired me to inspire your developers. Could you ... maybe let me do that instead of this tedious work that can be done by Claude? Help me help you. 

At that moment I had been handed a mess of tasks that I knew an LLM could knock out in short order, and, for some reason, perhaps ego, the lead I was working with insisted that it was too detailed for an LLM. I politely (yes, I maintained professionalism here, I promise) told him that I knew how to AI pretty well, and he might be surprised at the results.

He said no and I did what I do, which is to ignore mediocrity altogether and do the job that needs doing. It took me 15 minutes to finish the first draft and another 30 minutes to review the details to be reasonably sure that I wasn't making a mess.

When doing work like this with an LLM, you get to a point where the mistakes are indistinguishable from ones you would make anyway. Spelling issues, grammar, missed titles, and so on.

I went back to the lead and let them know the tasks were ready for review, and could I please get back to outlining our first TickTock video and awareness campaign?

Them: You used Claude for this, didn't you?
​Me: Of course, it's why we have it.
​Them: I can tell you used an LLM. This one thing here isn't what I asked for. There's a reason why I wanted you to do it yourself.
​Me: I would have made the same mistake as your directions weren't very clear. This will take me 5 minutes to fix.
​Them: Our policy is that you own the work created by the LLM. This is on you and you should have done as I asked.
​Me: This has nothing to do with an LLM. I'm giving you the work I would have turned in anyway.

That's when I knew Friday would be my last day, which was fine. As Pooh said:

I'm not lost for I know where I am. But however, where I am may be lost.

Ego and AI. What a fun mix.

Fighting For What You Love

I settled for this job because I needed a job, which is a good reason to settle. The work sounded fine, and the people seemed nice enough, but nothing about it really drew me in. Nothing made me actually care.

Now you could look at that statement and declare me entitled, privileged, and an ungrateful ass and that I should feel lucky to have a job (don't worry, I did the work for you and said that to myself daily).

You could also look at that statement and think I settled for something mediocre out of fear, so of course it wasn't going to work out. I did the company a disservice for taking the job in the first place - if I wanted something, go get it!

Welcome to the daily battle in my brain. In one corner, there's the ghost of my dad: stoic, hard-working depression baby that ate cream of mushroom soup with peas, on toast, regularly, until the day he died.

In the other corner is my mom, who never settles for anything. She lived a rich, long life and defined her own reality. It didn't matter what other people thought and, yes, it often drove my brothers and me out of our heads.

I suppose the point of all of this is that I am once again, semi-jobless and trying to figure out what's next. I'm still creating workshops and courses, and with a little effort and a ton of risk, I could be my own boss and strike out on my own again.

Or I could play it reasonably safe and try to find another job at a company that may, or may not, be a complete clownshow. Even if I did find something that was interesting and fun, it's entirely likely I would get laid off in the next 3-5 years anyway. 

See what I mean about malaise? It's so easy to let it in when you don't feel a sense of control. 

But, as my new friend said to me when I told her I got fired:

That's great news! Now you get to do what you want to do...

She's a keeper, I think.

What would you do? We're only given one life and it's up to each of us to make the most of it. That said, is it reasonable to try and find that much fulfillment from a job? Isn't that what friends, family, and F1 are all about?

I really am curious about your thoughts on this, so if you're motivated, hit reply and let me know. I read every single reply!

Thanks for reading,

Rob

When it comes to AI and programming, people focus way too much on code generation. Yes, if you use detailed instructions, specific prompts, and a super narrow scope, LLMs like Claude Sonnet can write passable code. But that's not where the time-saving comes in.

The efficiency gains come when you throw the tedious, mind-numbing tasks at it. Like verifying the steps in documentation or a README. Or actually creating the README in the first place.

That's what I do in this week's video. It's a short one, but I wanted to show how straightforward it can be to 1) create a README for your project while putting some shackles on Claude so it doesn't make stuff up and 2) verifying the README's code is accurate by having Claude actually run it.

I have tips like this and many more in the workshop I released a few weeks ago. Enjoy the video!

Oh, and if you want to play with Firefly (in the video), it's right here. You can see the generated README as well.

TL;DR: I'm releasing a workshop today focused on helping people move through the "this sucks" stage to "OK this is kind of useful" stage. You can read more below. I'm also hoping you reply and let me know your horror stories, and also your biggest problems with AI as I want to create a video that addresses these things directly.

If you haven't read about this guy's experience with Replit... well it's kind of wild:

Long story short, he tweeted out his vibe coding session and every ridiculous problem involved with creating an application on Replit. If you don't know, Replit is an app builder that's powered by AI, so you basically build what you want using prompts, and then host it there.

Neat idea, but apparently things can go pear-shaped quickly and you can have your production database dropped. If I'm honest: I don't know how true any of this is. Dude added screenshots to support his claims, so there's that, and he also got loads of press from this, which I can't help but think was intentional.

All that aside, I kept wondering: WTF was this guy doing to get these results?

Keep the Barrel Pointed Away From You

The massive problem we're having as an industry is straightforward: so much hype, so little care. Programmers have lamented the garbage that AI will produce, and are continuing to do so very publicly and loudly. I think complaining like this is good because it's drawing attention to the issue. It's also bad because it amounts to standing back, pointing fingers and laughing as other people jump off the same sinking ship you're on.

It's time to work the lifeboats, don't you think?

There's no way we're going to get away from AI in our industry. The main value proposition is that it saves time due to efficiency gains, and many people are realizing these gains, which means more money. That's pretty much the end of the story on that: more money means you get to learn how to use AI on the daily.

Rather than be pessimistic about it and point fingers while laughing, I think we can do better, and figure out a way to help people like poor Jason not turn on autopilot and let the car drive you off a cliff.

The Careful Art of Vibing

AI is a computer, which is the first and most important rule. You're coding with words, not code, which is bound to be extremely tricky. Just like coding, you move in small, well-defined steps, and work that process until you have what you need.

For instance: if you're converting an old Backbone.js application to Next.js, that's not where you start in terms of a prompt. You would do what any programmer would do without AI:

• Write down what it is you're doing and what you hope to achieve (aka "what 'done' looks like).
• Gather your style guides, policies, and "guard rails" for your team.
• Lay out your sprints, iterations, or milestones.
• Divide each of those into a set of tasks.
• Set up a branch to work in.
• Confine each AI "session" to a single task, which also represents a single commit.

This is the process I've used and it works really well. Yes, I've had things go completely wrong before and I've had to completely erase a sprint as I've realized I went the wrong way. The good news about that is that these "sprints" are usually represented in hours and minutes, not days. Yes it could be time wasted, but usually you learn something in the process.

Translating this to the real world, your sprints might be:

• Installing Next.js and making sure it works and you can deploy it to wherever the site will live.
• Asking the LLM to review the Backbone site's layout, and applying that to the Next.js site, while mocking up the data-driven bits (that part comes later).
• Move on to the home page, pulling in components, using mock data. Follow that up with the rest of the "main" pages that sit outside the app.
• Pick one "app" page and bring in the components, once again mocking the data. Rinse, repeat for every other app page.
• Create the API calls for each page, one bit at a time, slowly. Get a game plan in place from your LLM before you execute anything.
• Implement authentication, making sure to ask your LLM what is the best way to do this, provide sources, and even give you a game plan before anything is done. Go through a code review if needed, then do it.

There would obviously be more steps to consider, and this is just a general guideline, and it's exactly what I did when I rolled this site off of Rails back in April of 2025.

Plan. Plan a bit more. Gather your resources, move in small steps. Profit.

Taking the Time to Figure It Out

I was lucky in that my job at Microsoft was to figure out exactly how to do these things, so I had years to dig in to processes and what's possible. These days people are figuring it out on their own!

But you don't have to. I mentioned this in previous emails that I wanted to put together an updated workshop that I've given over the years, make some videos, and gather resources to help people move past the "gun/foot" stage of working with AI, and today it's available!

I'm considering this a "presale" in that I'm probably going to add to it, or possibly edit a few things where there might be a few issues; your feedback is crucial in this regard.

If you're interested, I have a discount for you because you've signed up to my site: use coupon code RJYM9KDP at checkout. If you take me up on this, thank you!

Why a Workshop?

The problem with creating AI "courses" is that they're simply not repeatable. There's no way you're going to watch a video I make and then be able to follow along and replicate it. Your LLM is going to decide, on that day, to do something completely different than what you see.

The only thing you can do, at that point, is to embrace the change and "go with it" by either tweaking your prompt to be more precise, or corralling your LLM by providing more explicit instructions.

Other times things can be a bit more positive. Your LLM might come up with something you didn't think of, and it might spark your curiosity, leading you to add a feature or two to other part of your application. That's when this stuff gets very fun and I wanted to capture that.

In the workshop there are "jump off points", where you can feel free to ride the wave and see where it takes you (being sure to branch and commit your work first). That's the brilliance of "vibe coding" - when you make something that you wouldn't have if it was just you coding away.

Anyway: if you're looking to make the leap from "all I get is CRAP" to "oh, yeah, I can see how this is super useful" then I made this workshop for you.

The Teams Version

I also built it so it can scale beyond a single person, through to a team. If you get the Team Edition, you'll get an instructor manual plus a ton of other useful "extras" that will help you roll out AI at your company. I even threw in things like policy templates, PR templates for AI-generated code, rollout plans, and more.

Share Your Horror Stories

I would love to hear about your horror stories, OR a problem you consistently have using AI tools. If you're OK with it, I want to make a video that addresses those concerns directly.

For instance: you might have a hard time moving from "fix this CSS so it doesn't suck" to something more precise that delivers exactly what you want. You might also hate the Python that's being generated because the variable names are always horrible. Another big problem is that LLMs tend to use old versions of libraries when generating things (like Tailwind or React) and what it gives you is useless.

Let me know! I would love to use real world examples, and I'm happy to leave you completely anonymous if you like.

Thanks for reading! Hope to hear from you...
Rob

There were a number of angel investors in the audience at this function and it was really neat (and inspiring) to see these entrepreneurs risk so much. Getting up on stage in front of a live audience, people in your field you don't know, and giving your pitch? That takes extreme courage!

Which is why I went. I really admire people who are willing to put it all out there, all in the hopes of refining their presentation and, perhaps, tweaking their business model.

Of course, given there were investors in the audience, every deck had some level of AI integration in there. Two of them stood out to me, however, in that they both based their value proposition on "using AI to match based on the interests of the customers".

Claude, Find Me a Date

The most notable one was a dating application. Before I dig in to this, I want to say the main reason these companies were at this pitch night was to get feedback and refine their model and decks. I'm not trying to pile on, yet I also think there's something to be learned here.

So this dating application is differentiating itself because, like the other company, it was going to "use AI to match people across a wide variety of preferences". This made me scratch my head.

AI isn't magical, and variants of matching algorithms are well known. I won't say it's a "solved problem", but it's kind of a solved problem. If you ask an LLM, let's say it's Claude Sonnet 4, to match people based on dating preferences, this is the response you're going to get back (I actually did ask using Claude Code, and it was a fun experiment).

Here's my prompt:

I have a large set of personal user data, which contains dating preferences of all kinds. Let's assume, for now, it's 10 preferences with range data involving subjects like education, politics, orientation, spontanaity, relationship length, location, and age (among others). Can you sift through this data and, using the preferences, create matches? If do, how would you do it?

And here's the answer:

This makes sense as far as answers go. LLMs are trained on things that exist and are very good at giving you code to run in the form of a script, or code you can add to your application. They are not, necessarily, genies in a bottle waiting to come out and solve your dating problems.

Either way, I pressed on:

I don't want an algorithm, I want *you* to do it. Give me information on how you would actually do this. Add a time complexity analysis.

The answer is basically "OK, I'll crawl your dataset for you, implementing the algorithm I was about to suggest":

This is a very reasonable approach. It's also completely unnecessary for the LLM to do this for us. In fact it's a very bad idea.

Here's why:

If you've ever had to create a matching algorithm, you know that a brute force way of doing it, which is something a machine might suggest, is going to be O(n^2), the worst time complexity you can have.

There are heuristics and approximations, of course, and this is where we get into graphing algorithms and NP-Complete problems, which are both fun and extremely difficult to deal with in terms of 1) getting them right and 2) getting them to scale.

The point here is simple: AI is not going to win the Millennium Prize proving that P = NP. It's only capable of telling us what we already know.

So why are these businesses expecting something more?

You Just Move the Slider

You might be wondering: so, Rob, did you share your thoughts with the founders then? The answer is: sort of.

It's been my experience that challenging someone's business model is a delicate business, and unless you're very persistent, you'll get ignored immediately. People will dub you a "hater" or simply think you don't understand their pitch. This is their dream, after all, and no one likes their dream shattered.

So I did the next best thing: I asked the angel investor sitting next to me. His company provided an angel round to the other startup using AI as its IP (a real estate rental landlord/tenant matching platform):

I'm curious how you would position this company for valuation since their IP is a flip of the coin in terms of an AI response. You really can't expect the same answer twice, and can only hope that you've provided clear constraints. That seems like a tough thing to evaluate.

The answer was fascinating: "It's not a flip of a coin. You just move the slider a bit to refine the answer". I'm not entirely sure, but I think the "slider" being mentioned here is the limitation on "guessing". No need to press this point, I translated this as "we're going to use laser-focused instructions to cut down on the variability".

By "variability" I mean telling it how you want the weighting and matching to be done, which would likely be something like the screenshot above using scoring and overlaps.

In other words: algorithms that already exist. This was my next question:

Matching algorithms are a known thing and not something you need AI for. In fact, that would be extremely expensive if you were to use AI to chunk through your customer base in a machine learning way. I can see using AI to suggest a first chat message between matched people maybe, or suggest locations for first dates that are public and provide a sense of safety...

That's when I saw the look: you don't seem to understand AI. It's capable of a lot of wonderful things.

Being Positive

There's obviously a massive land grab happening in our industry, and it's not just the startup space. Big companies are looking to improve performance and efficiency, and mid-size companies are trying to do more with less staff.

And yes, many of them are trying to create AI-centric apps that do magical things. I think this is due to the wildly embellished promises that AI tools present. Then again, maybe I'm wrong. One thing I've learned over the last two years of using this stuff daily: it will surprise you.

Either way, to me, these tools are great at enhancing your current idea. Matching landlords to renters is a fine idea, but perhaps AI could be used to fill in the documents or create the lease forms for you. You could have it help you create better ad copy for your property, and, if you're a renter, have it help you fill out your renter profile.

This is what MagicDoor does, and it's impressive stuff (I don't think the real estate founder knew about MagicDoor last night).

I think it's up to the people who are cutting through the marketing hype, the ones actually doing the work with AI, to provide their insights and experience. I didn't want to rain on anyone's parade, but I do plan on emailing the matchmaking founder and offering a few ideas for them to both fill their vision and use AI "stuff" to enhance their offer. I'm also going to offer my help, for free of course.

I'm also going to listen. I might have missed something entirely.

What do you think? Have you heard any wild pitches or ideas? If you're logged in, share your comments!

Your confidence takes quite a hit after getting laid off. Even if it's a "general reduction" and not performance based. Somehow that makes it worse (if you didn't know I was part of the 9000 souls let go in May/June). 

The good news, for me, is that I spent the year and a half before the Big L focused on one of Microsoft's flagship efforts: exploring Copilot/AI patterns with VS Code. That was my job as an advocate: to help solve developers' problems using Copilot + VS Code.

It was fun. 

The Problems

Probably the biggest problem we faced was the general attitude towards AI and "crap code". Hallucinations, bad patterns, security issues - all of these led to a general distrust.

Then there were the ethical issues of flexing someone else's work for your own. This problem has a lot of variants, of course, many of which have nothing to do with AI. Open Source, after all, is based on this idea! However you're also supposed to give back, which you can't really do with AI.

Then there are the other more "speculative" issues, including the erosion of core skills, blind trust in the tooling which leads you into a wall, and managers leaning on AI tools instead of peoplewhich leads to loss of jobs.

There are other issues, of course, but these are the notable ones that I see popping up routinely, and that I've heard from you after previous emails.

These are all valid opinions. AI does produce crappy code and it's built on other people's work, without a notion of giving back (unless you pay $20/mo to use other people's work in your project). Yes, it will erode skills because you're not using them, you're handing them off and yes, I'm a shining example of a "reduction in force" due to optimization of AI (I can't prove that, it's my opinion however).

But there is a middle ground here that I think we can explore.

Maybe Don't Generate Code

One thing that many developers don't realize is that you don't need to generate code with a given AI tool in order to get value from it. Or, put another way, you don't need to generate code that matters to your application.

Consider:

• Boilerplate code you've written 100 times over (data access classes, for instance.
• A build script.
• A utility script that converts things, compiles things, or generates things for you.
• Git commit message first pass.
• Markdown documents for your project, including the README, Code of Conduct, Security, Contributing, Issue Templates and more.
• A tutorial to get you up to speed on a given language, or prep for an interview.
• Tests, but without any code or assertions.
• Class outlines, without code, only comments that tell you what code goes where.

I've used AI tooling for all of these, and they're incredibletimesavers. 

For instance: I'm building out a number of workshops, and putting the wraps on my very first, an introductory one which I'm calling "AI Tools for Programmers with Deadlines" (with a nod to the Django framework for the inspiration on that title).

No, I don't use AI tools to generate the content (that's the fun part for me and what keeps me motivated. Just like writing this newsletter - all by hand, never generated).

The workshop is a series of Markdown files in a set of directories that look something like this:

As I mention: I love writing and creating things, but I loathe the publication process. Writing tools are great for writing, but when you need to turn that writing into something that people can read, it's very painful (and yes, thank you for the suggestion forming in your mind; I can almost guarantee you that I've tried it).

This is where AI shines. Notice the JS files I called out there? Those are compilers, all created by Claude Sonnet 4, that compile and output that markdown to HTML, a JavaScript manifest for use on a React app, a PDF, and a SQLite database. Each one took about 15 minutes to create.

Here's the PDF output:

Claude used Puppet, a Node.js package, together with some slick styling and created a PDF that I simply could not get Word, Pages, Google Sheets, or any other program/app to format properly.

That is a massive timesaver.

Controlling the Chaos

The "AI for Programmers with Deadlines" workshop is for teams, mainly, and I'm building it as I have a few live workshops scheduled in the coming months (if you're interested in something like this reply!).

I've shown the workshop to a few friends, and have received some great feedback - but they all seem to have the same question:

How do you write a good prompt? That's what always stops me.

In fact, my good friend Dave asked a variation of this question just today: 

​

My answer is always the same: small prompts, lots of instructions.

If you use Copilot, you need to get to know .github/copilot-instructions.md. If you're a Claude Code person, CLAUDE.md is your best friend. Gemini CLI? GEMINI.md is what you need.

Instructions set the context. This is where you tell the AI tool what you're doing, the name of the project, the stack, code styles, response tone (which mine usually is "stop being perky just get to the point"), and templates. Yes: templates.

You can tell your AI tools to "use this exact pattern" for just about any boilerplate code, and then have it blow your mind with nearly exact compliance.

For instance, here's an instruction for Jest tests with Node.js:

The comments act as "inline prompts", if you will, and LLMs are typically smart enough to understand the text replacement for outer blocks and test names.

Don't want the tool to write the test code? That's fine - just tell it in the instructions.

Doing all of this, your prompt now becomes:

 Create tests for the ShoppingCart service

Thanks for reading,
​Rob

TL;DR - I like Gemini CLI. It has a very, very generous free tier and is quite intuitive. The LLM (Gemini 2.5-pro) doesn't give as "complete" an answer as Claude Sonnet 4, but in many ways that's a good thing. It's also very, very fast. Only downside is that it's Google, who have a reputation for rug-pulling.

Let's Learn Python, Again

In my last post I took Claude Code out for a spin and loved it. It was quick, slick, and had a simple workflow that I liked much more than Copilot. The only downside was the free tier was non-existent at the time of recording.

In that video, I instructed Claude Sonnet 4 that I was trying to learn Python by building something. I wanted to see what it looked like and understand the idioms seasoned Python devs use.

For context, I set up an instructions file and told Claude I was an experienced programmer most familiar with JavaScript. I told it was I was doing, what kind of code I wanted to see written, and how I like to write tests.

Overall, I think Claude did very well. Go watch the video (or read the post if you want to see details).

This time, I'm going to do the exact same thing with the exact same prompts (mostly) with Gemini CLI.

Terse, Fast, Simple

Gemini CLI together with the Pro 2.5 LLM is compelling. It's simple to set up, you don't need to give them money, and they let you know how many more free calls you can use, which are a lot.

As you'll see in the video below, the main difference is that Claude Sonnet did extra work that it assumed you might want. Gemini doesn't do that, preferring that you be specific with your prompt.

For instance: I asked Claude to build me a data access layer based on a SQL file. It did, and then proceeded to also add generic repositories for me (which I hate) with code that kind of sucked (no error checks, no transactions). It did this because I instructed it to be "pythonic" and use All The Idioms, and I guess Python people dig their repository pattern 🤮.

Gemini didn't do that when using the exact same instruction set. It focused, instead, on the SQLAlchemy models and built them out with more detail. I'm not sure I like the detail it added - but you can watch the video and tell me what you think.

30 Minutes of Gemini

So here it is. As always: would love to read your thoughts. You can leave a comment here if you're a member, or reply to this email if you're on my list!

Thanks for watching...

TL;DR: Claude Code is worth every part of the $20 I'm paying for it (I'm not receiving any consideration for this review). In fact, if I was running a coding team, I would easily pop for a team license for this thing because it's that good.

The only thing it's not very good at, and this is a very big thing, is undoing its updates and you have to rely on Git a bit too much.

A Discussion On Speed

I think it's important to start off by acknowledging that Claude Code is a tool that accesses an LLM on a server somewhere in the cloud, wherever Anthropic (the company that created Claude Code and a bunch of LLMs) has set up an API endpoint for various tools to access.

I bring this up because people will rightly want to know if Claude Code is faster than Cursor, for instance, or Copilot. This kind of question has a complex answer, because I would use the same LLM with each of these tools: Claude Sonnet 4, which is my go-to at the time of this writing.

We now have at least three considerations when it comes to the notion of speed:

• The raw speed of your editor or IDE, which is probably VS Code or one of its forks.
• The responsiveness of the API endpoint you're hitting that is then calling over to the LLM you've chosen.
• The responsiveness of the LLM itself.

In terms of editors and IDEs, you can't get much faster than the terminal, which is where Claude Code lives. The last two considerations are the largest.

I don't have exact schematics for how the LLM calls work, but I have set up a few raw ones on Azure for OpenAI and they are a wee bit complicated. For our purposes, we can imagine a few backend systems sending messages around, trying to fulfill our chat request. If those backend systems are on Azure or AWS, how fast they respond will depend on how optimized/scaled out the overall system is.

There are different load profiles too, meaning that middle of day PDT will likely have far more requests than 3am PDT, so the system might "seem" to respond faster.

Finally, the LLM responsiveness is entirely based on the reasoning it has to do to respond to your prompt. If you have a lot of context (instructions, code files) and a big prompt, the answer will take longer.

If you're building out documentation that requires crawling over every code file in your project, the answer will take a very long time, possibly 5 minutes or more.

All of this to say a simple thing: pondering the speed of an AI tool is a fool's errand. Sure, some tools might cache context, rewrite/reduce your prompt for you, or some other trickery behind the scenes to appear faster, but that doesn't make the tool itself any faster.

Claude Code, however, does something that I think is wonderful, and makes it feel like it's zipping along, doing your bidding. I'll describe that below.

Installation

When I was creating the Learn Python video I'll be honest: I was expecting a clunky terminal interaction that really belongs in an editor or IDE. A terminal is good at terminal things, an IDE is good at interactive coding. Why mix the two?

I was wrong, and I'm happy for it. In fact I'll go so far as to say that you might not even need an IDE (and yes, I'm slotting VS Code in that category) if you're happy working in a terminal and know your basic commands. I can't believe I just wrote that, but here we are.

Getting started with Claude Code is as simple as running an NPM command (you'll need Node > 18 to run the CLI):

npm i -g @anthropic-ai/claude-code

This will install Claude Code globally and, the first time you run the binary claude, it will set up and configure things for you.

Setting Context

One thing I keep pushing people to do is to set up your dang instructions! It's like making white rice: wash it first! You can't expect your LLM to know what it is you prefer unless you take the time to tell it, which you can do with Claude Code by adding a CLAUDE.md file to the root of your project.

This is how Claude Code works: you start a session in a given project directory, and that sets the context for any requests you make. That's it. This is the first thing I love about Claude Code: it is so, so simple.

Still, I want to be sure I add my own context too, which is what the project is about, the stack I'm using, code styles, and so on.

Here's the starter I used for the Python video:

# Learning Python while building a database

I want to learn Python and build an ecommerce API application using best application practices for Python in terms of stack. 

Explain things to me as you go, but treat me like someone with over 20 years experience. I know a lot of languages, so just get to the point.

Comments should be short and instructional. Create them so I can read and understand what's going on (and why) as opposed to documenting the code.

Critical that any code generated by "pythonic" and idiomatic. I want to learn what an experienced Python person would do. Working code is good, idiomatic is better.

## Database

 - Database tables will be lower cased using underscores.
 - Every table will have an integer primary key called `id`.
 - `char`, `varchar` and `nvarchar` are never to be used for string fields, only `text`.
 - Use SQLite3 for development and testing, PostgreSQL for production.
 - Every table should have `created_at` and `updated_at` timestamps.
 - Many to Many relationships will have compound primary keys, never a single ID with compound unique.

## The Spec

This is an ecommerce store that will deliver both digital and physical goods. To that end, we need to track:

 - `products` with a sku, name, price, description, and type (digital, hardware, kitchenware, clothing, etc).
 - `inventory` that tracks products and their stock levels as well as location. For digital products, this should indicate download URL.
 - `orders` with a unique, random `number`, `total` in pennies, `date`, `status`, `transaction_id` if it's checked out.
 - `customers` with unique email, name, lifetime value

It's important to note that I don't know Python and the purpose of this exercise is to 1) play with Claude Code and 2) see if Python will finally stick in my brain! The video turned out really well - you should go watch it if you haven't.

The Problem with Copilot's Flow

One thing that drives me nuts about the Copilot extension in VS Code is the noise:

There are a lot of words in this panel that don't make sense to someone unfamiliar with AI tooling, especially the placeholder: Edit files in your workspace in agent mode. Do what with what now?

Then there are the buttons, drop-downs, and icons that really don't belong there (a microphone and paper airplane?).

Note: Microsoft has a mandate that any UI tools you create must comply with accessibility guidelines within the company. Having voice input here isn't a choice, my question is "why is it an icon at the bottom right?".

The idea here is that if you have a simple question, you use "Ask" mode and you get an answer as a chat response. If you have an edit to make, you go into "Edit" mode and the file you're on gets edited, pending your approval.

If you really want to edit things, you use Agent mode, which goes off and does all kinds of things to multiple files at once, and then asks you if that's OK. It's powerful stuff, and what I use most of the time.

There are a few problems with this, however:

• Why the "modes"? It's natural to ask questions, investigate, and then give a command. Followup questions with command options feels better, to me, at least.
• The responses tend to be quite different. Ask and Edit, for instance, don't seem to have the iterative prompt building step that Agent mode does, and therefore don't seem as complete. This is my impression, anyway.
• Switching between modes is clunky and unnatural. For instance: I might want to know what the best ORM is for Python, see an example using a local SQL file as reference, and then have Copilot make a class for me. Up until recently that required a few mode switches in Copilot, and it still does and it's hard to say when or why, but the extension does this for you now.

We discussed this flow a lot when I was at Microsoft and, to the team's credit, they love the feedback. The UX bits are always evolving and I'm sure this will get streamlined at some point.

Claude's Version: More Intuitive

There's a single input box with Claude Code and some hints/tips for how to use it:

I love this. So, so simple. Let's start with the ORM question above and see how this flows:

That last paragraph is enabled by the CLAUDE.md file I'm using, which explains this will be an e-commerce project using SQLite3 and PostgreSQL (for production) and that I want things to be "pythonic", whatever that means (I was told it was important from a Python person).

Oh Yeah? Show Me...

I love how I feel more in control of Claude Code's process and that I can ask follow up questions and move at the pace I'm comfortable with.

To that end, show me the code before I decide one way or another:

Claude replies that it will follow my specs and whip up a sample models.py file, which apparently is how Python people do it: all it one file. I'm OK with that!

Scrolling down, I can read through the code and see if anything catches my eye. If I see something I don't like, I can tell Claude to fix it:

I love the follow ups! I also love the idea of "just do this thing and stop asking questions", which is VS Code's way of doing things (more on that in a second).

Speaking of, here's one last thing I absolutely love about Claude Code! You can go "Full YOLO" mode, if you want, and tell it what you want to do. Something like set up a bare bones Python project that will use Flask and SQLAlchemy:

I LOVE the todo list here. You can see everything that is about to happen and you'll be asked for approval before it happens. You can alternatively tell Claude to "just DO IT" and it will cruise through the tasks, letting you know what it's doing as it goes along.

Copilot's Version

Let's run through this again, but with Copilot. I might do another post focusing on Cursor and Windsurf, but for now I need to keep this post under a million words.

I'll start with the same prompt in "Ask" mode, using the same context instructions (.github/copilot-instructions.md): What is the most popular ORM for Python?

The answer here is pretty lengthy, which I appreciate, and says basically the same thing. I like the alternative suggestions too.

The last bit is helpful too:

I think this is a recent addition to Copilot as I don't remember this being an option before - but I get flipped in to Agent mode and things are set up for me, which is great.

I have time to get up, get a coffee, go to the gym, and call my friends, because I'll be here for a while...

Oops. Not That. Uh Oh.

This is another difference between Claude Code and Copilot: Agent mode in Copilot will go off unless you pause it.

This is what I ended up with after a few minutes:

I have the foundation of a decent Python project here, which is considerably more than I asked for. This would be my fault, of course, because I just went with the follow up question when asked the question:

Want me to set up a SQLAlchemy-based project structure for your ecommerce API?

I probably should have said no, and used my prompt "show me an example in context".

Oh, wait, I can!

Copilot gives you a way to "back out" of any changes the Agent makes:

You can pause (or in my case hit "Cancel" when prompted for a shell command) and then click "Undo". To keep the changes, you obviously have to hit "Keep".

This works pretty well with code changes, but it won't delete files, which makes sense because how would it know if it created those files in the first place? There probably is a way to know, but... whatever, here's what happens when I hit "Undo":

I have a bunch of empty files. No biggie - I can delete those myself, and I will!

Next, I'll prompt Copilot in the same way I did with Claude Code: Show me an example in context...

Out comes a bunch of code which I can then review. It's the same LLM (Claude Sonnet 4) so I'm not going to compare/contrast the answers, but it's a much different process.

Here's where we leave off, without a followup prompt:

Which is too bad because it would seem to be a natural place to ask: "should I create these files for you?". I can do that myself, however, by switching in to Agent mode and prompting create these files (I did, and it did).

How To Undo Things In Claude Code

There are two ways I learned to undo things with Claude Code:

• Get good at Git. Make sure you're working in a branch and you're comfortable rolling back to HEAD or the last commit.
• Ask Claude to undo itself.

I've used both ways and honestly haven't had a problem. The Git solution feels the most natural by simply using git checkout --, which rolls back to the last commit.

Asking Claude to undo its own changes is obviously a gamble, but it worked perfectly the three times I did it. It takes longer, but if you haven't committed your changes in a while, this might be your only way out.

Summary

The VS Code team could learn a thing or two about the natural workflow of Claude Code, leveraging follow up questions and working off a task list. It feels so much more intuitive and simple to understand.

The Anthropic team could learn a bit from VS Code about using Undo. This one seems super obvious, and I can't imagine it's not coming in some form. Then again, the Unix world has a great philosophy: do one thing well. Git is really good at version history, why reinvent the wheel?

As for me: I love Claude Code and will definitely continue to use it as my go-to. I'm a terminal person anyway, and happy to lean on it more.

Have any recommendations for me? Let me know!

One thing I love to do when using an AI assistant is to have it explain things to me. I read a lot of example code when I'm building something new and I often find the documentation to be ... let's say challenging. When this happens, I point Claude at the URL and have it expand on the thing I'm missing.

For instance: I use Nuxt Content on my other site, bigmachine.io, and the search feature does a fuzzy string match - that's it. I know there is a better way - so I can just ask Claude (using Claude Code):

Learning Something Completely New

Before I get into this: yes I'm well aware that Claude and any other LLM can and will hallucinate. That's part of the process - validating and making sure what you're told is correct.

I don't think it's all that different from learning from a human if I'm honest. How many times have you watched a course on Language X or Framework Y and thought "hang on, I know that's not correct!" This happened to me with Elixir a few times, and I even read some "not so good stuff" in a very popular book.

That said, and returning to the land of the positive, you can have your LLM check itself and see if there are ways to improve, and explain what the improvement is and then, this one is hugely important, cite its sources.

You're still going to end up with some questionable code, but this is where we get to talk to other humans and go through a review. Maybe a friend online or someone willing to help you out.

Today's Video: Let's Learn Python

Python is one of those languages I've been meaning to learn forever. I'm not sure why it hasn't stuck and JavaScript has, but today I decided to dig in and play around, with the goal of learning something new.

I'm using Claude Code today with Claude Sonnet 4, expanding my horizons from my typical use of Copilot. I loved the experience, and recorded all of it. I had a ton of fun and address code quality throughout.

Hope you enjoy!

I created 10 or so workshop outlines during my time at Microsoft. Most started out at hour-long presentations that I built on top of and others got into the weeds quickly. Some were completely customized for the team I was working with too.

This workshop is for people getting started and has super simple steps for seeing what AI can do for you. It's a shorter one and usually lasts for an hour two if we stretch it, which is easy to do because it's damned fun.

I'm once again using Copilot as that's what I'm used to working with, but I might do a variation of this with Python and Claude Code, so look for that in the future.

Focusing on Iterative Exploration

That's the simple idea behind this workshop: using AI to think through a problem domain. I'm using my old go-to here, an eCommerce application, but you can apply this process to anything your trying to build out, including:

• A new application you're starting from scratch.
• A new feature you want to add to an existing application.
• A rewrite/refactor

The idea is straightforward: you write out what you want to do in a spec, just like you normally would, but this spec is for your AI tool of choice. Keep things terse and simple with lots of bullet points, like this:

# The Red:4 Store

This is an ecommerce store that will deliver both digital and physical goods. To do this we need to track:

 - `products` with a sku, name, price, description, and type (digital, hardware, kitchenware, clothing, etc).
 - `inventory` that tracks products and their stock levels as well as location. For digital products, this should indicate download URL.
 - `orders` with a unique, random `number`, `total` in pennies, `date`, `status`, `transaction_id` if it's checked out.
 - `customers` with unique email, name, lifetime value

This is a decent place to start, and the most important thing is that we can iterate on this as we go along. Copilot (the tool I'll be using) will do the "heavy lifting" on this, creating the boilerplate code that slows us down.

If we miss something, we can stop and go backwards and redo. It's OK! Copilot is extremely fast compared to me writing out all this code, so redoing something is not a complete loss. In fact, I think it's encouraged.

Clearer Instructions Mean Smaller Prompts

The more context you add to your instruction set, the smaller your prompts can be. If you're using Copilot, these instructions go into the .github/copilot-instructions.md file. For Cursor, you use Cursor Rules. If you're using Claude Code, you pop the instructions into CLAUDE.md in the root of your app.

Just about every AI coding tool out there gives you the ability to prepend text to your prompts, and it makes all the difference.

Here's the prompt I used to get started in the video below:

Generate the initial SQL file and put into db/schema.sql

That's it! When working with file creation you do need to get specific with the LLM, ensuring you give it a path and extension otherwise it'll make up whatever it thinks you want.

Once the schema is generated, go over it (as you should) and, if you find any issues, update your instructions.

For instance: I like integer primary keys called id that are auto-incremented. I like using text instead of varchar in every case (it's a PostgreSQL thing), and a few other preferences.

This type of thing is perfect for custom instructions, so we can add it in, right below our spec:

## Database

 - Database tables will be lower cased using underscores.
 - Every table will have an auto increment integer primary key called `id`.
 - `users` will not store passwords, only social login information as well as magic email links.
 - `char`, `varchar` and `nvarchar` are never to be used for string fields, only `text`.
 - Every table should have `created_at` and `updated_at` timestamps.
 - Many to Many relationships will have compound primary keys, never a single ID with compound unique.

You can then add coding standards as well as test preferences. I'll devote an entire post to that one as testing is one area where AI tools can really help.

Here's a gist with the markdown snippets I use, which vary from project to project of course. These get me started, which is nice:

Code style Snippets

Code style Snippets. GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

Generating Test Data

A lot of people don't know you can do this - but generating test data with a tool like Copilot and Claude Sonnet 4 (my LLM of choice) is ridiculously simple:

Create some test data for the database and put it in db/test.sql. Make sure the data is obviously fake and have some fun, but not too much fun. Add 10 products and 10 orders with necessary accompanying data.

After a few seconds, this is what I got back (a small sample of the whole thing):

INSERT INTO products (sku, name, price, description, type, download_file, created_at, updated_at) VALUES
('DIG-001', 'Quantum Meditation App', 999, 'Achieve inner peace through quantum entanglement guided meditation sessions', 'digital', 'quantum-meditation-v2.3.zip', '2024-01-10 09:00:00', '2024-01-10 09:00:00'),
('HW-002', 'Self-Stirring Coffee Mug', 2495, 'Never worry about stirring your coffee again with this battery-powered stirring mug', 'hardware', NULL, '2024-01-12 10:15:00', '2024-01-12 10:15:00'),
('KIT-003', 'Levitating Spice Rack', 8999, 'Magnetic levitation technology keeps your spices floating in perfect organization', 'kitchenware', NULL, '2024-01-15 11:30:00', '2024-01-15 11:30:00'),
('CLO-004', 'Invisible Socks', 1299, 'So comfortable you will forget you are wearing them (Warning: Actually invisible)', 'clothing', NULL, '2024-01-18 14:45:00', '2024-01-18 14:45:00')

At that point you can step into the terminal and, once again, ask Copilot to generate the command for you to create a SQLite database with the schema and test data (use CMD or CTRL-I):

If you're interested, I recorded doing all of this below. Total time IRL is about 16 minutes, but I chopped some elapsed time out for watchability.

Hope this helps!

Rob

I talk to "AI-curious" people just about every day, and almost without fail the first thing they ask me (after they tell me they're sick of the AI hype):

I would probably use it more but I apparently suck at prompting.

I blame this issue on the people who make the tools: there are too many engineers involved in the process. This was one of the main problems I had at Microsoft - trying to get the engineers working on the Copilot extension to unload some of the "visual weight" of the prompt box:

Even the placeholder here doesn't make sense: Edit files in your workspace in agent mode. What's "agent mode" and how is it going to edit my files? For someone new to all this, that doesn't sound exciting (having AI edit your files for you).

I don't mean to unload on the VS Code team. They're great people whom I consider friends. They would be the first to admit that the UX needs some polish and that they'll get there. That's great - it's my job (at least now) to nudge that process along.

Cursor is only slightly better, but even then their placeholder is meaningless nonsense:

Let's (Re)Start Here

Perhaps the thing that frustrates me the most is the engineers are allowed to name things. You have "modes" like "Agent", "Edit", and "Ask". Those aren't modes! One is a noun and the last two are verbs.

Cursor does kind of the same thing, but somehow causes more confusion:

Manually decide what now?

Let's be constructive. The main difference between these "modes" is that you can explore (Ask) and then have the AI tool actually perform edits and tweak your code for you. Why are these "modes"? It's more of a process where you explore and then execute.

There's a marketing aphorism that I love, and I think it's playing out realtime with the AI adoption in code editors:

Confusion means "no"

If you confuse your customer in any way, they will simply walk away because people don't like to be confused. It's uncomfortable. What they want is simplicity and to feel like what they're doing with your tool is simple and therefore elegant. Which also means "powerful".

Loading up the visual field with icons and meaningless text is not simple. Slicing up a simple workflow into "modes" that the user has to understand before doing something that is quite natural (asking a question) is the opposite of simple.

My entire point here is that if you're feeling confused, you're not alone and it's not at all your fault. We could have done better here. All of that said: let's see how to work with what we have.

The First Rule of Prompting: It's a Machine

One of the most difficult things to remember is that whatever LLM you choose is just a machine algorithm. It uses statistics to figure out an appropriate answer, and relays it to you in an all-too-human tone.

This makes it difficult to remember that you're querying, not conversing. There is no person answering your question, which means you must let go of conversational norms.

To that end, you:

• Don't have to say "please"
• Don't have to structure your sentences or "ask" for anything. Tell it what to do, clearly.
• Can use what I like to call "some pepper" if things aren't going right. For some reason, it's programmed to understand your tone.

The Second Rule of Prompting: Knowing What You Don't Know

Most programmers expect AI to generate code which will probably be "crappy". If there's an inverse to the AI hype, it's AI FUD.

AI is a tool that you can and should use to increase your efficiency and therefore your value to your client or company. That means you need to experiment to see where you can maximize this help.

Here are some ideas for you:

• Make it generate your commit message for you. You'll want to customize how this is done, and we'll go over that next.
• Have it create utility scripts to do that annoying task you've been meaning to do. For instance: if you have a blog, you can create a task to find 404 image links or resize big files.
• Use it to think through a domain problem. For instance: I used it recently to scheme out an email sequencer for my mailing list.

Use AI to explore. Have it run tasks for you that you don't want to do and never assume that it can't do something or just won't know what you mean.

Let's look at an example. One of the tasks I always put off is creating a remote repository on GitHub for a new local project I'm working on. I have the GitHub CLI tool installed (gh) but I just haven't taken the time to learn it.

This is the perfect task for AI. Here I'll use Copilot in "Ask" mode to see what it will create for me:

create a bash script that will create a GitHub repo for this project using the gh CLI tool, and add the remote repo to the local one as "origin"

There are a few things to notice about this prompt:

1. It's terse and direct.
2. I've spelled out a few details that are important: using the CLI tool, adding a remote repo, and finally the name.
3. The prompt is small.

If you imagine your LLM is a 15 year old programmer, it really helps. You have to spell things out a bit more and do it in simple language. The more you do it, the easier it gets.

Here's the result by the way:

#!/bin/bash
# filepath: create-github-repo.sh

# 🚀 Creates a GitHub repository and adds it as origin remote

# Get the current directory name for the repo name
REPO_NAME=$(basename "$PWD")

echo "Creating GitHub repository: $REPO_NAME"

# Create the GitHub repository (private by default)
gh repo create "$REPO_NAME" --private --source=. --remote=origin --push

echo "✅ Repository created and remote 'origin' added successfully!"
echo "🔗 Repository URL: https://github.com/$(gh api user --jq .login)/$REPO_NAME"

It's likely you won't get exactly what you need the first time, and that's OK too! Maybe I don't want the emoji here? That's OK - just add a new prompt that says exactly that: remove the emoji. Don't worry about being nice, just get the work done.

The Third Rule of Prompting: Customize!

When I was at Microsoft giving Copilot workshops to internal engineering teams, I would repeat the same phrase perhaps 10 times:

The best prompt is the smallest prompt

Customizing your AI sessions is absolutely paramount to getting answers that make sense! Not only that, but if you're instructions are clear and concise enough, you can get away with writing smaller prompts because you don't have to include all of that context.

The reason you see emoji in the script above is because I have custom instructions set up for the project. In the instruction file I have added this:

## Code Style

Every method should have a simple comment that explains what it does. Don't do this for private methods, only public. Add emoji.

There are other things too, but this is the biggest one. Go back up and read the script - Copilot did exactly what I asked it to do.

Here's how to set these things up:

• If you're using Copilot, create a directory and markdown file in the root of your workspace at .github/copilot-instructions.md. In that file you let Copilot know your styles, domain context, and more. I'll talk about that in a minute.
• Cursor allows you to create rules that get applied based on configuration settings. They work much the same as Copilot, with some slight variations but in the end it's just markdown with some stored prompts.
• Claude Code (which I'll talk about in another post) will look for a CLAUDE.md file in the project root. Same deal: text that gets prepended to your prompts to provide context.

These instructions are incredibly powerful. Here are more instructions from the project I discussed above, but this time they're about testing. I'm using Jest to test some Vue code, and I have a particular way I want the tests written, so I'm giving Copilot a template:

Use this exact pattern for all tests:

```ts
import { someMethod } from "./some_service.ts";

//The happy path, when everything works
describe("The thing I'm trying to test", () => {
  //arrange
  let testThing;
  beforeAll(async () => {
    testThing = await someMethod();
  });

  //act
  it("will initialize", async () => {
    //make sure the testThing initializes properly
    //assert
    expect(testThing).toBeDefined();
  });

  //rest of tests go down here
});

//The sad path, with error conditions
describe("The things I'm trying to avoid", () => {
  describe("Error conditions with initialization", () => {
    //act
    it("will throw an X type error with message Y", async () => {
      expect(someMethod(badData)).toThrowError("Some message");
    });
  });
  describe("Another set of error conditions", () => {
    //act
    it("will throw an X type error with message Y", async () => {
      expect(someMethod(badData)).toThrowError("Some message");
    });
  });
  //rest of tests go down here
});
```

This took me a while to tweak and get right, which was actually a fun process. I would roll back whatever the agent created for me, tweak my instructions, and then try again.

I'll discuss templates and instructions more in later posts and videos.

Just Keep Prompting

The best way to get off the ground using LLMs is to keep using LLMs. This is a tool you will have to master because they save your company time and money, and there's no way you're going to talk people out of that, especially with the argument "yeah but it also generates crappy code we'll need to fix later".

You're already doing that, friendo. We're only human, we don't write very good code no matter how experienced we are. Take a look at some code you wrote 2 years ago and confirm that for yourself. Or, better yet, ask someone you respect and admire what they think about their own code from years back.

I'm not trying to say that LLMs will write better code. They'll just write code - it's up to you to shape it to how you need it, and you do that through practice.

Just like any tool.