I build faster than I used to. A lot of the code on this site was written with an AI assistant, and the parts I already understand now take a fraction of the time they used to.
Knowing whether the result is correct takes exactly as long as it always did.
What got faster, and what didn't
Writing code was never the hardest part for me, but it was the slowest. That's changed. What hasn't changed is everything around it: deciding whether a piece of code should be there at all, working out whether it does what I think it does, and being able to show that the system behaves the way I meant it to.
Only the typing got cheaper.
A successful build tells me the code compiled. It doesn't tell me the system is doing its job. I knew that already. Then it cost me something.
The build output said it was fine
This site publishes from Sanity without a redeploy. I publish in the Studio, a webhook fires, the cache tag for that content type is revalidated. That worked, and I'd watched it work.
Then I checked the sitemap.
It hadn't regenerated in 62 hours. It was still serving what it produced at the last deployment.
I could tell because of how it's built. The static routes use lastModified: new Date(), so the timestamp in the file records the moment it rendered. The deployed sitemap was stamped with the last deploy. Not near it. It.
So a project I'd published during those 62 hours wasn't in the sitemap at all, while /work listed it correctly. Same query, same cache tag. One current, one frozen.
And the build output listed /sitemap.xml with a one-hour revalidation period, in the same table as the routes that were working.
Nothing was going to tell me this. Nobody reads a sitemap. Nothing threw an error. No test failed, because I'd never written a test that asserted the file renders per request rather than at build time. The only thing that reads a sitemap is a crawler, and crawlers don't complain.
Two things I believed that were wrong
My first explanation was that the sitemap is just a build-time asset and always had been, which would make this normal rather than broken. The build output disproved that on its own line: it declared a revalidation period, exactly like the routes that were updating.
My second explanation was caching at the edge. I checked, and the Age header climbed across requests, which looked like confirmation.
It wasn't. Age tells me how old the cached copy is. It says nothing about why the origin never made a new one. I'd found a fact that fit my theory and treated fitting as proving, and those are not the same thing.
What ended it wasn't a better guess. It was reading what actually renders that file. A metadata route here is cached by default unless it uses a request-time API or a dynamic config option, and mine used neither.
The fix was one line.
export const dynamic = "force-dynamic";I want to be accurate about how that line got there, because a one-line fix at the end of a long investigation makes the investigation look unnecessary. The code on this project was written fast, with AI assistance. The questions weren't. Nothing about working faster was going to ask why a file nobody looks at was three days old. The code ran correctly and still did the wrong thing.
Proving the fix instead of assuming it
The obvious test is to deploy and look at the sitemap. That test proves nothing. Deploying regenerates the sitemap whether or not my fix does anything, so a correct-looking sitemap afterwards is exactly what hid the problem the first time.
So I published a real content change through Sanity and left the deployment alone. The sitemap picked it up about 36 seconds later.
Then I compared the build fingerprint on either side of the change, the hashes of the JavaScript chunks being served, and they were identical. The site was still running the same build as before I published, which rules out the explanation I was worried about. A rebuild wasn't what updated the sitemap, so the publishing path was.
Designing that check was the engineering. The fix was one line.
There was a smaller version of the same thing sitting nearby. The structured data on journal posts worked out word count from the rounded reading time, so a 229-word post went out as 400. No reader would ever notice. It was still a number that wasn't true.
What I think the job is now
I'm early in this and I don't want to get a bigger lesson out of one bug than it can carry.
But the balance has changed for me. When implementation takes most of the time, verification is the last step, the one that gets whatever time is left over. When implementation gets much faster, that saved time has to go somewhere, and I think it goes into understanding the result.
I'm still learning how to work this way. AI has made me faster at producing software. It hasn't made me responsible for less of it. I still have to understand what I built, question the parts that look wrong before I can say why, and find a way to prove that it works.