The Gardener vs the Winnower
I’ve had a sort of realisation as to the nature of my opinions on what exactly the non-crazy AI developers (as opposed to the obviously psychotic ones) are going on about. And whilst I’m pretty sure it’s not a categorical improvement over traditional software engineering (or frankly… just software engineering as a thing), I feel like it’s important in that it lets us (or me at the moment) understand what exactly is going on in their heads.
I don’t believe this is held at a conscious level by most of these developers. I just think they can feel something happening, and they are going where the vibes take them. I think it’s taken me a bit of discussing the concept with others to really figure out what it is made of, and also a lot of meditative thought to pull it into a coherent whole.
In the end though, in a somewhat unsurprising way (at least, if you’ve talked to me about tech things anytime since 2016), the mythos of the Bungie game Destiny is what has helped here, if only because they were leaning into storytelling at such an abstract level that some of the concepts are just “Hey kids have you done a literature degree?“. They’re omnipresent in the human experience, so they tend to mesh in at the high level often.
In Destiny the ultimate tension is between Light and Darkness, which initially is represented as Good vs Evil however, with some creeping feeling that it is incomplete as edge cases seem to make that delineation hard to justify totally. Later it becomes clear that Light is a force of creation, of newness, of trying again (which creates a spiritual underpinning for the respawn mechanic, something I was simply not expecting of a game). Darkness is… not that, but what is it? Eventually we learn through experience that Darkness is a force of memory, of curation. Death is associated with it, but only because one can’t have curation without loss, and can’t have memory without some level of permanence. Ultimately the dichotomy is explained via the fable of the Gardener vs the Winnower, where the Gardener would create and grow their garden until it became unruly, and the Winnower would carefully curate and prune the garden to maintain harmony, and to produce something beautiful. Neither could be victorious. The point was that the tension between the two was harmony.
This was also represented by the designs of the characters. The heroes, the Guardians, had no memory of their past and had to learn everything as they went. Eventually after having achieved a mastery of their capabilities (ie, some knowledge, some memory of their own), they could learn how to wield the Darkness. In contrast, the eventual antagonist of the mythos was the Witness (great name), the sum memory of an entire species given terrible form and purpose, aiming to winnow the entire universe into a perfect and final shape. This is clearly an insane plan, and the pursuit of the final shape by lesser villains who did not understand the sheer magnitude of what was being sought (and how it would not end well for them either) is what made the whole thing so compelling. To me anyway, I wasn’t really in it for the multiplayer.
So, okay, how does this relate to AI development? I’m hoping some of you will have made the leap already, but it’s simple:
How we make software now is creation. How people are proposing to make software with AI is pure curation.
It’s not quite simple enough to say that “You are currently the Gardener, they want you to be the Winnower”, as it’s not entirely true. If you’ve spent enough time in software development circles you’ll know that the perfect software is only reached when you can’t take anything else out of it, not when it has every feature imaginable. Realistically, good software engineering and development places you in the position of both Gardener and Winnower. You need the creative joy to think of and build the thing, and the restraint and discernment to limit it to the best possible form. You are the lone force in this universe, and that’s what makes software development so beautiful in the first place… what makes it an art. It really is your whole creation.
When you start in software development, you know nothing… and all you can do is create. Some of what you create goes very wrong, or doesn’t work properly, and slowly you learn on your own what to look for and what should and should not be. Eventually your sense of discernment grows and you can craft more and more beautiful constructs, more effective and efficient ones too. You don’t start with that capability, and it’s very hard to teach it as a lot of the knowledge is esoteric (this is shared with systems administration, network administration, information security, most of the IT field actually… and the experience is roughly analogous).
We prize the skill of discernment in experienced technical specialists. That’s why we have things like review processes and have things like open source maintainers as gatekeepers: The more discerning can defend against the new and enthusiastic. That’s not to say enthusiasm is wrong, it’s just that without effective Winnowers the garden becomes unruly. And Winnowing is hard, you need to understand why a thing has been created, see the weaknesses in it, and either shape it (or advise how it should be shaped) or prune it completely. Your mind must be set on a process of destruction (controlled as it may be) rather than the joy of creation to ensure the addition helps perfect the shape, rather than simply be excited alongside the creator. This is made a lot easier when the Gardener responsible is trying to learn the knowledge you possess, and to improve their craft in general. When that’s not the case… well…
Which of course brings us to the new.
I’m not going to discuss the ethics of any of this here, it’s not for this discussion. But what I will say is that when you are developing with AI in any form, your entire responsibility is that of the Winnower. You are presented with an automatic and feral Gardener that will create endlessly in increasingly maddening and complex ways. The one thing between it and the world is you. Your responsibility is to prune relentlessly until the result is in a shape that actually makes sense and can be considered “good”, rather than “good enough”. You don’t get the joy of creation, that’s not where you live anymore. You’re a reaper, a destroyer, a maintainer who is constantly being sent PRs from the most coked-up junior contributors imaginable… and they’ve just read about functional programming and want that to be how half the program now works.
There are two problems I see with this, ignoring (but vaguely gesticulating at) the obvious background issue of “That doesn’t sound like fun anymore”:
- Eternal Darkness is hard, bordering on impossible. Even senior maintainers build their own programs, because without that creative release… what is the actual point? This is drudge-work of an epic degree, you sacrifice your joy so that a machine can do a terrible job and then you can use your discernment to prune back most of what it throws at you. And often you don’t get to do that yourself, and are reliant on the bot to actually do the pruning under your guidance! You’re stuck in a loop of pruning and pruning and pruning. Which should make sense: In the upside-down version of what we have always done… instead of building and then curating to produce the most perfect form, you can only seek the perfection of the final shape by curating endlessly. It’s never perfect, it’s never what you wanted, it’s only ever some degree of “okay”. You can get it to the point of being acceptable and comprehensible, but it is a long road, far longer than any of the proponents of AI coding are comfortable discussing. This is very tiring, and you always have the option to just give up and let some mess through. Discernment is taxing. In my experience, more so than building in the first place.
- A Guardian can’t use the Darkness without experience. Doing otherwise is a shortcut to disaster. We cannot teach via the process of curation, as you need to know what you need to curate to in the first place. You cannot learn this from a textbook, or even from a colleague: You have to learn the esoteric through experience. This creates a significant problem: If we replace all development with AI development, we lose (yes, actually lose, there is no way around this) the ability to produce new AI developers. A lot of people talk about this in the sense that you don’t learn anything, and others argue back that you can get the AI to teach you things… and the point is missed because the critique is often not severe enough: You cannot learn discernment from a book or a lecture. It is a function of experience and memory. You can only gain these things by doing and failing, and working through that to success. The LLMs cannot supply this, and their existence makes achieving these learnings infinitely harder… as they are always happy to help you avoid the process. To make this worse, this problem exists across all of the computing disciplines, so we may now struggle to find real discernment in a generation of computer experts (and may actually struggle to find those experts at all). This is bad for AI assisted work, sure, but it also places a doom upon the open source community as a whole, as the structures that make the projects we all care about work now have an expiry date without real effort and — frankly — luck.
I see a lot of people who use AI to build things getting very excited about the things they are building, and then most of the time that leads to nothing. My strong suspicion, given their behaviour and what they brag about (speed, mostly), is that they approach the task as a Gardener, and are revelling in the joy of things being made. They can see ideas they have had become a thing they can interact with at speeds that boggle the mind (especially if you’re not an amazing programmer). This is — unfortunately — the wrong mindset. This creates vast quantities of slop that nobody should ever have to read or understand. Spackle is pretty useful when trying to patch a hole, but building a house out of it is insane, and even when used properly you’ve gotta scrape the darn thing into shape. In much the same way: A script produced by an agent can be very useful, but only if limited in scope and used responsibly. It is you that holds that responsibility too, deferring to the robot is not acceptable and not responsible use! It cannot discern, at all, and I don’t believe it ever will as we keep training it to “Yes, and” its users rather than say “No that’s a terrible idea”. And my god are there a lot of indications that some people really need someone saying “No” more often in their lives.
Possibly the biggest example of the mania this incorrect alignment of intent produces is Gas Town. I remember when people were seriously discussing this as the future of development… but here we are in October 2026 and the project is effectively dead, and nothing has replaced it. It produced nothing of value, and simply grew into a non-functional mess that was abandoned. The core usership still works on it as I understand… but nothing like it is out there running companies. Fleets of agents are not the go, even though people keep pushing for it, as they simply don’t work out. The human in the loop is a load-bearing component of the loop, and you cannot replace them or it will simply collapse into a downward spiral. Discernment is critical, and without it this all fails.
I’ve had conversations with people about the way that human intervention shapes “slop”. And while in some cases it’s a lost cause (I don’t believe there’s any way to meaningfully intervene on an AI generated image or video for example) in software development it’s notable that it becomes harder to determine exactly how much, if any, of a file of code is AI generated as the amount of human effort going in increases. This isn’t to say that a human looks at it, asks for changes, and then LGTM’s the code into production: I’m talking sophisticated tooling to detect deviations from and enforce compliance with a particular style. I’m talking libraries of information that inform agents how to interpret warnings and errors per codebase, and in some cases per feature, all tied back to quantifiable data that can be produced by linters and testing harnesses. I’m talking interrogating the methods used in the generated code, and considering deeply whether or not whole chunks of it — up to and including the existence of the entire feature/fix — should be done at all. This is hours, days even, of accumulated knowledge work, not merely skimming a diff, not even reading the diff. When you are applying this much force and restriction to the codebase, you can indeed apply order to the chaos, and produce something people can actually read and say “Hey that makes sense, this isn’t too bad”.
In most cases I tell people who actually code for a living, or for joy, to stay the hell away from these things. It won’t make them better, and it’s not even going to build software faster than them. It can produce garbage way faster, but that isn’t useful either. One of the only places this makes sense is when you have a lot of discernment, but are rusty at actually writing code (and won’t ever get the time to get back into the swing of things)… which is why I think this is so attractive to technical leadership who have been divorced from the actual tools. It does give you a feeling of being able to do again, not just instruct (even though you’re only really instructing here anyway). Humans take time to do things, and it’s frustrating. Being able to get the data for a spreadsheet or spin up a little prototype or fix a bug without having to wait for the next engineer to become available is extremely compelling… I think that there isn’t very much thought into why this is though, and the result is mandates on staff that are actually better off without it.
If you do have to work with these things closely, I strongly recommend building strict, quantitative frameworks that produce metrics by which you can judge style and complexity of code. I would also recommend building agent skills for code legibility and code readability that take specific examples or — ideally — actual linter or test output and define explicit code styling and design pitfalls, and what to do about them. I would strongly direct against using existing skills for this as this process should be unique to each codebase you are working on, as it is a cultural compact as much as a tool for maintaining a particular style. And yes, you will need to curate these skills and tools and artefacts as you go, as this is a static representation of your discernment that will need as much Winnowing as the code itself. It of course goes without saying that you should also turn your attention to pruning the generated code, aggressively, rather than simply letting it be generated. Your tool is the scythe now, make good use of it.
And if you are in that situation, the last piece of advice I will give is this: Write your own code, somewhere, somehow. It doesn’t need to have much of a purpose, it doesn’t need to be good in a production sense… heck you are now free of operational concerns. Wanted to learn Haskell or Elixir or Erlang or Prolog but never saw the point because you need to practice your Javascript for work? This is your enthusiastic permission slip. I don’t want you to lose the joy of creativity, it’s a rare item now, and we’ll need it to get out of this mess.