AI is turning Engineers into Farmers, Doctors and Gardeners<br>· aswinmohan.me

If you love or hate what I write, or just want to talk, feel free to email me at<br>[email protected]

We can't find the internet

Attempting to reconnect

Something went wrong!

Hang in there while we get back on track

2026-May-24

AI is turning Engineers into Farmers, Doctors and Gardeners

Think about software engineering before 2022. We were building systems from the ground up. We knew how complex systems worked because we were the ones building it. Even if we didn’t have an idea about the entirety of the system, we knew people who we could ask. Even if we took years to interact with the codebase again, a few hours of digging around would bring back the fond memories of its creation.

When dealing with legacy codebases, we would experiment, we would observe its results and then make more changes. But every subsequent change was ours, every change would improve our comprehension of the codebase and our command over the codebase. Like Theseus’s ship, every change made this foreign object closer to us, closer to something we created. We were literal gods, reveling in the art of creation.

We now grow codebases from the seeds of a single prompt. Big complex trees, small personal plants, everything is grown instead of created. We throw the seeds and pay tax to magic AI entities to accelerate the process. The entities could only make funny looking weeds first, but they scaled themselves to produce trees that produce fruits that we can sell for money. The part of creation of these plants accelerated. And the magic entities became in such high demand that the village is skewing its own economy to pay them to grow more trees.

Generating code is an order of magnitude faster than writing it by hand, constrained only by the amount of money you can spend on tokens. The amount of time and conscious effort required also fell by a magnitude, seen by the rise of brain rot IDEs that play short form video content while agents do the farming.

This would have been great, if the output exactly matched the spec of what was required. But that isn’t the case as a sufficiently detailed spec is the code itself. So we have prompts which are an approximation of the requirements. Since the code is generated from an approximate prompt, we require change to make it conform to our requirements.

If we had expended the engineering effort to create the system by hand, we would have been rewarded with the comprehension required to make the change. But the generated code is foreign to us in the same way legacy code is. There we turn from farmers into doctors.

Doctors who work on the human body, work on a complex system they did not create. They do not have access to colleagues who have created the system. So they learn about the system and then experiment. They make the best effort changes, observe the effects of those changes, tune their future experiments based on the results and share the learnings with themselves and their peers. This is the same process we go through when we create changes in codebases that we did not create. We learn about the system and then we experiment. We make changes, observe the effects and improve the change and if the effect was not to be expected, revert the change and try again.

Contrast this to us making the change in a system we created. We would have an idea about the different parts, how they interact, the warts of the system, its breaking points. All this because we were gifted this comprehension as a result of the work we put into the system. We would know what change to do, how the change would affect the other parts of the system and what’s the most sensible part for this change to be. Even if a significant amount of time has passed between the act of creation and our revisit, we would still be in a much better place served by our fuzzy memory. Rather than wandering around in a new place without a map in the night, we would be wandering around in a place at night we have visited at least one time, and sometimes more. This makes making changes in a system you created a much more enjoyable process aided by a continuous improvement in capability. Instead we have to traverse a new unknown system.

What if we use AI to make the change instead of doing it ourselves? If we try to make the change by ourselves, our comprehension of the system improves on every subsequent change. If we offload that to the AI system that grew the codebase, we become much more similar to gardeners. Gardeners try to change the plants, by trimming, tending, and budding. If we want blue flowers instead of yellow, we bud the branch of the system and hope the forces that govern the growth of the system pushes into the direction where we want the change to happen. We lose much more control, effectively curtailing our ability to change the system to our nuanced requirement to a process similar to praying, effectively requesting our AI models again and...