A senior engineer plus AI
What one person with two decades of shipping can now own — and what hasn't changed.
For most of my career, shipping a serious piece of software meant a team. Frontend, backend, infrastructure, QA, designer, project manager, sometimes a data person. Two years ago I still believed this. Today I don’t.
The thing that changed is obvious. Modern AI — Claude, mostly, in my case — has collapsed a huge amount of the work that used to fall across three or four roles. I write less boilerplate. I search my own codebase with a paragraph instead of grep. I translate between stacks without actually knowing the new stack fluently. I hunt regressions by asking for a hypothesis and then checking it.
The result, in practice: the shape of what one engineer can own has changed — end to end. Design, build, ship, maintain, support. Work that genuinely did need a team two years ago can now, sometimes, be owned by one person with the right tools and the discipline to use them carefully.
What this is not
It is not “AI replaces engineers.” AI does not ship software. It helps one engineer ship much more software. The engineer is still the one making decisions, deciding what’s worth building, catching the subtle bug in the generated diff, explaining to the client why the thing they asked for is not the thing they need. Judgement is what you bring. Leverage is what AI is.
It is also not “one engineer can do everything.” I am still one person. I can’t beat a good team on scale, on resilience when someone is sick, on the thousand small specializations that mature companies need. The claim is narrower: for a well-scoped problem, one senior engineer with AI can now produce what a five-person team produced two years ago. That’s a different statement. It’s also true.
Why this doesn’t feel new to me
My university degree was in intelligent decision-making systems — neural networks, optimization, adaptive control — and I wrote my first adaptive algorithm around 2004. For twenty years that education felt like a curiosity. The internet rewarded me for shipping PHP and React, not for gradient descent.
Then in the last three years it started to matter again, in a way I hadn’t expected. Not because I’m training models from scratch — I’m not — but because I recognize what the tools are doing and what they can’t. I know when Claude is confidently wrong. I know which failure modes are inherent and which are prompt problems. I don’t get surprised by the things that surprise most engineers who only met AI in 2023.
That background is quiet. It doesn’t show on a CV as loudly as twenty years of React. But it’s the reason I reach for AI the way I reach for a compiler — as a tool I respect, not an oracle I beg.
What I think changed, structurally
Three specific shifts, which together explain why a single operator is now viable where they weren’t:
- The context window won. An LLM that can hold a whole codebase in its head removes the need for a second engineer who “knows this file.” That was a huge, invisible drag on solo work.
- The review loop closed. I can generate, critique, and revise within the same session without waiting on a colleague. That was a real bottleneck, not a manufactured one.
- The cost collapsed. The same capability that cost an engineer-day in 2023 costs a few cents in 2026. Economics flip when costs fall two orders of magnitude.
What Cybind is built on
Cybind — the studio this site belongs to — is simply me placing a bet that this shift is real and durable. I am not hiring to grow. I am not raising. I am operating as a single senior engineer with AI as permanent leverage, earning from consulting today and investing in products for tomorrow.
If you’re a team that used to need three engineers to ship a well-scoped problem, and now you need one senior engineer with real AI fluency — that’s what Cybind is. If you’re building something where twenty years of production discipline plus modern AI could help, I’d like to hear.