I just implemented some new features on a website I maintain, and I think it’s a great illustration of why so many software developers are excited and empowered by AI.
My website, techkc.org, has a calendar that shows a small grid for the month along with a list of all the events. I was asked to add multiple calendar views and make the calendar embeddable on other websites.
I know what some of you are thinking. A calendar widget isn’t exactly a distributed systems problem, and one anecdote doesn’t prove much. Fair enough. But stick with me, because the point isn’t that this particular feature was hard — it’s that a chunk of real, working, deployed functionality that used to eat up an entire side-project weekend now takes less time than writing about it.
In the distant past — like four years ago — I would have spent time thinking through the architecture and design: deciding whether I needed to convert this static site into something with a back-end database, and researching JavaScript frameworks that provide this kind of calendar functionality. My guess is that this would have taken me somewhere between 16 and 40 hours. Since this is a side project, I’d only be working on it an hour or two at a time, so I’d probably tackle the month view first, get it working on desktop and mobile, then build the week view and the toggle between them. I’d also probably need to refactor some code so that the shareable calendar URL and the page hosting the calendar could use the same underlying code.
Now let me jump to how I completed this same request today.
I gave Claude Code the following instruction:
“I would like to allow the user to toggle between different calendar views similar to Google Calendar — weekly, monthly, and the current small monthly calendar with the list. Also, I would like other websites to be able to easily embed the calendar into their own pages.”
Claude responded by reading through the existing codebase and handing me a wonderfully detailed plan. It took about 3 minutes to put that plan together, running on Sonnet 5. I’m on a Claude Pro plan at $200/year, but between usage I typically spend another $30 to $40 a month on Claude on top of that. If you want to see exactly what that plan looked like rather than just take my word for it, I’ve posted the full plan and Claude’s complete output while it built the feature.
I told Claude to “go ahead” and execute its plan. That took about 10 minutes, during which I watched cat videos. Literally. Claude gave me updates along the way and a summary of the changes once it finished. Everything looked plausibly reasonable, so I told it to commit and push, which triggers an automatic deploy. I tested it on my live public website, and it worked and looked great. I tested it on my phone too, and it worked well there as well.
I should also mention: this project has no spec files and no markdown files for Claude to reference (though most of my other projects do). It took me far longer to write this blog post than it did to implement and ship all of these features to production. This didn’t just save me dozens of hours — it also saved me the frustration I would almost certainly have hit debugging code I wrote by hand that didn’t quite work and needed to be researched, fixed, and retested.
And honestly, the hours it saved weren’t even the hours I enjoyed. I didn’t miss out on some deeply satisfying architecture puzzle — I skipped the parts I never liked much anyway: digging through JavaScript calendar library docs, relearning CSS grid breakpoints for the tenth time, and combing Stack Overflow for why some cross-browser quirk was breaking my layout. AI didn’t replace the engineering. It replaced the tedious research I was doing around the engineering.
Being able to build and deploy a solid, robust solution this quickly feels wonderful. I know plenty of software features are more complex and demand more careful thought — security reviews, cost reviews, and real design work. For those, spec files (usually markdown), along with agents that perform additional review passes, are incredibly powerful tools.
If you’re still skeptical, I get it — I was too, not that long ago. You don’t have to hand over your core production system to find out what this is like. Try it on your next low-stakes side project, or on some feature that isn’t going through a production review this week. See what it’s actually like to work alongside it before you decide it’s not for you.













