The Website That Ate My AI Credits

I wasn’t planning to become a website developer. I just wanted to rebuild my website, MartinGram.com, quickly.

The old website no longer reflected what I wanted to do. I needed a place to publish my writing, share my observations about AI, business, and technology, and present my professional experience without looking like another generic “10 Best Marketing Tips” marketing consultant.

I had a reasonably clear idea of what I wanted. A clean, simple website with good typography, plenty of whitespace, and a design that didn’t get in the way of the content.

And with Codex, I could suddenly build much of it myself.

I didn’t have to hire a developer every time I wanted to change a layout or adjust something in WordPress. I could describe what I wanted, let Codex work on it, and see the results.

It was exciting. Perhaps a little too exciting.

Because once I realized how much I could do, I kept finding more things to improve.

A small adjustment here. A new idea there. One more change to the layout.

When I first decided to rebuild the website, I thought I’d be publishing my first article that same day.

Instead, I found myself spending an extraordinary amount of time working on the website that was supposed to help me publish my work.

And then there were the AI credits.

The excitement of being able to build almost anything

I’ve been working with websites for almost two decades. Joomla, WordPress, HTML, CSS, plugins, themes. I’ve dealt with all of it in one way or another.

But I’m not a developer. I can usually figure things out, make small adjustments, and occasionally break something along the way. For anything more complicated, I’ve generally had to rely on developers or spend hours searching for solutions.

Codex changed that.

Instead of searching through forums, watching tutorials, or trying to figure out which piece of CSS controlled a particular element, I could simply explain what I wanted.

And in many cases, it worked.

I could experiment with layouts, create custom WordPress elements, adjust the design, and fix problems that would previously have taken me considerably longer to solve.

At some point, I realized I wasn’t just asking AI questions anymore. I was actually directing it to do development work.

And naturally, that made me curious.

What if I changed this? Could we build that differently? Would another layout work better?

Things I wouldn’t even have considered building before suddenly seemed possible.

The problem was that I was getting rather good at finding new things for Codex to do.

When Small Adjustments Become an Endless Project

It started with the usual things. Adjusting the layout, changing the typography, getting the spacing right, and making sure everything looked good on mobile.

Nothing particularly complicated. Or so I thought.

I’d ask Codex to make a small adjustment, check the result, and usually find something else that needed attention.

Sometimes a change looked great on desktop but created a problem on mobile. Other times, fixing one element affected something completely different.

So back to Codex.

And because it was so easy to ask for another change, I did.

One of the things I discovered was how difficult it can be to explain exactly what you want visually. I could see that something wasn’t quite right, but describing the problem in a way that Codex understood wasn’t always straightforward.

A little more space here. Move that element slightly to the left. No, not that one. The other one.

At times, I probably sounded like a terrible client trying to explain a design to a developer.

And then there were the things that weren’t actually broken.

I’d look at a perfectly functional page and start wondering whether another layout might look better. Or whether I should change the way a section worked.

There was always something else to try.

The funny thing is that I would probably have been much more selective if I had been paying a developer by the hour. Or if I’d been doing it myself, spending hours going through tutorials. I’d have thought twice before requesting another minor adjustment.

With Codex, that hesitation was mostly gone.

I was making progress. The website was improving. But the list of things I wanted to change wasn’t getting any shorter.

The Website That Ate My AI Credits

At some point, I started paying more attention to how many AI credits I was using.

Until then, I hadn’t given it much thought. I had a ChatGPT subscription, Codex was doing the work, and I was happily moving from one task to another.

But the credits were disappearing faster than I expected.

And suddenly, all those little adjustments didn’t seem quite so little anymore.

It wasn’t necessarily the big development tasks that concerned me. Building an entire section of the website or adding new functionality felt like a reasonable use of resources.

It was the smaller things. Spending multiple rounds trying to fix a spacing issue. Asking Codex to investigate something, making a change, and then having to investigate why the result wasn’t quite right.

Sometimes I’d return to something we’d already worked on because I’d spotted another detail I wanted to change.

And every time, there was another prompt, another investigation, another round of work.

I also began to realize I wasn’t always particularly efficient in how I gave instructions. A simple request could turn into a much larger task than I’d originally intended.

There was another problem I hadn’t really considered at first.

As my conversations with Codex grew longer, they accumulated more and more instructions, previous changes, investigations, and code. Even a relatively small adjustment could involve going back through work we’d already done.

And that meant more tokens being processed, sometimes for tasks that should have been fairly simple.

I began to realize that the way I organized my work with Codex could make a considerable difference to how much of my available usage I was consuming.

It wasn’t just about asking for too many changes. It was also about how I was asking for them, and how much previous work Codex had to deal with along the way.

As a ChatGPT Plus subscriber, I have usage allowances that reset over five-hour and weekly periods. During some stages of the project, when Codex was dealing with longer conversations and numerous previous instructions, I could exhaust my entire five-hour allowance in as little as ten minutes.

Of course, I couldn’t always tell exactly how much a particular task was costing me. Some problems were more complicated than they appeared, and not every unsuccessful attempt was a waste of credits.

But I could see the overall pattern.

I had started with the idea of rebuilding my website quickly so I could get back to writing and publishing the same day.

Instead, I was spending my AI resources on an expanding development project with no obvious finish line.

And the website still wasn’t finished.

It Wasn’t Just Me. It Wasn’t Just Codex.

It would be easy to blame myself for all the time and credits I was spending. After all, I was the one who kept coming up with new ideas and asking for changes.

But that wasn’t the whole story.

Some of that was probably down to the way I organized my work. But it also made me realize that using an AI coding agent efficiently requires more than simply knowing how to describe what you want.

Looking back, I think I underestimated how much responsibility comes with directing an AI coding agent.

When you hire a developer, there’s usually a project brief, a budget, and some idea of when the work should be finished. You discuss what needs doing, what’s important, and what can wait.

With Codex, I had effectively become the project manager, the client, and the person approving the work. All at once.

And I wasn’t always doing a particularly good job of it.

I could spend half an hour trying to get a small visual detail right without stopping to ask whether anybody visiting the website would even notice the difference.

That doesn’t mean the details aren’t important. I care about design, typography, and how a website feels to use. I still do.

But there’s a difference between paying attention to details and getting lost in them.

I also had to learn that how I structured my conversations and development tasks mattered. Continuing an increasingly complicated session wasn’t necessarily the most efficient way to get something done.

Codex wasn’t going to decide for me that the website was good enough and that I should probably go write an article instead.

That decision was still mine to make.

The Hidden Cost of Unlimited Possibilities

Something else occurred to me while working on MartinGram.com. The easier it became to build things, the harder it became to decide when to stop.

In the past, there were practical limitations. If I wanted to add a new feature or completely change a design, I had to consider how much time it would take, whether I could do it myself, or how much it would cost to hire someone.

Those limitations weren’t always a bad thing. They forced me to think about whether something was worth doing.

With AI, much of that friction has disappeared.

I can come up with an idea, explain it to Codex, and have something working without necessarily understanding every line of code behind it.

That’s remarkable when you think about it.

But it also means I can spend an entire afternoon experimenting with something I hadn’t even considered necessary that morning.

And this isn’t limited to website development.

The same thing can happen with writing. You can rewrite an introduction twenty times, generate another ten headlines, or keep asking AI to improve an article that was probably good enough several versions ago.

At some point, you have to decide whether you’re actually improving the work or simply enjoying the process of making changes.

I don’t think there’s anything wrong with experimenting. Some of the best ideas come from trying things without knowing exactly where they’ll lead.

But experimentation and getting something finished aren’t always the same thing.

For me, that became one of the more interesting lessons from rebuilding MartinGram.com. AI had made the technical side of building a website much easier.

Deciding what was worth building, and when enough was enough, was still up to me.

What I Changed About the Way I Work

I still use Codex, and I have no intention of stopping. It’s become one of the most useful tools I have for working on my websites.

But I’m trying to be a little more deliberate about how I use it.

One of the first things I’ve learned is to be more specific about what I want done. Instead of asking Codex to improve an entire section of the website, I try to identify the particular problem I’m looking to solve.

And if something isn’t working correctly, I’d rather investigate the cause before making another round of changes.

I’m also learning to separate things that genuinely need fixing from things I simply feel like experimenting with.

That’s probably the hardest part.

I still notice small details. A little too much spacing here, something slightly out of alignment there. And there’s always the temptation to open Codex and ask for one more adjustment.

Sometimes I do. Other times, I leave it alone.

I’ve also become more conscious of giving tasks a clear ending. Once something works, looks good, and does what it’s supposed to do, I try to move on rather than continuing to search for improvements.

None of this means I’ve stopped experimenting. That’s part of what makes working with AI interesting, and I wouldn’t want to lose it.

But I have other things I want to do.

MartinGram.com wasn’t supposed to become my full-time occupation. It’s a place for my writing, professional work, and the things I discover along the way.

And I have other websites, videos to produce, photographs to take, and places I want to explore. Oh, and there’s my job as a Network Lead to take care of as well.

I enjoy building things. But I also want to spend time doing the things I built them for.

The Website Was Supposed to Be the Beginning

Looking back, I don’t regret rebuilding MartinGram.com with Codex. Quite the opposite.

I ended up with a website that feels much closer to what I originally wanted, and I learned a lot along the way. Things that would previously have required a developer or hours of figuring things out myself are now within reach.

That’s something I still find remarkable.

But the experience also reminded me that just because I can build something doesn’t necessarily mean I need to.

There will always be another feature to add, another layout to experiment with, or some tiny detail that could look a little better.

And I’ll probably continue noticing those things.

The difference is that I’m trying to become better at deciding which ones deserve my attention.

I’ve also started paying more attention to how I organize my work with Codex. Long conversations, repeated investigations, and poorly defined tasks can all contribute to unnecessary credit consumption.

I’ve learned a few things about making those credits last longer, and I’ll share them in a separate article about how to stop wasting Codex credits.

After all, I didn’t rebuild MartinGram.com because I wanted another development project.

I rebuilt it because I had things I wanted to write about.

Like this article, for example.

Which, come to think of it, I was supposed to have published quite some time ago.