You Can't Parallelize a Certificate
Generation is free now, so the thing that ruins your night isn't the build. It's the wait you didn't start early enough: an ACME validation, a DNS TTL, a certificate authority's queue. Six agents don't help. Requesting it at 6pm does.
By Jason Waldrip, with Claude Opus 5 00:01
At 11:18 and 54 seconds on a Wednesday night, I merged the pull request that moved one of my products onto its real domain. At 11:19 and 38 seconds, I reverted it. Forty-four seconds of being live, most of which I spent reading an error.
Nothing was wrong with the code. The apex was cut over, the records were right, the app was healthy and serving. The certificate did not exist yet.
So I spent the next hour doing the least interesting work in software. At 11:57 I added the ACME challenge record so the certificate could issue. At 12:12 I wrote the ownership claim the host had started expecting. At 12:33 I set up the www redirect, because at that point I was just doing whatever was adjacent while I waited. Somewhere in the middle of that, I said something out loud that I happen to have a recording of, because I wear a device that catches this sort of thing:
“The SSL cert should not take this long. Says it’ll take up to 24 hours, but that’s bullshit.”
And a few minutes later, to nobody:
“Minting, minting, minting.”
I was not wrong. It should not take that long. Being right about it changed nothing at all, which is a distinction I apparently needed to learn twice, because the next afternoon I did it again. 11:47am, merged the captive portal onto its production host. 1:21pm, reverted it. Ninety-four minutes that time, so call it progress. The commit I wrote to clean it up says, in full: stage the prod cert before flipping the host. I wrote the lesson into the log thirteen hours after the first time I had learned it, and I still did not hear myself say it.
the part that actually got fast
Here is the context that makes those two nights worth writing about instead of just wincing at.
Over those five weeks I put 3,206 commits across 25 repositories, with at least one commit on all 38 days. I am not citing that to impress anybody. I am citing it because it is the setup: throughput was not my problem. It has not been my problem for a while now. When I want a feature, a migration, a whole service, I describe it and a fleet of agents builds it while I look at something else.
The day after the second revert I was on a call and said the thing I actually believe, which I also have on tape:
“I literally can’t imagine a software project that I couldn’t use AI to fully write in two weeks.”
I still believe that. In the same breath I said the leftover slice, the serial stuff, was the tedious part that does not compress. Right shape, wrong content. I thought the leftover was the gnarly code, the integration nobody wants to touch, the last mile of polish. It is not any of that. The fleet eats all of it.
the last five percent has a clock, not a keyboard
Look at what actually stopped me on both of those nights.
An ACME validation. A DNS record propagating. A certificate authority working through its queue. In the same month I also lost time to a domain verification that had to round-trip through a provider’s email, a payment processor’s review, and a mail sending domain that would not accept traffic until somebody else’s system agreed it was verified.
Not one of those is hard. Not one of them required a single idea from me. Every one is a wait, owned by somebody else’s infrastructure, and completely indifferent to how much capacity I brought.
That is the shape of the constraint now. Everything a fleet is extraordinary at is parallel and internal: six agents, six branches, six problems, no coordination cost between them. Everything that ruins a launch is serial and external. You can run six agents against a certificate request and you will get one certificate, at exactly the same time you would have gotten it with zero agents.
You cannot parallelize a certificate. You can only ask for it earlier.
the boring commit that would have saved the night
Which reframes what skill is worth having. For most of my career the question that separated people was some version of can you build this. That question is dissolving. The one that replaced it is quieter: do you know which clocks to start before you need them?
The commit that would have saved me that Wednesday is embarrassingly dull. Request the certificate in the afternoon. Park it. Go build something else for six hours. Flip the host when the certificate is already sitting there, ready. It generates nothing. It ships no feature. It would not survive a code review as anything other than housekeeping, and it was worth more than everything else I merged that night.
And a fleet makes this trap worse, not better, which took me a while to see. When generation was slow, the calendar spaced things out for you. You built for three days and hit the external dependency on a Tuesday afternoon with plenty of runway. Now I can build the entire cutover in one evening, which means I arrive at somebody else’s queue faster, with more momentum, later at night, and with exactly the same 24 hour wait sitting in front of me. Speed does not shorten the wait. It just gets you to it while the sun is down.
So the forty-four seconds were never the failure. The failure happened around 6pm, when I had everything I needed to start that clock and chose to build features instead, because building is the part that feels like progress.
I have started keeping a different list now. Not what I need to build this week. What I will be standing around waiting for, and whether I could have asked for it this morning.
What is on yours?