For about two years I paid a monthly fee for a tool that deployed my servers. It was a good tool. I had no real complaint, except the quiet one that never goes away for people like me: I knew, more or less, how it worked, and I resented paying rent on a thing I could probably build. So one December, between the holidays, I decided to find out if "probably" was doing too much work in that sentence. I gave myself seven days.
The result is SiteKit, a server and deployment tool we now run and have open-sourced. I want to tell the honest version of how it came together, because the headline, built in a week with AI, is true and also slightly misleading in a way that matters.
The bet, and why a week
I did not pick seven days because it was realistic. I picked it because a deadline that is slightly unreasonable is the only kind that prevents a side project from quietly becoming a six-month project. The goal was not a perfect product. It was a thing that worked, that I understood completely, and that I could put on a real server without wincing.
I had an AI model open the entire time, as a pair. Not as a magic wand, as a fast and tireless junior who had read everything and remembered none of the consequences.
The middle three days felt like cheating
The first day was slow, because the first day is always thinking, not typing. Once I knew the shape of the thing, the middle stretch was genuinely startling. The boilerplate, the API wiring, the second and third versions of a function I was still figuring out, all of it came in minutes instead of hours. If you measured those days by output, it looked like I had hired a team.
But output is a liar's metric, and I knew it even as it felt great. Every line the model wrote was a line I would later have to understand under pressure, because a server tool that you do not fully understand is not a tool. It is a future outage with your name on it.
The model gave me a week's worth of code in three days, and then quietly handed me the bill: now understand all of it.
The hard part was exactly where you would expect
The trouble started when the tool met a real server. Permissions, edge cases, the difference between a thing that works on my machine and a thing that works at two in the morning when something has gone wrong and a real site is down. The model was confidently useless here, because these problems are not in the textbook. They are in the scar tissue, and scar tissue does not train well.
So days five and six were old-fashioned. Reading my own code as if a stranger had written it, which in a sense one had. Deleting the clever parts. Adding the boring safety I would want at 2am. This is the work that does not demo well and decides everything.
What shipped, and what it cost
On the seventh day it worked. Not gloriously, but really. It deployed, it monitored, it did not fall over when I was unkind to it. We have been running it ever since, and putting it out in the open was its own small lesson in humility, because open source means strangers can read the parts you rushed.
I have written separately about what those seven days permanently changed in how I build everything now. The short version is that AI moved the work rather than removing it. It made the typing cheap and made judgment the entire job. I would do it again in a heartbeat, which is why I am now strict about asking why before I start, because the new danger is not that building is hard. It is that building just got easy enough to do thoughtlessly.
The thing I am proudest of is not the speed. It is that I can still explain every meaningful line, a year later, because in the only way that counts, I did write it. The model just typed faster than I can.