AI saved me time, so I spent more of it coding

There is a popular idea that AI gives developers their time back.

It did save me time on individual tasks. I then spent that time doing more tasks.

I worked on this site during parts of several weekends. They were not full weekends behind a screen, but enough evenings and weekend hours that OpenAI’s usage resets became part of the development rhythm.

At one point, I had one percent of my weekly usage left and three full resets waiting for me. Seeing those unused resets expire would almost have felt wasteful, so naturally I kept coding.

The site was already usable long before I stopped working on it. AI made another idea, architecture change or polish pass cheap enough to try. The project kept growing because continuing was fun.

My previous site made publishing possible, but every structural improvement came with enough friction that I could postpone it. A new content type, layout variation or project structure could consume an evening before I had written any actual content.

I wanted an architecture I would still understand and be willing to maintain months later. Strapi handles the content structure. Astro renders the frontend. Reusable components keep pages consistent, and a static build pipeline publishes the result.

Visitors open static HTML, CSS and JavaScript rather than waiting for a CMS to render a page. The site is fast enough for a 100/100 Lighthouse score, but the more useful outcome is that I can still explain how the system works without opening an architecture diagram.

That matters because the software under a personal site keeps moving even when I only publish occasionally. AI speeds up new software and the security research, automated scanning and package problems that come with it. I need a setup I do not mind returning to.

I used the OpenAI 5.6 models throughout the rebuild, but I did not give every task to the same model.

Sol handles larger work involving architecture, several parts of the repository or decisions with unclear consequences. It first inspects the work, divides it and proposes a direction. Terra handles contained changes such as Open Graph data, share buttons or an existing component. A small feature does not need an expensive architectural investigation.

For implementation, I created a luna-coder agent based on GPT-5.6 Luna. I usually run it with xhigh or max reasoning and give it a focused coding assignment after the direction is decided.

The focused assignment matters. Luna-coder does not need to redesign the application while editing it. I still review the result and make the decisions that shape the site. Coding agents are very willing to add another abstraction, configuration layer or helper class. A surprising amount of working with them involves saying that the simpler implementation is enough.

The unusual part of the setup is how content reaches Strapi. I almost never open the CMS and enter a new article or project by hand.

Articles and projects are created through seeding. The seed data defines the fields, relationships, metadata and reusable content structures Strapi should contain.

For an article, I start with rough notes, earlier conversations, a draft or a collection of points. AI turns that material into the structured format expected by the content model. I review the writing and generated data before seeding it into the CMS.

AI is not inventing generic articles to fill the website. It works with material I already wrote or explained and helps me fit it into the system I built. The CMS keeps a proper content model and API, while seeding makes publishing repeatable without turning it into a long administrative form.

The first usable version did not need all the time I spent across those weekends. The site I initially planned is not the one I deployed. I changed the architecture, rebuilt components, made the seeding workflow more important and spent more time than necessary on metadata, social sharing and image handling.

Some layouts were acceptable before I adjusted them again. Some components worked before I changed their internals. Using the first version showed me what I wanted from the second one.

AI reduced the cost of those iterations. Without it, I probably would have chosen an acceptable architecture earlier and left it alone. That would have been reasonable, but I would have learned less and enjoyed the project less.

The usage limits became a strange form of motivation. An available reset meant I could keep a good development session going without worrying about preserving the remaining budget. I am now two days into the new week, sitting at around 50% usage with two more full resets still available.

The setup works well for generating and publishing content, but I still have to bring the context myself.

When I ask AI to turn notes into an article or generate Strapi seed data, I provide the relevant instructions manually: tone of voice, audience, branding, content structure, preferred vocabulary, earlier writing, metadata requirements, image guidance and skills. Some of that context lives in files and prompts, but I still need to remember where it lives and what applies.

I want to manage that context through an interface alongside the content itself. The site could store editorial rules, audiences, brand language, design principles, taxonomy, the content model, approved terminology, source material and examples of good content. When an agent creates or updates something, the system could supply the relevant context automatically.

Six months from now, I should not need to reconstruct why the articles use a certain structure or which instructions produced the right tone. Those decisions should be stored, versioned and reviewed like any other part of the site. That is one of the most important parts of the CMS I want to use next.