If your engineers are still writing code, it's time to stop
For most of my time running Web3 Labs and building Enscribe, I largely stayed clear of our codebase and left it to our engineers. I’d give requirements, review direction and make product decisions, alongside my other strategic roles.
I knew touching our codebase was a time sink to avoid.
This boundary has changed somewhat this past month, though, and I think what I’m sharing is especially important if you’re working with engineers in any capacity.
My own inflexion point
Our website isn’t core infrastructure. It’s important, but it’s not the product. So when it needed updating, I’d been handling small tweaks myself — partly to keep the work off my engineers’ plates, partly because it was the one part of the stack I could engage with without causing damage.
The original site was built quickly using v0 by Vercel, then integrated with Docusaurus so we could host docs, blog, and website in one framework without external CMS dependencies.
That integration turned out to be non-trivial. For months, updates that should have been quick weren’t. I was using AI to help, but still working manually through the problems such as prompting for specific fixes, reviewing outputs, debugging things when it didn’t work. The AI was useful, but I seemed to still be doing the work.
A couple of weeks back, after speaking to a friend of mine who highlighted the big changes that have happened in GPT Codex and Claude Opus, I decided to give it a go and I handed the repo to Claude Opus with one instruction: rebuild our landing page based on our documentation and blog posts.
What came back worked. Dark mode, light mode, structured correctly, pulling from our actual content and creating a much better landing page. No debugging was required by me, I preovided my instructions and the work just got done.
That was the first clear signal that something had shifted, not in the model’s raw capability, but in what the interaction could now look like.
The bigger shift: engaging with the product itself
The website result made me curious about what else was possible. The main Enscribe application codebase had always been off-limits for me. It was too complex. In a former life I was a Java backend engineer, not a Typescript developer. Product direction was my job and I left the implementation to the engineers.
But I had a clear vision of where the product needed to go, and I’d been carrying it in my head for over a year without the bandwidth to execute it. So I handed Claude the application repo alongside our documentation and blog posts, described where I wanted the product to go, and let it work.
It scaffolded a new platform experience that reflected the vision I’d been unable to articulate in code. The backend integrations such as authentication, smart contract connections, live infrastructure still needed an engineer to run with them. But the gap between the idea and a working prototype closed in a way it never had before. I could see my ideas materialise and actually put it in front of people.
What changed wasn’t that I became a better engineer. It was that the model understood the intent well enough from the codebase and docs to act on it without me needing to write a line of code.
The conversation I’ve had to have with my team
This changes what I expect from my engineers, and I’ve told them directly: you’re not in the business of writing code anymore. The agents write the code. Your job is direction, judgment, and review.
That’s not a comfortable message. Engineering identity is built around the craft of writing good code. But the honest reality is that the models write working code faster than most engineers, and the value has moved to the person who can direct the agent clearly and review its output critically.
That judgment is more important now, not less. For production backend systems, engineers need to watch the changes closely — the agent doesn’t always take the best approach, and in critical infrastructure the cost of a wrong choice is real. For a marketing website, the tolerance is higher. Knowing which context you’re in, and calibrating accordingly, is itself a skill that takes practice.
The engineers adapting fastest are treating this as a change in what the job is, not a threat to whether the job exists.
My personal belief is that good, productive engineers will become more valuable as businesses wake up to how much they can now get done with their help. Outstanding technical debt and backlog tasks that once took weeks can, in some instances, be cleared with a single well-directed prompt.
What this means if you’re leading a team
The gap between teams that have made this transition and those still working the old way is already measurable and it will widen.
The questions worth sitting with: how much of your engineers’ time goes to work an agent could do? What would change if that time was freed? And who is going to lead that transition in your organisation, because it doesn’t happen without someone pushing it.
I’m a founder who spent years on the wrong side of my own codebase. That constraint is gone. If that’s possible for one person without a dedicated engineering role, the implications for a team with real infrastructure and budget are significant.