Ithaka Gave You the Journey: AI-Assisted Development

The Island

About fifteen years ago, I stood on a Greek island with my kids, looking out across the water at Ithaka in the distance. We never set foot on it. We just stood there looking at it — the actual island, not the mythological one, weathered and ordinary in the haze — and I found myself thinking about Cavafy's poem again.

Something clicked that I'd been getting backwards. It's not the journey to Ithaka that matters. It's that Ithaka gave you the journey in the first place. There's nothing waiting for you when you arrive, which is maybe why I never felt any pull to actually get in a boat and go. The gift was never the homecoming. It was everything the voyage taught you on the way — the wine, the knowing, the harbors you didn't expect.

Thirty years of chasing the right way to build software — Oracle CASE tools in the nineties, PowerBuilder scaffolding, spec-driven AI development today — was never a voyage toward some final island. It was the voyage itself. I'd become the kind of engineer who cares more about the specification than the code, who trusts the process more than the speed, who believes the model matters more than any single implementation of it. Nobody hands you that. You earn it one leg at a time.

I was already living that principle for thirty years before I had tools that let me execute it well. This is about the three years when those tools finally arrived — and what happened when I got to test whether that thinking actually held up at scale, in production, under pressure. It's a sequel to an earlier essay of mine, "Dependencies I Never Outgrew," where I traced how writers like Heinlein, Ishiguro, and Dylan Thomas wired how I think about systems, consequences, and the difference between speed and wisdom. This essay is what happened when I finally got to find out whether that wiring was any good.

It turns out it was. And it turns out I'd been documenting the whole thing as it happened, which is its own kind of luck.

Borrowed Competence

ChatGPT launched publicly in November 2022. Within months I was writing about it on this site — not because I planned to chronicle anything, but because writing is how I process what I'm learning. The early mode was narrow: a chat window, a request for a method, a fix that either worked or confidently didn't. A very smart pair of hands attached to a conversation, bounded by whatever you could paste into the box.

Even inside that narrow mode, something happened that changed how I thought about competence itself.

A client wanted to understand what ChatGPT could mean for developers. Their language of choice was PHP. I had never written a line of it — my demos were all C#. I remember thinking: if this tool is what I suspect it is, I should be able to build them a working PHP site without ever learning PHP.

So I did. I had it walk me through environment setup, tooling, hosting, structure. Then I asked it to build the things I knew — as a web developer of decades — that any real site needs: read from an API, present a table of data, export to CSV and JSON, parse XML, render markdown into HTML. I knew how to do every one of those things. I had no idea how to do them in PHP.

Here's the part that mattered: I didn't validate the code by reading it. I couldn't, not fluently, in a language I'd never used. I validated it by running it — inputs and outputs. Did the CSV export produce a correct CSV? Did the markdown render? The explanation was nice; the execution was the proof.

That was the seed of everything that followed. I could borrow competence I didn't have, as long as I could rigorously test the output with competence I did have. The judgment stayed mine. The domain knowledge of what a system actually needs stayed mine. Only the syntax was borrowed.

The Floodgates

Through 2024 I kept hearing about the frontier tools — Aider, Cursor, early rumblings of Claude Code — from friends who swore by them. They were all CLI-first, and for someone who'd spent a career in Visual Studio, that was enough friction to keep them in the "someday" pile. Not technically beyond me. Just wrapped in enough resistance that I never opened the door.

Then in February 2025, GitHub Copilot's agent mode landed inside VS Code. Control-Alt-I was the entire barrier to entry. No new CLI, no new mental model before you could start — it appeared inside the editor I already lived in and just started working. I told those same friends: this is the moment of democratization. The capability they'd been living with for a year had just become available to anyone who could press three keys.

Something shifted that I can only describe as a release of imagination. Before, the constraint on what I could build was my technical knowledge — the languages I knew, the frameworks I'd learned. Suddenly the constraint moved. I wonder if we could do this — and it did it. I wonder if we could do that — and it did that too. For the first time in thirty years, I wasn't limited by technical depth. I was limited by imagination, and by my own sense of what an application could even be.

That feeling was real, and I won't pretend it wasn't glorious. It's also exactly how you get in trouble, because the water doesn't stop at the good ideas.

What the Butler Knew

Within weeks of agent mode arriving, I was writing critically about what I was seeing in my own work. Code that ran but drifted from the architecture. Features appearing faster than review discipline could keep pace with. A codebase accumulating decisions no one had actually decided — no record of intent, just a trail of accepted suggestions. Speed without receipts.

I was retracing a pattern I already knew from my own reading, without realizing it at first. Ishiguro's butler in The Remains of the Day is the patron saint of flawless execution in service of unexamined direction — magnificent craftsmanship, wasted for want of asking whether the work pointed anywhere worth going. That's vibe coding, more or less exactly: perfect butler energy, nobody checking where the house is headed.

By July 2025 I'd hit enough of the failure modes to name them, in a piece called "Mountains of Misunderstanding: The AI Confidence Trap" — about the hubris plateau, the place where the tool's fluency and your own enthusiasm conspire to convince you that you understand more than you do, right before the depths of despair teach you otherwise. I wrote it with a friend, and the collaboration taught me something on its own: everything in that essay felt obvious to me. To him, it was eye-opening. Which meant I'd internalized the failure patterns long before I could articulate them, and writing it with someone outside my head was what forced the tacit knowledge into an explicit model.

That gap, between what you know and what you can state, turns out to be the entire problem with AI-assisted development. The AI can only work from what's stated. Everything tacit is invisible to it. Every architectural conviction, every hard-won constraint, every "we don't do it that way here" — if it isn't written down, it doesn't exist for the agent, and the agent will cheerfully violate it at machine speed.

I spent that late summer looking backward, at the Oracle CASE tools of my nineties, at every methodology I'd watched promise that the model could drive the code. S-Designer. PowerBuilder. ASP.NET scaffolding. Each one had the right instinct and died the same way: the distance between the model and the running system was too great, humans had to bridge it by hand, and humans stopped bothering. I could feel I was circling something, but I didn't have the framework yet.

The Bridge Finally Held

In September 2025, GitHub released Spec Kit, and a colleague suggested I take a look — one of those brief exchanges that turn out to be pivotal.

I don't want to over-dramatize what Spec Kit was. It was a starting point: a structure for writing specifications an AI agent could execute against. What it gave me wasn't a finished answer, it was vocabulary — specification-driven development, the idea that the spec, not the chat, not the vibe, not the prompt-of-the-moment, is the durable artifact, and the code is downstream of it.

Thirty years snapped into alignment. This was Oracle CASE again — the model driving the code — except this time the bridge between model and running system wasn't a human hand-translating and eventually giving up. It was an agent that could actually execute the specification, tirelessly, repeatably, at the speed the old tools had only promised. The principle I'd carried since the nineties, that the model matters more than the code, had finally become executable.

I adopted Spec Kit fast and outgrew it just as fast, because real production work breaks the greenfield fantasy quickly. Specs are wonderful until you need a hotfix at 4 p.m. on a Friday. Specification-driven development, as delivered, had nothing to say about brownfield code, documentation drift, or the ninety percent of engineering that isn't starting something new. So I built what it was missing: a full-lifecycle methodology I call DevSpark. Discovery for existing codebases. Right-sized workflows so a one-line fix doesn't demand a dissertation. A living constitution that captures the tacit knowledge — the architecture, the standards, the "we don't do it that way here" — so the agent finally has access to what used to live only in my head.

I validated it the same way I validated that first PHP site: not by admiring the explanation, but by running it. Roughly thirty repositories became the crucible. Inputs and outputs. Did it hold up? It held up.

And I documented it as I went, the way I'd been doing without any grand plan since November 2022. Most people's "AI journey" gets reconstructed in hindsight, polished for a resume. Mine sits on this site with timestamps intact — the enthusiasm of 2023, the floodgates of early 2025, the reckoning weeks later, the discipline taking shape that fall. I wasn't screaming into the void all those years. I was keeping the ship's log.

Still Sailing

Three years into this leg of the voyage, I'm writing specifications that agents execute — moving faster than I've ever moved and more deliberately than I've ever moved, which is the combination every methodology of the last thirty years promised and none delivered until now. When I watch a well-formed spec flow through DevSpark into working, reviewed, documented software, I feel some of what I felt looking out at that island with my kids: not that I'd arrived anywhere, but that the journey had been the entire gift — the failures, the tools, the timestamped record of getting it wrong and then less wrong. There was never going to be an island where the voyage stopped mattering and the destination took over. There isn't now either.

The methodology is already evolving into its next iteration — smaller teams, different domains, failure modes I haven't hit yet and haven't named yet. Those kids who stood there looking out at Ithaka with me are grown now, out on voyages of their own, which is of course exactly what Cavafy was talking about. Ithaka gave them the journey too. There's nothing waiting at their island either, and that's not a loss. That's the gift.

We are always on a journey. I'll keep the log as I go.

Explore More

• Mountains of Misunderstanding: The AI Confidence Trap — the essay where I first named the hubris-plateau failure mode this piece traces back to
• Why I Built DevSpark — the origin story of the methodology this journey builds toward
• DevSpark: The Evolution of AI-Assisted Software Development — how specification-driven development took shape in practice
• Dogfooding DevSpark: Building the Plane While Flying It — validating the methodology against roughly thirty real repositories