There was a time (hell, we're still in it for many devs) when writing beautiful code was a badge of honour. Indentation was sacred. Naming was poetry. We were craftsman, carefully carving perfection out of code. It was artisanal code: elegant, readable, perfectly abstracted. It was more than syntax, it was a signature: Hello world, look at how pretty my code is.

But here's the problem: the audience was always other developers. You weren’t optimising for performance or product outcomes. You were optimising for admiration. You were writing code to impress your peers.

And that era is dying.

Readability for whom?

Code readability has historically been about human cognition. You wrote your functions to be easy for someone else to reason about. You added comments so future maintainers would know your intent. You split up files for modularity, used design patterns for familiarity, and maintained a consistent style so that your teammates wouldn't want to strangle you.

All valid goals. But they rely on a world where humans are doing the reading. And that world is shrinking.

AI doesn’t care that you alphabetised your imports. It doesn’t care that you left vertical whitespace between logically distinct code blocks. It doesn’t care that your test files are named after the feature instead of the component. It just wants to know what the system does, so it can replicate, modify, or refactor it.

In a very short time, code won’t be written to be read by humans. It will be written to be parsed, interpreted, and reasoned about by models. Structure and metadata will replace elegance and flair.

If we look further ahead, we may not even need compilers or traditional abstraction layers in the same way. Those exist primarily to help humans bridge the gap between intent and execution - wrapping logic in formats we can understand, maintain, and debug. But AI doesn’t need code to be structured for human readability. It just needs a clear objective and enough context to generate something that works.

That doesn’t mean the end of abstractions altogether; many still serve a practical purpose in shaping execution paths or maintaining system flexibility, but it does mean the purpose of those abstractions will shift. Instead of being for humans, they’ll increasingly exist to support AI reasoning, orchestration, or cross-platform execution.

And eventually, with more direct translation between intent and execution, we may reach a point where high-level architecture is all that matters and the implementation just materialises from that. Expressive naming, clean indentation, and tidy formatting give way to structured semantics, embedded intent, and contextual metadata. It's not about how the code looks to us anymore; it's about how well it communicates with machines.

My own mini philosophical crisis

Recently I made a tiny react app called Strip AI over a weekend. It normalises text; cleaning up AI garbage like emdashes, curly quotes, and invisible whitespace.

But here's the twist: I didn’t really write it. I had the idea. I orchestrated the tools. I guided the AI. I made architectural calls and tweaked the prompts until it spat out what I wanted. I read the code, sure, and I course-corrected when needed. But the vast majority of the actual keystrokes were synthetic.

So... did I build it? Can I claim that?

It didn’t read like my code. It didn’t feel like my code. But it worked. It was accessible, fast, and production-ready. And most importantly, it fulfilled the product’s purpose. Nobody who uses it cares how clean the codebase is - they care that it fixes their formatting garbage.

And that shook something in me. Because for years, I’ve taken pride in writing beautiful, thoughtful code. But now I’m asking: is that pride based on an obsolete value system?

How long will it be before even looking at the code is just a waste of time?

Where Does That Leave Us?

Larger applications still need code crafters... for now. Even the best LLMs can still over-engineer, miss critical edge cases, hallucinate nonsense, or silently ignore key instructions. They still need hand-holding and careful review, especially in complex systems where the shape of the codebase affects long-term maintainability.

But that’s the part that’s changing so damn quickly.

Within just a few years the balance will shift. Engineers will be less about shaping code by hand and more about guiding AI systems with clarity, vision, and iteration. There will always be back and forth - there’s no such thing as a perfect one-sentence brief for a human or a machine. But the form of that back and forth will become less about syntax and more about intent, constraints, and quality.

The top-tier engineers won’t be the ones writing the best code. They’ll be the ones asking the best questions. Making the best decisions. Seeing the whole system and knowing how to shape it. Product thinking. Quality thinking. Leadership.

Soon 'software engineer' won't mean coder anymore...

From Coder to Conductor

Here’s the hard truth: code is becoming an implementation detail.

The engineer of 2030 won’t spend their day refining abstractions. They’ll spend it setting objectives, defining constraints, evaluating trade-offs, and stitching together agents, tools, and services. Achieving quality will be about iteration and knowing what quality looks like rather than crafting it, line-by-line.

Some may never write a single line of code in their entire careers but they'll still ship software.

So if you’re still hung up on whether your function composition is elegant enough, stop. Let go of the artisan mindset. Start thinking like an architect. Or a conductor. Or a systems designer.

And while you’re at it, stop stressing over algorithm trivia like it’s a badge of competence. You don’t need to reverse a binary tree on a whiteboard to be a great engineer. The kind of technical interviews that reward rote memorisation and obscure CS puzzles are rapidly becoming disconnected from the reality of software development. Knowing how to implement a hash map by hand isn’t what’s going to make or break your contributions in the future.

Understanding systems, navigating complexity, guiding AI output, and making judgement calls; those are the skills that matter now. The rest? They're museum pieces. Interesting, maybe even worth knowing for the context, but not the hill to die on. If you're not already thinking at a strategic level (Staff, Principal, or beyond) it's time to shift your mindset. Because the people shaping the future of software aren't the ones still arguing tabs vs spaces; they're the ones defining the interfaces between humans and machines, between intent and execution.

Because soon, nobody will care how clever your code is.

They’ll care if it works.

And they’ll expect you to make it work without ever touching the code.

(Also, yes I know the hero image is terrible, I don't have an Adobe Photoshop subscription at the moment so I'm winging it with ChatGPT)