Build with AI,
One Step at a Time.

01We tried to improve too much at once

The lecture pages already existed. I wanted better content, larger text and artwork that helped each lesson feel distinct. At first, we worked across several presentations. The pages became more consistent, but I disliked the result: too many repeated layouts, too little art and text that was still uncomfortable to read.

So I asked the agent to finish one presentation before touching the others. We focused on Product Eye, starting with a small set of slides. We worked on the illustrations, text size, colour and placement until the direction felt right. Then we carried it through that course, reviewed it and used what we had learned in the others.

My first request had been too broad. The agent could generate lots of changes, but I could not judge them properly as a batch. One presentation gave us something concrete to discuss: this heading is too small, this composition repeats, this illustration works. Deciding what good looked like was still my job.

02One task: make the chapter menu useful

Later, I noticed a smaller problem in Product Eye. The chapter menu showed a name, but it was hard to tell which chapter I was in. Its arrow sat outside the box, and the plain selector felt disconnected from the presentation. Here is a condensed version of the request we worked from:

Problem: Product Eye shows the chapter name, but not clearly which chapter I am in. The arrow escapes the box.
Change: Show the chapter number, name, slide range and my position. Keep the arrow inside.
Keep: The illustrations and readable text sizes.
Check: Open the menu, change chapters and use the keyboard. Try it on a phone and a laptop before applying it to the other courses.

The new menu showed the chapter number and name, slide ranges and my position within the chapter. We checked chapter changes, keyboard use and phone layouts. Once that worked, I asked whether the other courses had the same problem. They did, and we brought the navigation into a shared component. That meant we could fix the menu in one place rather than maintain a separate version for each course.

We solved it in one course, used it, then applied the pattern elsewhere.

The agent chose the implementation. I described the problem, the result I wanted and what needed to stay intact. That gave us a clear way to review the change before expanding it.

03The tests missed what my eyes caught

The slides also taught us the limits of layout checks. A page can fit inside the screen and still be difficult to read. On a comparison slide, the first words in one row landed over an illustrated hand. I noticed it while reviewing the page and asked for the text to be moved.

01

The page fits

Nothing extends beyond the screen.

02

Can I read it?

Words still overlap the illustrated hand.

Other slides left too much space between the opening text and the points below. Nothing was technically overflowing. The composition simply did not work for someone trying to follow a lesson. We adjusted the positions page by page.

The blog needed that same attention. Its first illustrations matched the palette, but they showed a generic woman. I wanted illustrations of me. The subscription box needed more readable colours, and the copy needed to sound like something I would say. I also corrected the schedule to one article a month, including the verification email and narration.

Tests help us check a behaviour we have specified. Using the product helps me notice what we never thought to specify. I ask the agent to test and review its work, then I use it myself.

04How this blog came together

The blog grew through several separate decisions. We gave the first article a readable layout and navigation, prepared English and Turkish versions, added narration, and then worked on comments and subscriptions. Reviewing those pieces brought more changes, including removing the old A2SV stories from this hub while keeping their existing URLs.

Comments made the difference between a finished screen and a working feature especially clear. We had to enter a comment, request a code, try a wrong code, verify the right one and see the comment appear. We checked replies and confirmed that commenting did not quietly subscribe someone to the newsletter. Subscribing and unsubscribing had their own checks.

We used a local test inbox for those checks, without sending real emails. We also checked the built Netlify version, rather than assuming that working on the source server proved the release worked. This revision is still under local review as I write it. Passing those checks is not the same as publishing it.

After a small change, I check the affected behaviour. Before release, I widen that check to the main journeys on the devices and in the languages we support. Secondary polish can wait. A broken primary task cannot.

05What I would carry into the next project

I would start by writing down three things:

1. What did I actually notice? For us, it was a chapter name without a clear chapter position.
2. What should someone be able to do? See where they are and move to another chapter.
3. How will I check it? Open the menu, change chapters and try it on a phone as well as a laptop.

Then I would give the agent that task, ask for relevant tests and a self-review, and use the result before asking for more. We did not always work this way on this site. The times we spread ourselves too thin are part of why I now prefer it.

I'll write here once a month about decisions like these. If you try this on your next change, I'd like to hear what happened.