Christian Heilmann's blog provides insights into web development, JavaScript programming, and technology advocacy. Readers can find articles covering topics such as web standards, accessibility, and developer tools. Additionally, they can learn about JavaScript frameworks, front-end development techniques, and the future of web technologies.

Christian Heilmann

A reflection on what defines developers in an era where AI writes code. The core argument is that being a developer was never about writing code itself, but about solving problems. Code is just a tool, and developers who embrace change and love problem-solving will continue to thrive. AI can handle the typing and releasing, but developers retain the ability to understand, improve, and direct what machines produce.

How do developers define their worth when code is written by AI?

Great post, man.
I’ve always been on a quest to write less code physically while still being able to complete my work. Between libraries, frameworks, snippets, and autocomplete, I write less code today than I did 15 years ago, and that was even before LLMs came along. I have no pride in typing every character. On the contrary, nothing was more satisfying then creating a reusable dynamic snippet that would prevent me from writing huge swaths of redundant boilerplate!
I also agree that the point wasn’t the code necessarily, but the problem solving opportunities that writing and creating with code presents us with. Some people problem solve with math, some with words, and some with code.
The only thing I am seeing in the industry right now that is disturbing to me, is this move towards assuming that developers shouldn’t need to think in code any longer, and that natural language specifications are the future. I fundamentally disagree, because not all developers think the same way.
Dax from OpenCode <a href="https://youtu.be/IGsbARhERqc?t=501" target="_blank" rel="noopener nofollow">recently said</a>:
“When working on something new or something challenging me typing out code is the process by which I figure out what we should even be doing. I have a really tough time just sitting there, writing out a giant spec on exactly how the feature should work. I like writing out types. I like writing out how some of the functions might play together. I like playing with folder structure to see what the different concepts should be. And this is all stuff that I think most people—most programmers—have always done. I don’t really see a good reason why I would stop that personally, because it’s how I figure out what to do.”
And problem solving also extends to debugging and troubleshooting, which I actually love doing. Everything fails at some point, nothing is infallible, especially non-deterministic pattern interpolators like LLMs. Everything works, until it doesn’t. When it doesn’t, who debugs the debugger? I’ve started <a href="http://confident-coding.com" target="_blank" rel="noopener nofollow">confident-coding.com</a> to address this, because I think we’re going to need to constantly remind, educate and guide people on what it means to think carefully, think critically, and know how to find the rope that can pull you back above the surface when you’re drowning in the error codes.