At the crossroads of cleverness and purpose
We should have been looking for practical trades-people, not arcane wizards.
A few weeks ago, for the first time in a while, I coded with only my wits. It was pretty great! Not quick, but educational. Not efficient, but full of that great feeling when challenges are tackled with one's own intelligence and experience. Do recommend.
But I think the era of coding with only our wits, experience, and accumulated knowledge is waning. Let me start with why (as though that wasn't obvious), then speculate on what will succeed it.
The cause of decline
We valued cleverness and skill at solving our own problems rather than solving the human and social problems we were given in the first place. Writ small in technology at first. Writ large in society more recently. Now we find ourselves the antagonists in many of the day’s stories.
Along the way, we tested for tedium instead of the ability to solve problems.
Folks are ruffled that LLMs, even without tool use, are pretty good at coding interview challenges. How will we even know who is good at coding anymore? (Current hypothesis: by collaborating with them as early as possible.)
Friend, I am here to tell you that LLMs and interest rates and higher expectations are not the central problem. The issue is that we were evaluating programmers on speed and competency at the tedious parts of programming. If we ever looked for what makes a programmer effective, it was accidentally. 🫠
The tedium we didn't see
In retrospect, we had mediocre insight into what activities are effective use of a programmer's time. At best, we were using metrics from decades ago, when knowledge of algorithms was rare and solving arcane puzzles was more valuable. The past twenty years of human knowledge accumulation—into reusable libraries, on the web, and then distilled into language models—has obviated much of that work.
That's not even counting all the tedium we didn't realize we created. Generating projects with their dependencies and libraries all lined up just the right way (looking at you, C and JavaScript ecosystems), upgrading those libraries, configuring our development environments, accreting unruly towers of software dependencies that grew an entire industry (e.g., software supply chain management), even the simple task of "commit my work to the correct branch and fix things up when I realize I was on the wrong branch when I committed." 🙃
All of that tedium is required toil for successfully developing software, but none of it contributes to solving problems for people.
For better or worse, we will soon delegate some or all of that tedium to agents that resemble slot machines and human-like intelligence in equal proportions. It may not always go well, but you may not need to remember the order of parameters to assert_equal or the correct way to perform a git rebase either. 📈
Insights
The wrong insight here is that developers will be replaced by LLMs that can quickly implement a linked list—and more, with a savvy human in the loop.
Maybe the 10x developers were really only good at tedium or algorithm tests. 🌶️
A safer insight is that Leetcode and similar schemes were never that great to start with. But they were easier (and perhaps better on average 🤷♂️) than developing a well-considered coding exercise yourself. Silver lining: it's an object lesson that you don't need the best product to succeed in the market.
The best insight: way more of software development is tedium than we previously guessed. And it's within our grasp to automate those bits away. If we can reclaim the parts of our brains that remember arcane shell commands or know how to rebase our way out of a sticky git conundrum, all the better.
How to spend our surplus
A couple ideas for what to do with this development-effort surplus, even if it's temporary:
Prototype more ideas, without the worry that we'll throw away a ton of time.
Build up our "workshops" so that humans and agents can move faster.
Building the workshop
I've been prototyping with llm lately, hoping to build some tools for my workshop and develop an eye toward what's feasible in our wildly changing world of software development.
The "AI space" in general is moving fast enough that, IMHO, the only tool worth committing to is one that maximizes the time spent iterating from data to prompts to results. Choosing a particular language or library is putting the cart before the horse. Better to arrive at a use case that seems to work well with the data, models, and prompts without committing to a technical ecosystem. That's why I think a tool like llm is great. Most of its functionality is about making the journey from "this prompt might work" to "I want to make this prompt + data a repeatable process" smoother.
Combined with ollama, it's easy to do early experiments with smaller models, paying no usage fees. llm makes it very easy to switch between models while holding the data and prompts constant. Some of these models aren't particularly great, but the best among them are fast enough (Mistral) and strong enough (gpt-oss) to glimpse what's possible in the near future.
From workshop to room
A thing about homeownership is that every room is a workshop until it becomes whatever room it's going to be. Every flat surface is in use to keep tools closer to hand or assemble whatever furniture, storage, or infrastructure is currently under construction.
The trope-y version of this is the montage or scene in every parents-to-be movie/show where they’re assembling the nursery, with great struggle. This seems to hold for brand-new homes and old homes alike. Sometimes for rooms you've been using one way for years, and now you want to use them for a different purpose. Or because you suddenly get intensely bored with their current layout.
As goes homes, perhaps goes software products. They start off with a bunch of weakly-held hypotheses about which problems to solve and how to solve them. In these early times, it may feel like you're working in a system that helps you explore problems and solutions quickly, rather than a system that actually solves those problems.
If you’re lucky and persistent, the purpose of the software comes into focus and you work more and more on expanding that solution instead of exploring. That is, the workshop helps you explore until you’re ready to turn it into a room and expand upon its real purpose.
Course change
Testing for the ability to reverse a list or solve a word game never helped us find the people who are really good at exploring the problem space until the purpose of the product comes into focus.
If we are mindful of how we use coding agents, we'll more quickly explore and experiment on turning the workshop into a room. If we revert too much to old ways, we may accidentally build out workshops for the sake of tools instead of making something useful in those workshops.