Tower of Babel

I've been coding with claude code and codex for a while now. And while these have amplified my breadth of understanding, I'm still tugging at the very peripheries of building depth in them. A story from the Old Testament succinctly captures what I think is the state of devs today.

A Tower to The Heavens

Here's the story:

In the post-diluvian world, all of humanity had the same language. And in their vanity, humans decide to build a temple that tears into the heavens by virtue of its sheer height. And so the work begins. But God intervenes and makes these builders unintelligible to each other by dividing this unifying language. As a result, work stalls.

The story is intended to explain the origins of the schism of language and beliefs. But I think it serves to illustrate an interesting juncture we're standing at right now in AI-assisted software development.

A Post-AI Software Landscape

I'm sure people must have lamented when we moved from punch cards to assembly or from assembly to C and so on. The loss of fine grained control is scary. But as we see from the MapReduce blog, a restrictive programming framework confines whats possible in exchange for giving some superpowers to the layperson.

Today software indeed pervades almost every system on the planet. The fact that machines can be carefully orchestrated to form closed-loops to write, test and self-improve is incredibly powerful. For an average developer too, the ability to absorb knowledge and adopt and adapt existing technologies has multiplied manifold. But in this crazy flurry, I do see some concerning patterns emerging. Patterns that I thought were almost absurd in the pre-AI software world.

Ignorance of lower level details of implementation

I've seen this with several PRs I've raised as well as reviewed. I've grown increasingly comfortable with the fact that I'm unaware of several granular details of implementation. Why does this matter? Because these come to haunt later in terms of unhandled edge-cases, memory leaks, OOM kills and throttled containers. And thus the beauty of a lean, efficient microservice has been lost.

Self-loops and implementation biases

What if you asked your alter ego what it would prefer to do rather than a peer who didn't share your ideas of what a good design meant? It'll tell you what you want to hear instead of discussing and debating. I've seen this happen several times while designing. Sure, it increases my bias for action. But sacrifices design optimality and rationale. And obviously this leads to shaky foundations for future work

Instant gratification and a garb of unfounded ego

Imagine not knowing what a kubernetes operator was and catapulting to a crazy complicated design for one a couple of hours later. And the icing on the cake is that when you deployed it on your cluster, it actually works. What a high right? The only catch is that several parts of the implementation remain arcane to you. Sure you read through and capture the general gist of what is being done. But the details? Bah! lets not fuss about those right now. Implicitly this means that maintaining and extending this code is also going to be a massively AI aided task.

If you've played with agents long enough, you know they're prone to extend and complicate current state rather than optimize and distil the codebase to be succinct yet complete. So what you ask? In a few iterations, this bloat becomes impossible to cut through and somehow we convince ourselves - lets just create a new microservice and avoid boiling the ocean.

So what now?

I don't think I ever intend to abandon agentic-coding. Quite the opposite. They're a force multiplier and its imprudent to shun their use. What I do intend however, is to reason better and have a firm grounding of the problem being solved. Lest my language is garbled by this new kind of builder wreaking havoc on my cluster.