The software engineering community is experiencing a moment of collective vertigo. AI coding assistants, from Claude Code to various copilots, promise that anyone — even founders without deep technical knowledge — can now build software as easily as recording a video. The dream of the “citizen developer” feels tantalizingly close. Yet this narrative fundamentally misunderstands what software engineers actually do.

The Ghost of Smalltalk Past

Alan Kay showed us in the 1980s that programming could be radically simple. Smalltalk offered an elegantly minimal mental model: objects receiving messages. In an era of COBOL’s verbose complexity, this was revolutionary. Children could build complete software systems in a fully visible, comprehensible way.

But something happened on the path from the 1980s to today. Software escaped the boundaries of personal computers and sprawled into networks. Systems became distributed, decentralized, and vastly more complex. Rich media interfaces emerged. The cognitive load of understanding a complete system exceeded what any single engineer could hold in their head.

This explosion of complexity birthed the modern software development team: architects, testers, front-end specialists, back-end engineers, database optimization experts. We invented the “full stack developer” as a pragmatic compromise — accepting that engineers might not know everything deeply, but could work effectively across domains. We lowered the bar on depth to raise it on breadth.

The Misconception of Code Generation

Now we’re hearing that AI coding agents will collapse these roles back down to the individual founder. The promise echoes Smalltalk’s original vision, but misses its fundamental insight.

Software engineers are not primarily code writers. We are clarity traders.

The real work of software engineering — particularly when combined with the roles of system architect and product designer — is bringing clarity to ambiguity. We take fuzzy business problems and understand them with such precision that we can translate them into instructions a machine can execute. This translation work consumes roughly 85% of our time.

The Translation Layer

Consider the mental models at play. On one side sits the business domain: customer needs, market requirements, organizational constraints, user experiences. On the other side lies the technology domain: programming language capabilities and limitations, hardware constraints, scalability considerations, security requirements, performance characteristics.

Software engineers build the conceptual bridge between these worlds. We don’t just translate business needs into code — we translate them into mental models that other engineers can understand, maintain, and evolve. We organize these models into project structures: classes in object-oriented systems, functions and monads in functional programming, or other abstractions that make the solution comprehensible to human minds.

This is why COBOL’s full name — Common Business-Oriented Language — was telling. Even in its verbose complexity, it represented an attempt to move closer to the business problem and further from the machine. Every evolution in programming languages has continued this trajectory: less focus on how the machine works, more focus on what the business needs.

What AI Actually Changes

Can AI coding assistants write code better than many engineers? Absolutely. Sometimes dramatically better. But code generation was never the bottleneck.

The bottleneck is clarity. Understanding the problem deeply enough to specify what needs to be built. Recognizing the unknown unknowns. Identifying which nonfunctional requirements actually matter. Designing abstractions that other humans can comprehend and maintain.

For truly simple problems — the three-tier CRUD application that’s been a solved problem for decades — AI can indeed take you from requirements to working software overnight. These systems are impressive demonstrations precisely because they tackle well-understood problem spaces with established patterns.

But notice what happens after that impressive first night. The resulting codebase is often extraordinarily difficult to maintain. It may dazzle investors in a demo, but becomes a maintenance nightmare when business requirements evolve. This isn’t a flaw in the AI — it’s the natural consequence of optimizing for code generation rather than clarity.

The New Role of the Clarity Trader

The future of software engineering isn’t about being replaced by AI. It’s about the translation layer transforming.

Previously, we translated business needs directly into code, using our understanding of hardware and software constraints. Now, we translate business needs into clear specifications for AI agents, which then generate the code. Our debugging duck finally talks back, validates our assumptions, helps us explore architectural alternatives, and challenges our solutions.

This is genuinely powerful. But it introduces a subtle danger.

When we write code ourselves, the act of writing forces clarity. We must understand precisely what we’re building because the compiler or interpreter demands precision. When we delegate code generation to AI, we risk losing this forcing function. We might accept solutions we don’t fully understand. We might let the AI paper over gaps in our own clarity.

The Open Question

This raises a profound question about the future of codebases. Will they remain human-readable artifacts that humans and AI collaborate on together? Or will they become fully AI-managed, with humans specifying only high-level requirements?

If the latter, do we even need programming languages designed for human comprehension? Perhaps AI agents could develop their own languages, optimized for machine efficiency rather than human understanding — vector spaces, geometric representations, or structures we can’t even imagine. The code could become a black box, with humans interacting only at the requirements level.

I don’t know the answer. But I know this: the work of clarity trading won’t disappear. It may transform radically, but the fundamental challenge remains — bridging the gap between what humans need and what machines can do.

Choose Clarity

Whether you’re working with AI coding assistants or writing every line by hand, your primary responsibility hasn’t changed. You’re not here to generate syntax. You’re here to bring clarity to complexity, to understand problems so deeply that solutions become obvious, to create mental models that bridge human needs and technical reality.

The vibe coding era may make the final step — code generation — trivially easy. But the journey to that point, the hard work of clarity trading, remains as essential as ever.

So bring clarity to your work. That’s what makes you an engineer.