It might not be the idiomaticity of the code that matters, but whether it is maintainable — so that it can evolve. In that case, the real question becomes: maintainable for whom?
Why must AI-generated code be idiomatic?
If a system can produce code whose behavior is verified through comprehensive testing — from unit and integration to behavioral validation against real data — why should its form matter? What if that same code were opaque or even unreadable to humans, yet demonstrably correct? Would that actually be a problem?
We typically insist on idiomatic code for three main reasons. First, in the real world, models often don’t fully complete a working program that satisfies all requirements, so a human developer may need to step in — and if the code is unreadable, that’s difficult. Second, there’s a lack of trust in machine-generated output: being able to see the code offers reassurance. Third, not all organizations are ready to operate in an LLM-augmented environment, so having code that looks familiar makes it easier to transfer ownership from machine-assisted processes to human-only ones.
These are social and practical reasons, not technical ones.
When programming moved from assembler to C, to C++, and later to interpreted languages like Ruby or Python, we accepted that human-written code would be compiled or translated into executable forms that nobody reads directly. We trust compilers to produce correct binaries from idiomatic human code because compilers are deterministic and verifiable.
Now consider the next level of abstraction: if prompting and agentic architectures become part of the programming process, perhaps we should view the generated code as another artifact in that chain — not meant to be human-readable, but verifiable through testing. While compilers are deterministic and LLMs are not, if correctness can be proven through a strong test harness, how different is that assurance, really? Of course, testing isn’t a perfect analog for compilation — it’s probabilistic assurance rather than mathematical proof, confidence earned through evidence, not guarantee. But for most of software engineering, probabilistic confidence is what we already work with.
Tests prove that a system behaves as expected — but only for what we’ve decided to test. They don’t necessarily capture intent, or non-functional qualities such as performance, security, and resilience. When something breaks in production, it’s still humans who have to debug, audit, or reason about what’s gone wrong. In those moments, idiomaticity — and the ability to navigate and understand the code — still matter.
Idioms also represent collective learning — patterns that encode what has proven safe or efficient over time. The point isn’t to discard them, but to see them as one of many tools that preserve maintainability. Tests don’t replace engineering judgment; they constrain it. Idioms, in that sense, remain part of how we keep change safe.
At the same time, idiomaticity also acts as a trust mechanism: it allows teams, auditors, and even new maintainers to see and verify what’s happening, without relying on a black box. It enables accountability and reduces perceived risk. These are not aesthetic values; they are operational ones.
Seen this way, idioms aren’t sacred — they’re scaffolding. But if scaffolding is only useful while construction continues, what replaces it when systems begin to maintain themselves?
This brings us back to the real question. If correctness can be proven independently, then perhaps it’s not idiomaticity that matters most, but maintainability — the ability of code to evolve, accommodate new features, and support innovation safely.
Maintainability encompasses more than readability; it’s the ability to modify, diagnose, and extend code with confidence. It depends on technical boundaries, testing, tools, and the people who interact with the system. For now, maintainability still assumes a human in the loop — not because machines can’t do the work, but because accountability still belongs to people.
And maintainable for whom? For humans? For LLMs? For both?
Readable code is maintainable for humans. Structured and data-rich code may be maintainable for models. As LLMs become co-maintainers of software, what’s idiomatic for them might differ from what’s idiomatic for us. It’s not far-fetched to imagine conventions, styles, or even programming languages optimized for machine comprehension and modification. We’re at the frontier of discovering what “maintainable for models” even looks like.
This isn’t prediction so much as preparation: exploring how maintainability might evolve as models become more active collaborators. Idiomaticity may shift, but the goal remains the same — to keep change safe.
In the near term, the most promising direction lies in writing code that is maintainable for both. That means being explicit about boundaries and side effects, predictable in structure, transparent in data flow, and rich in tests. These qualities make code easier for humans to reason about and for models to generate and modify safely.
Maintainability can be measured — in mean time to repair, ease of onboarding, frequency of safe releases, and audit effort — regardless of who writes or maintains the code. The outcome, not the syntax, becomes the benchmark. Even as models take on more of the work, maintainability will always include the ability to assign responsibility — to trace intent and accountability.
This might also be an example of what software engineers call the XY problem — focusing on the apparent issue (X) rather than the underlying one (Y). In this case, debating whether AI-generated code is idiomatic (X) might distract from the deeper question (Y): whether that code is maintainable and capable of evolving safely.
Maybe idiomaticity is just today’s shorthand for maintainability — a historical artifact of a human-centered era of programming. As we move into one where humans and machines share maintenance responsibilities, idiomaticity will evolve. What matters is not whether the code looks familiar, but whether it can keep evolving safely and predictably.
If tests let us prove what’s correct, maintainability determines what can change. And in an age of human–machine collaboration, that’s the higher bar.
The future of software engineering may not hinge on how we write code, but on how we keep it alive. And that begins by asking, again: maintainable for whom?
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Leave a comment
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere. uis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Delete