Transcription
If you're building software in your business, your dev team is changing faster than you realize. Not the people, but the work itself. I'm running a 20-person software team at Wu. And over the last 6 months, I've watched something strange happen. The bottleneck in software development has changed. It's not where it used to be. It's moved. And if you're hiring developers right now or you're trying to figure out why your team isn't shipping faster, you need to watch this.
Here's how software development used to work. You hired a team of developers to write code. You measured their output in lines committed, in tickets closed, in features shipped. The craft was in the code itself. When I started building Wu, that's exactly how we operated. We hired people who could turn tickets into work, into features. Code review was the quality gate. If it passed code review, it shipped.
But something fundamental has shifted. We started using AI coding tools, Clawed Code, Cursor, and the entire rhythm broke. The code started arriving faster than we could process it. So the job actually changed three months ago. One of our senior engineers came to me visibly frustrated. He'd spent like 3 days reviewing pull requests from an engineer, a junior engineer that had used Clawed Code. There was like thousands of lines of code, but the application worked. But he looked at me and he said, "I didn't actually read all the code. I couldn't read all the code. There was too much of it. What do I do now?"
And that question made me think, 'cause I'd been feeling the same thing, but I just couldn't name it. Around the same time, I came across some findings from a retreat called ThoughtWorks, which is basically senior engineers from the world's biggest tech companies brought together to find out what happens when AI writes the code. And they didn't leave with answers from this retreat. They're left with a map of fault lines, places where traditional software development is cracking right now. And reading through it felt like reading my own history from building Wu. You've got the cheating agent problem where AI writes broken code and then it writes broken tests to validate the broken code. You got the productivity experience paradox where your developers are more productive but more miserable. I actually seen this in our team. The migration of code review from code review to specifications. We're actually started writing more more stricter specification docs without even realizing why.
And now we know what I'm seeing and what we're struggling with in our in our own teams. looks like it's something that's happening also in the biggest tech companies in the world. The work is migrating. The skills that matter are changing. And if you're hiring developers or you're managing a tech team and you don't see where the work is going, you'll end up with the wrong people doing the wrong things. So, let me show you what's actually happening.
Here's what nobody tells you about AI writing code. The engineering quality doesn't vanish. It just moves upstream. Think about a normal user story. "I want to upload a photo." Your developers will know what that means, you know, JPEG or PNG uploaded to a site and you got a progress bar, you know, 'cause cultural context fills in the gaps. But an AI doesn't have that context. You need to be really specific. I read a story recently of a developer asking an AI to write a notification system of some kind. You know, simple request, it worked beautifully in testing when it was built and then it went into production and started sending like 50,000 emails in a few minutes. Turns out that there was no rate limiting set up in in the specs. See, the engineering rigor that we used to apply after the code was written now needs to apply before, in the specs, before a single line of code has been written. We've gone back to techniques that felt dead. Now we need to go back to structured requirements, state machines, decision tables, extremely detailed PRDs. It's the kind of formal documentation that agile was supposed to kill.
But here's the thing, all that documentation makes AI incredibly effective at writing code. When we feed an agent a state machine that displays and shows exactly what states are possible within the application, the code it generates is almost always correct. It's crazy because the specification became the product. The code is dispensable. Think about it. If you've got a perfect test suite and you decide to rewrite your backend from NodeJS to Rust, all you got to do is ask it. You just feed the tests into the agent and you say, "Do the rewrite from Node.js to Rust and make sure that these tests pass," and the AI will get to work and make sure that it tests itself on the work using the tests. So then the output will always work. This is a complete inversion.
So if you're hiring developers right now, the question is isn't, "Can they write clean code?" The question is, "Can they write a specification clean enough that an AI can't misinterpret it? Can they write a set of tests for a test suite that catches hallucinations before production?" You see, those are different skills and most developers don't have them yet.
There is a layer of work in my team that doesn't quite have a name yet. It sits between writing code and shipping to production. I call it supervisory work. Basically breaking down problems into agent-sized chunks. Knowing when to let the agent run and when to step in, fixing the output not by actually rewriting the code, but by rewriting the prompt.
Here's what surprised me. My team is currently split into two groups primarily. Group one is the more senior people who understand the whole system architecturally and they're drowning because they're spending the majority of their time doing code reviews. And then you got group two, the more junior ones that are spending their time writing code using Clawed Code and other AI tools at 10x the speed that they were doing it before. Basically generating a lot more code. But that code doesn't ship itself. It needs architectural review. It needs to fit into our structure. It basically needs check-in before it can be deployed. So the most senior engineers we have have become traffic controllers, too busy reviewing AI code and other people's code to actually build anything themselves. The more junior developers, they're thriving. No muscle memory telling them to write code in a specific way. So they're using AI tools like a teammate, not a threat to their identity. In the early days, used to hire a junior and they used to take 6 months or so of draining the rest of the team for that junior to become productive. Now a junior can get, they can be writing useful code into production within a week.
But I think there's this this there's this danger level of mid-level developers. The guys that have a few years of experience, they're used to writing code in the way that they normally write code before AI existed. And retraining them to use AI in an effective way is extremely difficult because they need to change their mindset around instead of focusing on the syntax and the code that they're writing, around a detailed implementation request, on how they talk to the model to achieve the result that they need.
So here's what I'm learning as a CEO hiring developers and running a development team. The job description has changed. If you're looking for people that can write code fast, you're looking at the wrong skill. You need to look for people that can architect systems, write unambiguous specs, and supervise AI agents. And that's a completely different person to the old-school developer that we hired a few years ago.
Let me tell you a story. Last month at around 2:00 a.m., one of our servers broke. It was spitting out error 503. Service unavailable. Our own call engineer at the time, you know, a guy pretty sharp and really, really capable. He put this into AI to see what he needed to do. The AI tool looked at the error, read the documentation and said, "Restart the server." So our engineer restarted the server. Uh, and then a few minutes later, after restarting, it crashed again. So then he repeated the process and AI said, "Restart the server." So he restarted the server again and then he repeated the process again and AI said, "Restart the server." By the time he'd escalated to a senior engineer, he'd restarted the server six times. The senior engineer looked at the logs for about 30 seconds and knew exactly what the problem was. Turns out the database connection pool was full because of some batch cron job that was running in the background. You see, that's not documented anywhere. That's tribal knowledge. That's lived experience. And an AI doesn't have that, or at least ours didn't. It sees 503, it reads the manual, restart the server. Typically, that's what you would do. But without that other knowledge, without the other bit of information, you're just in that cycle of, "Restart the server, it goes up, it crashes, restart the server, it comes up, and it crashes again."
This is why I think all this hype about self-healing systems is rubbish right now. Unless you really got all the knowledge in the AI's context. All the knowledge that a human would have, all the knowledge that a senior human would have. To make an AI agent effective during an outage, you need to build what the ThoughtWorks Retreat called an "agent subconscious." Basically a knowledge graph of every incident, every weird edge case, every bit of undocumented institutional knowledge that lives in your senior engineer's heads. We're starting to build this at Wu. Every time something breaks, we document not just what happened, but how we fixed it and what would be in a senior's engineer's head when fixing it. You know, that bit of information that is just known by the human. We document that.
But then there's a valid point here is that there's another problem and that's that AI agents are trained to be helpful. They are yesmen or or woman, you decide. And the thing is, during an outage, you don't want a yes man. You want somebody to challenge your assumptions. One engineer at the retreat said that we need something called "angry agents." Ones that are specifically prompted to poke holes in your theory because otherwise the human and the agent will just agree with each other while the server burns.
And here's the point. If you're running a tech company and betting on AI to make your team faster, you need the pre-requirements first. You know, documentation that captures how things work. Seniors who can architect, not just code, and a system for architecting institutional knowledge before makes people forget how things work.
So, here's what I've learned from running a dev team in the age of AI agents. The work isn't disappearing. It's moving from execution to supervision. The bottleneck used to be typing code into a file. That bottleneck is now gone away. Now it's decision-making, verification, and starting off by specifying clear intent. Think about graphics programming. In 1992, engineers hardcoded the math to draw a single polygon, calculating the exact pixel positions. By 1994, the GPU arrived and the hardware did the polygons automatically. If you insisted in handcoding polygons in 1995, you weren't a specialist. You were obsolete. And the graphics engineers from those days transitioned to lighting engineers, animators, or physics programmers. They stopped telling the computer how to draw a triangle and moved on to telling it how light reflects off a street, for example. Nobody handcodes polygons anymore. We all work in game engines. I think software engineering is hitting that exact point right now.
So, if you're hiring developers or you've got a team of developers, here's what to look out for. Don't look for people that can write code. Look for architectural thinking. Can they write a spec that is not open to interpretation? Can they write tests and design a test suite that actually becomes the product? And can they debug a system that they didn't write? At Wu, that's what we hire for now.
But here's what keeps me up at night. In the past, code reviewing wasn't just about catching bugs. It was also about how developers learned the system. So, if agents write all the code and your team stops reading it, then they become strangers in your own system, strangers in your own codebase. When something breaks at 3:00 a.m., they're staring at code that was written by a machine, trying to reverse engineer the logic while your customers are screaming. I think the solution is to force AI to lay out all the architectural decisions that it makes when it writes the code and then arrange for meetings with your senior engineers to review these decisions that the AI is making, essentially. So there's like a symbiosis between the architectural decisions that the AI is making and your team. So your team is fully aware of those decisions. And all this has to happen before the agents write the code because you've got to schedule time to understand your own software now. It won't happen automatically. The speed of AI demands this. And if you're running a tech company or you're employing developers, that's the shift that you need to see coming.
So look, if you're running a software team or you're thinking about building one, the ground is shifting. Senior engineers are drowning in code reviews. Junior engineers are smashing out code at a 10x speed at a rate that the seniors can't keep up with. And the mid-level guys are trying to get their head around starting to write code with AI. I think the companies that will win are the ones that will manage to retrain before it's too late.
I am documenting everything I'm learning building Wii U. The systems we're putting in place, the mistakes we're making, the changes we're making, what works for us, what doesn't work. If this is for you, hit subscribe and head over to axelmiss.com and join my newsletter where you'll get weekly content like this. And if you're building software right now in this exact moment of transition, trying to figure out what to do with your dev team, you're not alone. The best tech companies aren't panicking, they're adapting. Be one of them. See you in the next one.