From an idea to a shipped change
I want to make the important calls and let the agent carry the work through.
That starts with giving it a problem, rather than a long list of edits. For this site, the problem was simple: friends ask how I use AI, and I wanted something I could send them that showed the actual systems. The morning report and the small command-line tools were the first examples.
We chose to put the stories on my existing site, with demos people could explore. The agent inspected the site and the workflows before proposing the first pages. That inspection mattered: the site’s principles deliberately restricted new pages and scripts, so the addition needed a narrow, explicit exception.
- DefineI explain the problem and choose the scope
- DesignThe agent researches, proposes and tests uncertain parts
- BuildThe agent implements and checks the result
- PublishI authorize release; the agent verifies the public pages
Follow this site’s first release
This is a summary of the actual work, with some implementation details left out. Expand each stage to see the decision and its consequence.
1. Choose the home for the stories
I chose gabe.work and asked for a playground with demos. The agent proposed an AI section linked from Projects, while keeping the existing career introduction.
That gave the work a destination and a reader: friends who want to understand the tools, with optional detail for people who build software.
2. Decide what the demos should do
The proposal used fictional inputs and preset responses. That let people inspect the workflow without connecting to my accounts or waiting for a model.
I approved proceeding through publication and iteration. The first version could show evidence, proposed decisions and validation, but it would not measure a model’s quality.
3. Build and verify the behavior
The agent wrote static pages and small browser scripts, checked the morning walkthrough and the CLI outcomes, and checked reading without JavaScript. It also rendered mobile and desktop layouts in both themes and scanned the publication files for confidential terms.
The initial layout checker reported overlap involving collapsed disclosure content. The agent inspected screenshots and made the hidden-content behavior explicit before repeating the checks.
4. Check the release itself
The agent pushed the reviewed files, waited for the hosting build, and fetched the public pages to confirm that they served the expected content. A successful push was an intermediate step. The public URLs were the result I wanted.
Where I stay involved
I choose the problem, the audience, and the decisions that change the shape of the work. The agent does the research, implementation and routine verification. When a tradeoff needs my judgment, I want a concrete proposal I can assess.
For substantial new systems, my workflow calls for design review and prototypes before the full build. These stories extend an existing static site, so later additions can use the same structure and checks. I don’t need a new architecture discussion for every page.