Rise of the Grey Developer

There's a moment — and if you've experienced it, you'll know exactly what I'm talking about — where you look at something you've just built and think: wait... I just did that?

Not a slide deck. Not a strategy document. Not a requirements spec that'll get interpreted three times before anyone writes a line of code. An actual, working thing. Something that does what you intended it to do. Something you can point at and say: that works, and I made it.

I'm not a developer. Or at least, I wasn't. I'm not sure what I am now. But I know this: something fundamental has shifted, and I don't think most organisations have even begun to understand what it means.

The Old World

For years — decades, if I'm honest — I've been the person who understood the problem. I could see the inefficiency, map the workflow, articulate exactly what needed to change. I knew what needed to be built. I just couldn't build it myself.

I work as an individual contributor. There's no development team down the hall to hand a brief to. No sprint backlog to add my idea to. It's just me, my experience, and whatever tools I can get my hands on. For a long time, that meant I could see solutions everywhere but deliver almost none of them. The gap between understanding a problem and being able to solve it was enormous, and I was permanently stuck on the wrong side of it.

I'd sketch things out. Prototype in spreadsheets. Cobble together workarounds that got the job done but never quite the way I knew it should be done. The ideas were good. The execution was limited by what one person, working alone, could realistically achieve.

The Returning Builder

Here's the thing that makes my story slightly different from someone picking up code for the first time: I used to build things. Years ago, I was hands-on, I led a team of software engineers and testers. I understood systems from the inside — not at an abstract level but at the level of actually making them work. I thought in logic, in processes, in cause and effect.

But then the career happened. The promotions. The drift upward into management, into strategy, into the world of influencing outcomes through other people. Nobody tells you when it's happening, but slowly, the tools move on without you. The languages change. The frameworks multiply. The gap between what you once knew and what you'd need to know to be useful widens until it feels uncrossable.

The understanding never left, though. The way of thinking, the instinct for how systems should behave, the ability to see a problem and mentally architect a solution — all of that stayed. It just had nowhere to go. It calcified into architecture diagrams and strategy decks.

What AI did wasn't teach me something new. It reconnected me with something I'd lost. It's not learning. It's remembering.

The Shift

It didn't happen in a single moment. It crept up. I was using AI tools for writing, for research, for the kinds of tasks everyone was using them for. And then one day I asked it to help me with something more ambitious — a small automation, a workflow, something I could see clearly in my head but couldn't have coded myself. And it worked.

That first time felt like a fluke. The second time felt like a coincidence. By the third or fourth time, I started to realise this wasn't a parlour trick. I was building things. Real things. Things that solved real problems.

The feedback loop was intoxicating. For years, my "output" had been limited by what I could achieve alone with conventional tools — spreadsheets, workarounds, duct-tape solutions. Suddenly I was making real software and watching it work. The loop tightened from days to minutes. I could see the direct result of my thinking, immediately, without compromise.

Honestly? It felt great to feel productive again. Not productive in the corporate sense of having contributed to a decision or influenced a direction. Productive in the way that actually matters to a human being: I built a thing and it works.

Experience is the Hard Part

There's a narrative taking hold right now that AI is coming for the developers. That code is being commoditised. That engineering teams should be worried.

I think that narrative is backwards. Or at least, it's missing the real story.

The real unlock isn't AI replacing people who can code. It's AI enabling people who can think. People who understand systems, workflows, organisations, and problems — but who were locked out of building solutions because they didn't speak the right programming language.

Code was always just the implementation layer. The hard part was never writing a function or structuring a database. The hard part was knowing what needed to exist in the first place. Understanding the messy, human, political, practical reality of how work actually gets done — not how an org chart says it should get done, but how it actually gets done. That knowledge lives in the heads of experienced people who've been doing the work for years, and no amount of technical skill can substitute for it.

AI doesn't replace that understanding. It amplifies it. It takes the person who's been saying "someone should build this" for fifteen years and turns them into the person who builds it before lunch.

The Grey Zone

So what am I now? I'm not a developer — not in any traditional sense. I couldn't pass a coding interview. I couldn't explain Big O notation without looking it up. I don't think in algorithms.

But I build things that work. I solve problems with software. I ship.

I'm something in between. Something that didn't really have a name until now. A grey developer. Grey as in the hair — the experience, the years, the mileage. Grey as in the grey area between developer and non-developer, between IT and business, between the people who build and the people who know what needs building. And grey as in the grey matter — because it turns out that what you know matters more than what you can type.

There are more of us than you'd think. And there are about to be a lot more.

What It Does to You

I won't pretend it's all smooth sailing. There's an impostor syndrome that comes with it — a nagging voice that says this doesn't count, that you're cheating somehow, that a "real" developer would do it differently, better, properly.

But underneath that, there's something more powerful: I have a team now. Not a team of people — a team of capability. AI fills the gaps in my skillset in real time, the same way a good colleague would. I think through the problem, I know what needs to exist, and now I have a collaborator that can help me get it from concept to reality. For the first time, being an individual contributor doesn't mean being limited to what one person can do alone.

That does something to you. It changes how you show up. It changes your energy, your engagement, your sense of relevance. After years of feeling like the person who has ideas but can't execute, suddenly you're executing. The satisfaction is almost physical.

And there's a compounding effect. Each thing you build gives you confidence to try the next thing. Each success expands the boundary of what you think is possible. You start looking at problems differently — not "someone should fix this" but "I could probably fix this by Thursday."

What It Does to the People Around You

When the person who understands the problem can also build the solution, something changes in how they're perceived. You stop being the person with ideas and start being the person who delivers. That shift ripples outward.

Colleagues who used to nod politely at your suggestions start paying closer attention when you can show them a working prototype instead of a slide deck. Conversations move faster because you're not describing what could exist — you're demonstrating what does exist. The gap between concept and reality collapses, and that changes the dynamic in every room you're in.

For other individual contributors watching this happen, there's an obvious question: could I do that too? And for many of them — especially the experienced ones who've been quietly frustrated by the same limitations — the answer is yes. One grey developer in an organisation is interesting. A dozen of them is a movement.

What It Means for Organisations

Zoom out from my own experience, and the implications are significant. Every organisation has a long tail of problems — small inefficiencies, broken workflows, manual processes — that were never quite important enough to make it onto the IT roadmap. They sit in a permanent backlog, costing time and energy every day, because the people closest to them can't fix them and the people who could fix them don't know they exist.

Grey developers start solving those problems. Not the big platform migrations or the critical infrastructure work — that's still the domain of professional engineering teams. But the hundred small things that fall between the cracks. The spreadsheet that should be a tool. The manual process that should be automated. The report that takes half a day to compile that could take ten minutes.

And there's a deeper strategic value here too. Institutional knowledge — the kind that lives in experienced people's heads and slowly walks out the door when they retire — starts getting encoded into actual systems. The person who's been running a process for twenty years doesn't just describe it for a knowledge management document that nobody reads. They build the thing that captures it.

The Risks

None of this is without risk, and pretending otherwise would undermine the argument. There are real challenges that organisations need to confront.

The most obvious is ungoverned proliferation. If experienced people start building tools and automations without oversight — whether inside organisations or as independent operators — you get a sprawl of solutions with no code review, no security assessment, and no documentation. The thing that works brilliantly today becomes a liability when it needs maintaining, updating, or handing over to someone else.

Then there's the sustainability question. A grey developer builds something that solves a problem beautifully. Then they move on. Or step back. Who maintains it? Who fixes it when it breaks? Who even knows how it works? When you're a team of one — even with AI as your collaborator — there's no institutional memory beyond your own.

Quality and safety are genuine concerns too. Understanding the problem deeply doesn't automatically mean understanding error handling, edge cases, data protection, or the dozen other things that professional software engineering practices exist to address. Knowing enough to build something is not the same as knowing enough to build something safely.

And within organisations, there's a human dimension. IT teams may feel bypassed. Professional developers may feel devalued. Governance teams will — rightly — have concerns. These aren't irrational reactions. They're legitimate responses to a genuine shift in who gets to build, and they need to be addressed with respect rather than dismissed.

Perhaps the subtlest risk is the confidence gap: knowing enough to be dangerous but not enough to know what you don't know. The grey developer who builds a tool handling sensitive data without understanding encryption. The automation that works perfectly until it encounters an edge case that corrupts a database. Enthusiasm without guardrails can cause real damage.

The Path Forward

The answer to these risks isn't to dismiss what's happening or pretend it isn't real. Grey developers need to be honest with themselves about what they don't know — and proactive about filling those gaps. Seeking out code review, learning about security basics, documenting what you build, thinking about what happens when you're not around to maintain it. The capability AI gives you is real, but so is the responsibility that comes with it.

For organisations, the answer isn't to lock the door. It's to create space for grey developers to build while providing the guardrails that matter — access to review, security guidance, architectural oversight. Not as a bureaucratic hurdle but as a genuine support structure. The organisations that figure this out will move faster, solve more problems, and retain more institutional knowledge than those that try to maintain the old boundaries.

This Isn't Vibe Coding

There's a term floating around — "vibe coding" — that captures some of what's happening but misses the point entirely. Vibe coding implies something casual, almost accidental. Someone messing about with AI and stumbling into working software.

What I'm describing is something different. It's what happens when decades of experience — real, hard-won, battle-tested understanding of how things work and why they break — meets a new kind of capability. It's not accidental. It's not casual. It's the long-overdue unlocking of people who always had the most important ingredient and were just missing the last mile of execution.

The grey developers are coming. Some of us are already here. And we're not replacing anyone — we're filling a gap that's existed for as long as software has been written by people who didn't understand the problem it was supposed to solve.

The future of building isn't just about who can code. It's about who understands why.