"I told an AI 'I really want to give up on everything' and it made me realize something obvious about development"

When I started working on the GA4 monthly report automation project, there was a day I said this to the AI:
"I'm really fed up with so many similar fixes piling up, and the things I've fixed keep causing new problems. I want to put an end to this once and for all. If my approach is wrong, please tell me."

The AI's response was:
"The fundamental problem is that you've been making individual fixes repeatedly without grasping the whole picture each time. We've been repeating this over and over, but at this rate, it will never end. How about we create a complete specification document for all slides first?"

I'm a marketer and can't write code. This is a story about how I failed by relying on the convenience of things coming together through conversation alone, only engaging with the questions presented to me one at a time. When I hit a wall, the conclusion I arrived at was the practice of "putting things into a specification" — something taken for granted in the world of development. This article is about the trial and error that led me there.

The project's starting point and my first stumble

The project began with the thought, "Can I use AI to improve my work?" I wanted to automate monthly reports and make multi-client management easier. If I could leave it to AI, I could operate with a small team even as the number of clients grew.

The first thing I tried was claude.ai's Projects feature. I connected it to GA4 and Google Slides, registered sample slides, tracking design documents, client information, and report creation conditions as knowledge, and when I asked it to "create this month's report," the slides were completed. The quality wasn't bad either.

However, this approach wouldn't work without me being hands-on. Thinking about multi-client rollout and automated execution, I needed to rebuild it into a system that anyone could operate from a Web UI.

This is where I stumbled right away. The layout shifted with every generation. Font sizes, element placement — everything was different each time. I just wanted to produce the same thing that the Projects feature had been outputting, but I could no longer get stable, consistent results. A long battle with layouts began.

Adding rules, only to have unexpected places break

I set things up so that AI would write the slide generation code at each monthly generation timing, compiled the design specifications into a ruleset called "DESIGN_TEMPLATE_SPEC," and included it in the prompt every time.

As I kept adding rules whenever a problem was found, I noticed a certain phenomenon.
When I added a rule that applied universally across all slides — such as "prevent elements from overlapping" — layouts on other slides that had been fine up until then would sometimes break. The broader the instruction, the wider the AI's range of interpretation, and it would act on unexpected places. When I rewrote things concretely by naming specific slides — like "this slide is 60% left, 40% right" — only that spot would stabilize and get fixed.

I realized that rather than writing abstract instructions to reduce the number of steps, taking a bit more effort to write specific instructions ultimately resulted in less rework.

Fixing things individually, only for them to resurface in a different form elsewhere

As I rewrote the rules more concretely, fixes started going through. But as I continued, a different problem emerged.

Fixed spots would get fixed, but after a while, similar problems would reappear in different slides in different forms. When I fixed the header color of a table, the same problem would show up in a table on another slide. No matter how much I fixed, new problems kept appearing in new places.

What I was doing was nothing more than symptomatic treatment — just tackling the problems in front of me one by one. The finished image I'd been building with the Projects feature existed in my head, but all I was communicating to the AI was scattered instructions like "fix this here" and "this looks wrong." From the AI's perspective, it was receiving nothing but fix requests without knowing what the overall end result should look like. All I had in my hands was an ever-growing list of fix history.

Symptomatic treatment was easier in the short term, but there was no end in sight with this approach.

Choosing to write a specification first

Around the time I began to feel that continuing this way would never get me anywhere, I opened up to the AI about my frustrations. The response that came back was what I wrote at the beginning: "How about we create a complete specification document for all slides first?"

In hindsight, it was obvious. In development, you decide on the specifications first, and then build according to them. The process of progressing through conversation with AI had felt so natural that I had skipped right over that step.

I accepted the suggestion and wrote a specification document for the slides.
For each slide, I documented what data goes in it, where comments are positioned, how many rows and columns the tables have, what the font sizes are, and so on. At the same time, elements common across all slides — brand colors, comment placement standards, table header styles, and so on — were defined up front as shared constants. I started by separating and organizing what to write per slide and what to keep in one shared place, and then began writing it out. The specification document was also gradually refined through review during subsequent operations.

Once the specification was complete, I had Claude Code implement everything at once. The loop of "find a problem → give fix instructions" changed to "finalize specifications first → implement all at once → check everything together."
The fix loop decreased. Because whether or not something was written in the specification became the standard, I was able to quickly judge whether something was "as expected" or "deviating from the spec."

Closing thoughts

I started out with the feeling that even someone like me who can't write code might be able to do something close to development with AI, and there was a sense of doing something new. But when I hit a wall, what saved me was something that has long been taken for granted in the world of development.

The project began with "let's just give it a try," but now it has reached the point where it supports multiple clients — automatically pulling data from GA4, LINE, iOS, and Android stores every month to generate reports. Providing those reports to clients and gathering feedback is also moving forward little by little. It's still in the testing phase, so it's easy to consult on various things. If there are any interested clients, please reach out to Classmethod.

I'm nowhere near mastering this yet, but I'll keep going.