I recently joined the GitHub Developer Program, an option GitHub made available through my account. It is a small marker, and I want to treat it as one. The badge is not the story. The story is the trail behind it, and the honest version of that trail is messier than any badge suggests — which is exactly why it is worth writing down. I have spent most of my career insisting that architecture should be honest about where it succeeds and where it quietly fails. It would be strange to abandon that the moment the subject became me.
So here is the honest account.
The trail behind the badge
Over the past several months I have produced more than thirty repositories, founded five organisations, and pushed past two thousand commits. In the same breath, and without contradiction, I have to tell you the rest: I have failed basic commands that an engineer would run without thinking, leaned on scripts I did not fully understand, and worked my way through what feels like every continuous-integration platform in existence, hitting the constraints of someone who does not code for a living and does not pretend otherwise. Both of those paragraphs are true at once. The architect who can only tell you the first one is selling a portfolio. The one willing to tell you the second is describing what actually happened.
Because a commit is activity, not achievement, and I know the difference well enough not to let the number flatter me. Many of those repositories are sketches, restarts, and scaffolds that only make sense because I still remember the argument that produced them. They are not a product catalogue. They are a trail of questions, left in public, with the working-out still visible. That is the point of a workshop. It is not meant to look finished.
The workshop
What changed is not that I became a developer. What changed is that the activation energy collapsed. For most of my career, turning an architectural idea into even a modest working tool would have required a team, a budget, a backlog, and weeks of translation between the person who held the intent and the people turning it into code. That translation layer has not disappeared, but the loop is now tight enough that I can sit inside it myself. I start with an idea, draft it through AI, push it into a working interface, break it, repair it, deploy it, look again, realise the original thought was not quite right, and reshape the thing.
GitHub became the workshop and the system of record. Cloudflare and Vercel became deployment surfaces. AI became the build partner. The architectural mind became the control plane. That last phrase is where the hype usually gets the story wrong, and where my own experience confirms the correction: the tooling did not replace the architect, it gave the architect a control plane. It gave someone with judgement about structure, risk, and connection a way to test those things much closer to the surface of execution than a diagram ever allowed. This is what executable architecture feels like from the inside. It is not elegant. It is close.
The same shape underneath
It helps to be concrete about what has come out of the workshop, with the honest caveat attached up front: these are projects, not products. I am not selling anything, and I am not going to tell you they are finished, because they are not. I am building toward something, and the building is the point I am making here, not a launch.
So, concretely: a 2-D tabletop game. A scuba diving organisational advisory site. The consulting brand itself — the identity, the designs, the sites that carry it. And an AI-assisted enterprise delivery capability, which is the one I have put the most into. It is built as a set of role agents that mirror how real delivery is actually staffed: an enterprise architect, a solution architect, a project manager, a programme manager, a security team. Each of those is not a single prompt but an orchestrator, running its own agents behind it — somewhere around thirty to forty in total — and worked toward current industry standards rather than improvised. I want to be exact about the claim: I am not describing a product, I am describing a capability, and the capability is the thing I am interested in proving I can stand up. None of these sit in the same business. A game, a diving advisory, a brand, an agentic delivery capability — on the surface they share nothing at all.
A few years ago, not one of them would have been possible without a team standing behind it: developers, architects, designers, brand managers, the whole assembly line of specialists you convene before a single idea becomes visible. That is the part that still surprises me. One person with domain judgement and enough stubbornness can now stand up a working version of each, alone, in the open.
And here is what the surface hides. Architecturally, they are the same project. Every one of them needs interactive agents, pipelines, control over what runs and when, keys and secrets handled properly, security that actually holds, and a real understanding of the functions underneath — what each part is for and who depends on it. Strip away the subject matter and the diving site, the game, the brand, and the agentic delivery capability are one structural problem wearing different clothes. Seeing that sameness is not an engineering skill. It is the architectural one, and it is the reason the lens still matters even while the hands are still learning.
The thrash
The continuous-integration sprawl was only the most visible symptom of a larger habit, and the larger habit deserves the honesty more. I have been trying everything. Every new release that gets advertised, every CLI, every new product, every famous tool, every vendor offering, anything I read about on a repository — I install it, wire it in, and see what it does to the work. Part of that is genuine curiosity, the same instinct that named a blog Coffee and Curiosity, and I do not apologise for it. The other part is harder to admit: a good deal of it was a search for the tool that would simply work without requiring me to understand the model underneath.
The CI platforms make the pattern obvious because they all share that model — a pipeline that builds, tests, and ships on defined triggers. Someone carrying an engineer's muscle memory would have chosen one and bent it to their needs. I did not have that muscle memory, so I migrated, hoping a different surface would solve a conceptual problem that no surface can solve. Multiply that across every category of tool and you have a fair picture of how the months actually went: less a straight line, more a wide sweep across the whole landscape, picking things up to feel their weight.
But the sweep was not wasted, and this is the part I would not have predicted. Every constraint I hit taught me where the real structure lived. The tools that frustrated me were, in effect, showing me their architecture by refusing to let me ignore it. The mess was not separate from the learning. The mess was the learning. I do not recommend trying everything as a method — it is expensive in time and attention, and it is easy to mistake the next release for actual progress. I am simply reporting that, handled in the open, it worked as one.
The commands I cannot run
I am not going to dress up the gaps. I have fumbled basic version-control commands in ways that would make a good engineer wince, and I have relied on generated code I could produce but not always fully explain. My value was never in typing the command. It was in knowing what should exist, why it matters, where it connects, what risk it carries, who owns it, and what happens when it meets reality. That has not changed.
What I will not do is pretend the gap is a charming quirk, because over time it is a ceiling, and I keep meeting it. Not understanding the mechanics means some problems arrive as mysteries to be brute-forced rather than situations to be reasoned about. That is a real limit, not a footnote. And it is precisely why I respect engineers more now, not less. Engineering is still a discipline. Security, testing, maintainability, operational resilience, privacy, performance, and accountability still matter, and they may matter more, not less, now that working systems have become easier to produce. The current wave of generated code does not always give good engineers the credit they are owed. I would rather be the architect who names that plainly than the one who quietly takes it for granted.
Why I am careful with “vibe coding”
If the only method is enthusiasm, the result will usually be fragile. A generated screen is not a product. A working demo is not a governed system. Two thousand commits are not a maintained system, and I hold that fact against my own numbers before anyone else has to. The version of this I am interested in does not start with code. It starts with intent, and asks what capability is being created, why it matters, what decisions it touches, what data it handles, what should remain private, how human review works, and what should never be automated simply because it can be. That is not AI as a shortcut around architecture. It is AI as a way of making architecture more executable — and the only way that distinction survives contact with reality is if someone is honest about the difference between a thing that runs and a thing that is trustworthy.
A small marker
So the badge is a small marker, and the meaningful part is the chance to engage more deeply with the GitHub developer community — to build, break, and learn alongside people who do this with a rigour I am still assembling. I am not claiming a new job title. I am not a software developer, and I am not pretending generated code is engineering mastery. I am an architect who has found a way to build, and who would rather show you the rough trail than a polished diagram of it.
The principle that organises everything else still holds, and the GitHub journey has only made it sharper. AI lowers the activation energy; it does not remove the need for competence. The architect brings structure, AI brings acceleration, the tooling provides the path to deployment, the review loop provides correction, the governance model provides control, and the practitioner still brings taste, judgement, and consequence. That combination is powerful, and it is dangerous if handled lazily. The trail in those repositories is my attempt to handle it in the open, mistakes included.
AI drafts. Architect reviews. Clients receive controlled artefacts. That part is still on us.