Over the past 5 months, I’ve delivered 8 workshops, 17 sessions, one podcast, and participated in more discussions about AI and its capabilities than I can count. Most of those included some talk around how we should approach this AI power marching into our offices – and I won’t say here “AI power taking our jobs” because that’s so totally not what I want to talk about or what I fear in any way. Want the lousy part of my job? Have at it!
Yesterday waldo posted the “the waldo way” blog post where he touches on a clash of two stream of thoughts: one group of people says we should build my-way-or-highway scaffolding that every developer in the company uses; another group says we should empower every developer to build their own scaffolding and use it to being a far more efficient version of themselves.
I think the dichotomy isn’t really that – there are more than two distinct points here. It’s a continuum of possibilities between the two distinct ends. My personal position is far, far to the left side of this continuum, where I believe we are far, far better off building code-printing machines and then make everybody in the company use them, than to let everyone build their own code-printing machine and use that one. I said that – without fear, but not without pushback – at stages of Directions ASIA back and Days of Knowledge Central back in May, and I’ll say it every time this discussion is being held, until it’s no longer a discussion. And that will be soon, I’m sure.
The reason why I believe that is the same reason as we would never assign the most complex engineering tasks to just about anybody in the company who happens to have a pair of spare hands at the disposal at the particular moment that task appears. The most complex, most critical tasks get assigned to the best, top engineers we have, because we want those engineers’ judgement, capabilities, skills, mindsets, everything – for that particular super critical task.
No company has 20 developers or 100 developers because they need 20 or 100 genuinely different opinions or ways of building software. They have 20 or 100 of them because there is work for 20 or 100 of them. When there is no work, they downsize. When there is more work, they hire. Simple.
Also, I don’t know a single company who would say: we want more mediocre engineers. Everyone would prefer having 100 of those top-minded, best-judgement, most capable ones so they could really assign any task to every engineer who just happens to be most available at the moment.
Now we have machines that can do (most of) engineering for us. But it doesn’t just do it. It’s a wild beast that may happen to do it right (in fact it’s getting better and better at doing it right right off the bat), but it also may happen that it produces junk at cosmic scale. It needs constraints. It needs guidance. It needs the scaffolding (some say harness, call it what you want, we are still building terminology for this, so potato-potahto).
Scaffolding I use for my project is usually so tight that I dare ending most of my requests with “when you are done, commit and push” knowing that it will hit the CD pipeline and end up right in production. Some will say this is reckless. The moment they see (and understand) the scaffolding I built, they not just agree – they want that scaffolding. And funny enough – it’s not me who is the only “reckless” or “crazy” guy who does that. The entire SDD thing is built around this concept: let the agents build your software. The best thing you can do there is just get the f** out of the way.
But here’s the thing: you get out of the way of constructing. You stay very much in charge of designing.
Design is an onion. It has a million layers. Inner parts of it are also now being chewed-on by the machine. Give the machine enough time, it’ll eat most of the layers, but that’s also not the point. The point is that for a (considerable) while the outermost layers are ours to eat.
Now one thing that most of conversations I had missed is why I believe we are all far better-off just building the one code-priting machine than letting everyone build their own, is because while it turns most of our developers into machine operators, it also liberates us all for something we never had time or budget to do in the past: experiment.
We can now generate new ideas, brainstorm, and then build all of them! In the past we took a path, walked that path for three months, figured “heck, wrong way”, and then – due to a lot more than just sunken cost fallacy – we kept pushing on. Simply because we felt (and were probably right) that it was much better to try improving the not-the-best solution than to throw it all out the window and try again.
Now we can do that. On an unimaginable scale. We can try fifty different ideas at the historic cost of trying one. As Boris Cherny said in one of his recent pieces, most of our ideas will never see production. But that’s the point. The best ones will. And not just the best ones – the right ones.
Want to empower your developers? Build the perfect code-printing machine for them, and let them go crazy experimenting.
