That’s a wrap on this week. I’m ready for a long weekend here in the States, and will be back with a reading list next Tuesday.

[blog] The Incumbents Are Coming. I’m probably in the minority, but I like when staggering leaders roar back into a primary position against the feisty challenger.

[blog] Your Agent Doesn’t Know How to Wait. Huh. I don’t think I’ve come across this idea before. If your agent needs to wait for an operation to finish, make sure you design it correctly. Otherwise, your costs can quickly balloon.

[blog] How to Handle Errors in Go. Whether you’re writing it yourself or asking an AI agent to do it, make sure your code has robust error handling.

[article] Research: How Curveball Questions Can Surface the Insight You’re Looking For. I’ve spent a fair amount of time this year working on asking better questions. I liked this perspective.

[article] How does developer experience shape the way teams use coding agents? From this data, it looks like those with more experience in a project apply more careful use of AI, and with more rigor.

[blog] Stop rebuilding from scratch: cache Docker layers on Cloud Build. These numbers can have a big impact at scale. Great deep dive here.

[blog] Portal by Spotify cut my Claude Code token usage by 90%. Wasting a ton of tokens just having your LLM read files and do I/O tasks? Save the LLM for real reasoning work.

[blog] How to Think About Open Weight Models. Excellent analysis from Steve here. If you’ve only kept a casual eye on the open model space, or even if you’ve paid close attention, you can learn something here.

[article] Twenty Years of jQuery: How a Little Library Rewired Web Development. This was a big deal twenty years ago. My how everything has gotten more complicated since then.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below:

Microsoft flagged a phishing campaign last week that exploits a gap in how machines read text. Attackers are slipping invisible Unicode tag characters into email bodies; they don’t render on screen but change the underlying string that software processes.

The company says attackers are already using the technique at scale to bypass spam filters and ML-based classifiers, and the same approach could cause problems for AI systems that regularly ingest text from external sources.

Tag characters split keywords

Security researchers have documented a nearly identical technique targeting LLMs, commonly called “ASCII Smuggling,” which uses Unicode tag characters in the U+E0000 to U+E007F range — code points that exist in the character stream but aren’t displayed by most interfaces.

That gives you two versions of the same text: what a person reads and what software receives.

For example:

Human view:     funding
Under the hood: fun⟨U+E0020⟩ding

In the campaign tracked by Microsoft Defender for Office 365, attackers weren’t using tag characters to smuggle hidden instructions into an AI model. They placed them inside high-signal words associated with financial phishing, such as “funding,” “loan,” and “credit,” so that filters scanning for those terms would no longer find an exact match.

A hunting signature for ASCII Smuggling fired on roughly 21,000 messages the day before the campaign started and the next day, it fired on more than 1.3 million. Then, just two days later, the count passed 2.3 million. The whole time, recipients saw ordinary-looking offers for business loans and credit lines.

Just two days later, the count passed 2.3 million.

Tokenizers parse them differently

NLP systems break text into tokens before processing it, and slipping an unexpected Unicode character into a word can change how those tokens are formed. Researchers have already shown that encoding techniques can hide adversarial content from AI systems, although Microsoft’s campaign uses the trick for a different purpose.

NLP systems break text into tokens before processing it, and slipping an unexpected Unicode character into a word can change how those tokens are formed.

Exactly what happens depends on the tokenizer. Some may ignore the tag character while others split the surrounding text differently, so developers have to test the models they’re actually using rather than assume they’ll all behave the same way.

Running the text through standard Unicode normalization won’t necessarily remove the tags, either. NFC and NFD can clean up different representations of the same character, but they weren’t designed to strip Unicode tag characters, which means those tags can still make it through to the next step.

Agents lack email’s defenses

Email providers have other ways to spot a suspicious message beyond the words it contains, but an AI pipeline may be working with far less information.

That then becomes a problem when agents are pulling in outside text and using it to decide what to do next because those invisible characters buried in the text can change how it gets processed along the way, while also making a hidden prompt injection much harder for someone looking at the original to catch.

Normalize before the model

For applications that have no reason to accept characters in the U+E0000 to U+E007F range, the simplest approach is to remove them before the text reaches the model, although that gets trickier when an application has a legitimate reason to keep them.

In those cases, developers can compare the original text with a version that has the tags removed and look for anything that changed, while also testing the tokenizer their application actually uses to see how it handles the same characters. Whatever gets cleaned should stay that way through the rest of the pipeline, rather than checking one version of the text and then sending the untouched original to the LLM.

The subdivision flag edge case

Stripping every Unicode tag character isn’t always safe because some serve a legitimate purpose. The subdivision flag emojis for England, Scotland and Wales rely on invisible tag-character sequences to render, and Microsoft’s initial hunting signature was broad enough to trip on those flags before the team carved out an explicit exception.

Stripping every Unicode tag character isn’t always safe because some serve a legitimate purpose.

The post Microsoft built a prompt injection detector. Then it caught a phishing campaign instead. appeared first on The New Stack.

Audacity 4 has been in the works for some time, and had its own mini controversy last year when an unfortunate redesigned logo started making the rounds. The final version of the new icon isn't nearly as bad as the early rendition that was circulating last October. But more importantly, all the promised improvements to the self-proclaimed "world's most popular audio editing and recording app" are here, turning Audacity from a free and capable but extremely clunky audio editor into a powerful modern tool.

The biggest change is the move to a non-destructive editing workflow. That means you can trim a clip down, then recover the audio simply …

Read the full story at The Verge.

Four years and 210 weekly issues taught me more than the topics did. The four lessons I keep coming back to are the ones this issue walks through: consistency beats brilliance, teaching is the fastest way to learn, the fundamentals outlast the frameworks, and your audience is smarter than you think. I also want to talk about AI, because the next four years of this job will not look like the last four.

Four years ago this week, the first issue of this newsletter went out.

Two hundred and ten Saturdays later, something has landed in your inbox almost every single week. Whether I was traveling, sick, buried in work, or completely out of ideas.

I want to do something different this week. Instead of an EF Core trick or an architecture deep dive, I want to step back and talk about what writing four years of these actually taught me. The lessons turned out to be bigger than the topics.

I Almost Didn't Make It Past Issue 10

The first issues were rough.

I wasn't sure anyone wanted to read what I had to say. I'd write something, second-guess it, rewrite it, and hit send with my stomach in a knot. A few people replied, most didn't, and there were weeks I was convinced I'd run out of things to write about by issue 20.

What kept me going was a decision I'd already made: one issue, every week, no exceptions. Motivation alone would never have done it, because motivation shows up when you don't need it and vanishes when you do.

That decision did more for my career than any single piece of code I've ever written. I wrote about that same itch to build in The Urge to Build Something, and this newsletter became the longest-running thing I've ever built.

Lesson 1: Consistency Beats Brilliance

Not one of these 210 issues was perfect. Some I'm proud of, some I'd rewrite completely, and a few I'd quietly delete.

But the brilliant issue you never publish helps no one. The decent issue you ship every single week, for four years, compounds into something neither of us could have predicted at the start.

It's the same lesson I keep relearning in software. The clever architecture that ships to production in eighteen months loses to the boring one that ships to production every two weeks.

If you're sitting on a blog post, a side project, or a talk you haven't given, this is the only advice that matters: start, and then don't stop. Quality grows out of quantity.

Lesson 2: Teaching Is the Fastest Way to Learn

I thought I understood things, until I tried to explain them to thousands of developers who would absolutely email me when I got it wrong.

You can hold a fuzzy, half-correct model of a concept in your head for years and never notice the gaps. The moment you sit down to write 1,500 clear words about it, every gap suddenly becomes obvious. Why does this pattern exist? What problem does it actually solve? When would I not use it?

A huge amount of what I know about .NET, architecture, and system design, I learned because I had to explain it on a deadline. Writing the newsletter forced me, week after week, to actually know the things I thought I already understood.

If you want to understand something deeply, teach it. Write the post, record the video, or explain it to a junior on your team. Writing the explanation is where the learning happens.

Lesson 3: The Fundamentals Outlast the Frameworks

Look back across four years and you'll see the surface change constantly. .NET 6 became 7, then 8, then 9, then 10, and .NET 11 is right around the corner. Libraries came, went commercial, and got replaced. Patterns I championed, I later qualified.

But the advice I keep giving hasn't changed since issue 1:

• Start with a modular monolith. You can extract a service later, but you can't easily un-distribute a system. Split when something concrete forces you to (a team blocked on every deploy, a module with its own scaling needs), not because the monolith feels messy. I believe this enough that I built an entire course around it.
• Keep business rules inside the domain model. A rule that lives in a controller or a request handler gets duplicated the day a second caller needs it, and the copies drift apart. The model enforces it once.
• Treat your API as a long-term contract. Consistent error responses, pagination, and versioning cost you an afternoon on day one. Retrofitting them after clients depend on the API costs you months. That thinking became Pragmatic REST APIs.
• Assume every network call will fail. Which means retries, and retries mean idempotency and the Outbox pattern for anything that publishes messages.

That list was true in issue 1, and it'll be true in issue 420.

Spend most of your learning budget on the things that don't expire. The new syntax is the easy part once the underlying ideas are solid.

Lesson 4: Your Audience Is Smarter Than You Think

Some of the best thinking in these four years didn't come from me. It came from your replies: the corrections, the "have you considered…" emails, the pushback when I oversimplified, the war stories from production systems far bigger than anything I've run. Every time I wrote something a little too confidently, someone wrote back with the nuance I'd missed, and the next issue was better for it.

Writing in public is the best feedback loop I've ever found. It's terrifying to be wrong in front of an audience, and it's the fastest way to get less wrong.

Thank you for being demanding readers. You made me a better engineer.

What This Newsletter Actually Became

I started writing to share a few .NET tips. Somewhere along the way it became the spine of everything else: the videos, the courses, the community, this whole second career I never planned. The YouTube channel turned four this year too, and I told that side of the story in What 4 Years on Tech YouTube Taught Me.

But strip all that away and the core is still just this: every week, I try to explain one thing clearly to people who want to get better at their craft. That's it. That's the whole job, and it's the most rewarding work I've ever done.

When someone emails to say a piece helped them pass an interview, ship a system, or finally understand something they'd struggled with for years, that never gets old. That's the reason there's a 210th issue at all.

What About AI?

I can't write a four-year retrospective in 2026 and not talk about AI.

When issue 1 went out, AI meant a slightly smarter autocomplete. Today, coding agents write a growing share of new code, and the argument has moved on to whether a human should even read the output. Uncle Bob, the author of Clean Code, says he stopped reading the code his agents write. I recorded my reaction to that one, because I think it's the most interesting question in software right now.

I'm very bullish on AI. I've spent a good part of this year going deep on agentic coding, and I shared my whole setup in a video I called Tokenmaxxing: My Claude Code Workflow.

Notice what AI didn't change on the list of lessons above.

The fundamentals became the review checklist. Whether a human or an agent wrote the code, I ask the same questions: does this rule belong in the domain model, will this change break an existing API client, what happens when this call fails. The agent changes how fast the code appears, not what makes it correct.

And teaching turned out to be the perfect preparation. Directing an agent well is mostly the skill this newsletter forced me to practice for four years: explaining a problem clearly enough that someone else can act on it.

Expect more AI in these issues going forward.

Thank You

I don't say this enough, so let me say it plainly.

Thank you for reading. Thank you for the four years. Thank you for forwarding issues to teammates, for replying with your own hard-won lessons, for trusting me with a few minutes of your Saturday. Some of you have been here since the early, rough issues. Some of you joined last Tuesday. Either way, you're the reason this exists.

I have no plans to stop. There are at least 200 more issues of ideas rattling around, and the urge to build, to explain, and to share hasn't faded one bit.

So here's to the next four years. Same deal as always: one issue, every week, no exceptions.

If you've gotten value from these over the years and want to go deeper into the way I actually build software, that's exactly what I put into Pragmatic Clean Architecture.

See you next Saturday.

Thanks for reading.

And stay awesome!