Every few days there is a new list. The nine Claude Code plugins you must install. The fourteen things that changed everything. The skills framework you are apparently missing out on.

A developer in my community reads these obsessively, and he made an observation last night that I have not stopped thinking about. Some of them are from March, which makes them completely obsolete. And then the part that mattered: he does not think you need any of it. You tell the thing what you want, clearly, and it figures out the rest.

I agree with him, and this is not laziness or contrarianism. There is an actual argument, and I want to make it properly.

If you would rather see it than read about it

Everything I am about to argue for is in the Blazor AI Workshop. Three hours, recorded live and unedited, empty folder to a Blazor app deployed on Azure. No plugins, no frameworks, no skills. A constraints file, an architecture, and a lot of reading what came back.

It is the principle applied to a real build, including the parts where something does not work. You can get it here.

Now, the argument.

I tried skills. I dropped them again.

Let me be specific rather than vague, because I do not want this to read as dismissing something I never used.

When skills arrived, I tried them. I set some up, used them for a while, and then quietly went back to what I was doing before.

Not because they are bad. Because what I already had was doing the same job.

What I already had was markdown files. A constraints file that describes the architecture and the rules. Notes files where decisions get written down. That is it.

And every time I look properly at one of these new mechanisms, I find myself asking the same question: what does this do that a well-written file in my repository does not?

Sometimes there is an answer. Often there is not.

The pattern I keep noticing

Here is a small example from the same conversation.

One of these lists recommended a compact command as a great tool. Compact your context when it gets long.

Except the tool already does that automatically. So the recommendation is to manually trigger something that happens on its own.

And honestly, when I see automatic compaction happen, my first thought is usually mild worry. What did it just decide was unimportant?

Someone in the session suggested the obvious alternative: start a fresh session and keep the old one open if you need to go back to it. No feature required. Just a second terminal window.

That is the pattern. A capability gets a name, the name gets a list post, and the list post gets shared as though something fundamental changed.

Why the churn is so intense right now

I do not think the people writing these lists are acting in bad faith. Something more mechanical is going on.

The tools genuinely are changing fast.

New features appear constantly. Some of them are significant. So there is always something new to write about, and no reliable way to tell in advance which ones matter.

Novelty is easier to write than judgment.

"Here are nine new things" takes an afternoon. "Here is what actually held up over six months" takes six months.

And nobody publishes the negative result.

I tried skills and went back to markdown files. That is a genuinely useful data point and it makes a terrible headline.

So the visible conversation is systematically biased towards new, and away from durable.

What actually holds up

Here is the thing that has survived every tool change I have been through.

Write down what you want, where the thing can read it.

That is the whole idea. The architecture. The patterns you use and the ones you have banned. The decisions that are not visible in the code. What is off limits.

Call it a constraints file, call it a memory file, call it a dev bible like one member of my community does. The name does not matter. The mechanism does not matter much either.

What matters is that the thing doing the work can see what you have decided.

I keep arriving back here from completely different directions.

I was rebuilding an old side project recently, a game I had abandoned eighteen months ago. Different domain, different language, nothing to do with .NET. And within an hour I was telling it to write notes into markdown files. A notes file for problems, a feedback file for what I did not like, an inbox for ideas to handle later.

Nobody told me to do that. It is just what works, and it is what I end up doing regardless of the project or the tool.

How to evaluate the next shiny thing

I am not saying ignore everything new. Some of it is genuinely useful. Loops and goals changed how I work, and I would not want to go back.

So here is the test I actually use.

Does it do something a file cannot?

If a plugin's value is "it gives the model some instructions", you already have that. If it does something structurally different, like running work while you are asleep, that is worth attention.

Does it survive a tool change?

Markdown in your repository works everywhere, including in tools that do not exist yet. Anything living inside one vendor's session state is temporary by definition.

Is it solving a problem you actually have?

Most of these lists are written by people whose workflow is not yours. Security plugins, code review frameworks, front-end designer skills. If you have not personally hit the wall, you are buying a solution to a hypothetical.

And would you notice if it disappeared?

This is the one I like most. I stopped using skills and my work did not change. That told me everything.

The thing underneath

All of these mechanisms are variations on one idea: give the model relevant context at the right moment.

Skills do it. Constraints files do it. Plugins do it. Subagents do it, with the added benefit of keeping the reading out of your main session.

They are flavours of the same thing.

Which means if you understand the underlying idea, you can evaluate any new mechanism in about thirty seconds. And if you do not, you will keep installing things because someone said they changed everything.

The underlying idea has not changed in two years, and I do not think it is going to. Everything else is packaging.

If you want to watch the principle applied end to end, the Blazor AI Workshop is three hours of exactly that, with the full source code and a thirty day money back guarantee.

And if you are earlier on and want the foundation first, my free Blazor AI Jumpstart is here, at no cost.

Learn the principle. The features will keep arriving without your help.

Take care.

In February, a group of us got on a call and talked about migrating to Blazor Web Apps, Azure, and how to choose an architecture.

AI barely came up.

Last week, the same fortnightly call was about billions of tokens, what corporations are allowing their developers to run, and who actually gets to decide the architecture now that a model can propose one.

Six months. Ten sessions. Roughly sixteen and a half hours of recorded conversation.

I did not set out to document anything. I just kept turning up every two weeks with a group of working .NET developers and talking about whatever was in front of us. But looking back at the titles in order, there is an arc there that I did not notice while it was happening, and I think it is worth writing down.

Subscribe now

February: AI was not the subject

The first session was about architecture choices and moving to Azure. Ordinary, durable .NET concerns. The kind of conversation we could have had in 2022.

That is worth remembering, because six months is nothing. Half a year ago, a room of serious .NET developers could spend ninety minutes together and treat AI as a side topic.

March: it arrives, as a tool among tools

Session two was AI tools and Copilot, sitting alongside Blazor render modes. Note the framing. AI was one item on a list, roughly equal in weight to a rendering decision.

Most people I speak to are still, mentally, in March.

May: the reality check

By May the tone had changed. Not to enthusiasm, to scepticism. The session was a reality check on Claude Code, Copilot, agents, and what became the markdown file workflow.

This is the point where people had used the tools enough to be disappointed by them. Confident nonsense. Invented packages. Code that does not compile.

And it is exactly where the constraints file emerged, because a room full of people hitting the same wall independently starts looking for a way through it. Two weeks later the session was called "Beyond Copilot," which tells you which way they went.

June: the terminal, the loops, and the money

June is where it gets strange, in a good way.

First, people moved into the terminal and started leaving work running overnight. Someone described their loop as a night shift, which is a phrase I have used ever since.

Then, two weeks later, the token cost scare.

This one deserves more attention than it gets. A developer looked at their usage, saw a number, and had a genuine fright. Not because they had done anything unusual, but because the pricing model was impossible to reason about. One person put it plainly: they understand what a hundred a month means, they cannot calculate what a per-million-token price means for their actual work.

That session ended on why we still steer, which was not a coincidence. When the meter starts running, you stop letting the thing wander.

Then: MCP routing, and someone coding from their phone while away from their desk.

July: the moat question

July was the month it stopped being about tools and started being about people.

The mid-month session was legacy migration, which sounds technical and was not. A contractor who has spent two decades modernising old systems described watching the barrier that protected his niche dissolve. Old code was hard, that hardness was the moat, and the tools are unreasonably good at exactly that.

Two weeks later, the other side of the same coin. Someone had documentation, deployment configuration and change logs he had never typed a line of. Someone else pointed out that none of the rest of us could build what he was building, because we lack the years of financial expertise that tell you what a correct answer even looks like.

That was also the session where someone admitted he could not sleep, because he was too excited about what he could build in the hours he was about to waste being unconscious. Somebody else in the room called it an emerging illness among programmers. Nobody laughed, because everyone recognized it.

August: governance and judgment

The most recent session was about corporate limits on what developers are allowed to run, and who picks the architecture now.

Both of those are governance questions. Not technical ones.

Six months ago we were choosing between render modes. Now we are working out who is accountable when a model proposes a structure and a person approves it.

What the arc actually shows

Four stages, roughly, and they happened in this order:

Tool. Something you might use, alongside other things you use.

Workflow. Something you build a process around, with constraints, because unconstrained it produces plausible mess.

Economics. Something with a meter attached, which changes how you use it in ways nobody warns you about.

Judgment. Something that raises questions about accountability, expertise, and what you are actually being paid for.

Most public conversation about AI development is still stuck at stage one, arguing about which tool is best. The developers I sit with every fortnight went through all four stages in six months, and they did it because they were using this stuff on real client work with real money attached.

That is the thing I did not expect when I started these sessions. I thought I would be teaching. Mostly I have been taking notes.

Why I am writing this down

Two reasons.

The first is that six months moved faster than any six months I have worked through, and I suspect the next six will too. Having a record of what people actually believed in March, and how wrong some of it turned out to be, seems worth keeping.

The second is more practical. Those ten sessions are sixteen and a half hours of recorded conversation, and they sit inside the .NET Web Academy All Access Pass. Not as a bonus. They are the part that cannot be recorded in advance, because by the time I edited a course about June, it would be August.

If you want to be in the room for the next ten, that is what the membership is for. Twice a month, no slides, no agenda, whatever people bring. Every session recorded, so it’s in the middle of your working afternoon, you watch it later.

Join the All Access Pass

The full course library and all the source code come with it. But the sessions are the reason it exists.

Session eleven is on Tuesday, August 25. Join before then and you are in the room for it.

I have no idea what it will be about, which after ten of these is the part I have come to like most.

Take care,

Patrick

Subscribe now

There is a developer in my cohort who built an entire career on one bet.

The bet was this: young developers do not want to touch old code. They want green fields, new frameworks, the shiny thing. So the old systems, the ones quietly running real companies, would always need someone. He would be that someone. Legacy modernization as a niche, all the way to retirement.

For twenty years it paid. And then AI arrived and went straight for the part he thought was safe.

He called it a black swan. I want to tell you what actually happened to his niche, because the same thing is happening to yours. And then I want to give you the method, the one he uses now on real client systems, because the story on its own is not much use to you.

Modernizing old apps with your team

If your team is sitting on an aging .NET application, an old Web Forms system, an early MVC app, a desktop tool everyone is afraid to touch, and you want your developers to modernize it with AI instead of rewriting it by hand over months, that is exactly the kind of work I now run private workshops for. One focused day, your codebase, your team. You can request a team workshop here.

Now, back to the bet.

The niche that was supposed to be safe

His logic held for two decades, and honestly it was good logic.

He and his partners find what he calls a cash cow business. A company whose software still works, still makes money, but has aged badly. Web Forms. Early MVC. A desktop tool that three people understand and everyone else is afraid to touch. And they modernize it. His phrase for it is make it great again.

The work is unglamorous. It is high trust. It pays extremely well. And almost nobody young wants to do it, because there is no conference talk in migrating a fifteen year old billing system.

That scarcity was the entire moat. Old technology was a barrier to entry, and the barrier is what kept the work valuable.

Then large language models learned to read old code better than most humans can.

Why AI is so good at legacy code

Here is the thing most developers have backwards.

The hardest part of modernizing a legacy system was never the typing. Anyone can type. The hard part was the understanding.

You inherit a solution with thirty projects. Strange patterns. Three different approaches to data access because three different contractors passed through. Decisions nobody remembers making and nobody dares reverse. And before you can safely change a single line, you have to reconstruct the whole thing in your head.

That reconstruction used to take weeks. Sometimes a month of billable time before the client saw anything at all.

Now you point a capable model at the entire solution and within hours you understand the architecture. What calls what. Where the risk is concentrated. What the previous developer was trying to do, and where they gave up.

Another developer I know, someone with a master’s degree in AI from the nineteen eighties, did exactly this. He fed a whole multi-project solution to a model and a couple of hours later he could talk intelligently about tradeoffs that would previously have taken him a week to even see.

Notice what actually happened there. The AI did not replace his judgment. It removed the slow, expensive, boring part that used to sit between him and his judgment.

The black swan

So he called it a black swan, and I think that is exactly right. The thing that was supposed to protect his niche, the difficulty of old code, is the thing AI is best at dissolving.

But look closely at what did not change.

The client still needs someone they trust to make the call. The AI can explain a legacy system in two hours. It cannot decide what to keep and what to kill. It cannot tell you which risk is acceptable on a system that moves real money. It cannot sit in a room with a nervous CTO and say, we migrate this piece first, and here is why.

Someone has to steer.

So the niche did not disappear. It compressed. Work that took months takes weeks, which means he takes on more of it, delivers faster, and charges for outcomes rather than for the time he used to spend deciphering.

The moat moved. It used to be “I can understand this old code and you cannot.” Now it is “I can direct AI through this old code with judgment, and catch it when it is wrong.”

Here is how that is actually done.

Step 1: The understanding pass, and do not write any code

Your first session with a legacy codebase is purely about understanding, and you let the AI do the reading.

The mistake almost everyone makes is opening with something like “modernize this application.” That prompt is worthless. It is too big and too vague, and the model will confidently produce something plausible and wrong.

Ask narrow questions with verifiable answers instead:

• Map the projects in this solution and tell me what each one is responsible for.

• Trace what happens when a user submits an order, file by file.

• Where does this application talk to the database, and how many different ways does it do that?

• Which parts of this codebase have no tests at all?

That last one is gold, because untested code is exactly where your migration risk lives.

And then verify two or three of the answers yourself. Open the files. Check it has not invented a service that does not exist. You are calibrating how far this model can be trusted on this specific codebase, before you let it write anything.

Step 2: Write the rules down where the AI reads them

Before any code gets generated, you write your constraints into a file the AI reads every single time. I use AGENTS.md.

On a legacy project this is not optional. It is the highest leverage thing in the entire workflow.

What goes in it:

• The target architecture, explicitly. If you are moving to vertical slices, say so, and describe what a slice looks like in this project.

• The .NET version you are actually on, or it will happily write code for one you do not have.

• The patterns you want, and just as importantly the ones you have banned.

• Which folders are off limits entirely.

• How data access is done now, not the three legacy ways it used to be done.

• And one line that saves enormous pain: do not add NuGet packages without asking me first.

Because here is the failure mode every experienced developer hits. Left unconstrained, the model invents things. It hallucinates packages that do not exist. It writes code that does not compile. That is the moment people give up on AI and go back to typing everything by hand.

Constrain it, and the exact same model becomes reliable and genuinely fast.

That is the whole difference. Not a better model. Better boundaries.

Step 3: Migrate one vertical slice, not one layer

This is where a lot of migrations die.

People modernize horizontally. All the data access, then all the services, then all the UI. And halfway through you have an application that is half old and half new and entirely broken, where nothing works until everything works.

Take one feature instead. The whole thing, top to bottom. One screen, its endpoint, its data access, its tests. Get it working in the new architecture while the old system keeps running around it.

The old name for this is the strangler fig pattern. New code grows around the old system, feature by feature, until one day there is nothing left of the original. It worked before AI. It works dramatically better with AI, because each slice now takes hours instead of days, and you can ship one a week to a client who can actually see it.

You always have something demonstrable. That matters more than people admit when someone is paying you for a migration.

Step 4: Review it like a pull request from a talented junior

You read everything.

The contractor I opened this piece with still works in Visual Studio, still reviews every change, still participates in the entire process. He is not sitting back while it works. He is directing and checking, constantly.

Treat the output like a pull request from a talented junior who has never seen your business. Fast, capable, occasionally confidently wrong, and not accountable for what ships. You are.

And one more rule that is worth actual money. If it fails at the same thing twice, stop. Do not let it try a third time.

When a model is stuck, it does not get unstuck by retrying. It burns your budget going in circles and you finish the day with nothing to show. I know a developer who lost an entire working day and his whole monthly token allowance doing exactly that on one stubborn problem. When it fails twice, pull back and make the task smaller.

Where this leaves you

The barrier that protected legacy work is gone. That is real. If your value was purely that you could read code nobody else wanted to read, that value is falling.

But the work did not vanish. It got faster, which means there is more of it, and the people who can direct AI through a difficult system with judgment are worth more than they were two years ago, not less.

That is the skill. Not typing faster. Directing well, and knowing when it is wrong.

If your team is facing an old .NET system and you want them to learn to modernize it with AI properly, with control instead of chaos, that is exactly what I teach in private workshops. One day, your actual codebase. Request a workshop for your team here.

And if you want to build this skill yourself first, I put the whole foundation into a free course, the Blazor AI Jumpstart. It costs nothing and it is the fastest way to feel this workflow for yourself.

Take care.

AI has made me more productive than I have ever been.

Which is why I keep getting stuck on one question.

Why am I working more than ever, not less?

This was supposed to buy me time

That was the promise, was it not. AI does the heavy lifting, and you get your evenings back.

The productivity half is real. I am building things in hours that used to take weeks, shipping more than I ever have.

But the more-free-time half has gone the other way for me. I find myself back at the screen after dinner, thinking, if I just send one more prompt, I can get three more hours of work done while I do something else.

And when I talked about this with other experienced developers recently, they had all fallen into the exact same pattern. So I want to be honest about what is actually going on, because I think a lot of us are walking into this without noticing.

Subscribe now

AI removed my off switch

Here is the mechanism, and once you see it, you cannot unsee it. AI did not just make each task faster. It removed the friction that used to make me stop.

It used to be that by the end of the day, the work was genuinely hard. My brain was tired. Building the next feature meant real mental effort, so at some point I would stop, because I was spent.

The difficulty itself was a built-in off switch. I worked until I could not, and then I went and had a life.

Now the next feature is one prompt away. It costs me almost no energy to set three hours of work in motion. So that natural stopping point is gone. I am not drained in the old way, because the AI is doing the heavy part. So I just keep going. One more prompt. One more thing. Each one is so cheap to start that there is no reason, in the moment, to stop.

Easy work does not mean less work

So the productivity did not buy me free time. It raised my appetite for output.

That is the trap. When work becomes easy, you do not do the same amount in less time and then relax. You do far more, because there is always one more cheap prompt to send. The ceiling that used to be my own exhaustion just vanished, and nothing rose up to replace it.

And it is a sneaky trap, because it does not feel like overwork. It feels wonderful. It feels productive. You are shipping more than ever.

But you are also at the screen after dinner, prompting from your phone in the grocery line, running six projects at once. Which, if I am honest, is not good for my brain, and I know it even while I am doing it.

The off switch has to be a decision now

So here is where I have landed, and I am still very much working on it.

The off switch used to be automatic. It was my own tiredness, and I could trust it to stop me. Now I have to install the off switch manually.

The boundary has to be a decision, not a feeling. Because the feeling, I am not even tired, I could easily do one more, is exactly what runs you into the ground. You do not get the warning your body used to give you, because your body is not doing the hard part anymore.

The whole promise of this technology was that we would work less, not that we would each run a tireless night shift we feel quietly obligated to feed. And if you are not deliberate about it, you get the second one. More output in the same hours, or more hours, and a mind that never gets to clock out.

Subscribe now

The skill nobody talks about

So the real skill here is not a coding skill at all. It is knowing when to stop when nothing is forcing you to.

That might be the most important thing I am trying to figure out right now, and I do not have it solved.

If you are feeling more productive than ever and somehow also more drained, you are not doing it wrong, and you are not the only one. The tool removed your natural off switch. You have to put a new one back in on purpose.

So be more productive, and then actually take the time it gives you back. That is the part I keep forgetting, and I am starting to think it is the part that matters most.

If you want to get the productive part right, building with AI on a foundation you actually understand so the time savings are real, I made a free course that walks you through exactly that setup. It is the free Blazor AI Jumpstart: grab the free Blazor AI Jumpstart here.

Then go install your off switch.

Take care.

Subscribe now

I want to admit something that is a little embarrassing for someone who builds software for a living.

I barely open my own tools anymore.

Quick context on why that is a strange thing for me to say.

I have been writing code for almost 30 years, from QuickBASIC and Turbo Pascal as a kid to about 20 years in .NET. I have built SaaS products, line-of-business apps, even video games. These days I teach thousands of developers, and I build my own tools.

Two of them are StackBuddy, which runs my Substack, and TeachStats, which tracks my business. I made them. I rely on them every day.

And lately I drive both of them, plus Kit for my email, entirely through Claude over an MCP connection, without opening their dashboards at all.

Instead I sit in one place, my terminal, and I talk to an AI.

Draft three Substack notes in my voice and schedule them. What did my last launch email actually convert? Pull my recurring revenue and tell me what changed this month.

It does all of it, across all three tools, and I never load a single web page.

The first time it really landed, I got that small jolt you feel when something has quietly changed and is not changing back. The tools did not get worse. The reason to visit them just evaporated.

So here is the thought I cannot put down. In an AI-native web, the tool matters far less than the feature you can reach through one interface.

If you are a .NET developer who wants to get ahead of this shift, that is exactly what I built the Blazor AI Accelerator for.

Four live weeks building real things with AI on a foundation you actually understand, and enrollment is open now.

Join the Blazor AI Accelerator

If you would rather go at your own pace, my All Access Pass is the steady way to get there. More on both at the end. For now, let me show you what I mean.

The app as a destination is dying

For twenty years, the unit of software was the app. You went somewhere. You logged in. You learned its menus and its buttons and its particular opinions about how things should be done.

The interface was the product. A lot of us spent our careers polishing those interfaces.

What is happening now is that the interface is being peeled off the top of the product. Underneath, the valuable part is still there. The data. The logic. The network. The thing the tool actually does. But the front door, the dashboard you used to live inside, is becoming optional.

The mechanism behind this has a boring name. MCP, the Model Context Protocol. Strip away the jargon and it is simply a standard way for a tool to hand its capabilities to an AI. Once a tool speaks it, the AI can use that tool as a set of actions, with no screen required.

I added MCP to StackBuddy and to TeachStats. Overnight, they stopped being places I visit and became capabilities my AI can call.

And the moment that was true for all of my tools at once, my software stopped being a pile of browser tabs and turned into a single conversation.

What AI-native actually means

Let me be precise, because the phrase gets thrown around. AI-native is not bolting a chat box onto the corner of your app. It is the inversion.

The app becomes a set of capabilities. The AI becomes the place you actually work. The polished screen becomes one optional view among many.

The user no longer picks a tool and then hunts for a feature. They state an intent, and the AI composes features across whatever tools can serve it. The boundary between tools goes invisible.

I do not think open StackBuddy anymore. I think schedule these, and the right capability quietly runs, wherever it happens to live.

Once you feel that, going back to clicking through five separate dashboards feels like dialing a rotary phone.

What this means if you build software

If you make things, this is the part to sit with. Build capability-first, not interface-first. Expose what your product can do through an API and through MCP, not only through your own screens.

Because the moat is moving. It used to be your slick interface. The AI is busy commoditizing exactly that.

What it cannot commoditize is the underlying value, the proprietary data, the genuinely hard logic, the network only you have, and whether you are reachable by the AI layer at all. A tool that does not expose its capabilities simply becomes invisible in an AI-native web, no matter how beautiful its dashboard is.

That is an uncomfortable thing to say after a decade where interface craft was the job. But the value is concentrating into two places: what is hard to replicate, and being present in the AI’s toolbox when the moment comes to act.

The catch nobody is selling you

Here is where I climb off the hype train, because there is a real cost and almost no one mentions it.

When one AI interface can drive all of your tools, it can also be confidently wrong across all of them at the same time. The exact orchestration that makes you powerful makes you dangerous the second you cannot evaluate what it is doing.

I have written before that there are two kinds of operator now. The pilot and the passenger.

In an AI-native web that line stops being about a single codebase and starts being about your entire stack. A passenger states an intent and accepts whatever happens across five tools because they cannot tell good from bad.

A pilot knows enough to catch the one action that is subtly wrong before it emails the wrong list of sixteen thousand people, or quietly misreports the revenue they are about to make a decision on.

So the skill that goes up in value is not operating any one tool. It is judgment, applied across an AI that suddenly has its hands on everything you own.

Where I think this goes

Fewer dashboards get visited. Tools start competing to live inside the AI’s toolbox rather than to win one more tab in your browser. Open the app slowly turns into ask for the outcome.

And the products that win are the ones built capability-first, with a human kept firmly in the loop for the part machines are still bad at, which is knowing whether the answer is actually right.

I am not mourning the dashboard. I built a few good ones. But given the choice, I would rather build capabilities that show up wherever my users already are, including inside their AI, than fight for one more icon on their screen.

The future of the web is not more tools. It is fewer interfaces and a lot more judgment.

If you want to be the pilot, not the passenger

This shift rewards the people who can build with AI and still steer it. Here are the two ways I can help you get there.

The fast, structured way is the Blazor AI Accelerator.

Four live weeks, with me and a small group, building real things with AI on a foundation you actually understand, so when the AI reaches for all your tools at once, you are the one flying the plane.

Enrollment is open now.

“I knew how to use Copilot in Visual Studio, but I did not know how to use it efficiently. Confused about skills, agents, copilot-instructions.md files? Hash it all out in this AI Accelerator.” (Jeff, senior software engineer)

Join the Blazor AI Accelerator

And if you would rather go at your own pace, the All Access Pass gives you the full course library, twice-monthly live sessions where we work through exactly this kind of thing together, all the source code, and the community. It is the steady way to keep getting stronger, month after month.

Be the one who can tell the difference.

Take care.

A developer wrote to me this week.

His company is replacing senior roles with mid-level developers. Not because the mid-levels are cheaper, though they are. Because they are faster.

They work with AI in a way he does not, yet.

He watched it happen. Colleagues running several AI sessions at once. Agents writing whole plans from the requirements. Review agents in the CI pipeline. Pull requests flying.

And he sat there, a senior, and realized the ground had moved under him.

He is now looking for a new job. And he said something that stuck with me. He understood the decision. He could see exactly why the company made it.

I want to talk about that, because it is the most important thing happening in our field right now, and almost nobody is saying it plainly.

It is not juniors beating seniors

The headline version of this story is scary and wrong. Juniors are not beating seniors. That is not what is happening.

What is happening is that AI-fluent developers are beating AI-illiterate ones.

Right now a lot of the AI-fluent ones happen to be earlier in their careers, because they had less to unlearn and jumped in first. But the dividing line is not age or years of experience. The line is whether you know how to work with these tools or not.

That is good news, for everyone, at every level.

Because fluency is learnable. If the advantage came from being a certain age, half of us would be stuck. It does not. It comes from a skill, and skills can be picked up by anyone willing to put in a few focused weeks.

So if you are panicking, you have the wrong frame. The question is not how do I compete with younger developers, or how do I keep up with the seniors.

The question is how do I become AI-fluent, fast.

Different question. Much more hopeful answer, no matter where you are in your career.

If that is the question you are asking, that is exactly what I built the Blazor AI Accelerator for.

A four-week cohort that takes a .NET developer and makes them genuinely strong at modern AI-assisted work. Early-bird pricing ends today.

You can have a look here: see the Blazor AI Accelerator.

Join the Blazor AI Accelerator

Now let me make the case for why your experience, however much you have, is worth more in this world, not less.

Why judgment is the thing that wins

Here is the part that should change how you feel about all of it.

AI is fast. It is not wise.

It will write you a hundred lines that look perfect and quietly get the auth logic wrong. It will pick a pattern that works today and rots in six months. It will confidently do the wrong thing.

Who catches that?

The developer with judgment. The person who has seen the failure modes, who feels when something is off, who knows what good looks like. That judgment is the rarest and most valuable thing in an AI-heavy workflow, and experience is how you build it.

So the real winner is not the fastest prompter. It is the developer who pairs judgment with fluency.

The AI handles the speed. The human handles the part the AI cannot do, knowing whether the fast output is actually right.

If you are a senior, this is your advantage, and it is a big one. You already have the judgment. You just need the fluency on top.

And if you are earlier in your career, this is your map: build real fundamentals so you become the person who can tell good output from bad, and pick up the AI workflows alongside them.

The developers who pair those two things are the ones who will be hard to replace, at every level. The ones in trouble, at every level, are the ones who skipped one or the other.

What AI fluency actually looks like

When that developer watched his colleagues, he saw a few specific things. Let me name them, because once they are named they stop being magic and start being learnable.

Running several AI sessions in parallel. Not one chat at a time, waiting. Multiple tasks moving at once, each in its own session, while you steer.

Agentic loops. Giving an agent a clear, bounded task and letting it work through the steps on its own, instead of hand-holding every line.

Agents in the pipeline. Review agents that read every pull request. Planning agents that turn a requirement into a task list automatically.

Connecting AI to real tools. Through things like MCP, so the AI can reach your database, your services, your systems, and actually do work, not just talk about it.

None of that is genius. It is a set of workflows.

Any developer can learn all of it in a few weeks. And the more experience you have to direct it and catch its mistakes, the more powerful it becomes in your hands.

The passenger and the pilot

This is the idea I keep coming back to, and it fits here perfectly.

There are two ways to work with AI. As a passenger, or as a pilot.

A passenger types a prompt and accepts whatever comes back, because they cannot yet tell good from bad. When it works, great. When it quietly breaks, they do not notice until it is too late.

A pilot sets up the flight. They decide the structure, the boundaries, what the AI is allowed to touch. They let it run, and they catch it the moment it drifts, because they understand what it is doing.

And here is the thing. This is not about age.

Anyone can be a passenger. Anyone can become a pilot.

There are seniors who refuse to touch AI and have all that judgment grounded, unused. And there are juniors learning to fly faster than people twice their experience, because they are pairing real fundamentals with the tools.

The trap is not being young or being old. The trap is staying a passenger.

The developer who wins, the one nobody replaces, is the pilot who flies. Judgment plus fluency. That is the goal, at every stage of your career.

The clock is real, and that is okay

I will not pretend there is no urgency. The developer who wrote to me is proof that this is happening now, not in five years. Companies are making these calls today.

But urgency is not doom.

The gap that got him in trouble is a few weeks of focused learning wide, not a few years. He is not behind because he is a senior. He is behind because he waited. The moment he stops waiting, his experience becomes the asset it always was.

Wherever you are in your career, the worst thing you can do is freeze, or decide it is too late and coast.

It is not too late.

If you have experience, you are closer than you think, because you already have the hard part, the judgment. If you are earlier on, you have less to unlearn. Both of those are advantages. Use the one you have.

What to do this week

Do not try to learn everything at once. Pick one thing.

Take a real task you understand well, and instead of doing it by hand, try to direct an AI agent through it. Write the task out clearly. Set the boundaries. Let it run. Watch where it breaks, and learn from that.

Do that a few times and the fear starts to fade, because you see it for what it is. Not a colleague who is better than you. A set of workflows you can learn, and the better your fundamentals, the better you will be at steering them.

The developers who adapt are not going to lose to anyone. They are going to be the ones everyone else learns from.

Be that.

If you want help getting there faster, here are the two ways I can do that.

The fast, structured way is the Blazor AI Accelerator. Four weeks, a small group of developers, working through these exact workflows with me live, the parallel sessions, the agents, MCP, shipping real work. It includes a full year of the All Access Pass on top.

Early-bird pricing ends today. If you want to close the gap quickly, this is the one: see the Blazor AI Accelerator.

“I knew how to use Copilot in Visual Studio, but I did not know how to use it efficiently. Confused about skills, agents, copilot-instructions.md files? Hash it all out in this AI Accelerator.” (Jeff, senior software engineer)

Join th Blazor AI Accelerator

If you would rather go at your own pace, the All Access Pass gives you the full course library, twice-monthly live sessions where we work through this kind of thing together, all the source code, and the community.

It is the steady way to keep getting stronger, month after month: join the All Access Pass.

Either way, do not wait.

Take care,

Patrick

Let me tell you about a developer I talked to a few weeks ago.

Fifteen years in .NET. Genuinely good. The kind of person who has shipped real systems, mentored juniors, and knows where the bodies are buried in a legacy codebase.

And he told me, quietly, that for the first time in his career, he feels like he is falling behind.

Not because he got worse. Because the ground moved under him.

He had watched a developer half his experience use AI to ship in an afternoon what would have taken him a careful week.

And the part that stung was not the speed. It was the quiet thought underneath it: that his fifteen years of hard-won skill had somehow started to feel heavy. Like he was lugging a toolbox to a fight that had moved to a different street.

If any part of that lands for you, stay with me.

Because I think the story he was telling himself is wrong, and I want to show you why, because it changes everything about what you should do next.

Most of us are still working like it is 2018

Same architecture habits. Same workflow. Same mental model we have had for years. And honestly, for a long time, that was completely fine.

It is not fine anymore. AI quietly rewrote the rules of what it means to be a productive .NET developer, and the people who adapted are pulling away from the people who did not. Not because they found the cleverest prompt. Because they changed how they work, at the root.

Here is the part that should give you hope instead of dread: the gap is not talent, and it is not experience.

It is workflow.

And workflow is learnable.

The developer pulling ahead of you is not smarter than you. He just rewired one habit. You can too.

Before I go any further, let me put the offer up front, because some of you already feel this in your gut and just want the door.

I run a four-week live cohort, the Summer Cohort of the Blazor AI Accelerator, where a small group of working .NET developers rewires exactly this habit together, with me.

Early-bird pricing ends July 1. If that's what you want, grab your seat here.

If you want the why first, keep reading.

The trap almost everyone falls into first

When you feel that ground move, the instinct is to reach for the obvious fix. A prompt-engineering tutorial.

A “top ten AI tools” video.

A weekend of watching demos at 1.5x speed.

So you learn a lot about AI. And then Monday comes, and you sit down, and you work exactly the way you did in 2018, with a few more browser tabs bookmarked that you will never reopen.

Nothing actually changed, because watching someone else do it is not the same as it becoming yours.

I know this because I did it too.

My own breakthrough was not a better prompt. It was a completely different relationship with the tool, and I only got there by building real things with it, badly at first, until it clicked.

The shift: stop being a passenger

The developers thriving with AI right now are not the ones typing magic incantations. They are the ones who stay in charge.

They set their projects up so the AI builds their way instead of inventing its own.

They know what to keep and what to throw away.

They treat the AI like a sharp junior partner, not a vending machine you bang on and hope. The result is that AI makes them dramatically faster without quietly turning their codebase into a mess they cannot explain three weeks later.

And here is the reframe for that developer with fifteen years behind him, and maybe for you.

Your experience is not heavy. It is the exact thing that lets you steer the AI and catch it the moment it hands you something that looks right and is quietly wrong.

The junior shipping fast cannot do that yet. You can. That is not obsolescence. That is leverage, if you learn to use it.

But it is a skill. It does not arrive from one tutorial. It comes from doing it, on real projects, with people who push you, until it is yours.

So I built the room where you actually build it

That is exactly why I am running the Summer Cohort of the Blazor AI Accelerator.

Four weeks. Every Wednesday, starting July 15. Ninety minutes a session, live, with me and a small group of working developers.

No slides. No theory dump. We build, we get stuck, and we work through it together, the way the best conversations between developers actually go.

Week one we get your tools and project foundation right. Then we build real features with AI, the kind you will recognize from your day job. By the end you walk away with a repeatable way of working that you trust, not a one-off demo you forget by Friday.

The whole point is that you do not leave with notes.

You leave with a new default.

Do not take my word for it

Here is what two people from the first cohort told me, unprompted.

“I have saved months of effort learning on my own. Working with developers who are also learning and utilizing what they learn in real time and in real world situations has been exactly what I needed to get from A to Z quickly.” (Tim, business owner)

“I knew how to use Copilot in Visual Studio, but I did not know how to use it efficiently. Confused about skills, agents, copilot-instructions.md files? Hash it all out in this AI Accelerator.” (Jeff, senior software engineer)

Notice that neither of them talks about prompts. They talk about how they work now. That is the thing that actually transfers to Monday morning.

What you actually get

Both plans include the same core, and it is more than four weeks. You get the four live sessions, a full year of the All Access Pass with every course and workshop I have made, all the recordings from the first cohort, and an Accelerator-only Discord where the conversation keeps going.

So you are not buying a month.

You are buying a year of getting better, with a live month to kick it off.

• Core is everything above. Early bird $599, normally $799.

• Pro adds two 45-minute one-on-one sessions with me, and it is capped at 5 seats. Early bird $999, normally $1,199.

Early bird saves you $200 on either plan, and it ends July 1.

See the full plan and grab your seat

The honest part

I am not going to promise you magic or that you will never struggle again.

You will struggle. But the struggle, with people beside you who are figuring out the same thing in real time, is the entire point.

That is where the skill actually forms.

What I can promise is this. A year from now, the developers who adapted will be glad they started somewhere.

I would love for that somewhere to be this room, and for the version of you a year out to look back at this email as the moment your experience became an advantage again instead of a weight.

Take care,
Patrick

P.S. The 5 Pro seats are the one thing I cannot make more of, because the one-on-one time comes straight out of my own calendar. If that is the one you want, do not wait for July 1. The seats can go before the deadline does.

I saw an article about the night shift with AI a few weeks ago, and I could not make it work.

That idea stayed in my head.

Not because it was flashy. Because it felt close. It felt like the kind of thing that should work for .NET developers building real products, real features, and real systems that never seem to have enough time in the day.

Now I think it can work. Not as magic. Not as autopilot. But as a real workflow.

And the piece that changes everything is the combination of Claude, Fable 5, maybe Opus 4.8, and the /loop command.

That last part is the one that makes me stop and look twice.

By the way, if you’re trying to figure out how to actually use AI in your .NET and Blazor work, I made you a free Blazor AI Jumpstart Course.

When I started, I wasted a ton of time.

Visual Studio, then VS Code, then Copilot, then Claude, learning the hard way what actually works.

The Jumpstart is the shortcut past all those mistakes, straight to the workflow I use now.

It’s free.

Get the Blazor AI Jumpstart

The screenshot says a lot. It shows the difference between random prompting and a real overnight loop. It shows how a single prompt can turn into a focused execution plan. How AI stops being a chat tool and starts acting more like a tireless junior engineer with a very specific assignment.

That is the shift.

What the night shift really means

When people talk about AI doing work overnight, I think they sometimes imagine a fully autonomous agent building an app while they sleep.

That is not how I think about it.

I think about it more like a night shift in a real company.

You do not hand over your whole business and hope for the best. You leave behind clear instructions. You define the boundaries. You tell the next person what matters, what not to touch, and what success looks like.

That is what good AI prompting feels like to me now.

Not “build something cool.”

More like:

“Here is the problem. Here are the rules. Here is the architecture. Here is the safe scope. Go work on this until morning and come back with something useful.”

The screenshot prompt does exactly that.

It asks for performance profiling. It asks for page-level bottleneck discovery. It asks for improvements in performance and UX. It even asks for shells and skeletons on every data-heavy page. That is not vague. That is a real backlog item with real shape.

And that matters.

AI works much better when the task is narrow, concrete, and connected to visible user pain.

Why this time feels different

A few weeks ago, I tried to imagine this same workflow and it felt too loose.

The agent would drift. The scope would expand. The changes would get noisy. I would spend more time reviewing than I saved by delegating.

That is the trap with early AI coding workflows.

You think the model is the problem, but often the real problem is the loop.

Now we have better models. We have better context handling. We have better commands. And we have better ways to break work into chunks that make sense for an AI system.

That is why Claude plus Fable 5 plus Opus 4.8 feels promising to me.

Claude gives me the strong reasoning and the long, structured output I want.

Fable 5 gives the workflow a shape I can trust. (I think sooner or later we will get Fable 5 back…)

Opus 4.8 may be the model I reach for when I want deeper analysis or better planning, but also provides impressive results with said workflow.

And /loop is the part that turns one prompt into a repeated cycle.

That cycle matters more than people think.

Because one AI response is a suggestion. A loop is a system.

That is the real shift here.

What I would actually ask AI to do overnight

The screenshot gave me a good mental model for the kind of work I would trust to an overnight loop.

I would not start with my hardest domain logic first.

I would start with work that is obvious, measurable, and safe to review.

For example:

• Find slow pages in the app.

• Add profiling around requests, handlers, and SQL timing.

• Identify the worst bottlenecks.

• Implement shells and skeletons for data-heavy screens.

• Improve the first load experience on critical pages.

• Write down what changed and why.

That is excellent overnight work.

Why?

Because the AI can make progress even while I sleep, and in the morning I can inspect the result with a human brain and a cup of coffee.

I do not need it to be perfect.

I need it to move the app forward in a way that is easy to validate.

That is a big deal in .NET work, especially in Blazor apps where rendering, loading state, and user experience all get tangled together very fast.

A good AI night shift does not replace architecture. It respects it.

Subscribe now

How I would structure the loop

If I were setting this up in a real Blazor app, I would keep the instructions simple and sharp.

I would want the model to work inside a clear slice of the system.

I would also want it to keep producing useful status, not just code.

My mental checklist would look something like this:

1. Pick one area of the app.

2. Define the goal in one sentence.

3. List the files or layers it can touch.

4. Tell it what good looks like.

5. Ask it to work in small steps.

6. Make it report progress after each loop.

7. Stop when the work is done or the context gets weak.

That is important.

Most AI failures happen when the system keeps going after it should have stopped.

The work gets vague. The context gets dirty. The changes become harder to trust.

The loop has to be disciplined.

That is true for humans too.

Night shifts only work when the handoff is good.

The best kind of overnight work is boring

This might be the most underrated part of the idea.

It is boring in the best way.

It is the kind of work a good senior developer would delegate if they had more time and more patience.

It is profiling. It is loading states. It is repeated cleanup. It is finding slow paths. It is adding visibility. It is turning vague performance complaints into actual numbers.

That kind of work is perfect for a loop.

Because once the AI has a structure, it can repeat the process across multiple parts of the app.

It can inspect a page. Add timing. Find a delay. Suggest a fix. Implement a shell. Move to the next page.

That is useful.

And it lines up well with modern .NET architecture, where the app often has clear boundaries between UI, application logic, and infrastructure.

If the AI can stay inside those boundaries, the results are much easier to trust.

That is where I see real value.

Why shells and skeletons matter more than people think

The prompt in the screenshot mentions shells and skeletons, and I think that part is very smart.

It is easy to focus only on raw speed.

But users do not experience your code. They experience the page.

If a page takes time, the right loading state can make that delay feel much smaller.

That is especially true in web apps with pages that load data, analytics, schedules, or reports.

A blank screen feels broken.

A skeleton says, “I am working on it.”

That one small change can make the app feel much faster, even when the backend work has not changed much yet.

So if the AI is already hunting slow pages, it should also be improving the perception of speed.

That is a great use of overnight work.

Not just fix the bottleneck. Fix the experience around the bottleneck.

What I learned from trying this before

I think a lot of us are in the same place with AI coding.

We tried it early. We got some good results. We also got a lot of noise.

Then we backed off a little.

Not because the idea was bad. Because the workflow was not ready.

That is where I was with the night shift idea.

I liked the concept. I just could not make it hold together.

Now I think the missing piece was not ambition.

It was control.

Control over scope. Control over iteration. Control over the model’s attention.

Claude and Opus can reason well, but they still need structure.

That is why I keep coming back to the loop.

The loop makes the work persistent.

It keeps the AI from treating every prompt like a brand-new puzzle with no memory of the last step.

It creates momentum.

How I would use this in a real .NET shop

If I were rolling this into a real team workflow, I would start with one practical rule.

Do not give the AI the whole app.

Give it one feature, one page, or one problem area.

Then let it work like this:

• Measure what is slow.

• Explain the likely cause.

• Propose a fix.

• Implement the fix.

• Add a better loading state if needed.

• Report the result.

That is a workflow I can trust.

It fits well with how I like to build software anyway.

Small slices. Clear intent. Fast feedback.

And if the AI can do that while I am offline, that is a real productivity win.

Not fake productivity.

Actual output.

My honest take

I do not think the night shift with AI is hype anymore.

I think it is becoming real.

Not because the models are perfect. They are not.

Not because the tools are magical. They are not.

But because the workflow is finally getting close to something practical.

Claude is strong enough to reason through a serious task.

Fable 5 and the loop idea give the work structure.

Opus 4.8 may help when the task needs deeper thought.

And the screenshot prompt shows the right kind of problem: useful, bounded, and worth doing overnight.

That is where AI starts to feel less like a toy and more like a teammate.

Not a teammate I hand the keys to.

A teammate I trust with the night shift.

That is a much better fit for modern .NET development.

And honestly, that feels like the direction we should have been heading all along.

What I would do next

If you want to try this, start with one page in your Blazor app that feels slow or messy.

Write one tight prompt. Keep the scope small. Ask for profiling first, then fixes, then loading-state improvements.

Let the loop run long enough to produce something real, then review it in the morning with fresh eyes.

That is the experiment I would run.

Not because it is fancy.

Because it is useful.

And useful is the whole point.

If you want the shortcut for getting started with this kind of workflow in .NET and Blazor, grab my free Blazor AI Jumpstart Course.

It will save you a lot of the trial and error I went through, and it gives you the foundation I wish I had when I started.

Get the free Blazor AI Jumpstart

Then take that first overnight loop and make it work on something small.

That is how this gets real.

For almost every .NET project I start now, I reach for the same architecture.

Not clean architecture.

Not the classic three-layer controller, service, repository stack that pretty much every tutorial taught us a decade ago, me included…

I reach for vertical slice architecture.

And I want to walk you through exactly what it is, why it became my default, and why I think it has quietly become the single best way to structure an application now that we are all building software alongside AI.

That last part is the one I really want you to sit with. Because most developers are still choosing their architecture the way they did in 2018, and the rules have changed.

If you would rather watch this whole approach get built and shipped instead of just reading about it, this is the exact architecture we used in the Blazor AI Workshop.

The full three-hour recording is available here, and there is a discount waiting for you with the code SUBSTACK.

Get the Blazor AI Workshop

Now, let me back up and explain what we are actually talking about.

Organize by feature, not by layer

Here is the simplest way to put it.

Most architectures organize your code by technical layer. You have seen it. You have probably written it.

You open a project, and there is a folder called controllers, another called services, one for repositories, maybe one for models or DTOs. Every file in your application gets sorted into one of those buckets based on what kind of thing it is.

Vertical slice architecture flips that ninety degrees.

Instead of organizing by what kind of thing a file is, you organize by what feature it belongs to. So instead of a controllers folder and a services folder, you have a folder called CreateOrder.

And inside that one folder lives everything that feature needs. The endpoint, the validation, the business logic, the database call, the response it sends back.

One feature, one place. Everything it touches sitting right next to each other.

Here is the analogy I keep coming back to. Imagine a kitchen.

The layered approach is a kitchen organized by type of object. Every knife in one drawer across the room, every pan stacked in another corner, every spice on a shelf by the door. Technically very tidy. But to cook one single dish, you are running back and forth across the entire kitchen.

Vertical slices are a kitchen organized by meal. Everything you need to make the pasta is in one station. The whole recipe within arm’s reach. You cook the dish without touching anything that belongs to a different dish.

That is the whole idea. Organized by feature, not by layer.

Subscribe now

The hidden tax of organizing by layer

Let me describe a feeling you already know.

You are working in a nicely layered codebase, and you get a simple request. Add a phone number to the customer profile. Sounds like five minutes of work.

So you open the controller and add the field. Then the service to handle it. Then the repository. Then the DTO. Then the validator, which lives somewhere else entirely. Then the mapping configuration.

And by the time you are done, you have touched seven files in six different folders for one tiny change, and you are praying you did not miss one.

That is the hidden tax of organizing by layer. A single feature is smeared across your entire codebase. The code that changes together does not live together.

Engineers call the opposite of this high cohesion. Layered architecture is famous for having low cohesion. Things that belong together are scattered.

With vertical slices, that same change happens in one folder. You open the slice, you see the whole story of the feature top to bottom, you make your change, you are done.

And if you want to delete a feature entirely, you delete the folder.

Gone.

No archaeology, no hunting for the three orphaned service methods nobody else is using.

Here is the part people underestimate. This makes onboarding dramatically easier.

A new developer does not have to understand your entire architecture to be productive.

They open one slice, and that slice teaches them everything they need to ship that feature. The blast radius of understanding is small.

That alone would be enough to make the case.

But now I want to talk about the thing that turned vertical slices from a good idea into the obvious default for me.

Why AI changed the calculation

We are now writing a huge amount of code with AI. Assistants, agents, autocomplete, the whole spectrum.

And it turns out AI deeply cares about how your code is organized, even though almost nobody is talking about it.

Here is why. An AI model can only reason well about the code it can actually see.

Whatever fits in the context, whatever you hand it, whatever it can find by searching your files. That is its whole world for the task.

Now think about what happens in a layered codebase.

You ask the AI to change how orders get created. To do that correctly, it has to find the controller, trace the call into the service, then into the repository, then over to the validator, then check the mapping.

The relevant logic is spread across six files, and the AI has to go fishing for all of them and hold them together at once. Every hop is a chance for it to miss a file, misunderstand a connection, or confidently edit the wrong thing.

More indirection means more places to get lost.

Now, picture the same task in a vertical slice.

Everything about creating an order is in one folder, often basically one file. You hand the AI that slice, and it sees the entire feature at once. The input, the rules, the data access, the output.

No fishing, no tracing calls across the project. The full picture in one piece.

There is a term I love for this, borrowed from the HTMX crowd. Locality of behavior.

The behavior of a feature should be obvious from looking at one place, not assembled from clues scattered everywhere.

Humans have always benefited from this. AI benefits from it enormously, because it does not have your years of intuition about where things probably live. It can only work with what is in front of it.

And this matters even more with agents. The AI that goes off and makes changes more autonomously.

In a layered system, one small change can ripple across the whole project. And an agent rippling changes across your whole project is exactly the nightmare scenario.

In a sliced system, the blast radius is contained to one folder.

The agent works inside that slice, and the rest of your app is structurally protected from it. Smaller self-contained units, predictable edits, far less risk.

And when the AI builds something new, it just creates a new slice. It does not have to thread a new feature through five existing layers and risk breaking all of them.

So here is my claim.

Vertical slice architecture is the most AI-friendly way to structure a .NET application, because it maximizes locality of behavior and minimizes blast radius.

Those are the two things that determine whether AI helps you or quietly wrecks your codebase.

Where it is not a silver bullet

I do not want to sell you a magic answer, so let me be fair about the tradeoffs.

The first thing people worry about is duplication. If every feature is its own little island, will you copy and paste the same code everywhere?

The answer is that you have to be a bit disciplined. Shared logic still deserves a real home.

The skill is telling the difference between two slices that happen to look similar right now and code that is truly the same concept. Do not force two features to share code just because they rhyme today. But do not let genuinely shared logic get copy-pasted into twelve folders either.

That judgment is the actual craft.

Second, if you are working on a massive enterprise system with heavy cross-cutting concerns, you may need more structure than a pure slice approach gives you out of the box.

Vertical slices scale well, but you can layer some shared infrastructure underneath them. It is not all or nothing.

So I am not telling you to stop thinking.

I am telling you that for the vast majority of projects, and especially the ones you are building with AI in the loop, this is the default that gets out of your way and keeps both you and the model productive.

See it built end-to-end

If this clicked for you and you want to see it in action, not just read about it, that is exactly what we did in the Blazor AI Workshop.

We built a real application using vertical slices with AI as the coding partner the whole way through, and we shipped it to Azure live. You see slices, and AI working together end to end, instead of in the abstract.

The full three-hour recording is available here:

Get the Blazor AI Workshop

Use code SUBSTACK for an exclusive discount.

Last week I asked a room of .NET developers a simple question.

Does anyone still write code by hand anymore?

The answers were honest, a little uncomfortable, and more interesting than any benchmark chart.

This was one of the live sessions I run twice a month inside the .NET Web Academy.

No slides, no agenda. Just working developers talking about what is actually happening in their day-to-day.

People building industrial systems in Sweden, migrating decades-old ERP systems in Italy, shipping iPhone apps, and analyzing financial data.

Different problems, different stacks, one shared and slightly disorienting realization.

The way we work has changed, and it changed fast.

“I live in the terminal now. Four terminals at once.”

I will be honest about my own state, because I was honest with the group.

Since Opus 4.8 landed, I have barely looked up a line of code. I do not mean that as a brag.

I mean it as something closer to a confession. I described living in four terminals at the same time, context switching between five different applications, prompting one while another builds.

One developer, Jeff, put words to the part that is genuinely useful.

You can walk away. You can start a task, set it running, and go read your kids a bedtime story or stand in line at the grocery store and write the next prompt from your phone while you wait.

That is the part that still feels strange to say out loud. The most-used app on my phone right now is not a social network.

It is Claude.

Instead of doom scrolling, I am building things from my pocket.

Earlier that day, I had it take one of my long-form videos, transcribe it, find the best clips, reframe them vertically, bake in highlighted subtitles, and prepare them as YouTube Shorts.

From my phone.

While I was away from my machine.

Is that healthy? Probably not.

Jeff said it plainly, and he was right. The whole promise was supposed to be that we sleep more, not less.

I am not there yet.

But the capability is real in a way that it simply was not a few months ago.

Where the skeptics were right

Here is what I appreciate most about these sessions.

Nobody in the room is a hype machine. The pushback is real, and it is the most valuable part.

Jeff is building a financial analysis app. The kind of thing that decides whether to buy, hold, or sell a stock. And he said something that has stuck with me since.

The results look correct. They look great.

Clean analysis, credit risk, year-over-year numbers, a confident recommendation.

But they might be wrong.

The data was scraped from the web, and it could be last quarter’s report, or a bond rating for a different company that happened to share a page.

His point was not that AI is bad.

His point was sharper than that.

Anybody can build an app now.

But “it runs” is not the same as “it is correct.”

If your iPhone app works, great, the definition of done is that it works.

But if your app fakes being right when it is actually wrong, that is a real problem, and no amount of looping over it fixes a flawed foundation.

Per, who builds industrial systems where a mistake costs real money, made the quieter version of the same point. You have to be able to quantify what better and worse actually mean before you can ask AI to optimize toward them.

Asking AI to analyze a stock is, in his words, a bit like asking it who will win the Stanley Cup. It will give you a confident answer. It is still a probability, and the best goalie might get injured tomorrow.

This is the part that does not make it into the breathless takes.

AI is astonishing at the problems where the answer already exists somewhere, and you can recognize a good result when you see it.

It is far shakier where correctness is genuinely hard to define.

Knowing the difference is the job now.

The skill did not disappear. It moved.

There is a fear underneath all of this, especially for newer developers, and we talked about it directly.

We have a 22-year-old junior on my team, and he asked the honest question.

If I do not really write the code anymore, what does that mean for me?

I have been writing code for about 30 years, since I got my first machine as a kid and poked at QuickBasic and Turbo Pascal.

I love writing code.

So I understand the grief in that question. But here is what I told him, and what I believe.

The art was never really in typing the syntax.

The art is in deciding what to build, choosing the architecture, knowing which tradeoffs matter, and recognizing when something is off.

Arnold, who built and shipped an iPhone app, said the thing every experienced consultant eventually learns.

Clients tell you what they want.

Your job is to understand what they actually need, which is usually something they cannot articulate.

That skill has not been automated. If anything, it matters more now.

Jeff said it best. In the last four months, he has broadened his architecture skills and incorporated patterns he would never have had the time to learn before.

Does he understand them as deeply as he would have with, in his words, bloody fingertips from debugging them by hand?

No.

But he is using them, and shipping with them, and he thinks that tradeoff is worth it.

The artistry, he said, is at the higher level now. Not in checking whether something was null for the hundredth time.

The honest, practical takeaways

A few concrete things came out of the conversation that are worth passing along.

The newer models genuinely changed the experience, not just the benchmarks. I used to hit a build error two or three times a day and had to feed it back.

Since 4.8, I struggle to remember the last one, across five projects running at once.

Others in the room who were still on older models through their work tools described it as living a couple of decades in the past by comparison.

The gap between what you can use at home and what your company allows is becoming a real source of friction.

The tool wrapper matters as much as the model.

We got into why the same underlying model can give better results in one tool than another.

The answer is the shell around it, the system prompt, the way the tool feeds context and handles permissions. It is not only about which model number you are on.

MCP servers finally clicked for me, and it was Jeff who explained it.

You put an MCP server on top of an existing API so that AI agents can call it easily, because agents have a hard time calling a raw API directly, but a much easier time using the tools an MCP exposes.

My own use case made it concrete. I am building my own community platform to replace an expensive tool we were unhappy with, and I want my wife to manage it, creating spaces and assigning roles, by talking to Claude through an MCP server I built for the app.

That is the moment MCP stopped being an abstract acronym for me and became a thing I actually want to build.

Why I am sharing all of this

These conversations are the most valuable thing I do, and they are members-only for a reason.

They are not lectures.

They are a room of working developers being honest with each other about what is exciting, what is overhyped, and what is genuinely hard.

The skeptics make the optimists sharper.

The optimists pull the skeptics forward. Nobody is selling anything.

If you want to be in the room for the next one, that is what the All Access Pass is for.

Twice a month, live, plus every course I build and the recordings of every past session.

We go deep on exactly this kind of thing, with real developers working on real problems.

Join the All Access Pass

Use the code SUBSTACK for an exclusive discount.

And if there is one thing to take away without joining anything, it is this.

The developers who are thriving right now are not the ones who prompt the fastest.

They are the ones who still understand the foundations well enough to know when the confident answer in front of them is actually wrong.

That skill is not going anywhere.

If anything, it just became the whole job.

Knowing how to prompt is not enough anymore.

If you want to land clients or your next role, you need real projects you can point to, things you built that you can show and explain.

And one of the simplest, highest-leverage things you can build is a portfolio page.

You could build it entirely by hand, the way we always have. Or you could let AI do most of the heavy lifting, and get to the same result in a fraction of the time, as long as you still look under the hood.

That phrase, “as long as you still look under the hood,” is the whole point of this article. So, before we go further, one related thing worth mentioning.

If you want to see this same approach applied to a full real-world application rather than a portfolio page, the Blazor AI Workshop recording covers exactly that.

Three hours, starting from an empty folder, building a complete Blazor app with a database and AI features, and deploying it live to Azure.

It is the deeper version of everything I am about to walk through.

Get the Blazor AI Workshop

The one rule

Everything on that page should be something you can explain.

This sounds obvious until you actually start letting AI build things for you.

Because the temptation is real.

You prompt, the code appears, it compiles, it looks good, and you move on. Multiply that across a whole project, and you end up with something that works but that you do not understand.

And the moment someone asks you a real question about it, you are exposed.

A portfolio page is the perfect example because the stakes are so clear. The page is not just the artifact. It is proof that you can build and reason about real software.

If a client asks how you structured it, or an interviewer asks why you chose server-side rendering over WebAssembly, “the AI did that part” is not an answer that gets you hired.

The portfolio stops being proof the moment you cannot explain it.

So I treat AI like a capable junior developer I trust to do the work, but whose work I still review.

I decide the architecture.

I decide the approach.

I read what comes back.

The AI types faster than I do and knows more APIs than I will ever memorize, but the decisions stay mine.

Deciding before prompting

Before I wrote a single prompt, I made a handful of decisions I could defend.

Static server-side rendering everywhere. A portfolio page needs to load fast and respond instantly. It does not need interactive components re-rendering on every action.

So SSR is the right call, and I can explain exactly why.

Knowing the Blazor render modes, and knowing that you set them per component rather than globally unless you choose to, is the kind of “under the hood” knowledge that separates someone using AI well from someone using it blindly.

A single scrolling page with anchor navigation. Rather than separate routes for each section, I wanted one page where the navbar scrolls you smoothly to anchors. That is a design and UX decision, and I made it deliberately rather than letting the AI guess.

No vertical slice architecture. For a bigger or mid-size application, I would reach for VSA. For a portfolio page, that would be over-engineering. Knowing when not to apply an architecture pattern is itself a senior decision, and one worth being able to explain. Reaching for the most sophisticated pattern on every project is a junior move. Matching the structure to the actual problem is what experience looks like.

None of these decisions were made by the AI.

They were made by me, and then communicated to the AI. That order matters. You decide, then you delegate. Not the other way around.

Briefing the AI like a teammate

With the decisions made, I started the actual build.

I created the project myself first using the .NET CLI and the standard Blazor web app template, the same thing you would do in Visual Studio. I added a gitignore, committed, and pushed to GitHub. Small steps, but each one something I understand and control.

Then I talked to Claude the way I would brief a developer joining my team.

I want a portfolio page for me as a .NET and Blazor developer. Use static server-side rendering everywhere for performance. Do not use the default design, think of something better. Put the navigation on top, not in a sidebar. Make it one scrolling page where the menu navigates to anchors.

Then I listed the sections I knew I wanted: a hero, an about section, projects, my LinkedIn, a contact option, and told it to suggest anything else that made sense for a portfolio. For now, surprise me, and ask if you need more information.

That last part matters.

I left room for the AI to be useful beyond pure dictation, but within boundaries I set.

It came back with smart, clarifying questions.

Which visual vibe?

How should it handle content I would fill in later?

How should the contact form behave?

Good questions, the kind a thoughtful teammate would ask, and I answered each one with a decision I could justify.

What Claude actually built

It planned first.

A concept for the page, a visual direction, a set of sections.

Then it worked through the build, creating files, writing the components, generating realistic placeholder content with markers so the page looked finished and I could swap in real text later.

Modern models like Opus 4.8 tend to create their own to-do lists and work through them methodically, and you can even ask for that plan as a markdown file so you can follow along and steer.

A few minutes later, I had a real page.

Sticky navbar, hero, about, tech stack, projects, an experience timeline, a contact section, smooth scrolling, and a mobile version.

For a few minutes of work, the amount of finished structure was genuinely impressive.

But, and this is the important part, it was not done.

The mobile menu did not work yet. Some sections had the telltale signs of AI-generated design, the little chips and arrows that have become a visual cliche.

The content was all placeholder. This is exactly the eighty percent that AI gets you quickly, and exactly why the remaining twenty percent still needs you.

Getting real data in, and hitting a wall

Placeholder content makes a page look finished, but a portfolio needs to be real. So I asked Claude to pull my actual information from my GitHub and LinkedIn profiles and update the page, especially the experience timeline.

GitHub worked. LinkedIn blocked the fetch.

I want to dwell on this because it is the most honest moment in the whole build.

The AI tried to web fetch my LinkedIn profile, and LinkedIn refused.

If you did not understand what was happening, you would be stuck.

But because I know how this works, the path forward was obvious.

Copy and paste the content directly. Hand it a screenshot and let it read that. Or route through a proxy with the right tokens if you want to automate it.

The AI did not remove the need to understand the problem. It removed the typing once the problem was understood.

This is the pattern over and over.

AI accelerates the parts you already understand. It does not replace the understanding.

When something breaks, and something always breaks, you are the one who has to know what to do next.

The design trick most people miss

The first design was good but generic. That AI look. If you want a portfolio that stands out, generic is the enemy.

So instead of describing a new design in words and hoping the AI interpreted me correctly, I showed it one.

I went to Dribbble, found a portfolio design I liked, grabbed a screenshot, and asked Claude to overhaul the page to match the attached image.

It did not reproduce it pixel for pixel. Claude reads images well but is not an image-perfect copier. What it did was understand the direction. A new color palette pulled from the screenshot, different typography, restyled components, a different feel for the links and sections. From generic to intentional in a single prompt.

That is the move worth remembering.

Do not describe a design and pray.

Show the AI a reference and let it match the direction, then steer from there.

It is the difference between explaining a destination over the phone and just sharing your screen.

Where this leaves you, and the one thing to set up first

When Claude stopped typing, the heavy lifting was done, but the page was not finished.

The portrait was still a placeholder. The timeline dates needed correcting. The mobile menu needed a fix. Testimonials were sample text.

That final stretch, the polishing and correcting and judgment calls about what good actually looks like, is the part that is yours.

It is also the part that makes the page worth putting your name on.

That is the honest picture of AI-assisted development in 2026. It is not “AI builds your portfolio while you sleep.”

It is

“AI gets you eighty percent of the way in a fraction of the time, and your judgment turns that into something real.”

The developers who win with this are not the best prompters. They are the ones who can read what comes back, recognize when it is wrong, and steer it to something they understand completely.

There is one thing I would set up before any of this, though, if you are doing it on a real project rather than a quick portfolio. A copilot instructions file, or an AGENTS.md file.

It encodes your conventions, your architecture, your rules, so the AI follows your standards instead of inventing its own every session. It is the single biggest upgrade to working with AI, and it is the foundation everything else builds on.

And if you want to see this entire approach applied to a full production application, with a real database, authentication, AI features, and a live Azure deployment, that is what the Blazor AI Workshop walks through from start to finish. Same philosophy as this portfolio build, scaled up to a real app you would actually ship.

Get the Blazor AI Workshop

There was a period - not that long ago - when getting GitHub Copilot approved at work felt like a genuine win.

Legal had concerns about training data. Security had questions about what the model might suggest. Management was still figuring out where AI fit into the workflow.

And developers were watching all of this from the sidelines, using Copilot on personal projects, waiting.

Then the approval came through.

And something genuinely good happened, almost immediately.

Developers started talking to each other about it.

Not just what they were using it for - but how much.

Token counts. Weekly usage. Who was prompting the most.

It became a kind of informal leaderboard, and it was actually fun. Not competitive in a toxic way - more like the excitement of early adopters comparing notes.

Someone would share a prompt that worked surprisingly well.

Someone else would share a failure that was entertainingly bad. Teams started building shared intuitions about what the tool was good at.

That version of AI adoption - organic, curious, social - is the version that actually works.

And then, for a lot of teams, things changed.

The Shift

At some point, leadership started asking a different question. Not “should we allow this?” but “are people actually using this?”

Fair enough. Companies invest in licenses. They invest in training. They want to know if that investment is doing anything.

So usage tracking came in.

Token counts per developer.

AI activity over time.

Trend lines.

And in some organizations, more than just the volume - the actual content of prompts started being logged, visible to managers or reviewed in aggregate.

The intent is understandable. Identify who’s adopted the tools well, who might need support, understand how the investment is being used.

The problem is what happens to human behavior the moment people know they’re being measured on something.

Goodhart’s Law, Applied

There is a principle in economics - you may have encountered it - called Goodhart’s Law.

The short version: when a measure becomes a target, it ceases to be a good measure.

The longer version: once you start evaluating people on a metric, they start optimizing for the metric rather than the underlying thing the metric was supposed to capture.

AI token usage is an almost perfect case study in this.

When token usage was a voluntary, informal signal of curiosity and engagement, it genuinely reflected those things. Developers who were excited about the tool used it more. The number meant something.

The moment it becomes a formal metric - something visible to management, something with implicit expectations attached - it stops meaning the same thing.

Now it’s also a number that someone might game, consciously or not, when their genuine work doesn’t produce it.

And here is the critical thing: a lot of legitimate, valuable developer work does not naturally produce AI token usage.

A developer spending Monday in architecture discussions is doing real engineering.

A tech lead reviewing five pull requests in a day is doing real engineering.

A senior developer writing an architectural decision record, running a retrospective, mentoring a junior, planning the next sprint - all of this is real work.

None of it requires opening Copilot.

But the metric doesn’t know that. The metric sees a blank day.

What Developers Actually Do

So what happens when a developer has a legitimately non-AI day but feels the pressure to show activity?

They fire off a prompt.

Not because they have a real question. Because they need to look active.

And certain prompts become the default. The ones that look substantive, sound responsible, and generate impressive-looking output:

• “Do a deep analysis of this codebase and identify security vulnerabilities.”

• “How would you improve the overall architecture of this project?”

• “Are there any performance bottlenecks I should be aware of?”

• “Write unit tests for this module.”

• “Review these files and suggest refactoring improvements.”

None of these are bad prompts in isolation.

The problem is when they’re generated not because the developer needs the answer, but because the developer needs the metric.

By the end of the month, some teams have run the same security vulnerability scan on the same codebase a dozen times.

The AI finds the same things each time - some already known, some not applicable.

The output gets skimmed or ignored. The tokens are spent. The dashboard looks healthy.

This is AI theater.

It looks like adoption from the outside.

It isn’t.

The Developers Who Suffer Most

Here is the irony that I find most striking about this dynamic.

The developers who suffer most under AI usage monitoring are often the best ones.

A strong senior developer tends to be working on things that don’t reduce neatly to “ask the AI a question”.

System design.

Code review.

Stakeholder communication.

Mentoring.

Technical debt triage.

Strategic planning.

These are the activities that require the most experience and judgment - and they’re precisely the activities that have the lowest AI token footprint.

Meanwhile, someone spending the day using Copilot to generate boilerplate or running the same architectural review prompt they ran last week will show high engagement in the dashboard.

The metric is, in effect, penalizing judgment and rewarding activity.

That’s backwards.

And experienced developers will notice this.

They’ll feel the discomfort of being implicitly asked to justify their work in terms of AI usage.

Some will adapt by gaming the metric.

Others will become quietly resentful.

Neither outcome is good.

If this is a problem you’re seeing play out on your team - or if you’re a tech lead trying to figure out how to think about AI adoption in a way that actually works - this is exactly the kind of thing we work through in the live sessions at the .NET Web Academy.

Real questions, real scenarios, no abstract frameworks.

Join here

What to Measure Instead

The good news is that the underlying question - “is AI helping our team”? - is a reasonable thing to want to know.

The problem is the proxy, not the question.

Some approaches that actually capture something meaningful:

Ask developers directly.

At sprint retrospectives, in one-on-ones, in team discussions - ask where AI helped and where it didn’t.

This gives you qualitative signal that no dashboard can replace.

Developers who genuinely find the tools useful will have stories.

Developers who are struggling will have specific friction points you can address.

Look at outcomes over time.

Are teams shipping faster?

Are bug rates changing?

Are developers reporting higher confidence in their output?

These are slow signals and they’re hard to attribute cleanly to any single tool, but they’re the real thing you care about.

Token counts are not.

Track adoption at the team level, over longer windows.

If you aggregate AI usage across a team over a quarter, you get a much more meaningful signal than tracking individuals per day.

Planning weeks will pull the number down. Feature sprints will push it up. That’s fine - that’s what real work looks like.

Create social conditions for sharing.

The organic token competition happened because developers were talking to each other.

Lunch-and-learns, Slack threads, demo sessions where someone shows a prompt workflow that saved them two hours - these create the conditions for genuine adoption spreading. You can encourage this without measuring it.

The developers who were most excited about GitHub Copilot in the early days weren’t excited because someone tracked their usage.

They were excited because the tool was genuinely useful and they had people to share that excitement with.

Surveillance doesn’t create that.

It replaces it with performance.

Where This Ends Up

If you’re a developer reading this and recognizing your own situation - the quiet guilt of a low-prompt day, the reflexive security scan just to have something in the log - know that the frustration you feel is pointing at something real.

You’re being asked to optimize a number instead of doing your best work.

That’s a legitimate problem.

And if you’re on the leadership side thinking about AI adoption metrics, I’d offer this reframe: the question isn’t “how much are they using it”? It’s “what are they building with it”?

The first question has a number.

The second question has an answer.

The answer is the one worth having.

For five years, I worked 100% remotely.

My employer was over 600 kilometres away.

We had never even talked seriously about me being in the office - because it didn’t matter.

The work was great. The results were great. Deadlines were met. Products shipped. Colleagues were reachable. Everything worked, beautifully, for five years straight.

Then, for family reasons, we moved. To our old hometown. Closer to my employer. And the moment the physical distance closed, something changed.

Now I have to come in three times a week.

I want to tell you what that actually looks like.

Not the version where the open-plan office buzzes with energy and spontaneous whiteboard sessions and serendipitous hallway conversations.

The real version.

The Room

The office uses a hot-desk system.

You book your seat in an app before you come in. When you arrive, you sit at whichever desk you booked. Nobody has a permanent spot. Nobody has their own setup. You get a docking station, two monitors, and a chair.

Most days, I end up in a room with three desks.

Alone.

Not alone because I’m unsociable. Alone because nobody else booked that day.

Because not everyone comes in on the same day. Because the whole point of a flexible desk system is that people have the freedom to choose, and when people choose, they don’t all land on the same three days.

So I sit there, in a room with two empty desks, in a building I drove to, and I do the same work I would have done at home.

The room itself is clean.

It’s functional.

It has everything a room needs to technically qualify as a workspace.

It has one plant - undeniably in need of water - and a view of another office building.

There are no posters on the wall. No whiteboards with anything interesting on them. Nothing that would make you think this is a place where creative, engaged people spend their days. Because it isn’t. It’s a booking slot.

There’s a second room.

A social room.

A sofa. A television - large enough to be used for meetings, not interesting enough to actually make you want to spend time there. No foosball table. No games console.

Nothing you’d want to do with a colleague when you have twenty minutes and you want to actually enjoy each other’s company.

It’s a room that communicates, clearly and without ambiguity: we thought about you having fun here, and then we decided against it.

The Irony

Here’s the part that gets me every single time.

In the office, when I need to talk to a colleague, I open Microsoft Teams and call them.

Because they’re working from home. Or they’re in a different room in the office, on a call themselves. Or they’re somewhere else entirely.

The point is: they’re not next to me. They’re never just next to me.

I drove in. I booked a desk. I sat down. And I called someone on Teams.

Exactly as I would have done from my home office.

This is the full journey: leave the house earlier, sit in traffic, find parking, walk to the office, boot up a machine that isn’t mine, and then do the same thing I would have done without any of that.

And when I’m in the office, I also have to track my time.

Not working time.

The time I spend in the office. Because I’m not working there - I’m just there.

So there’s a system for logging office presence separately from any record of actual work done.

This, in a single detail, tells you everything you need to know about the purpose of the policy.

What Home Actually Looks Like

My home office is a room that is mine.

It has my machine - the one I built, configured, and optimised myself.

It has my monitor, my keyboard, my headphones.

It has things on the desk and walls that I look at and smile.

When I sit down to work at home, I put on the music I want to hear. I open the projects I need. I go deep. Real deep focus - the kind that takes 20 minutes to build and an open-plan office booking system to destroy.

When I’m hungry, I walk to my kitchen and make something.

An actual meal.

Not a sad desk lunch.

I can cook. I have a coffee machine I care about. I can step away from the screen for 10 minutes and come back genuinely refreshed.

And when I want to talk to my wife, I walk down the hall and do that. A 3-minute conversation with someone who matters to me, in the middle of a workday, without having to book anything or perform for anyone.

None of this is luxury.

None of this is unusual.

This is what a functional adult working environment looks like when the employer doesn’t insist on controlling the physical location.

The Arguments That Don’t Hold Up

The stated reasons for return-to-office policies are almost always the same: you do better work in person, and you socialise more.

I worked remotely for five years.

The results were excellent.

I know this because I was never told otherwise, never put on any kind of performance plan, and continued to be trusted with significant work throughout.

If remote work produced bad results, someone would have noticed in five years.

They didn’t.

The socialisation argument collapses even faster.

If your goal is genuine social connection between colleagues - the kind that builds relationships and makes work more human - three days a week in a hot-desk room with people who booked different days is not the answer.

You want socialisation?

Bring everyone in on one day. Have lunch together. Have coffee together. Let people actually talk without it being incidental.

But here’s what you have to accept if you do that: that day will not be a productive workday.

Not in the focused, deep-work sense.

There will be meetings and conversations and catch-ups and lunch and coffee and all the things that make a day with colleagues worthwhile and memorable.

And that’s fine.

That’s the trade.

One day of genuine human connection in exchange for a day of focused output.

What you cannot have is three days of presence plus the expectation of focused output. Those two things are not compatible in a lifeless room with empty desks and a plant that’s crying for help.

And if you actually want to go further - if you want the kind of team bonding that people remember - you organise something real.

Laser tag. A dinner out. Something that isn’t a booked desk in a sterile room.

We tried.

We wanted to do exactly that.

There was no budget for it.

If it was going to happen at all, it would have to be in the evenings, on our own time.

So the company that mandates three days a week in the office for the sake of socialisation won’t fund a single team event. The socialisation argument isn’t a goal.

It’s a justification.

Want To Talk About It?

If this resonates with you, these conversations happen regularly inside the .NET Web Academy.

Twice a month, I run a live session - no prepared slides, no agenda. Just developers talking honestly about what’s working, what isn’t, and what we’re all figuring out in real time.

If you want to join future sessions and get access to everything else - the courses, the Discord community, the recorded sessions, all of it - the All Access Pass is the way in:

Join the Discussion

What This Is Really About

I don’t think this is about productivity. I don’t think it’s about socialisation.

I think it’s about control.

The feeling - for some managers, for some executives, for some institutional cultures - that if they can’t see you, they can’t be sure you’re working. That presence equals effort. That visibility equals value.

The time-tracking system for office attendance is the tell.

You’re not tracking whether I shipped a feature.

You’re tracking whether I was in the building.

These are different measurements of different things, and choosing to measure the second one instead of the first one is a choice.

Five years of remote work proved that output can be measured without proximity. I was there for the proof. I was the proof.

Going back to the office didn’t change what I do or how well I do it.

It added 90 minutes of commuting.

It replaced my environment - one that energises me - with one that drains me.

It put me in a room alone, calling colleagues on Teams, tracking my presence, sitting next to a plant that deserves better.

If you’re a developer who has been told to come back in, and you feel like something is off about the reasoning - you’re right. The reasoning is off. The results were fine before. They’ll be fine again when we stop pretending that location is a proxy for performance.

What I’d Actually Accept

One day a week.

Come in, see people, have lunch together, have real conversations, go home.

I would do that happily. I’d look forward to it. I’d leave the house with energy.

Three days a week in an empty room with a hot desk and a Teams call waiting on my screen?

That’s not a workplace.

That’s a commute with a monitor at the end of it.

If this resonated - if you’re living some version of this - I’d like to hear it. What does your office mandate look like? What’s the thing that bothers you most about it? Leave a comment. This is the kind of thing worth talking about.

A few weeks ago, I wrote about why the AGENTS.md file changes everything about AI-assisted .NET development.

Last Wednesday, I got to watch 40 developers see it work for the first time. Live.

Here is what they noticed.

We were in the middle of the live Blazor AI workshop.

We had just finished implementing the first feature without an AGENTS.md file. Just a raw prompt to Claude: implement the shopping list entity and wire up EF Core.

It worked. It compiled. It ran.

But Claude made decisions I would not have made. The folder structure was generic. The architecture was its own, not mine. The naming felt slightly off.

I said to the room:

“This is what most developers do when they start using AI. They just prompt and accept whatever comes back.”

Then I created the AGENTS.md file with Claude.

• I described the conventions.

• Vertical slice architecture.

• Custom mediator.

• Feature folder structure.

• No paid packages.

• Files for everything.

We saved it. Started a new context. And prompted Claude again.

Same project. Same task. But this time with the AGENTS.md file in the project root.

The difference was immediate.

The folder structure matched what I would have written by hand. The naming followed our conventions. The handler signature was exactly what I wanted. Even the way Claude split files matched the rules in the AGENTS.md.

Per typed in the chat: “Yes.”

Just that. One word. From a developer who builds industrial systems for sawmills in Sweden, where a mistake costs ten thousand euros an hour. Someone who is genuinely skeptical of AI for anything critical.

“Yes.”

That was the moment.

Why this lands harder when you see it live

You can read about the AGENTS.md workflow.

You can try it yourself.

But there is something different about watching it work in real time, with a real developer making the decisions, and seeing the AI follow conventions you can verify with your own eyes.

That is what the workshop ended up being about, even though I did not plan it that way.

Edgardo had to leave early. He dropped this in the chat before disconnecting:

“Hey Patrick. I’ve got to run. Thanks so much — expectations exceeded.”

That sentence stayed with me.

Because expectations are exactly what these sessions challenge.

You show up thinking you will see another AI tutorial.

You leave thinking differently about how to actually use these tools in your real work.

The full session, on-demand

If you missed the live workshop, the full three-hour recording is now available.

Get the recording here

Seven chapters.

From an empty folder to a deployed Blazor Server app on Azure.

Real .NET 10.

Real SQL Server.

Real GitHub Actions deployment.

Real multi-user sharing.

Real OpenAI integration.

Use code WORKSHOP49 for a launch discount until Wednesday.

Grab the discount

What else stood out

The AGENTS.md moment was the obvious one. But other moments hit just as hard.

When Claude restyled the entire app from a Dribbble screenshot in a single prompt, Morgan wrote:

“Wow! Updating the entire site design is impressive.”

He continued:

“Design is my Achilles heel. If this works, I’m more than sold!”

When the multi-user sharing feature worked on the first try, Morny shared a list with me, tony@stark.com, to test it.

It worked.

He confirmed it in the chat.

When the OpenAI recipe feature generated ingredients for spaghetti carbonara, Roberto — actually Italian — pushed back live:

“Garlic? Pancetta? You need guanciale and pecorino romano.”

That is the chat from this workshop.

Real developers, real reactions, real corrections from someone who knows better than the AI.

This is what the .NET Web Academy live sessions feel like. Not lectures. Not tutorials. Real conversations between developers building something together.

What I learned watching 40 developers see this for the first time

Three things.

One.

The AGENTS.md workflow is not obvious until you see it work.

Once you do, you cannot go back. You start thinking about how to encode your team’s conventions into a file the AI can read.

The discipline of writing it down also makes the project better.

Two.

The architecture vote in the chat — vertical slice or services and repositories — was almost exactly split.

There is no consensus among working .NET developers about the right pattern.

There is only the right pattern for your project, your team, your stack.

And the AGENTS.md file is what makes either pattern stick.

Three.

Live sessions hit different.

Recordings are great. The workshop recording is genuinely useful.

But there is a quality to the live conversation that the recording cannot fully capture — Per’s “Yes,” Edgardo’s “expectations exceeded,” Roberto correcting the AI on Italian cooking.

Those moments happened because real people were in the room together.

Want to be in the room next time?

The .NET Web Academy All Access Pass includes every future workshop, twice monthly live sessions, every course, all source code on GitHub, and the private Discord community.

If you want to be in the room for the next one — and you want to keep going deeper on AI-assisted .NET development — that is the way in.

Join the All Access Pass

Last week, someone in our live session inside the .NET Web Academy said something that made me stop mid-sentence.

Arnold, one of our members, described how he’d spent a few hours experimenting with Claude Code in the terminal.

No Visual Studio open.

No IDE at all.

He described a .NET MAUI app, gave Claude the instructions, and just... let it run.

It compiled. It ran. And then - and this is the part that got me - Claude walked him through provisioning the app to his iPhone through his Apple Developer account.

Step by step. Correcting errors. Adjusting parameters. Pushing through the parts where Arnold said he would normally have quit after an hour.

His words:

“Holy shit, that was so good.”

Yeah. Same, Arnold. Same.

This Wasn’t a Demo. This Was a Tuesday.

What made this moment land differently than your typical “AI is amazing” story is the context.

This wasn’t a controlled demo from a YouTube channel.

This was a group of working developers - from Sweden, the US, Italy, Austria - sitting together on a Tuesday evening, talking honestly about what’s actually working and what isn’t.

And the conversation was genuinely mixed.

Per, who builds industrial systems for sawmills in northern Sweden - we’re talking real-time log analysis at one to three logs per second - was skeptical.

He trusts AI for generating classes from JSON, writing documentation, and helping debug compile errors. But the core logic? He still writes that himself. When you make a mistake in his world, it costs between 10 and 100,000 euros an hour. So yeah, he’s careful.

Paul put it plainly early on:

“In the hands of an experienced developer, any AI tool is an accelerator. In the hands of a rookie, it’s just dangerous.”

That line sat with me for a while.

A quick note

If you want to learn how to build complete .NET AI-powered apps step by step, including Blazor, EF Core, Vertical Slice Architecture, Copilot workflows, and OpenAI integrations, I have just the right course for you:

👉 .NET Web Development with AI & Copilot

Use code SUBSTACK at checkout for an exclusive discount!

👉 Get it here

The Thing Nobody Talks About: Experience Still Matters

We spend a lot of time in these conversations talking about what AI can do.

We don’t spend enough time talking about why it works better for some people than others.

Here’s what I actually think is happening.

When Arnold described a .NET MAUI app to Claude, and it delivered something real, he wasn’t just typing natural language and hoping.

He knew what he wanted. He read the code. He pushed back - “why are you doing it this way? Can we do it like this instead?” - and Claude adjusted.

That’s not vibe coding. That’s a developer using a capable collaborator, while staying in charge of the decisions.

When Mark - also in our session - tried Grok for Blazor and it didn’t recognize a Razor file, that’s a different problem. The tool wasn’t ready for that task. But knowing that, knowing which tool fits which job, knowing how to read what comes back - that still requires experience.

Jeff summed it up well when he described his own workflow: he doesn’t read every line the AI generates anymore. But he runs manual tests for every feature generated by the AI itself. He knows where the gaps might be. He catches bugs later and fixes them in context. That’s a judgment call. It requires knowing what “good enough for now” means in a given situation.

These aren’t beginner skills.

They’re developer skills, applied to a new kind of tool.

The MD File Is the New Architecture Conversation

The part of our session that honestly excited me most wasn’t the iPhone story. It was the conversation about Markdown files.

Arnold has what he calls a DevBible - an MD file with all his standards, naming conventions, and how he does things. He feeds that, plus a project spec file, into Claude at the start of every session. Claude follows his rules. His architecture. His way.

Jeff does something very similar. MD files for project status, for tasks, and for decisions he’s made along the way. When the context window gets too big and he opens a new thread, he hands Claude the Markdown file and says: continue from here. No re-explaining. No drift.

I’ve been doing this too. For bigger rewrites, I generate a phased plan as a Markdown file - phases, tasks, checkboxes. Claude and I work through it together. When Claude needs more information, it asks. When I want to go in a different direction, I change the file. The plan is the source of truth.

What I love about this is what it forces you to do before you prompt: actually think the project through. Write it down. Agree on conventions. That discipline makes the AI work better - but it also just makes the project better.

Arnold put it well:

“Before you even start prompting, you just write this sucker out.”

This is what mature AI-assisted development looks like. It’s not less technical than before. In some ways, it’s more technical. It’s just technical in different places.

The GitHub Copilot Situation

Quick practical note from our session: GitHub Copilot Pro upgrades are currently paused. If you’re on the free tier and want to upgrade, you can’t, at least not right now.

This came up because a few people were asking what to try next. My honest recommendation is Claude with the Pro subscription. For Blazor and .NET specifically, it’s the most capable option I’ve used. Grok doesn’t know what a Razor file is. That’s a 2025 problem we shouldn’t still be having.

I’m currently paying for the Max plan - the $180/month tier - and yes, that’s a lot.

But I’m also running multiple projects, using Claude Code, running automation workflows on my machine. For someone just starting, the basic Pro plan at around $18/month is a very reasonable place to begin.

What This All Means for You

Here’s where I landed after this session.

The developers who are thriving with AI right now share a few things:

They stayed in charge of architecture. They encode their decisions - in AGENTS.md, in AI Skills, in a DevBible - and let the AI implement them. The judgment is theirs. The execution is shared.

They verify the output. Not every single line every single time, but they understand what’s being generated. They know when something looks off. They push back.

They use AI for the stuff that used to eat their time - boilerplate, scaffolding, class generation, tests, documentation - and reclaim that time for the things that actually require a developer: understanding what the customer needs, designing the system, making the calls that matter.

And they’ve accepted that this is part of the job now.

Per staying skeptical of AI for core logic isn’t wrong - it’s the right call for his context. But even he uses it for documentation and debugging.

Roberto uses it daily for code that’s clear enough to specify.

Jeff uses it to manage a complex solo project he genuinely doesn’t think he could have built otherwise.

There’s room for different workflows here. But there’s less and less room for opting out entirely.

Want to Go Deeper?

If this resonated with you, these conversations happen regularly inside the .NET Web Academy.

Twice a month, I run a live session - no prepared slides, no agenda. Just developers talking honestly about what’s working, what isn’t, and what we’re all figuring out in real time. The session I described in this article is one of them.

If you want to join future sessions and get access to everything else - the courses, the Discord community, the recorded sessions, all of it - the All Access Pass is the way in:

Grab the All Access Pass

Thanks for reading.

And if you’re ever in a session and you’ve built something that made you say “holy shit, that was so good” - please share it. Those are the moments worth talking about.

A few days ago I asked one of our All Access Pass members what he wanted to see built live during my upcoming live workshop.

He did not hesitate.

A shopping list app.

Then I stopped myself. Because here is the thing: I have built a shopping list app before. Years ago, for myself. Just a simple web app I used privately. Nothing fancy. But I actually used it.

And I remembered exactly why I built it. Because every shopping list solution I tried was either too complex, tied to a specific ecosystem, or required my wife to download yet another app.

So I built my own. As developers do.

When this member suggested the same thing, I knew immediately he was right.

Not because it is a simple project - it is not, once you start thinking about it properly - but because it is the kind of app that solves a real problem that real people actually have.

In his reply, he wanted items organized by category. He wanted AI to suggest things he might have forgotten. And then he said the thing every developer says when they build a shopping list app:

“And it would be great if I could share it with my wife.”

I smiled. Because I have been there.

And then I had to tell him the truth: we have two hours.

We are building it this Wednesday. Join us live:

The Blazor AI Workshop is this Wednesday, May 20th. We start with an empty folder and finish with a real deployed Blazor app on Azure. All Access Pass members are already in for free.

Reserve your seat here

📅 Wednesday, May 20th

🕐 Berlin 9:15 PM / London 8:15 PM / New York 3:15 PM / Los Angeles 12:15 PM

Now, back to the feature list problem.

The hardest skill in software development

Deciding what not to build is harder than building.

Categories sound simple.

They are not.

Now every item has a foreign key. Your UI needs a category selector. You need a way to manage categories. You need to decide what happens when you delete a category that contains items. Suddenly, you have three extra screens and a migration headache.

Sharing with your wife sounds simple.

It is not.

Now you need user accounts.

Authentication.

Authorization.

A way to invite someone.

A way to handle the case where she edits the list at the same time you do.

Conflict resolution. Suddenly, you have built half of a SaaS product.

AI suggestions sound simple.

They are not.

Now you need a prompt that understands context. You need to handle the case where the AI suggests something you already have. You need to decide when to show suggestions and when to stay out of the way.

Every one of those features is the right feature for the right project. None of them fit in two hours alongside a real Azure deployment.

So here is what we are actually building on Wednesday.

The stack

.NET 10.

Blazor Server.

EF Core with SQL Server.

Azure deployment via GitHub Actions.

GitHub Copilot or Claude as our coding partners.

No shortcuts on the stack.

This is production-grade technology you would actually use in a real project.

What we are shipping

A real Blazor Server app. Clean component structure. No shortcuts.

A data layer with EF Core and SQL Server. Items stored properly. Not a static list.

One AI feature done well. Natural language input. You type “add milk, eggs, and bread”, and Claude or GPT parses it into three separate items. Simple to describe. Genuinely useful. A real example of AI integration that is not just autocomplete.

A GitHub Actions pipeline for deployment. Not a manual click-through-the-portal deployment. A proper CI/CD pipeline that deploys to Azure automatically.

And then we open the deployed app in the browser with a real URL before we close the Zoom call.

And yes, we do all of that with the help of AI like GitHub Copilot or Claude.

That is the scope. It fits in two hours. And it is more than most developers ship in a weekend of solo work.

The sharing feature? That is a great idea for a future workshop. Or something you build yourself after Wednesday, using the foundation we create together.

Why I am excited about this specific app

I have built versions of this before.

I know where the interesting decisions are. I know which Blazor Server patterns make sense here and which ones are overkill. I know exactly where Claude and GitHub Copilot shine in this kind of project and where you need to stay in charge of the architecture.

That knowledge is what makes a live workshop different from a tutorial.

You are not just watching me follow a script. You are watching someone who has thought about this problem before make real decisions in real time.

When something breaks - and something always breaks - you see how I actually debug. Not the clean version. The real version.

What you walk away with

A deployed Blazor Server app on Azure with a real URL you can share right after the session.

The complete source code on GitHub. .NET 10, Blazor Server, EF Core, SQL Server, GitHub Actions pipeline - all ready to clone and use as a starting point for your own projects.

The full recording with lifetime access, so you can revisit any part of the build or code along at your own pace.

A clear mental model for how to use GitHub Copilot and Claude as actual coding partners in a real .NET 10 Blazor project. Not just autocomplete. Real AI-assisted development where you stay in charge of the decisions.

The member who suggested this will probably be in the room

There is something I genuinely like about that.

Someone had an idea. Mentioned it. And now we are building it live, together, in front of everyone. We cut his feature list in half, and he is okay with that because the core of what he wanted is still there.

A real app.

Deployed.

Working.

Something he can actually use.

That is what the .NET Web Academy is supposed to feel like.

Join us this Wednesday

All Access Pass members are in for free.

Reserve your seat

📅 Wednesday, May 20th

🕐 Berlin 9:15 PM / London 8:15 PM / New York 3:15 PM / Los Angeles 12:15 PM

Already a member? Find your Zoom link here.

The source code and full recording come with every ticket. So even if you cannot make it live on Wednesday, you still get everything.

Hope to see you there.

Recently I sat down with a completely empty folder, a terminal, and a simple idea: a little app for rating books.

No starter template. No pre-built architecture. No existing codebase to fall back on. Just that blank slate feeling every developer knows, where the first decision is somehow always the hardest one.

Where do you even start?

I have been building .NET applications for a long time.

And for most of that time, the answer to that question was the same: crack your knuckles, set up your folder structure, create your base entities, write your first service, and slowly, carefully, build your way up from the ground floor.

It works. It has always worked. But it is slow.

And honestly, a lot of it is repetitive work that does not really require your best thinking.

So this time I tried something different.

I kept the thinking for myself, the architectural decisions, the conventions, the overall structure, and handed the repetitive implementation work to AI.

What happened next genuinely surprised me.

Not because the AI was magic.

It was not.

There were errors. There were decisions I would have made differently. But in about thirty minutes, I had a running Blazor Server app with real architecture, real features, and a codebase I actually understood and owned.

Here is exactly how I did it.

Where we start

No templates. No starter kit. Just a fresh folder called BookRatings and a terminal.

The first step is as simple as it gets:

dotnet new blazor

That gives us a Blazor Server app with all the default scaffolding. Components, pages, the basic layout. Nothing special yet. But from here things get interesting, because before we write a single line of application code, we need to make a decision that most developers skip entirely.

What architecture are we actually using?

Deciding on architecture before writing code

This is where AI-assisted development differs from vibe coding. You don’t just start prompting. You think first.

For this project we go with vertical slice architecture. The idea is simple: instead of organizing code by technical layer (controllers, services, repositories), you organize by feature. Every use case gets its own folder, its own command or query, its own handler, its own response objects. Everything that belongs to a feature lives together.

It scales well. It keeps things focused. And it maps very naturally to how AI generates code, one feature at a time.

But here is the thing. If you just start prompting Claude or Copilot without telling them about your architectural decisions, they will make their own. And you might not like what you get.

So we define things upfront.

Let’s build this together

Would you like to build an app like that together with me? That is exactly what we are going to do in the upcoming live Blazor AI workshop.

Two hours, hands-on, building together from an empty folder to a real deployment. If you are serious about making AI-assisted development part of your workflow, this is the most practical way to get there.

Learn Blazor + AI here

The AGENTS.md file: your AI’s instruction manual

The AGENTS.md file is a markdown file that lives in your project root.

Both Claude and GitHub Copilot can read it, and it acts as a persistent set of instructions for how code in this project should be written.

You can prompt Claude to generate it for you:

“Please create an agents.md file with general instructions on how to implement features. Use vertical slice architecture with feature folders. I want a folder for every entity and then for every use case. Inside the use case folder I want commands, queries, and the corresponding handlers, response objects and so on. Use individual files for everything. Also use dependency injection with interfaces and best practices in general.”

What comes back is a solid starting point. Folder structure conventions, naming rules, how to handle results instead of throwing exceptions, where Blazor components live relative to their feature slice, and more.

This file now travels with your codebase. Every time you or your AI touches this project, the conventions are right there.

Going further with AI skills

Once you have the AGENTS.md file, you can go one step further: AI skills.

Skills are small, focused markdown files that live in a .claude/skills folder. Each skill has a name, a description that acts as the trigger, and a checklist of steps.

The idea is that instead of cramming everything into one big instructions file, which gets read in full every time you prompt and costs you tokens, you split things up into on-demand instructions.

For this project we create two skills.

One for creating a vertical slice, covering the backend side. Command, query, handler, response, all of it.

One for creating the corresponding Blazor Server UI. The page, the component, the wiring.

Now when you want to add a new feature, you can simply say “create a vertical slice for X” and Claude will pick up the right skill, follow the checklist, and generate code that matches your conventions.

This is the setup work that pays off every single time you add a feature. Invest fifteen minutes here, save hours later.

Scaffolding the first feature

With the AGENTS.md and skills in place, open a fresh context window and give Claude its first real task:

“Create a vertical slice for reading a list of books. Also create a simple book entity with ratings included. Use EF Core with an in-memory database and seed some books.”

Watch what happens. Claude reads the AGENTS.md file, picks up the vertical slice skill, and starts scaffolding. It creates:

• A Book domain entity with a Rating relationship

• A ListBooks query and handler

• A response DTO and a BookListItem DTO

• A Blazor page that renders the list

• A DbContext with EF Core in-memory configured

• A seed method with a handful of sample books

Is every decision perfect?

No.

In this case Claude generates a repository layer that is not really necessary here since the handler could talk to the DbContext directly. But that is a conversation for your AGENTS.md file (or the skill). Define your preferences once, and the AI will follow them.

The point is: in a few minutes, we have a running list of books rendered in a Blazor page.

From scratch.

Adding the create and rate features

From here we keep going in the same rhythm. One prompt per feature, one vertical slice at a time.

“Implement the create book feature.”

Done. A form, a command, a handler, a redirect back to the list.

“Now also enable adding ratings to books.”

Done. A rate button, a simple form, a command, a handler that adds the rating to the book.

Each time Claude follows the conventions we defined. Each time the output lands in the right folder, with the right structure, with the right naming.

This is what it looks like when AI is working with your architecture instead of inventing its own.

When things go wrong

Here is where things get honest.

When we try to submit a rating, we get an unhandled exception:

“Attempt to update or delete an entity that does not exist in the store.”

A year ago this would have sent most developers straight to Stack Overflow. Now we paste the error into Claude and ask what is going on.

The explanation is actually quite good. In Blazor Server, the DbContext is scoped to the WebSocket circuit, not to individual requests. When you create a book in one operation and then try to add a rating in another, they share the same long-lived DbContext instance. The change tracker carries state between operations, and the in-memory provider gets confused.

The fix is to use IDbContextFactory instead of injecting the DbContext directly, creating a fresh context per operation rather than sharing one across the circuit.

Claude implements the fix. We run the app again. It works.

This is a real lesson worth internalizing.

AI-assisted development does not mean error-free development.

It means you have a very capable debugging partner available at all times. But you still need to understand what is happening. You still need to read the output, review the changes, and know enough to catch the things Claude gets wrong.

That is the line between skilled AI-assisted development and just hoping for the best.

What we ended up with

Starting from nothing, in roughly thirty minutes, we have:

• A Blazor Server app with vertical slice architecture

• A book entity with ratings

• EF Core with an in-memory database and seed data

• A list view, a create form, and a rating form

• A working AGENTS.md file and two reusable AI skills

• A git history with meaningful commits along the way

Is it production-ready?

Not quite.

There are things to clean up: the repository layer, the placement of Blazor pages, a few conventions that could be tightened up in the AGENTS.md file.

But as a foundation it is solid. And more importantly, it is yours. You understand every part of it because you designed the architecture. AI just helped you build it.

Want to go further?

If you want to take this from a local in-memory app all the way to a deployed application on Azure, that is exactly what we cover in the live Blazor AI workshop.

Two hours, hands-on, building together from an empty folder to a real deployment. If you are serious about making AI-assisted development part of your workflow, this is the most practical way to get there.

Join the Blazor AI Workshop here

About a year ago, I published a YouTube Short. I said I didn’t think “vibe coding” was the future. I described it as prompting an AI, copying the output, and repeating until something works. I said I didn’t think it was the right approach.

I want to revisit that.

Not because I was entirely wrong.

I wasn’t.

Mindless copy-paste is still bad engineering. But I was wrong about the bigger picture - and I think a lot of developers still are.

So let’s walk through what changed, what the distinction actually is, and why it matters for your career right now.

A quick note

If you want to learn how to build complete .NET AI-powered apps step by step, including Blazor, EF Core, Vertical Slice Architecture, Copilot workflows, and OpenAI integrations, I have just the right course for you:

👉 .NET Web Development with AI & Copilot

Use code SUBSTACK at checkout for an exclusive discount!

👉 Get it here

What I Actually Got Right

The specific workflow I was criticizing - prompt AI, copy output, paste it, run it, repeat until it compiles, ship it without really understanding what’s in there - that workflow is still a problem. Not primarily because AI is involved, but because not understanding your own code is always a problem.

If you can’t read the code the AI generated, you can’t:

• Debug it when it breaks (and it will)

• Review a colleague’s PR that changes it

• Extend it six months from now without introducing bugs

• Recognize when the AI made a subtle architectural mistake that will cost you three weeks in six months

That criticism holds. The term “vibe coding” always pointed at the mindlessness, not the AI. And that part hasn’t changed.

What I Got Wrong

I implied the answer was to be skeptical of AI coding tools altogether. That’s where I was wrong.

Here’s what changed in 12 months:

The tools crossed a threshold

GitHub Copilot went from inline autocomplete to a full agent that reads your codebase, understands your architecture, and executes multi-step tasks.

Claude went from a capable chatbot to an agentic coding environment. The quality of output for routine tasks - boilerplate, scaffolding, tests, refactoring - is now correct on the first attempt often enough that it fundamentally changes how you should think about your time.

The gap between users and non-users became undeniable

A year ago, using AI tools was a competitive advantage.

In 2026, not using them is a competitive disadvantage.

Teams with AI-first workflows are shipping faster with the same headcount. The developers who invested in learning these tools early are the ones setting the pace now.

The ecosystem matured

Custom instructions, AI Skills, MCP servers - you can now teach AI your patterns once and have it apply them correctly, indefinitely. It’s no longer about prompting a generic model and hoping for the best. It’s about a collaborator that knows your codebase.

The tools from the beginning of 2025 and the tools of May 2026 are not the same category of product.

The Distinction That Actually Matters

I still wouldn’t call good AI-assisted development “vibe coding.”

The difference isn’t whether AI is involved. It’s whether the developer is engaged or checked out.

Skilled AI use means:

You still own the architecture

The AI generates code to your specifications. You decide the patterns, the folder structure, the trade-offs.

Then you encode those decisions - in AGENTS.md, in AI Skills, in a custom system prompt - and the AI implements them consistently. The judgment is yours. The execution is shared.

You verify everything

You read what the AI generates. You wouldn’t merge a PR from a junior developer without reading it. Treat AI output the same way.

Read it.

Understand it.

Push back when something looks off.

You use AI for tests, not instead of tests

One of the biggest gains from AI tools is generating test cases - including edge cases you’d miss in a manual pass.

But you still decide what coverage means and whether the tests are meaningful.

You stay current

These tools evolve faster than almost anything else in software right now.

A workflow that was optimal six months ago may already be obsolete.

Staying close to the tooling is part of the job now.

Why You Can’t Opt Out Anymore

Let me be direct: a year ago, using these tools gave you an edge. Today, not using them is a liability.

Two equally skilled developers are both applying for the same role or competing on the same team. One has mastered Copilot and Claude. One hasn’t.

The productivity difference is real and measurable - not 10%, but in some cases 2x or more for the kinds of tasks that consume most of a developer’s day: scaffolding, boilerplate, test generation, refactoring, documentation.

This isn’t about AI replacing developers. It’s about the bar shifting.

The barrier to entry for junior-level tasks is collapsing - AI can generate basic CRUD endpoints, write unit tests for simple functions, stub out boilerplate faster and more reliably than most people.

That means the value a developer brings now has to be above that threshold: architecture decisions, code review judgment, debugging complex systems, domain knowledge, knowing what to build and why.

Developers who use AI as a force multiplier for that higher-order work are the ones who will thrive.

Developers who either vibe code without understanding what they’re shipping or refuse to use these tools at all are the ones who will struggle.

By the way, I built a free Blazor AI Starter Kit for you. A clean Blazor project with AI integration already set up, including AI instructions, Skills, and the right architecture.

Get the free Starter Kit

What This Looks Like in Practice

In my own workflow - building .NET and Blazor applications - here’s what AI-assisted development actually looks like day to day:

• I define the architecture. CQRS, vertical slices, the patterns we use for validation and error handling. I encode those decisions in AGENTS.md and in dedicated AI Skills.

• I give Copilot a task: “Add a CQRS slice for DeleteVideoGame.” It reads the project structure, finds the existing pattern in my Features/ folder or the matching Skill, and generates the command, handler, and endpoint matching my actual conventions.

• I read what it generates. Every file. I push back if something doesn’t fit.

• I run the tests. Always. Often I’ll prompt Claude to generate edge-case tests I wouldn’t have thought of - and then I read those too.

That’s not vibe coding. That’s engineering with a capable collaborator.

A Year Later

One year ago, I was skeptical of a new term and a new workflow. I was right that the mindless version of it is bad. I was wrong to be skeptical of AI-assisted development as a category.

The developers who figured that out early - who invested the time to learn these tools, to set them up properly, to understand how to get consistent and reliable output - they’re the ones leading the way right now.

If you haven’t made that investment yet: it’s not too late, but the window is narrowing. Start with your most repetitive task.

Spend 20 minutes setting up a proper instruction file or a reusable AI Skill. See what it actually feels like to use these tools well.

That’s where the compounding starts.

It started, as all great engineering disasters do, with something completely reasonable.

We were building a feature. The feature needed a delete button. The delete button needed a backend endpoint. I had the endpoint half-written when a colleague leaned over from his desk and said four words that would define the rest of my week:

“Shouldn’t we soft delete?”

I looked up. He looked sincere. The question was fair.

And thus began what I now refer to internally as The Great Soft Delete Debate of Sprint 14 - a conflict that consumed five meetings, one whiteboard, roughly eleven Slack threads, and a significant portion of my will to live.

This is that story.

Day One: The Innocent Question

Tuesday, 10 AM. We had a scheduled 15-minute architecture sync. The agenda was light: confirm the delete endpoint, agree on a response format, done.

Alex - the dev who had asked the question - made his case calmly and professionally. We should add a DeletedAt timestamp to the table. Soft delete means we don’t actually remove the row; we just mark it as deleted. And while we’re there, we should probably add CreatedAt too. Good practice. Standard stuff.

He wasn’t wrong.

Sarah pushed back. “Do we actually need that? Who’s ever going to un-delete one of these records?” Alex said it was best practice. Sarah said it was scope creep. I said maybe we should think about it.

The meeting ended without a decision, which meant we would need another meeting.

Subscribe now

Day Two: The Whiteboard Era

Wednesday. We booked a room with a whiteboard. This felt like progress.

By the end of the session, we had a very thorough pros/cons list that I am going to reproduce here in its entirety because I think it captures the energy of the moment:

Pros of soft delete:

• Can recover records if needed

• Audit trail built-in

• “Best practice” (source: Alex)

Cons of soft delete:

• Every query needs WHERE DeletedAt IS NULL

• Breaks unique indexes

• Global query filter needed in EF Core - easy to forget

• Cascades become complicated

• GDPR complicates things (you may need to hard delete anyway)

• Need to test both delete paths

• “We’ve never actually needed this” (source: Sarah, three times)

Pros of hard delete:

• Simple

• Explicit

• Every query just works

Cons of hard delete:

• Can’t recover records

• No audit trail

• “Not best practice” (source: Alex, same tone as before)

The meeting ended without a decision. We agreed to “sleep on it.”

Day Three: The GDPR Twist

Thursday brought a new combatant: Marcus from the compliance team, who had somehow heard about the debate and arrived with a printed document.

“If this table contains personal data,” he said, placing the document on the table with the gravity of someone delivering a verdict, “GDPR requires actual deletion upon request. So your soft delete still needs a hard delete path.”

Silence.

Alex said: “That’s fine, we’d have a purge job.”

Sarah said: “So now we have two delete paths, a purge job, a DeletedAt column, AND a CreatedAt column.”

Marcus said: “And you might need a DeletedBy field.”

I stared at the ceiling.

The meeting ended without a decision.

Relatable?

If this debate is relatable and you care about making better architectural decisions and shipping cleaner .NET solutions, the .NET Web Academy membership is built for you.

Live office hours. Real projects. Practical discussion.

Join the .NET Web Academy

Day Four: The Hypothetical User

Friday. I was now writing WHERE DeletedAt IS NULL in my sleep.

We convened again, this time with a product manager. The question on the table: has any real user, in any real scenario, ever needed to recover a deleted record from this particular table?

The product manager thought about it. She checked her notes. She opened Slack and scrolled for a while.

“I can’t think of a specific instance,” she said finally. “But they might want to someday.”

Alex said that was exactly his point.

Sarah said that was exactly her point.

I said that if we didn’t ship this feature by end of sprint, we were going to have a very uncomfortable retrospective.

The meeting ended without a decision.

Day Five: The Resolution (Sort Of)

Monday. The delete button had now been in “in progress” on the sprint board for seven working days. The senior engineer - who had been on leave the entire previous week and was experiencing all of this for the first time - looked at the board, looked at us, and asked a single question:

“Is this going to an archive feature, or is it actually gone when it’s deleted?”

We said we didn’t know. That was the whole debate.

He shrugged. “Users expect deleted things to disappear. Hard delete. If we need soft delete later, we add it. Ship the button.”

And that was it. The meeting lasted four minutes.

What We Should Have Done on Day One

Looking back, here’s the thing: Alex wasn’t wrong. Soft delete is a legitimate pattern. It’s genuinely useful for audit trails, recovery workflows, and systems where deletions have downstream consequences. For the right use case, it’s the right call.

But for a delete button in our specific feature, with our specific requirements - there was no evidence we needed it. And in the absence of evidence, we should have defaulted to the simpler thing.

Here’s the decision framework we now use on our team before the debate even starts:

1. Does a real user, in a real workflow, ever need to undo this deletion? Not a hypothetical user in a theoretical future - an actual person, in a scenario you can describe. If yes, soft delete makes sense. If you can’t name the scenario, proceed to step 2.

2. Do you need a formal audit trail? If you need to know who deleted what and when for legal or compliance reasons, consider a dedicated audit log table rather than DeletedAt columns on every entity. It’s more flexible and doesn’t contaminate every query in the system.

3. Are there regulatory obligations? GDPR, HIPAA, financial compliance - know your obligations. Soft delete and compliance requirements sometimes conflict directly, so understand this before you commit.

4. What’s the cost of being wrong? If you hard delete now and later find out you needed soft delete, how hard is it to add? Usually: a migration, some query updates, maybe an EF Core global filter. Annoying, but not catastrophic. When the cost of changing course is low, lean toward the simpler option now.

Default: hard delete. Not because it’s always right - but because it’s simpler, it’s explicit, and you can always add soft delete when you have real requirements instead of hypothetical ones.

The Broader Lesson

The soft delete debate is a specific instance of a general pattern: teams that are smart, diligent, and thoughtful can spend enormous energy on decisions that don’t actually require enormous energy.

The delete button wasn’t a hard decision. The architectural pattern wasn’t deeply controversial. The data didn’t have any unusual requirements. And yet we spent a week on it - not because we were bad engineers, but because we didn’t put a time box on the decision.

The rule I now apply: if the decision is reversible and the stakes are low, you get ten minutes. Put both options on the board, ask if anyone has a blocking concern based on actual requirements (not hypothetical ones), and pick the simpler one. Write it down. Move on.

Save the long debates for the decisions that actually deserve them: the ones that are hard to reverse, high stakes, or genuinely ambiguous in ways that require deeper analysis.

A delete button is not one of those things.

Conclusion

The feature shipped on Monday afternoon. Users can now delete things. The data is actually deleted. Nobody has complained. Nobody has asked to un-delete anything.

The DeletedAt column remains hypothetical.

Alex has since proposed soft delete on two other features. Both times, we went through the four questions above. Once the answer was yes - we needed recovery - and we implemented soft delete properly, with full awareness of the tradeoffs. The other time, the answer was no, and we shipped a hard delete in about twenty minutes.

The framework works. The delete button is fine.

But I still hear “shouldn’t we soft delete?” in my dreams sometimes.

TLDR

Cohort 2 of the Blazor AI Accelerator starts May 13. Small group. Real projects. Real AI. Real Azure deployments.

Early bird seats are available for a limited time.

Claim your spot here

When I launched the Blazor AI Accelerator in March, I had a plan.

By week 3, it was gone.

Not because things went wrong.

Because something better happened.

The real struggle is not finishing

Most developers do not struggle because they lack knowledge.

They struggle because they never start.

Or they start and never finish.

You spin up a Blazor project. You follow a few tutorials. It works. Until it does not.

Your architecture feels messy. Deployment fails again. And even with GitHub Copilot or Claude, you are still not sure if your approach is actually right.

That is what I call tutorial limbo.

And it happens to thousands of developers.

What I thought would happen

I designed a structured 8-week program.

Week by week. Topic by topic. Clean architecture, identity, Azure deployment, AI integration.

I had a plan for every session.

By week 3, nobody wanted the plan anymore.

What actually happened

The 8 developers in the room were all dealing with real problems.

Not toy projects.

Actual production challenges they were paid to solve.

Most of them were migrating legacy desktop apps and fat clients to the web with Blazor. Others were building new apps from scratch using GitHub Copilot and Claude as actual coding partners.

So instead of following the plan, we followed the work.

Someone would share a tricky architecture decision. Another would pull up their screen and show how they tackled something similar. We debated live. Real code, real decisions, real projects.

It turned into a mastermind.

And honestly? It was the best thing I have ever run.

Here is what cohort 1 developers built

Tim migrated the entire printing job system of a legacy ERP to a cloud API. Then his purchasing team saw the Blazor front end and told him they wanted to drag documents from email directly into the app. He showed them live. It worked perfectly. Now he is rebuilding the whole thing in Blazor.

His words:

“I moved the whole printing jobs from my legacy desktop app to the API and it works. It is moving so fast. I think I am just going to stop doing it in the desktop and purely do it on a Blazor front end.”

Aaron built a tablet app for his field team. Using AI to generate UI components in real time. Live in session 7, he told the AI to change a component and it just knew what to do.

Jeff came in as an experienced developer who could have built his financial portfolio app alone. He joined anyway. His reason:

“I tried talking to my five or ten reliable developer friends about AI. One guy said he would look at it over Christmas break. Never did. To stay on the cutting edge of stuff like GitHub Copilot, the ability to communicate with Patrick and the other developers is important.”

His before and after:

What I learned from running cohort 1

You do not need a curriculum. You need a destination and accountability.

The destination is simple: by week 8, you have shipped a real Blazor app with AI and Azure.

The accountability is the group. Ten developers who see your progress every week. That alone is worth the price of admission.

Jeff said it best:

“Perhaps the number one benefit is simply that you will actually carve out time to show up for a 90 minute session each week. We often do not take the time to learn. Here, you will.”

That is exactly it.

The cohort does not just teach you. It makes you show up.

And showing up is what separates developers who ship from developers who stay stuck.

Cohort 2 starts May 13

Same format. Max 10 developers. 8 weeks. One shipped app by the end.

Every Wednesday at 9:15 pm Berlin / 8:15 pm London / 3:15 pm New York / 12:15 pm Los Angeles.

No slides. No rigid curriculum. Real code, real decisions, real projects.

What you get:

• 8 live weekly group sessions

• Lifetime All Access Pass to every .NET Web Academy course

• All cohort 1 session recordings

• Private Discord for replays and resources

• Mastermind format with max 10 developers

Early bird spots are limited. Details and pricing here:

Check availability and claim your spot

This is for you if:

You are a .NET developer working on a Blazor project right now. You are migrating a legacy desktop app to the web. You want to integrate AI into your stack and do not know where to start. You learn better by doing than by watching.

This is not for you if:

You are a complete beginner to .NET. You are looking for a structured video course. You are not ready to commit to showing up every week.

One last thing

The cohort transformed because the developers in it were serious.

They showed up every week. They shared real problems. They pushed each other forward.

If that sounds like you, I would love to have you in cohort 2.

Claim your spot here

Spots are limited. Starts May 13.

Take care,

Patrick