The last thing I published here, on Friday the 13th of March, ended with a promise: “At this rate, Part IV should be ready by Monday.”

It’s June 11th.

The terminal that was “still open” at the end of I Am Iron Man went dark on March 13th and stayed dark for almost three months. No commits, no posts, no agent waves running at 11 PM. If you subscribed to the RSS feed back in March expecting a steady drip of crime scenes and quality gates, you got silence instead, and you deserve an explanation.

So here it is, all of it.

Why I Went Quiet

In March, I stepped back and reassessed the whole situation. The premium accounting department was in the middle of a big transition, I knew exactly how to help them, and I knew Claude could multiply what I could do alone. So I made a decision: pour my full effort into the day job. I joined my employer’s pilot program for AI-assisted development to do exactly that.

I’d spent the first two weeks of March documenting on this blog what Claude Code could do when you build the right protocols around it — the spec-driven workflow, the agent orchestration, the quality gates that catch the crimes before they hit production. The pilot was my chance to bring that same approach inside a real enterprise, on real production systems, for the organization where I’d spent years building things.

But there was a problem, and it was mine to solve: I was building an insurance platform on nights and weekends while working for an insurance company by day. The moment I started using AI tooling on their systems, with their data, solving their problems, the line between “my project” and “their project” needed to be a wall. I didn’t want a conflict of interest, or even the appearance of one. So I made the clean choice and paused all plcy.io work. The repo sat untouched and the blog went dark.

The plan was straightforward: keep the role, keep the pay, bring my ideas into reality inside the organization, and come back to plcy.io with a clear conscience whenever the timing made sense.

That’s not how it went.

The Project That Explains Everything

One project explains everything that came after, so I’ll start there.

Cash application is one of the great unsolved grinds of insurance accounting. Money comes in — checks, ACH, wires, lockbox deposits — and somebody has to figure out what it’s for. Which insured, which policy, which invoice, which installment. The remittance advice that explains a payment might arrive in the payment file, or in a PDF attached to an email, or not at all. At most operations, “somebody” is a team of accounting staff manually matching bank statements to receivables, one line at a time, every single day.

This wasn’t a passion project I pitched up the chain. It was the thing they needed built. The premium accounting department had recently taken over additional business units, and the platform those units ran on had none of the automation we’d spent the past 13 years building around the old one. I was tasked with closing that gap, and lockbox was the first project: a bank statement parser and cash application engine. Parse the statement feeds automatically. Run each payment through eight matching strategies — exact invoice match, amount-and-date heuristics, remitter history, on up to an AI matching engine as the final pass — each one feeding a confidence score that accumulates until the system knows exactly how sure it is before applying a dime. Let every payment the system applies teach it how that remitter behaves, so the match rate climbs over time. Pull remittance advice out of the email already flowing into the accounting inbox, so the explanation finds the payment instead of a human hunting for both. And one wrinkle made it new territory even for me: the new platform had to be integrated through web services rather than the direct SQL approach I’d used for years. This wasn’t a port. It was a redesign.

I put my heart into that spec. Architecture document, feasibility study, API signatures, user stories broken out by work stream and ordered by implementation. And since I was working under the pilot program — I had to test Claude on something, right? — I designed a full-featured user interface to go with it, built on atomic design principles: you start with the smallest pieces (buttons, inputs, labels — the atoms), compose those into molecules and organisms, and by the time you reach full pages, every screen is assembled from the same small set of tested parts. I sized and spaced the whole thing on golden ratio and Fibonacci proportions, because if accounting staff are going to stare at a tool for eight hours a day, it should be beautiful. And I built it in Storybook as a live, working prototype rather than a stack of static mockups — MSW hooks intercepting the API calls, play functions walking the interactions, and AI-generated fixture data realistic enough to pass for a real book of business. You could click through the entire workflow before a single line of backend existed.

This is premium accounting automation, the exact discipline I’ve spent my career on. I knew every edge case the system would hit because I’ve hit them all personally.

Then I took it to the Architecture Review Board.

Multiple meetings, months of calendar time between them, presentations, revisions, follow-up questions, more meetings. The board turned out to be a bit capricious. Their verdict was that we were “doing too much.” Strip away the polite language and what that meant was they doubted I could pull it off. They doubted me. They thought they knew better, and that I was wasting their time. A member of the architecture team gave the plan his OK, and the approval failed anyway. I’d brought them the most detailed spec I’ve ever written, and it wasn’t enough.

That’s when I knew I needed to leave.

I hope my confidence here doesn’t read as arrogance. The plan was ambitious, and if an outside vendor or a managed-services pod had pitched this same platform, I might have voted with the board myself. But ambition was the point. I wanted to prove what these tools can do when somebody with years in the domain is driving them. And the build was never the risky option anyway — cash application has a manual workaround, so the risk sat on the other side of the ledger: do nothing, and the premium accounting department slowly drowns in the extra load from the new business units, applying it all by hand.

As for whether I could pull it off, nothing in my history said I couldn’t. In almost 13 years there I never missed on a project I said I could deliver. I’ve moved billions of dollars of transactions across data bridges running in both directions, built payment approval processes, and integrated more vendors than I can remember. This one was mine to land, and I would have landed it.

They did eventually grant approval for a small slice of the full project. So I split the spec, pulled in just the requirement stories and features that slice needed, and agreed to deliver as much of it as I could on my way out. I gave three weeks’ notice.

In those three weeks, using the same AI tooling I write about on this blog, I got the slice to 76% complete. Dozens of user stories done, every one of them pending code review, waiting on a human-in-the-loop resource that never freed up. The code came fast. Reviewers didn’t. And the code wasn’t all of it: I recorded a series of training videos from Teams meetings where I walked through the project and taught Claude Code at the same time, and I documented everything in Confluence — step-by-step instructions for completing the PoC slice and continuing into the full build. Whoever picks it up will have everything I could leave them.

Sit with that math for a second. Three weeks, one person, three-quarters of the approved scope, while the governance process spent months approving a fraction of the project. If the board had approved the original plan, the entire engine more than likely ships inside the same three months we spent in meetings about it. The bottleneck was the approval process, not the engineering.

I still defend the concept of architecture review — I’ve cleaned up enough unreviewed disasters to know why it exists. But somewhere along the way this one started reading ambition as risk and detail as overreach, and a process like that defaults to a slow no.

And the right version isn’t hard to describe. Set the standards and document them well, so every team knows exactly what criteria their project will be judged against before the first line of code. Provide the shared libraries, so teams aren’t reinventing the wheel. Be the central nervous system of development across the organization — the group that shepherds every project, guards the enterprise, and judges work on how well it adheres to the published standards. When a project needs to deviate, the deviation gets discussed, then signed off or reworked, and everybody learns something from the conversation. A board like that expedites development. It builds bridges, not walls.

Will the project ever see the light of day? Possibly, if they contract me to finish it. Without me? I’d give it 50/50, and only if they find talent that also carries that specific business-function knowledge. That’s a tall order. Meanwhile, an accounting team somewhere is still matching bank statements by hand today, and no line item anywhere records what that costs.

Too Many Chiefs

The ARB was the sharpest example, but it wasn’t the whole picture.

While the pilot program was spinning up, a leader I’d long respected announced his retirement. I liked the guy. He was a wealth of insurance knowledge with a willingness to share it at every opportunity, and that deep industry grounding shaped how he ran things. The leadership that followed didn’t have it, and their attention went to different priorities. Nobody did anything wrong. It just wasn’t a good fit for me anymore.

Meanwhile, my own plate had grown past the edges. I was overseeing too much. Too many people came to me for answers to too many problems, with very little help to actually get any of it done. And when the workload grew, the answer was always more people to manage the work, never more engineers who could make the work smaller. You end up with layers of coordination wrapped around a thin core of people who can actually build, and the core keeps getting thinner. Developers and engineers got treated just like what everyone called them: “resources” to be assigned, as if IT work were a commodity anyone can do. It’s not. Talent matters, and not all developers are equal. You find the talented ones, and then you hold on to them as long as you can.

It’s a tale as old as time: too many chiefs, not enough warriors.

And then came the message that settled it: changes to how people would be rewarded that read, to anyone doing the math, like a decision made for shareholders rather than for the people doing the work. You can dress that kind of thing up however you want, but employees can read.

Exciting things happen at big companies. Some of my proudest work happened at one. But I was overworked, overwhelmed, watching a deep well of industry knowledge head into retirement, and being told in fluent corporate that doing more would now be worth less. I wanted to get back to building things. I thought I could do that there. The hurdles to getting anything done were just too much.

The Decision

I resigned, effective June 5th.

In I Am Iron Man I wrote that the safe option stopped existing when AI started eating jobs — that it was never really a choice between safe and risky, just a choice between building something while you still can or waiting until someone else does. I wrote that at 11 PM as a thought experiment. Three months later I handed it to my employer as a resignation letter.

I doubt I will ever work directly for a publicly traded company again. The people were never the problem. The managed-services development pods I oversaw were a good group, and I trained them well — well enough that I expect them to be successful without me, and I genuinely hope they are. The coworkers around them were just as good: an exceptional group of people who deserve credit for everything that got built in those years. I’ll miss them more than I’ll admit in a blog post. But a public company answers to shareholders, and every quarter that answer gets a little louder. I’ve now seen what one person with 28 years of domain knowledge and an AI development partner can produce in three weeks, and I can’t go back to renting that capability out for a salary plus a bonus tied to somebody else’s math.

Hanging Out a Shingle

In the coming days, I’m starting my own consulting company.

The pitch writes itself, because it’s just my career: 28 years in insurance technology. Decades of building automation around insurance processes. Dozens of system conversions. Six data bridges between policy admin platforms. Hundreds of enhancements built on top of the vendor systems this industry runs on, with a clear focus on premium accounting automation. Deep working knowledge of AIM and ConceptOne — not “read the documentation” knowledge, but “spent fifteen years inside one of them and traced bugs through the other’s stored procedures” knowledge. If your operation runs on either platform and there’s a process your team does by hand that a machine should be doing, that’s the exact intersection where I’ve spent my entire career.

Add what I’ve spent the last year learning — how to wield AI agents as a real development partner, with the protocols and quality gates to make the output trustworthy — and I think the skillset should be in high demand. Automating policy admin and premium accounting is what I’ve been doing in one form or another for most of my career — cash application is just the latest chapter — and I now know firsthand how fast that work can move when nothing stands between the builder and the build.

And for the record: I didn’t retain a single line of source code from my prior company. I don’t need it. If this past year with Claude Code proved anything, it’s that the real power sits with the knowledge of the person directing the AI. What I carry is the cross-section of deep technical skill, software development experience, and insurance domain expertise — knowing what to build, why it matters, and which edge case will blow up in production eighteen months from now. Give the same tools to someone without that and you get plausible-looking software that solves the wrong problem. It’s the craftsman, not the tool. It’s always been that way.

Will I do work for my former employer? More than likely, yes. There are projects there I still care about and people there I’d gladly build for. But it’ll be on my own terms this time, billed appropriately, with the scope and the timeline written into a contract instead of dissolved across a committee calendar. And I’ll be looking for other clients beyond them — MGAs, wholesalers, program administrators, anyone whose accounting team is still re-keying bank statements into a 2003-era admin system.

I want to be honest about the other side of this, because this blog doesn’t do press releases. Going independent is a risk. You don’t always know what the future holds. There’s no salary now, no bonus structure to complain about, no big-company logo doing my credibility work for me. If the clients don’t come, that’s my problem and nobody else’s. I’ve watched enough better mousetraps die in the graveyard to know that being right about the technology guarantees nothing. That possibility keeps me honest. It also doesn’t change the decision.

The Goal

And then there’s the reason this blog exists.

Plcy.io is no longer the nights-and-weekends project I have to firewall away from a day job. There is no day job. There’s no conflict of interest left to manage, no pilot program competing for the hours, no ARB between me and the build. The goal for this year: complete plcy.io and make it work. Hopefully a few consulting clients fund that effort along the way. That’s the model — consulting pays the bills while I build the platform.

The repo is open again. The agent waves are running again. Part IV of the Crimes series is coming, because believe me, my partner did not spend three months becoming less interesting. We have a Coverage Tower to finish, an observability command center to stand up, and a quoting engine that needs to hit eight seconds. The build log resumes now, and you’ll get the same deal as always: the real numbers and the real mistakes, written down while the bruises are still fresh.

Twenty-eight years working for somebody else’s company. I think I’m ready to work for mine.

Subscribe via RSS, follow along at plcy.io, or reach out if your accounting team is drowning in bank statements — I know a guy now.

The terminal is back on. It’s staying on.

We’re back.