A couple of popular open source projects in the .NET ecosystem, first Verify and now Polly - have adopted (or are thinking about adopting) the Open Source Maintenance Fee to support the long-term development of their projects.

What follows is the popular cycle of rancor, procurement rage, sad /r/dotnet users, and another popular .NET library monetizing the library itself to sustain the OSS project.

Things are different than when I first started writing about IdentityServer relicensing five years ago.

IdentityServer has been very successful commercially since relicensing and everyone can see it, serving as an inspiration for many other maintainers.

Maintainers are no longer intimidated by u/CheetoDustedFatPig or u/DisgruntledMidCoder expressing public disapproval on /r/dotnet. The .NET Foundation is absolutely powerless to stop its own projects from leaving and relicensing¹.

In short, what we have here is the classic incentives problem that has always faced OSS maintainers and their commercial users.

What’s different this time is the maintainers have a proven go-to-market strategy for essentially sticking a loaded gun into the mouths of corporate users and demanding that they pay or face the consequences.

There’s a way to put a stop to the cycle of relicensing, but will anyone listen?

Read More

There’s been lots of rancor online about whether you should read and review LLM-authored code. I wanted to share a project we’ve been using in production for months where I rarely review any of it: ShellSyntaxTree.

ShellSyntaxTree is a parser that attempts to create AST representations of both bash and PowerShell commands using a shared tree representation and parser abstractions, albeit with slightly different grammars to accommodate the quirks between the scripting languages.

SST is an essential tool for powering one of my other projects: Netclaw - a “claw”-style autonomous AI assistant. We use SST to power Netclaw’s approval system for requesting humans to authorize commands: netclaw.dev/architecture/security-model.

SST isn’t a security tool, but it sits inside a security decision. Netclaw auto-approves commands by matching them against pre-approved patterns - git pull, gh pr view - and SST is the layer that extracts those patterns from the raw command string. Get the parse wrong and Netclaw can auto-approve commands the user hasn’t blessed or prompt for commands the user already has.

Read More

I experienced a type of AI psychosis, but not the one everyone else is talking about - in my case it was a need to “keep my agents busy” at all times or I was “falling behind” relative to everyone else using large language models to move “faster” in the software industry.

I’ve recently concluded that this fear is nonsense and, like most other things you read online, is manufactured to sell something. AI inference probably.

Read More

In “Software 2.0: Code is Cheap, Good Taste is Not” I introduced “Software 2.0,” broadly, as an emerging practice in software development where large language models implement and humans act as planners, designers, and verifiers of LLM output. We’ll continue to get more into the specific techniques, tools, and practices of how to do that throughout these essays.

In this post, I’ll walk through the core techniques for greenfield Software 2.0 development - planning mode, reference architectures, agent skills, and verification pipelines - using TextForge, an AI email automation tool I built for sales and operations, as a real-world example.

To give you a sense of how far these techniques can take you: TextForge had to pass a CASA2 audit in order to get verified by Google. That’s a higher bar than I’ve had to clear for any of my hand-written applications and we passed it easily because even though LLMs wrote nearly 100% of TextForge’s code, my planning, QA, testing, security hardening, and verification processes were rigorous.

Read More

I’ve been using LLMs to help me develop software in earnest since the original releases of GitHub CoPilot.

The earliest talk I gave on the subject was in March / April 2024 to a customer who was interested in rolling out LLM-assisted coding to their staff. I made a public-facing version of this talk in July, 2024. All of those techniques are still fundamentally useful, but the tooling and models are simply lightyears ahead of what they were then.

Things are moving very quickly in the LLM-assisted coding space, leading many to ask “is this the end of the line for human software developers?”

The “short” answer to this question is:

1. There are classes of human software developers who are already rendered obsolete by LLM-assisted coding tools and it’s only a matter of time before bureaucratic and market inertia catches up to either eliminate their roles or compress their wages. We are going to call these developers who steadfastly refuse to learn LLM-assisted techniques “coasters¹” going forward;
2. Developers and designers who escape “coaster”-ism through learning how to wield LLMs effectively, skeptically, and cautiously are going to be more productive and needed than ever before; because
3. LLMs have fundamental limitations that will likely never be resolved with transformer architectures, despite advances in both techniques and hardware. These are irresolvable issues with the mathematics of LLMs, verifiability of output, scaling laws of AI, and design trade-offs that AI labs have explicitly chosen with transformer architectures.

In the longer text of this essay, I want to explore these questions and others in more depth.

In addition to addressing the current and future state of the software industry, I also want to introduce some techniques for leveraging LLMs correctly - not merely prompting, but through treating LLMs like programmable virtual machines that can be used in ways that were not possible with Software 1.0 engineering tools.

I hope you find this helpful and insightful.

Read More

“I have a great idea: let’s create a five-layer deep inheritance hierarchy with a universal base class that every domain object inherits from! That way, when requirements inevitably change, we’ll only need to touch… everything.”

This is episode two of my Why Your Software Sucks video series, and today we’re talking about inheritance - specifically, how deep inheritance hierarchies turn your codebase into an unmaintainable mess.

Read More

I had never heard of Michael Green before his now-infamous essay “Part 1: My Life Is a Lie - How a Broken Benchmark Quietly Broke America” went extremely viral on X.

Go read it. The short version: real poverty is closer to $140,000 than $31,000.

“The U.S. poverty line is calculated as three times the cost of a minimum food diet in 1963, adjusted for inflation.”

and

The composition of household spending transformed completely. In 2024, food-at-home is no longer 33% of household spending. For most families, it’s 5 to 7 percent.

Housing now consumes 35 to 45 percent. Healthcare takes 15 to 25 percent. Childcare, for families with young children, can eat 20 to 40 percent.

If you keep Orshansky’s logic—if you maintain her principle that poverty could be defined by the inverse of food’s budget share—but update the food share to reflect today’s reality, the multiplier is no longer three.

It becomes sixteen.

Which means if you measured income inadequacy today the way Orshansky measured it in 1963, the threshold for a family of four wouldn’t be $31,200.

It would be somewhere between $130,000 and $150,000.

And remember: Orshansky was only trying to define “too little.” She was identifying crisis, not sufficiency. If the crisis threshold—the floor below which families cannot function—is honestly updated to current spending patterns, it lands at $140,000.

This article resonated with me because I have had three children born since 2021 - well, technically, my third arrives in a week.

I have spent $30,000, $35,000, and now $40,000 for each child delivered.

That is my full out-of-pocket cash-paid cost as a self-employed entrepreneur who runs a small business. I do not have a corporate daddy to share costs with me. This is totally unsustainable and insane, yet every central bank-worshipping think tank economist who attacked Green had nothing to say when I asked them to justify my socialized cost for the public good of bringing a new tax-payer into this world.

America has a cost of living crisis; it’s not being taken seriously by “serious” economists; and the ongoing failure to address it will lead to political, social, and economic calamity.

Read More

I’ve done a ton of consulting as part of my work at Petabridge over the past 10 years and I run into developer onboarding problems constantly with new clients. It takes much longer than it should to clone a customer’s application from source control and successfully run it.

Continuous deployment and continuous integration (CI/CD) get a ton of attention in the DevOps space, but improving the “first run” experience for onboarding new team members is rarely mentioned in these spaces. A strong “first run” experience just as important and an essential ingredient to good CI/CD outcomes.

Bad “First Run” Experiences

If your “first run” experience is agonizing, this means your local development feedback loop is broken too even for experienced members of your team.

For instance, if I want to make a SQL schema change and test it, how easy is it for me to:

1. Actually do that, in a local environment;
2. Revert that change / change it again if I’m unhappy with it; and
3. Verify that my change was safe or otherwise acceptable?

If your applications’ first run experience is any more complicated than git clone && run¹ then you have room to improve.

Read More

We were getting ready to redesign and simplify phobos.petabridge.com - our Akka.NET observability platform documentation site. The plan was to remove a bunch of old pages, restructure the information architecture, and redirect everything properly so we wouldn’t break any inbound links from Google, Stack Overflow, or the blog posts referencing our documentation.

The problem: how do we know we’re not blowing up external links during this restructuring? We needed full, measurable, observable control over the sitemap as we made changes. Every redirect had to work. Every removed page needed a destination. One broken link could cost us traffic and credibility. At its core, this is a continuous integration problem.

So I built LinkValidator - a CLI tool to validate all internal and external links in our statically generated sites during CI/CD on Azure DevOps and GitHub Actions.

The goal: fail the build if we break anything. Crawl the site, validate every link, and catch problems before they reach production.

Then I hit an immediate problem.

Our documentation has links to localhost resources - Grafana dashboards at http://localhost:3000, Prometheus at http://localhost:9090, Jaeger tracing at http://localhost:16686. These are part of our observability stack demos. They’re 100% correct when someone’s running the demo locally, but they fail validation every time in CI because there’s no Grafana instance running on a GitHub Actions runner.

I needed a way to selectively suppress link validation, and I wanted it to be contextual - right there in the HTML where the “broken” link lives, not buried in some global configuration file that’s completely divorced from the context of the page itself.

Here’s how I built that in C# using HtmlAgilityPack and a little sprinkling of Akka.NET.

Read More

Everyone in tech is convinced that AI will eliminate junior developers first. “Why hire a junior when AI can write code?” they ask. The prevailing wisdom is that entry-level developers are most vulnerable to automation.

They’re dead wrong.

I wrote “The Future of AI Belongs to Experienced Operators with Good Taste” a few months back and that’s still absolutely true. But there’s a massive plot twist most people are missing: AI coding assistants aren’t just productivity tools - they’re the great equalizer.

Junior developers with the right attitude and intentional practice are positioning themselves to outpace expensive, slow senior developers who refuse to adapt. The window is open right now, but it won’t stay open forever.

Read More