Over a decade ago I had the good fortune to be in the audience for a talk that was so thought-provoking that I still find myself pondering it.
At New Adventures 2013 (Nottingham) Steph Troeth talked about 'The Beauty in the Impermanent': the leather briefcase that takes the shape of the hand that carries it, the things we own that get better with use. (The recording of the talk seems to have slipped off the web since, which feels about right for the subject.) In contrast of course the Web has a general tendency to hand every visitor an identical pristine page that no one can leave a mark on.
Last Saturday morning I popped into my office with the question: what would it mean for a web page to wear-in, wear-out or 'wear' at all? By that evening it was simple but likable application, which I hope might be the starting point of a voyage of exploration in to this topic. Editors note: the bulk of the day was spent out walking with the dog, occasionally chatting with the Amp Code app about the project as ideas percolated and prodded.
Over the years, I have hand-built quite a few projects including some pretty complex ones like Storyus. For the longest time building digital experiences was synonymous with writing code, which also necessitates time and attention. But in this current era, the building can become more one of directing and collaborating with non-organic intelligences. And it completely reshapes the profile of what I can choose to build, just for fun and interest, without having to trade anywhere near as much of my evening time.
Ideas have always been reasonably inexpensive, but now, so too is the initial act of exploring them
For years I've carried a little notebook to jot ideas down as they pop up, which is about as far as David Allen's advice that a mind is for having ideas rather than holding them ever got with me. Most of the ideas stayed in the notebook. Not because they were bad, but because finding out whether one would be worth pursuing further used to cost a weekend. Now the barrier between a note in a pocketbook and something I can actually look at is greatly reduced: a requirements document, a round of hard questions, a mock in HTML, an early working prototype, and by lunch I know. Most ideas still don't survive that, and I'd not want them to. Experiments are only really experiments if you don't know how they are going to work out, and creativity thrives on experimentation. The difference is that the ones that fail now fail quickly, leave a note behind, and I get my evening back.
The other thing that has shifted is where the learning happens. I joined Laravel in Solutions Engineering this autumn after many years on JavaScript-focused stacks, and I'm going about my learning of the Laravel framework and stack mostly by building things with it and asking the agents to explain what they built as they went. The agents build, I learn, and the learning gets written down somewhere the next session, or the next reader, can find it. That turns out to be a very satisfying way to learn.
So the balance has tipped from hands-on coding toward something closer to directing. Progress that used to take a month takes days to weeks, and because none of it needs my full attention all of the time, several projects move at once. In the last eight weeks or so: this website rebuilt from scratch, a private industry insights tracker I call The Monitor, a personal-growth app called Be9.ing rebuilt in Laravel, a fictional coffee retailer called Artisan Supply Co built as a Cloud demonstration, a field guide to Laravel, a Node app from 2017 moved to Cloud, and the gallery I started that morning.
The method: an idea, a document, then a grilling, then the build, review and rapid iterations
It starts with the idea, usually a line in the notebook or a sentence said out loud on a walk. The first thing I do with it is write it down properly, as a Markdown file, in a hurry while it's still warm, before I know whether it's any good. The kickoff brief for The Monitor, kept word for word in its repository, opens with "Do not write code yet. Read the context below, then interview me until the design is settled, then propose a plan." That interview is a skill called grill-me, from Matt Pocock's collection, which I picked up on his AI Hero course in April. It asks one question at a time, each with a recommended answer, until the plan has no soft spots left. It's where most of my weaker ideas get found out, and I've grown rather fond of it, because it's so much cheaper than finding out in code.
The rules travel with me. A private repository called The Workbench holds who I am professionally right now: role, mission and values, how to work with me, how I write, which stack I prefer. Every project starts by reading it, then carries its own AGENTS.md with the rules that matter there. Some of those rules are scars. The one that says I do the committing and pushing is in every file because an agent once committed without being asked. The one that says do not propose that again unless asked exists because the same layout idea came back three times.
Then the build, in cycles, on a branch. Claude Fable 5.1 does most of the work, with Opus 5.5 for some of it. Each cycle ends with the same paragraph: tests counted, TypeScript clean, build green, Pint run, desktop and mobile screenshots reviewed, overflow checked at 320, 390 and 1440 pixels. Pre-existing failures are named so the new ones stand out, and regression tests are written to fail against the old code first. None of that's new. What's new is that I get all of it, every time, without having to summon the discipline myself at eleven at night.
At the end of a chunk of work, and there are many chunks in a day, I turn to the other terminal. GPT-6 Astra, through Codex, reads the branch cold and undertakes an adversarial review. I parse it, and then we go round again: fixes, a re-review, more fixes. On the gallery project the first review found twelve problems, four of them serious, and all of them were fixed the same afternoon. Two models with different training disagree in useful ways, and I rather enjoy being the one who adjudicates.
And then I read the diff myself, in GitHub Desktop, in proportion to how sensitive the change is. A copy edit gets a glance. Anything touching authentication, money or somebody's data gets reviewed more thoroughly, and goes through a preview environment on Cloud before it comes anywhere near the live site.
What's left behind matters to me as much as what ships, partly because I know I will forget. This site's migration journal is 1,800 lines, separating decisions from implementation from measured outcomes. A learnings log tags each entry public, internal or vault-only. Artisan Supply Co ships with a learning guide to Laravel and Cloud beside the demo guide. The site has a page called How this works, drawn as a diagram, so that I can point at the explanation rather than have to remember it.
The desk: one VS Code window per project, three terminals in each
Each project lives in its own VS Code window and the windows stay open, sometimes for weeks. They are part of the memory; the repository holds the rest. Coming back to a project after a fortnight means the agent re-reads AGENTS.md, the docs folder, the journal and the decisions, and I don't have to hold any of it in my head. That, more than the speed, is what makes several projects at once feel calm rather than frantic.
Inside each window: the editor, the local dev server and its logs beneath it, and a right-hand column with two terminals, Codex above Claude Code. The blue lines marking the splits come from my own colour theme, Workbench, which went on the VS Code Marketplace at the end of September. I made it because I wanted to see where one terminal ends and the next begins without having to look for it, which is a small thing to spend a weekend on, and the kind of small thing I can now afford to.
Image generation sits on the same desk. Pencil sketches for the About page, every product image in Artisan Supply Co, the mocks for the field guide, the daily Bluesky images, and a good deal of design exploration that never ships and was never meant to. Open Graph images are a different job: those are rendered at build time with Satori, from the page's own text.
Amp is the newest arrival, and so far it lives on the gallery project only, so this is an early observation rather than a verdict. The Impermanent Site runs in an Amp orb: a setup script installs PHP and Composer, the dev server runs as an orb service, the Cloud token is held as a project secret, and Laravel Boost and the Cloud CLI work from inside it without fuss. What I'd not expected to like so much is the shape of the window. The conversation sits on the left and the room we are working on sits on the right, in Amp's own desktop pane, so I can press the lamp on my desk and watch the window in the drawing light up a second later, then say what's wrong with the afterglow. Side threads hang off the main one: a second model's independent review of a room, and a weekly thread that reads Nightwatch and reports back. Most of the gallery has been built this way, one short message at a time, with the thing itself in view.
The Laravel part: Boost, the AI SDK, Nightwatch and the field guide
Laravel Boost is the piece I'd not work without now. It gives the agent a version-matched documentation search, the application's logs and schema, and a set of skills for the packages in use: testing, Inertia, deploying to Cloud, the AI SDK, Nightwatch configuration. What that buys me is fewer guesses. When Pennant needed a custom store, the agent found the driver extension point in the docs rather than inventing one. One confession: for the first week Boost was configured for Codex only, because that's what the installer had been told, and Claude was quietly reading the Cloud docs over the web instead. One line in a config file fixed it, and I only noticed because the answers got better.
The AI SDK runs the two streaming assistants on this site through the Vercel AI Gateway, which also carries the Perplexity Sonar calls behind The Monitor and the image generation. The SDK went from 0.11 to 1.0 underneath me and the upgrade guide was enough, which isn't always the case.
Nightwatch has watched this site since the start of October, connected with one click from Cloud and sampling one request in ten. On The Monitor it taught me something on day one: a log channel set in the environment was overriding the one Cloud injects, so log lines were going somewhere I wasn't looking. This week the Nightwatch MCP server joined the terminal, so the agent can read issues and environments directly. First read on this site: no issues, which is good news, and I've left an AmpCode scheduled thread to check again at least weekly.
The rest of the kit, across the projects: Pennant for feature flags, Reverb and Echo for the live lamp and the energy page, Valkey, object storage with a tested restore, the scheduler, Pint, Pail and Tinker, Horizon on the coffee demo, Passport and passkeys on The Monitor, and Laravel MCP on two of them. Just as useful are the pieces I looked at and didn't adopt, with the measurement to show why: Octane, Pulse (I built a small first-party monitor of real visitors instead), Scout, and the Image facade, where sharp at build time won for static art and the journal admits that should have been an explicit decision rather than a default.
The Field Guide is the counterweight to all of this. Agents wrote most of the PHP in Artisan Supply Co; I directed it and I understood it, but I'd not typed it, and I could feel the difference. So the guide, an explainer and encyclopaedia of Laravel drawn to one standard, is written by hand, every sheet from the source, slowly, in some of the evenings I've won back. I don't think fluency can be delegated.
The Cloud part: the CLI, preview environments and approvals
Giving the agent the Cloud CLI paid for itself in the first ten minutes. It read the build command and noticed php artisan optimize was missing, then found the hibernation flag and the Browser Integrity Check setting, none of which are visible from the code. The rule since then has been simple: reads are automated, and every write (a deploy, an environment variable, a resource, a domain, a delete) is stated in full and approved by me, one at a time. It's the arrangement I'd want with a new colleague, and it hasn't once felt like a bottleneck.
Preview environments are how the sensitive changes reach production. Each branch gets its own environment, with its own Reverb server, and the diff review above happens against a running copy. Everything else is push to deploy, and I've stopped thinking about it.
The other habits are smaller. Flex compute that hibernates, and a review of why it never slept (crawlers, and my own LaMetric clock polling a counter every fifteen seconds). Cost reviews from the usage page and the CLI together. Environment flags as removable workarounds while a platform default catches up. Purge on publish through the API with a scoped token.
And it isn't only Laravel. Storyus, the Node and Express app from the top of this post, moved to Cloud on 6 October and is in monitoring now. Cloud's docs cover Express and Hono, Next.js, Nuxt, Go, Python and Rails. My account has eleven applications on it and not all of them are PHP.
What still goes wrong
Three things, and they're really all the same thing: the agent fills a gap with a confident default, and the default is reasonable until it meets a constraint I never wrote down.
The clearest example is Pennant. On 19 September the feature flags went in on the SQL database driver, with a migration for a features table, for what was at that point one boolean: is the lamp on. It was correct, tested and documented, and it would have needed a database resource that sleeps, with the latency to wake it, for a flag read on every page. I came back the next morning for an architectural review, weighed SQL against global configuration against a key-value store, and chose the smallest always-awake Valkey. The journal records, in the agent's own words, that the earlier recommendation hadn't adequately accounted for my cost and idle-latency requirements, which is a polite way of saying I'd not told it. A custom Valkey driver replaced the SQL one that day, and the site counter joined it two days later. The fix wasn't the driver. It was writing the constraints down before the work starts, which is what the stack-preferences file in The Workbench now does.
The second is commits. Twice an agent committed because I'd said yes to a change, not to a commit. It's a rule now, and a memory, and it hasn't happened since, though I notice I still check. The third is local data. The energy experiment pulls a day of battery data every five minutes from an inverter's API, and local and production drift apart in ways that look like bugs and are not. I've not solved that one. I check which copy I'm looking at, and occasionally I forget.
The kit
For anyone who skims to the end for the list: VS Code with the Workbench theme; Claude Code with Fable 5.1 and Opus 5.5; Codex with GPT-6 Astra for reviews and images; Amp on Pro; GitHub Desktop. Laravel 13 with Inertia and React on this site, Blade and Tailwind on the gallery, Livewire on the coffee demo. Boost, the Laravel AI SDK through the Vercel AI Gateway, Nightwatch and its MCP, Pennant, Reverb, Valkey, object storage, the scheduler, Pint, Pail, Tinker, Horizon, Passport, Laravel MCP. Laravel Cloud with its CLI, preview environments and Flex compute. Skills from Matt Pocock's collection through skills.sh, Boost's own, and a handful I wrote for typography, photography and web performance. Playwright, PHPUnit and Pest, WebPageTest, Lighthouse. Satori for share images, sharp for the rest.
Building the start of The Impermanent Site in a day
The gallery is called The Impermanent Site. The idea had waited since that talk in Nottingham, and in all those years I'd never found the time to see whether a web page could be one of the things that get better with use. On 13 October I did, between pre-breakfast, over-lunch and the evening. The requirements document came first, then the questions, then a reading room where every pass of a pointer softens the sentence beneath it, with safeguards so no one visitor can spoil the shared page, and a scheduler that resets the daily room at dawn in Kyoto. It was built in Amp in multiple threads with occasional lightweight touches and nudges, deployed from the agent's terminal with the Cloud CLI, documented as it went, and reviewed cold by a second model before the domain went live.
I did not hand-type the code, and I miss hand-coding far less than I expected to. But I love the building, and I think that was probably the point all along. Thirteen years is a long time for an idea to wait for an evening. I am not sure I have ever enjoyed building things more.