The code was never the hard part

For the last six months I’ve been working hands-on with companies trying to put AI to work. Startups, scale-ups, big enterprises. Different sizes, different cultures, the same underlying story. I can see the change happening, I can see how hard people find it to adapt, and I can see the opportunity getting bigger every month as the models get better.

I’ve written about the shape of this before. That most companies are doing AI wrong because they treat it as a tooling problem instead of an organisational one, and that the real move is to organise around AI, not on top of it. This is the practical companion to those two. Less about why, more about what I’ve actually seen inside these companies, and how I’d start if it were up to me.

One line sums up everything I’ve seen: the code was never the hard part. Or it stopped being. Building software is close to solved. The process and the org chart around it are not.

The scale-up: everyone’s waiting for permission

One scale-up I worked with was trying to find a form for its engineering team to work faster with AI, together with designers and PMs. A sensible goal on paper. In practice it ran straight into people.

The engineers were stuck in old ways of thinking. They had access to the best models but didn’t trust them, didn’t push them, didn’t use them anywhere near full capacity.

The PMs and POs were sceptical and, I think, a little afraid. If AI changes how the work gets done, it threatens their position and removes the reason to build a bigger team under them.

The designers were the ones pushing ahead, trying to build directly.

And the CEO was all in on AI personally, building all sorts of things for himself, clearly convinced. But he was afraid to make the structural changes the company actually needed to go all in. He floated a good idea, spin up a small AI-native team on the side and see how far it gets, but never executed on it. Running the existing organisation and a genuinely new way of working at the same time is hard, and it stalled.

The tech was never the blocker. The willingness to change shape was.

The startup: they deleted the roles

A Silicon Valley startup I worked with went the other way. They looked at what AI could do and made a hard call. They let go of their front-end engineers and had product managers push code directly. I came in as a designer to add some guardrails and keep the thing looking on brand. In their eyes they didn’t really need designers anymore either, so they leaned on AI for pretty much everything.

Was it a mess? A bit, honestly. Using AI for all of it meant the result wasn’t perfect. But they seemed to manage, and the intention was right, which is the part that matters. The trajectory is the interesting bit, and the trajectory is what I’d pay attention to. This is a new way of working and thinking, and the rough version of it today tells you where the smooth version is heading.

Boris Cherny, who created Claude Code, put words to it recently when he looked at his own team and saw the old roles melting into something new:

As engineering, product, design, DS and so on melt into a new kind of role, I’ve been reflecting on what roles might look like in the future. Looking at the Claude Code team I see five archetypes.

1. Prototyper: comes up with brand new ideas, most of which don’t ship.
2. Builder: quickly turns a prototype into a production-grade product.
3. Sweeper: cleans up the UI, simplifies the code, unships, optimises performance.
4. Grower: takes a built product and iterates to improve product-market fit.
5. Maintainer: owns a mature system and keeps it secure, reliable and fast as it scales.

Many people span two or three of these, and they aren’t really tied to job function. Some designers match the first, some the second, some the third. Same for engineers, PMs and data scientists.

Maybe that’s where we’re headed. Not designers and engineers and PMs, but people who prototype, build, sweep, grow and maintain, wherever their title happened to start.

The enterprise: it’s already bubbling from within

Inside a large enterprise the picture is different again, and more hopeful than you’d expect. The change isn’t coming from the top. It’s bubbling up from within. A few champions here and there, frustrated with bad tools, endless Excel sheets and development cycles that take forever, quietly taking things into their own hands.

Some start with a simple mockup of a tool they wish they had. Some go a lot further and build fully fledged, specialised tools that replace a mess of spreadsheets or an expensive SaaS subscription like Monday.

There are some guardrails in place, but the ground is still shaky, and you can hear it in how they talk. They build something genuinely useful and then ask, “Can we really do this?” The next instinct is usually to hand it to a traditional dev team to take it properly forward.

That instinct is the wrong one, and it’s worth understanding why.

Development is solved. The org chart isn’t.

The models keep getting dramatically better, faster than almost anyone adjusts for. Fable, Opus, GPT 5.6, Grok 4.5. Whatever you make of any single one, the direction isn’t in doubt. This is the worst AI will ever be. In six months it will be meaningfully better again, and in a year the version you’re nervous about today will look quaint.

So there is no reason to go back to the old way of building. Handing the champion’s working tool to a legacy dev team to rebuild it the traditional way is running in the wrong direction. Building is no longer the hard part. The hard part is the process, the structure and the org chart wrapped around it, all of it designed for a world where building was slow and expensive.

Upskill the people who own the problem

Here’s the shift I’d make. Stop reaching for a big dev team. If you work in marketing, supply chain, logistics or any other domain at a big company, you no longer need a large engineering department to solve your problems. You need one or two domain experts, some time to upskill part of the team, the right mindset and the approval to make some mistakes along the way.

Working with AI is mostly about understanding the problem you’re actually solving, then asking the right questions to get there. Domain experts already do the first part better than any outside developer could. They live with the problem. Give them the tools and a bit of guidance and they’ll out-build a team that has to learn the domain from scratch.

The scarce skill isn’t writing code anymore. It’s knowing which problem is worth solving and being able to describe it clearly.

Start with internal tools

The easiest place to begin, and the highest return, is internal tools. This is where AI is genuinely amazing right now. You can get rid of a pile of confusing Excel sheets and expensive software that never quite did the job in the first place, and replace it with a specialised tool shaped exactly around your business, one that just works. Then you add automation and AI at the right points, where they actually help.

One warning I keep coming back to. Don’t just pave the old path. Before you rebuild a process, ask why each step exists, because half the time it was a workaround for a limitation that no longer applies. Understand the process, redesign it, and automate last, not first. Automating something you don’t understand just makes a bad process run faster.

Workshop, then hackathon

If you want a concrete way to start, this is the one I’d suggest.

Get people together and workshop the problems first. Not the solutions, the problems. What actually slows you down, what’s held together with spreadsheets, what everyone quietly hates.

Then, as a next step, run a hackathon. Define the problems clearly and solve them together, with the right tools, the right structure, the right way of thinking and access to the APIs you need.

You’ll be surprised who shows up and delivers. It won’t always be the people with the senior titles. Some of the best builders in the room will be domain people who never wrote software before and turn out to have exactly the mindset this work rewards. It’s genuinely empowering to watch, and it changes how people see themselves.

Empowering and disruptive

I want to be honest about both sides of this, because it is both.

It’s empowering. When getting a report out of a spreadsheet stops taking two days and becomes a button you press, so the thing is just there, people get real time back for real work. The person who owns a problem can solve it themselves instead of filing a ticket and waiting a quarter. That feels good, and it should.

And the time it frees up is the real prize. When you’re no longer managing piles of Excel sheets, fighting clunky SaaS software that was never built for your job, or turning work into another PowerPoint, you can point that time at harder, more interesting problems instead. Getting rid of the boring, time-consuming tasks isn’t the win in itself. The win is what people do with the hours they get back, which is almost always the work that creates real value.

It’s also disruptive, and pretending otherwise helps no one. It can mean dissolving a big dev department that was mostly maintaining legacy structure. It can mean freeing up so much time that, over the long run, you need fewer people. Or different people, because some will find the new way of working hard to adapt to, and not everyone will make the jump. That is real, and the people it affects deserve honesty, time and proper support, not to be treated as a cost line.

But the direction is set. The companies and the people who lean into this, who upskill the domain experts, start with internal tools and let the right people build, will pull away from the ones still waiting for permission. The code was never the hard part. Everything around it is, and that’s exactly where the opportunity is now.