DEV Community: Mark Hazleton

The Power of Lifelong Learning

Mark Hazleton — Thu, 22 Oct 2026 00:05:04 +0000

The Field Keeps Moving

Life is an endless classroom where every interaction offers a chance to learn something new — that's B.B. King's observation, and it holds up. The beautiful thing about learning is that no one can take it away from you. But in software development, the corollary is also true: the things you already know have a shorter shelf life than you might expect.

Technologies that were foundational five years ago are optional today and legacy tomorrow. Practices that represented the state of the art become the thing the next generation is hired to replace. This isn't a complaint about the pace of change — it's just the nature of the field. The question isn't whether things will change but whether you're positioned to stay genuinely useful as they do.

What that requires isn't a specific platform or a study schedule. It's a posture — a sustained orientation toward staying curious and capable rather than coasting on what's already known. The mechanics of how to do that are worth examining, because they're more varied and context-dependent than the usual "take more courses" advice suggests.

I also recorded a Deep Dive video on Lifelong Learning that covers this topic in more depth, including a discussion of how the pace of change in software makes deliberate learning a non-negotiable rather than a nice-to-have.

Structured Learning: When the Curriculum Helps

There are times when organized, externally structured learning is exactly the right tool. A new technology you need to get up to speed on quickly. A certification that matters for a role or a client. A domain you're entering from the outside and don't yet have the mental map for.

Platforms like Pluralsight, Microsoft Learn, and LinkedIn Learning have made this kind of learning far more accessible than it used to be. Microsoft Learn in particular is worth noting for anyone working in the Azure ecosystem — the free hands-on labs and sandboxed environments let you experiment without provisioning real infrastructure, which lowers the barrier to actually trying things rather than just reading about them.

The part of structured learning that tends to matter most isn't the content itself — it's the forcing function. A defined curriculum with a clear endpoint provides external pressure that self-directed exploration often doesn't. For learning that needs to happen on a timeline, that pressure is useful. For the kind of exploratory learning that leads to unexpected discoveries, it can be limiting.

Passive Learning: Using Dead Time

One of the more practical observations about professional development is how much usable time gets written off as dead time — commutes, workouts, housework, walks. None of these inherently require the part of the brain needed for deep problem-solving, and they can accommodate the kind of listening that turns out to be quite good for learning.

.NET Rocks! is the podcast I keep coming back to — Carl and Richard have been covering the Microsoft and .NET ecosystem for years with a combination of technical depth and genuine curiosity that's hard to find elsewhere. The conversational format works well for audio because it doesn't require following dense visual content, and the range of guests means you're regularly exposed to perspectives and projects you'd never seek out directly.

The key to making passive learning actually useful is selection. Subscribing to too many things produces a backlog that functions more as ambient anxiety than genuine learning. Better to follow a small number of sources well than to accumulate a long queue that never gets processed.

Unstructured Learning: Getting Your Hands on Real Code

There's a kind of understanding that can only come from working with real code in a low-stakes environment — exploring a GitHub repository for a technology you're evaluating, making modifications to see how behavior changes, tracing through a codebase to understand a design decision you've only read about.

This kind of unstructured experimentation is harder to schedule than a course, and it resists the productivity metrics that make structured learning feel satisfying. You can't put "explored a repository for three hours and followed several dead ends before understanding the pattern" on a progress bar. But the understanding it produces tends to be more durable than the understanding that comes from following a linear curriculum, because you've encountered the actual complexity rather than a curated simplification of it.

The discipline required is different from structured learning: instead of following a path, you're choosing where to look. Setting a loose intention — "I want to understand how this library handles concurrency" — without being rigid about the route tends to work better than either pure wandering or overly structured exploration.

What Sustains It

The practical challenge of lifelong learning isn't finding resources — those are abundant — it's sustaining the habit when the immediate pressure of current work competes with the longer-term investment of developing new capability.

What tends to sustain it, in my experience, is treating learning as part of the work rather than something separate from it. Not "I'll carve out time after the project ships" but "I'll understand this technology more deeply by working with it on the project." The project teaches you something; the thing you learned shapes how you approach the next project. That compounding is slower and less dramatic than a focused study sprint, but it accumulates in ways that feel meaningful over years rather than weeks.

The other thing that sustains it is genuine curiosity — which can't be manufactured through willpower alone. The fields within software that have kept me most engaged over time are the ones where I kept finding new things that surprised me. When a domain stops producing surprises, that's usually a signal worth paying attention to.

Explore More

Sidetracked by Sizzle: Staying Focused on True Value -- A Personal Reminder to Stay Anchored to What Actually Matters
When the Pressure is On - Late Sprint Hotfix Governance -- Rational decision-making when everyone's screaming "rush, rush, rush"
Accountability and Authority: Walking the Tightrope -- A continuation of Dave's story — what happened Monday morning
AI and Critical Thinking in Software Development -- What AI Handles and What Humans Must Still Own
The Managed Transition Model: Leadership Promotion as Power Exchange -- A Unified Theory of Leadership Promotion and Power Exchange

I originally published this on markhazleton.com, where I keep the rest of my writing.

From Oracle CASE to Spec-Driven AI Development

Mark Hazleton — Wed, 21 Oct 2026 23:40:44 +0000

Early in my career, I had the opportunity to work with tools that many engineers today have never experienced — environments where you didn't write code, you defined rules. Where a central repository governed truth. Where systems could be regenerated deterministically from a model. These were called CASE tools, and Oracle CASE was the one that changed how I thought about software forever.

At the time, they felt revolutionary. Looking back, I realize they were something even more important: they showed me what software engineering could look like when the model, not the code, was the center of gravity.

That lesson stayed with me for decades. And it explains why, when I built DevSpark around modern AI-assisted development principles, my reaction wasn't excitement about something new. It was recognition. It felt like coming home.

The Early Foundation: When the Repository Was Truth

What made Oracle CASE powerful wasn't just that it generated forms or PL/SQL. It was the philosophy behind it. Quality didn't come from hand-crafting the code — it came from governing the model. The repository defined truth. Every screen, every table, every relationship flowed from that single source. As a developer, I was focused on intent and design, not on the repetitive mechanics of implementation.

Yes, these tools were often seen as clunky — heavy, proprietary, and rigid by modern standards. But the philosophy behind them was sound. That mental model changes how you see software forever. Once you've worked that way, it's very hard to go back to thinking of the source files as the thing that matters most.

S-Designer: Refinement and Regeneration as the Real Workflow

After Oracle CASE, I worked extensively with S-Designer — later known as PowerDesigner — and it expanded on everything I had learned, but it crystallized one idea I hadn't fully articulated before: the model is what matters, and regeneration after refinement is the secret sauce.

I wasn't maintaining code. I was maintaining a design. Every time requirements shifted, I went back to the model, refined it, and regenerated. The output was almost beside the point. What endured was the design artifact, not the implementation. That discipline — going back upstream instead of patching downstream — changed how I approached software development. It also made me deeply skeptical of any workflow that treated generated or scaffolded code as something you were supposed to edit by hand.

PowerBuilder: The Original Low-Code That Actually Worked

PowerBuilder approached the same idea from a more practical angle. Think of it as the original low-code platform before that term existed — declarative UI bound to database schemas, automatic SQL and CRUD behavior, rapid regeneration of working applications. It wasn't repository-heavy in the way CASE tools were, but it kept proving the same underlying point: high-level definitions can reliably produce working software.

It also reinforced something important about developer trust. When the generation was reliable and consistent, you stopped second-guessing the output and started investing more carefully in the inputs. That shift in attention — from reviewing what was generated to improving what drove the generation — is exactly the right place for a developer's energy to go.

ASP.NET Maker: Iterate on the Model, Not the Code

ASP.NET Maker brought these ideas forward into the web era, and it taught me something I still carry with me today. What it demonstrated wasn't just that you could generate a full CRUD web application from a database schema — it was that you should never edit the generated code. The moment you touched the output, you'd broken the contract. The right move was always to go back, refine the model or the configuration, and regenerate.

Iterate on the model, not the code. It sounds simple, but it cuts against a deeply ingrained instinct developers have to just fix the thing in front of them. ASP.NET Maker forced discipline because the alternative — a hand-edited generated file — was immediately fragile. That constraint was a feature.

The Middle Years: When Speed Meant Shedding the Model

Somewhere between the CASE era and today, the industry made a deliberate choice: shed the overhead, empower the individual developer, move fast. The heavy repositories and proprietary tooling of the 90s gave way to something fundamentally different — lightweight editors, command-line workflows, and developer productivity without a central model.

This wasn't loss. This was learning to move at a different speed.

VS Code became a text editor that could be anything you needed it to be, without forcing you into a specific methodology. It was the opposite of Oracle CASE. No repository. No regeneration. No enforced structure. Just you, the code, and whatever extensions you chose to install. The freedom was intoxicating after years of heavy tooling.

The command line came back into focus.

npm install
dotnet new
git commit

Direct, immediate, unmediated. You weren't asking a CASE tool to interpret your intent and generate an artifact. You were issuing instructions and seeing results in seconds. The feedback loop collapsed from minutes to milliseconds.

DevExpress CodeRush taught me to navigate and refactor .NET code at the speed of thought, tightening that loop even further. IntelliSense wasn't just autocomplete — it was working at a higher level of abstraction, letting me think in concepts while the tool handled syntax. The .NET MVC scaffolding templates let me generate working application structures directly from a database schema — not as sophisticated as the CASE environments I'd come from, but fast, and just enough structure to get started.

What all of these tools had in common was that they optimized for individual developer productivity without the overhead of a shared repository or governance layer. You could clone a repo and be productive in minutes. No database to set up. No CASE workbench to install. No team repository to sync against. Just code.

The 90s solved the structure problem with centralized models and regeneration. The 2000s and 2010s solved the speed problem by giving that up and optimizing for individual velocity. Modern AI-driven development is the synthesis of both — the structure and governance of the old philosophy, married to the speed and lightweight tooling of the modern era.

The Inspiration for DevSpark: Recognition, Not Discovery

When I started building DevSpark around spec-driven principles, something clicked immediately — and now I understand why. DevSpark restores the same foundational principles I'd been working with since the early CASE days. Human-readable specifications as the source of truth. Lifecycle governance around intent. Structured review before build. Deterministic implementation once clarity exists.

This wasn't a reinvention. It was the original promise of model-driven engineering, finally usable at organizational scale, without proprietary repositories or heavy tooling. The specifications are open. The governance is adaptive. The execution engine is AI. But the philosophy is the same one I recognized the first time I watched a CASE tool regenerate a consistent, correct system from a well-governed model.

But there's one critical difference that makes AI-driven development genuinely better than what came before.

The Critic: From Passive Walls to Active Partners

Here's the fundamental difference between the old CASE repositories and modern AI-driven development: the old tools were passive enforcement. They said no. The database schema didn't match the model? Error. Relationship violated referential integrity? Blocked. It was governance through constraint — a wall you couldn't cross.

AI governance is active engagement. It doesn't say no. It asks, are you sure?

One of the core DevSpark features I built — the critic prompt — stood out not just technically, but emotionally. It reminded me of the senior developers early in my career, the ones who always pushed back before you got too far down the wrong path.

Did you think this all the way through? What happens at scale? Is this solving the real problem, or just the visible one?

Great engineering cultures institutionalize that voice. But over the middle years, as teams grew and velocity became the primary metric, that voice got drowned out. The pressure to ship overrode the discipline to pause. Modern teams have lost it — not intentionally, but inevitably.

The critic prompt brings it back, not as a person, but as a repeatable governance mechanism. It asks the uncomfortable questions every time, without politics or fatigue. It's not a sycophant that always agrees with you. It's the senior architect who's seen this pattern fail before and wants you to consider the edge cases.

That's the evolution. The old tools were walls. The new tools are partners.

What the 40-Year Arc Actually Looks Like

Looking back at this journey — Oracle CASE in the nineties, S-Designer and PowerBuilder through the late nineties and into the two-thousands, ASP.NET Maker and the scaffolding era, CodeRush and IntelliSense as practical companions along the way, and now DevSpark with AI execution — I can see the pattern clearly.

The 90s gave us structure. CASE tools proved that models could govern quality and that regeneration from a single source of truth was possible.

The 2000s and 2010s gave us speed. Modern IDEs, scaffolding, and iterative workflows made it possible to move at the pace of changing requirements.

Modern AI gives us synthesis. The structure and governance of the old CASE philosophy, married to the velocity and adaptability of modern development, with active rather than passive guidance.

The goal has always been the same: translate business intent into reliable software with minimal ambiguity and maximal consistency. What's changed is our ability to do it continuously, collaboratively, and at a scale that CASE environments could only approximate.

Where I Am Now — And What You Can Do Monday Morning

My creation of DevSpark wasn't about chasing something new. It was about recognizing something old, reborn in a form that actually works for the way organizations build software today.

Oracle CASE taught me that models govern quality. The decades in between showed me what it costs when governance erodes — the architectural drift, the inconsistent patterns, the growing distance between business intent and what actually gets built. DevSpark, and the AI-driven lifecycle it enables, showed me the path back.

I work differently now than I did in the nineties, but the instinct that drives how I work hasn't changed at all. Describe the intent carefully. Govern the model. Regenerate rather than patch. Let the implementation follow from clarity, not the other way around.

If this resonates with you, here's what I'd suggest:

Treat your prompt library as the new repository. It's your source of truth. Version it. Govern it. Review changes to it the same way you'd review schema changes in the old CASE tools.
Never edit the AI output manually. This is the same discipline ASP.NET Maker forced on me. The moment you touch the generated code, you've broken the contract. If the output isn't right, go back upstream. Refine the prompt. Refine the spec. Regenerate. Don't patch.
Install a critic in your workflow. Whether it's a formal prompt like mine or just a checklist you run before committing, create a mechanism that asks the uncomfortable questions. Did you think this all the way through? What breaks at scale? What happens when this fails?
Document the model, not just the code. Your future self — and your teammates — need to understand the why, not just the what. The specifications, the architectural decisions, the constraints that shaped the implementation: those are what endure.

That's what CASE taught me. That's what every tool since has reinforced in one way or another. And that's what I finally feel like I can do well — not just in pockets of a project, but across the whole lifecycle.

Explore More

Why I Built DevSpark -- Building the tool I needed to survive the reality of brownfield developm
DevSpark: From Fork to Framework — What the Commits Reveal -- A commit-by-commit record of what went from concept to code — six commands, many iterations, and eight weeks to v0.1.0
DevSpark v0.1.0: Agent-Agnostic, Multi-User, and Built for Teams -- How canonical prompts, thin shims, and per-user personalization let teams share governance while celebrating individual workflow
Getting Started with DevSpark: Requirements Quality Matters -- Enforcing requirements quality before code generation
DevSpark: Constitution-Driven AI for Software Development -- DevSpark aligns AI coding agents with project architecture and governance through a constitution-driven toolkit for the full software development lifecycle.

I originally published this on markhazleton.com, where I keep the rest of my writing.

The Dependencies I Never Upgraded

Mark Hazleton — Wed, 21 Oct 2026 23:30:16 +0000

The Other Reading List

Every Friday, I enjoy reading a friend's roundup of technology trends. New AI models. Emerging frameworks. Leadership articles. Research papers. The kind of reading that helps all of us stay current in an industry that refuses to stand still.

I read those things too. After many years in software, I've learned that staying curious isn't optional. Languages evolve. Platforms change. Entire architectures appear, dominate for a decade, and quietly disappear. If you're not learning, you're falling behind.

But his newsletter recently made me think about a different reading list. Not the one that shaped this week. The one that shaped my life.

As software developers, we spend our careers upgrading dependencies. We replace libraries, retire frameworks, and migrate platforms. Some upgrades are revolutionary, others barely noticeable, but over time almost every dependency changes. Looking back, I realized there are a handful of dependencies I've never upgraded. Not software dependencies. Intellectual ones. They've survived every programming language I've learned, every methodology I've practiced, every technology revolution I've lived through. Not because they predicted the future. Because they were never about technology in the first place.

The Books That Never Got Upgraded

Arthur C. Clarke got to me in high school, and like most teenagers, I came for the spaceships. Rendezvous with Rama was mysterious and imaginative and unlike anything I'd read before, and Tales from the White Hart showed me a completely different side of him — playful, clubby, more interested in the shape of a good idea than in getting the science exactly right. But somewhere along the way I realized I wasn't captivated by the alien spacecraft so much as by Clarke himself — a writer patient enough to let mystery stay mysterious for three hundred pages. He never rushed to explain Rama. He just kept looking at it more carefully. I've had a standing, half-serious wish for years to go to Sri Lanka, where Clarke spent most of his life, and ask him what he was really trying to tell me — not about spaceships, but about the wonder and the intellectual humility underneath them. That combination is the thing I still borrow from him: observe first, explore honestly, and don't pretend to know what you don't. When a legacy system does something inexplicable, or a production issue doesn't match any pattern I recognize, my first instinct used to be to force an explanation onto it fast. Clarke taught me the more useful instinct: sit with the unfamiliar a little longer before you decide you understand it.

Robert Heinlein arrived around the same time, for a completely different reason. I probably read him because he was rebellious — Stranger in a Strange Land felt subversive, Time Enough for Love felt like a dare, and Job: A Comedy of Justice was the first book that showed me an author could be funny and furious about the same subject in the same paragraph. I was maybe seventeen, reading it after everyone else had gone to bed, feeling like I'd gotten away with something. Only much later did I realize the books weren't really about rebellion. They were about refusing to accept an answer just because it was the one everyone already agreed on. Why do we believe what we believe? Why do we do things the way we've always done them? Those turned out to be excellent questions for a lead engineer to keep asking — especially in a room where "that's just how we've always built it" gets treated as an argument instead of a habit. I'll admit, affectionately, that Heinlein — and probably his editors — occasionally seemed to lose track of time somewhere inside those enormous later novels. Even the writers who teach you the most aren't immune to sprawl.

Kurt Vonnegut made me laugh, and he still does. Harrison Bergeron is eight pages long. Eight pages, and it dismantles an entire idea of enforced equality without ever once sounding like it's trying to. That's the whole trick — he never preached. He just told you a story and trusted you to notice what it meant on your own, usually a beat after you'd already laughed at it. I've never fully pulled that off in a design review. I'm still trying.

The Ones I Didn't Understand Until Later

I encountered C. P. Cavafy's Ithaka in college, in a twelve-credit-hour Great Books course that nearly ate my lunch. I appreciated the poem. I admired the language.

I didn't understand it.

Decades later, traveling through Greece with my family, I glanced out the window of our car.

There, across the water, was Ithaka.

And suddenly the poem wasn't literature anymore.

It was life.

The destination had never been the point. The years between college and that moment had filled in everything the younger version of me couldn't yet see — career successes, failures, marriage, raising children, mentoring colleagues, building businesses, losing sleep over projects that eventually worked out fine. The journey had quietly become the lesson. That's the part nobody tells you about judgment: it isn't handed to you at the destination. It accumulates, unglamorously, out of the choices along the way — which is another way of saying the journey doesn't just teach you things, it builds the judgment you'll need for the next one.

For years I knew only a single line from Dylan Thomas: "Rage, rage against the dying of the light." I admired it without understanding it. Only much later did the words start to mean something different. I no longer hear anger in them.

I hear determination — and lately I've started thinking of it less as a line about mortality and more as a line about keeping the fire. Not rage in the sense of anger, but the refusal to let curiosity go quiet just because you've seen enough failed projects to know exactly how hard meaningful work really is. That's what I take from it now: stay curious, stay engaged, and don't let cynicism pass itself off as wisdom just because it's easier to carry.

The book that surprised me most was Kazuo Ishiguro's The Remains of the Day. When I first finished it, I thought it was a tragedy about serving a flawed man. I wasn't wrong.

I also wasn't finished with it.

As the years passed — and especially now that my kids are grown and building lives of their own — the story changed on me. What once read as a tragedy of misplaced loyalty became something richer: a meditation on the dignity of service, on doing work well because the work deserves excellence, on the quiet melancholy that comes with a life devoted to purpose, and the moments that can never be reclaimed along the way. The lesson isn't that Stevens's service was a mistake. It's that service, purpose, relationships, and the courage to exercise your own judgment all have to coexist — leave one out, and the others curdle.

I didn't expect one of the most useful lessons I'd learn about leadership to come from an aging English butler.

Yet here we are.

That pattern — a lesson that only becomes visible once you're old enough to have lived past the surface of it — is worth pausing on, because it isn't limited to a bookshelf. It shows up in how I evaluate technology decisions too.

Curiosity Needs a Compass

There's a reason this reading list keeps circling back to judgment instead of settling for admiration of good writing. I've spent a long career being handed other people's money, time, systems, and people to look after — as an architect, a consultant, a mentor. That's a form of stewardship, and it changes what curiosity is actually for. Curiosity that only serves my own interest in what's technically fascinating isn't the same thing as curiosity in service of the problem actually in front of me.

I wrote about this more directly in Sidetracked by Sizzle, where I described the pull toward whatever looks most advanced instead of what a problem actually requires. That article and this one turned out to be circling the same idea from different directions. Sizzle is what happens when curiosity goes undisciplined — when the newest, most impressive option gets treated as the right one simply because it's new and impressive. The antidote isn't less curiosity. It's judgment: the accumulated, unglamorous sense of which possibilities are worth pursuing and which ones just look worth pursuing.

Innovation provides the possibilities. Judgment decides which of those possibilities deserve the time. That's Ithaka's lesson wearing work clothes — the years of choices, mistakes, and course corrections that build the judgment good technology decisions actually depend on.

Craft as a Form of Service

None of this works, though, without craft. Judgment tells you what's worth pursuing; craft is what lets you actually deliver on it well. I still care, more than I probably need to at this point in my career, about doing the work well regardless of whether anyone notices — documentation that quietly makes the next developer's day easier, an architecture decision that never gets celebrated because it never causes a problem, a mentoring conversation that eventually helps someone become better at this than I am.

That's the same thread Ishiguro's butler was pulling on, translated into a career I actually recognize. Good work, measured this way, often looks quieter than impressive work. It leaves systems clearer, teams stronger, and people a little more capable than it found them — not because it announced itself, but because it did what it was supposed to do and got out of the way. Service and craft aren't separate values sitting next to each other. Craft is what makes the service real instead of just well-intentioned.

What They Taught Me Instead

None of these books taught me software development. They taught me curiosity, humility, craftsmanship, patience with the unfamiliar, respect for the reader — or the teammate — sitting across from me. They taught me that wisdom often arrives years after knowledge does, and that experience has a way of finishing books we thought we'd already read.

That last part is the one I keep coming back to. I didn't understand Ithaka the same way in a twelve-credit-hour Great Books course that I did seeing the actual island from a car window decades later. I didn't understand Dylan Thomas's rage the same way at twenty as I do now. Heinlein's rebellion eventually revealed lessons that had nothing to do with rebellion at all, and The Remains of the Day keeps changing as my own life changes around it. The books haven't changed. I have. Some books, I've come to believe, don't fully reveal themselves until you've lived long enough to understand what they were saying all along.

If there's a single thread under all of it, it's something close to this: curiosity that keeps going, a journey that's allowed to do the teaching, craft practiced well enough to be worth putting in someone else's service, and not letting what's shiny substitute for what's actually worth pursuing. None of that is really a technology philosophy. It just happens to be the one that's shaped how I think about architecture, mentoring, and every dependency — software or otherwise — I've picked up along the way.

Every week I'll keep reading about AI, architecture, and whatever comes next. Those technologies deserve to be upgraded. But these ideas have been quietly shaping how I think for most of my life. They remain the dependencies I never upgraded — and, unlike everything else in this industry, I'm not looking for a replacement.

What book, poem, or story has stayed with you — not because it had all the answers, but because it kept revealing new ones as you grew?

Explore More

Sidetracked by Sizzle: Staying Focused on True Value — the professional-practice version of the same idea: curiosity only holds up when judgment is doing the steering
Ithaka Gave You the Journey: AI-Assisted Development — the direct sequel, tracing what happened when thirty years of this thinking finally met tools fast enough to test it
The Art of Making Yourself Replaceable: A Guide to Career Growth — craft as service, examined from the mentoring side
The Power of Lifelong Learning — a companion piece on why staying curious is a career-long practice, not a phase
Turtling: When a Team Stops Looking for the Door — on the difference between comfort and growth in a long-running system or career

I originally published this on markhazleton.com, where I keep the rest of my writing.

Ithaka Gave You the Journey: AI-Assisted Development

Mark Hazleton — Wed, 21 Oct 2026 23:26:59 +0000

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, "The Dependencies I Never Upgraded," 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

The Dependencies I Never Upgraded — the essay this one is a direct sequel to, tracing the writers who wired how I think about systems, consequences, and judgment
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

I originally published this on markhazleton.com, where I keep the rest of my writing.

DEV Community: Mark Hazleton

The Power of Lifelong Learning

The Field Keeps Moving

Structured Learning: When the Curriculum Helps

Passive Learning: Using Dead Time

Unstructured Learning: Getting Your Hands on Real Code

What Sustains It

Further Reading

Explore More

From Oracle CASE to Spec-Driven AI Development

The Early Foundation: When the Repository Was Truth

S-Designer: Refinement and Regeneration as the Real Workflow

PowerBuilder: The Original Low-Code That Actually Worked

ASP.NET Maker: Iterate on the Model, Not the Code

The Middle Years: When Speed Meant Shedding the Model

The Inspiration for DevSpark: Recognition, Not Discovery

The Critic: From Passive Walls to Active Partners

What the 40-Year Arc Actually Looks Like

Where I Am Now — And What You Can Do Monday Morning

Explore More

The Dependencies I Never Upgraded

The Other Reading List

The Books That Never Got Upgraded

The Ones I Didn't Understand Until Later

Curiosity Needs a Compass

Craft as a Form of Service

What They Taught Me Instead

Explore More

Ithaka Gave You the Journey: AI-Assisted Development

The Island

Borrowed Competence

The Floodgates

What the Butler Knew

The Bridge Finally Held

Still Sailing

Explore More