The past two and a half years have been, for me, an exercise in staying oriented while everything moved. Models improving faster than I could learn them. Tools promising more than they delivered. A profession I had spent years building suddenly asking to be renegotiated. I was curious, but I was also uncertain about what would remain. It turns out I no longer write a single line of code. The team does.
In early 2024, I was asking ChatGPT questions about code. Then Copilot for autocomplete, which I eventually had to disable (too intrusive, interrupting more than it was helping). Each had its uses, but I was still doing all the work, just some of it faster. Then came Cursor, which gave me access to Claude Sonnet. For the first time, I had a model that felt like it was actually built for this kind of work. Procurify gave engineers access to several of these tools along the way, and that openness made the exploration possible.
The real change came in Q1. Necessity, as it turns out, is still the mother of invention.
I had set an aggressive target: one month for a project I had originally estimated at three, without expanding the team. A nod to the Mythical Man-Month, if you like. The math required a different way of working.
I started with Cursor rules and prompts stored as markdown files. I was assembling the right prompt for each task, carrying the context myself as I moved between the work of an analyst, an architect, an implementer, a reviewer, and a writer, sometimes all within the same day.
Midway through the month I switched to a set of markdown prompt files, each mapped to a step in my workflow, with one entry-point file that asked me for the right variables and picked which prompt to run next. That helped, but the setup was inflexible. The prompts were hardcoded, sometimes asking for variables that weren't needed and unable to adapt to what a given situation actually required. I was thinking about AI as an execution platform for a custom prompt library, a set of tools to call in sequence, each waiting for input, each returning output, with me threading everything together by hand.
What if I stopped treating AI as a sequence of steps to execute and started treating it as a set of roles to fill? That question changed everything.
Instead of prompts mapped to process steps, I imagined personas mapped to areas of expertise, each one knowing not just what to do but how to think about a problem, capable of accumulating context and holding a role across sessions without being re-briefed every time.
Andrej Karpathy had been exploring something similar, using LLMs to manage knowledge bases stored as markdown, with the LLM doing the writing while you remain the architect. That idea had spread through a community of practitioners sharing their own implementations publicly, and it was that community that reached me first. But the actual shift was simpler than I thought. I stopped asking how to write a better prompt and started asking how to design a team.
The result is what I've come to call, loosely, my "AI team." Alfred is the orchestrator, the one I brief first, who figures out who should handle the work and routes it accordingly. Pam handles requirements and user stories. Elena takes on the architecture. Cal scopes the work and maps out what needs to be built before anyone writes a line of code. Soren writes the code. Miles reviews it, adversarially. The work doesn't flow through the team in sequence. A task goes to whoever it belongs to, and we work through it together.
Each team member has a profile: a markdown file that describes their role, their thinking, their responsibilities. When I need a new member, I don't write that profile myself. The team has its own hiring process, from a research brief to a drafted profile and a final review, and a new member joins when there's a gap. Elena, for instance, joined when I needed a thinking partner for architecture, someone who could pressure-test approaches, weigh trade-offs, and help shape a proposal.
Beyond the members who build, a few others keep the rest of the team running. Finn keeps the records and the team's memory. Nova keeps the writing in my voice. Ritchie researches the field when it is time to hire.
The team also learns as it works. Some of that learning has a fixed rhythm, skills like a daily standup and a weekly retrospective that review how the work is going. But more and more of it happens in the moment. As we move through a task, Finn records what worked and what didn't, so each task starts from what the last one taught us instead of from nothing.
Looking back, what surprised me most wasn't what the setup could do. It was what it revealed about my own work.
My profession hasn't changed. Only how I apply my experience to it has.
The judgment, the taste, the ability to distinguish a fragile pattern from a sound one, the sense of when something is technically correct but architecturally wrong: none of that is automated. It is amplified. The agents reflect my thinking. They make the mistakes I would catch, not the ones I wouldn't. When something goes wrong, I at least know where to look, because I designed the system that produced the result.
I no longer directly write a single line of code, or a technical document, or a Jira ticket. The team does. Doing so would bypass the iteration that makes them better. But every decision about what gets built, and how, and whether this is the right approach at all, is still mine. The profession is intact. The keystrokes are just somewhere else now.
There is still work to do. Context management across sessions is still an open challenge, and one the setup continues to evolve around. The setup grows when I find a gap, and I keep finding gaps.
But the disorientation I felt two years ago has settled into something I recognize. The tools changed faster than I could track. My judgment, accumulated over years of building software, was the one thing that didn't need to keep up. It was the thing the tools were waiting for.