AI can certainly accelerate development, but if you're not careful, you can just end up accelerating your technical debt and maintenance burden.
Recent drama with Mythos/Fable has kept a lot of us on our toes, but it is obvious that patching vulnerabilities faster than ever before is necessary in the current security environment. Meanwhile, if you're really building "hundreds of real production apps and websites with AI weekly," as you no doubt can see plenty of people online claim, the sheer amount of patching alone you have to do eventually becomes unmanageable.
I've been a long-time user of Github Copilot, but I've only fairly recently (compared to some people out there) embraced heavily agentic coding workflows after seeing how powerful OpenAI's Codex was in helping me migrate my R package between 2 JS charting libraries. R packages can be high-leverage to develop if they speed up future data analysis, but it's not a free lunch. You can't just keep creating infinite R packages because it becomes a pain to maintain them at some point. And that's not to pick on R; when you build systems, they tend to require maintenance. That's life! Most web-exposed systems are even worse in this regard.
Even if AI speeds up new development, reaping real value from it is non-trivial because of how maintenance burden eventually threatens to crowd out work on new features/products. And context-switching costs can become brutal if you let them.
I like poking at the boundaries between static site generation and dynamic apps. In line with that, my favorite CMS is Statamic, and I think it's great for lots of workflows with Codex, largely due to the flat file architecture but also because you can lean on Laravel Boost. But perhaps maturity is realizing that not everything in the world needs to be a PHP, React, or Shiny app. The real alluring part of static sites is that there's no backend or database to hack once it's deployed! This is incredibly powerful. So if you can build static sites that are valuable to you, that seems like a fairly clean opportunity for a sort of "coding agent arbitrage."
I chose to dive into Astro for this to see how I liked it. Astro's server-first mentality and zero-JS defaults make it easy to context switch into as someone who spends a lot of time with PHP and Blade and Antlers templates.
Astro has a docs MCP server for developing sites with AI, but you might not need it starting out. I didn't even know about it until after I finished my first Astro site with Claude Code.
AI makes it easy to build some over-abstracted mess that nobody can reason about, but in the projects I've completed with Astro, the project structures are really understandable. I use a mix of .astro and .md files, and it's all really standard stuff if you've built a (non-React) website before.
Let's dive into 2 projects I built recently with Astro and liberal (but hopefully not mindless) use of Claude Code.
Astro project 1: Multilingual "Psalm of the day" website
It started with a joke mocking the desire to automate and scale everything, but I think this turned out to be a very valuable project for me.
If you aren't scaling your prayers with Claude code, are you even trying to get to heaven?
— Alex Kraieski (@alexkraieski.bsky.social) March 21, 2026 at 11:02 AM
Later, I had an idea to build a site to help me read a little bit of the book "Psalms" from the Bible each day, and it struck me as a near-ideal situation for SSG. The content itself isn't going to change any time soon. For a personal website with the goal of supporting prayer, I don't want to be updating stack dependencies weekly. The ritual of this site is supposed to be reading the scripture, not patching upstream vulnerabilities and not worrying about my CI pipeline.
Excessively cluttered, redundant, and overexplained UIs are a hallmark of sites designed/built with AI. However, the goal of this site was always to steer clear of extraneous clutter and anything that could cause any sort of pressure on me to engage more than I wanted (either as developer or user). Everything has too many distractions these days and demands you do various things. This site asks for no "engagement" beyond whatever level of of effort you want to put into reading the current page/verse.
I started with a couple English translations (KJV and WEB), but I ended up expanding to various other languages that interested me such as Italian, Polish, and Spanish. From both a language learning and a Bible study perspective, this makes it all the more useful, but I did have to figure out some stuff about international SEO once I went down this rabbit hole.
It was definitely tempting to add features like daily streaks or notifications, but restraint won out. It's not that it's hard to build stuff like that (and certainly not if you are having Claude do it for you), but browser features and compatibility inevitably drift over time for something like this. That goes against the whole low-maintenance ethos I've been talking about here. It's also ok for something to just exist without some kind of gamification layer!
Sure, you could make a "Psalm of the Day" native mobile app, but that's just more headache for what I am already showing is fundamentally a document-based problem. And the web is good at this because HTML is ultimately for documents. I access the site frictionlessly from a bookmark on the homepage of my phone for quick nuggets of reading.
See Keratoconus (eye disease awareness and advocacy site)
Keratoconus is an eye condition that causes vision loss as the cornea loses its shape. There are treatment options now that can stabilize this, but time is of the essence to catch it with a diagnosis before too much progression. My experience was that it was not easy to tell that my vision was gradually becoming blurrier and more distorted.
There's plenty of information about this disease available from clinical and research experts, so my focus in building SeeKeratoconus.com was contextualizing it with an animated page inspired by how my own vision changed. People love scrolling, right? So, I wanted to tie scrolling to the progression of visual symptoms, and I chose GSAP. GSAP can be overkill for some projects; CSS transitions are great if you just need to add some simple text animations to a page. But this is a clear application for GSAP timelines instead of some AI-rolled, layered, sphagetti CSS system.
Compared to the "Psalm of the Day" site above, this seems like a less obvious candidate for Astro (vs. Next.js or another SPA type thing) if the only requirement was for an animated visual demonstration. But I ended up wanting to add some content: an about page and a page with some thoughts about disability advocacy. Again, Astro was a natural choice because of content collections. And the content collections allowed this site to evolve into something more valuable than just an animated demo: a public, standalone online home for my disability/accessibility advocacy.
Representing a visual condition is always going to have accessibility limitations (even beyond the normal accessibility considerations GSAP docs note when building animations), but I have attempted to make the content and experience of this site as accessible as possible. This isn't just a coding problem, but a design and user empathy problem too. Anyone can build a relatively shiny web frontend with coding agents these days, but thoughtful accessibility for novel experiences is where the bar has to be for professional developers. (Because that is the expected output in the business/institutional world!)
Overall, I'm glad I built this, and I'm glad I used Astro specifically. I'll probably play with the animations more some time now that I'm no longer under internal pressure to "finish and launch" the site!
Not all static sites are low-maintenance (or even static)
An example of a non-Astro project I built recently is a permit and crime tracker for Buffalo, NY (where I'm moving) that builds each morning in Github actions with R. Although there isn't a backend that runs at request time, this is basically a batch application, and we can't take a "set-it-and-forget-it" approach to deployed html files with projects like this.
This isn't good or bad necessarily, but we need to be aware of maintenance burden, especially since I am focusing on projects with a theoretically lower burden than this.
Concluding thoughts
I'm not even sure that Claude makes it faster to finish sites like these. There's an 80% problem of sorts where AI can get something that looks fairly impressive quickly, but you can't avoid some sort of deep dive into some technical area eventually. Overall, both of these sites took a little longer (and were more work) than I expected but came out in a state where I could be very happy with them.
The main model I used working on these sites was 4.6 Sonnet, although I did bump things up to Opus for more difficult tasks. I don't think Opus is smart enough to build things totally end-to-end without heavy-handed human opinions and interruption, so the increased cost seems kind of questionable. In general though, compared to all sorts of other crazy things people might want to build with LLMs, building Astro sites in Claude has very manageable token usage vs. current Anthropic plan limits.
Although I'm happy that I don't have to maintain a server for either of these sites (b/c I hosting on Github pages), it's critical to acknowledge that this isn't risk-free from security standpoint. The sites still depend on the security of my Github account. But that applies in principle to any git repo.
I don't think you can realistically call either of these sites "AI slop" unless you want to call the Bible or my life experience slop. The whole point of both sites is to build on existing human storytelling and extend the experience based on my preferences.
Some readers might be disappointed or suspicious that I'm not telling you about all sorts of Claude skills I have for Astro, but that just seems like another thing to maintain that only reinforces dependence on Claude Code. Maybe down the line, a "GSAP refactoring" skill could help me with SeeKeratoconus.com, but I'm not sure that's the end goal (vs having fun with GSAP myself).
I don't buy the idea that using an agent like Claude or Codex to help build a project prevents you from learning. If AI is really so dumb (which it frequently is), then aren't people going to speedrun all the rookie mistakes found in the training data? And in both of the projects I've highlighted in this article, I was able to push my comfort zone a little bit with internationalization and animations, respectively, in a way that required me to learn more to make good choices. At the same time, I can't pretend I have been "learning Astro" as in-depth as I would if I were building this fully manually. Perhaps that's a feature and not a bug? I am at a point in my life and career where there is a huge opportunity cost to learning a totally new technology up from the basics before trying it out on real projects that solve real business/life problems. But building these products has shown me enough to conclude that it's worth me continuing to go deeper into learning both Astro and GSAP!
If you build websites (with or without AI), I recommend checking out Astro. I think the file-based routing and simple templating make it fairly easy to understand what's going on for a wide variety of skill levels. Even though I was moving quickly with AI for these projects in a framework that was new to me, I never felt forced into any sort of unnecessary abstractions. If you need something in your toolbelt for static sites and content-based frontends, Astro can be a great fit. You can bring UI framework/libraries like React, Vue, and Svelte and integrate with Astro islands, so it's not an either/or situation if you like those UI frameworks already. Astro seems great for a wide variety of devs and vibe coders to learn in terms of optionality! Although I deliberately chosen not to use a CMS for the projects I've discussed here, Astro could also be useful for me in the future by integrating it with headless Statamic (Personally, I still really like Statamic's Antlers for templating, so I don't need to force every frontend to be Astro now either).
Like it or not, marketing matters even more than ever, so Astro and GSAP both generally seem high-leverage right now.
A younger version of me might be unimpressed with these sites and this whole article. But they do what I need them to and pose little threat to become an ongoing maintenance nightmare. That's the whole goal. I also appreciate any constructive feedback as well! Thank you for reading, and have a great day!