I've been writing code for a living for 16 years. During that time, my work has changed constantly and often very quickly: programming languages, frameworks, IDEs, best practices, etc. As a developer (especially a web developer) I got used to change. But the changes I've seen in the industry over the last year feel like something else entirely.
In the last six months, I haven't written a single line of code completely by myself. That's something not so long ago I would never have thought possible. So I wanted to share some thoughts about the current state of the industry from a programmer's perspective, and how I imagine the future.
I'll use terms like programmers, developers, and software engineers more or less interchangeably to refer to people whose job involves writing software.
Developers and Code
Being a software engineer was never just about code, but for most of us it used to be the part we enjoyed the most. We had long discussions about trivial things like spaces vs tabs, formatting, idioms, and design patterns. Endless discussions in pull requests, sometimes genuinely useful for improving code and product quality, but very often just matters of personal taste and preference. We lost time and energy trying to make our opinions prevail, often just so our egos wouldn't get hurt.
As an example of how extreme discussions about code could become, I remember when the Prettier code formatter appeared. The JavaScript community split between engineers who refused to use it because it didn't match exactly how they liked their code to look and preferred to keep spending time manually adjusting formatting (or asking others to adjust their pull requests), and developers like me who were happy to automate that part of the work and stop wasting time on unproductive debates.
But there were also more interesting debates about code. The most beautiful one, in my opinion, was around the Promises/A+ spec, when Brian McKenna proposed a monadic interface for promises and was accused of living in a fantasy land. Other discussions I particularly enjoyed were the traditional OOP vs FP debates that I was introduced to by Joe Armstrong's classic article, which I remember reading during lunch breaks at my first programming job. And then of course there was React. Its creation challenged many of the established good practices in the frontend community, and in many ways it still does.
Some of these discussions involved deep architectural choices, but most of them were, at the end of the day, about the code we wrote every day and how to make it more ergonomic, easier to understand, and easier to maintain.
The Code Skeptics
Even before AI, not all software engineers had a natural love for code. Over the years, I've met different kinds of code skeptics. I'd roughly group them into three types.
Disengaged: These developers are not particularly enthusiastic about code itself. They often don't have strong preferences for programming languages or frameworks and just stick with whatever they learned first. As long as the job gets done, they are satisfied.
Artisans: These folks like building things. They enjoy creating applications that solve real problems, and they care about the final result and about getting there quickly. For them, technology is just a means to an end.
Systems analysts: These guys believe in one thing: specs. Once the system is fully defined in a specification, the code becomes almost irrelevant. It can be auto-generated or simply handed over to programmers to implement. They have been pushing code-generation approaches for decades: CRUD applications generated from database schemas, 4GL languages, UML diagrams, and similar ideas.
This third group is especially interesting to me because it was quite influential when I was studying to become a programmer, but practically nonexistent in the web industry outside of old-fashioned corporations where transactional software was dominant. My career focused on building complex user interfaces, distributed web systems, and highly customized user experiences, where code generation was more or less irrelevant.
I'm not sure how many pure system analysts or software architects are still out there. They didn't adapt very well to the agile era, where coders became the real protagonists, but I imagine they will enjoy the current state of the industry.
Enter the AI Era
My AI coding journey started with skepticism, like for most programmers. The first tool I tried was Copilot. I hated it from the start. I found autocomplete-style code suggestions extremely annoying and often wrong or simply not what I intended, so I uninstalled the VS Code extension and forgot about it for a while.
After ChatGPT arrived, I gradually started keeping a chat open while working on something new and asking it to write specific functions or chunks of code for me, then copy-pasting them into the IDE. At that point I was already hearing people talk about how AI would replace programmers, and I found it funny. The code it produced was becoming more and more impressive, but most of the code we write is highly context-dependent. Developers love to bury primitives under layers and layers of custom abstractions, so even routine operations often depend on custom helpers, internal libraries, and conventions.
I found myself giving ChatGPT more and more information so it could write code for me: pasting entire files, dependency lists, and configuration details.
Then Cursor IDE appeared. I used it for a while and was very happy with it. Somehow they found a better UX for code completion. It felt more natural than Copilot. The "guess the next code with Tab" feature was also pretty cool. But that was still hands-on coding with Cursor as an assistant.
Cursor also came with an agent integrated into the IDE, with a chat interface where you could request code changes like I had been doing with ChatGPT, but without needing to manually provide the context. It was able to read the relevant files on its own. This was extremely powerful, and little by little I started relying more on the agent and writing less code myself.
And then Claude Code appeared, and it really changed the game. Since I started using Claude Code, I have practically stopped writing code manually. It felt wrong at the beginning, probably not only to me (I still have programmer friends who resist it), but it worked.
From time to time Claude goes down a rabbit hole, and you have to sit down and find the issue yourself by reading the code. But most of the time it finds bugs quickly and implements features from scratch if given a proper prompt, usually with some iteration and testing until everything works.
After six months, writing code manually just feels too slow. I don't think there's any going back now.
My New Development Life Cycle
Modern coding assistants like Claude offer different modes of working. There is what people often call "YOLO mode," where you just prompt the agent and check the results without even looking at the code, and more conservative approaches where you review the changes step by step and can stop and redirect the agent if you're not happy with what it's doing.
I'm still not in YOLO mode. I read the code it writes and approve the changes step by step. Over time I've become more confident and better trained at knowing where to pay attention and noticing when it starts to drift. I still make the high-level decisions about how the code is structured, how it is split into files, and how the pieces fit together. But I mostly just write prompts, review the code, and test the functionality.
I'm no longer in control of every detail, but I would notice if it started modifying parts of the logic I wasn't expecting. Sometimes I catch mistakes Claude was about to make. Other times it changes something I didn't expect, and it turns out the change was actually necessary or had implications I hadn't foreseen but the model did.
Most of the development time now goes into manual testing, design decisions, and writing specifications (for the moment mostly in the form of prompts). We still have a human code review process. I read the code manually, but we also have Copilot on GitHub reviewing pull requests and leaving comments.
Is Code Still Relevant?
This is probably the question every programmer is asking: if the coding part can be automated, is code still relevant in the software industry?
At least for now, code is definitely still relevant to me. Even though I'm not writing it myself, I'm still responsible for it and aware of how it works and how it's implemented. Some interesting reading on this topic:
- Dangerously Skip Reading Code by Facundo Olano
- The Future of Software Engineering by Thoughtworks
At this point I haven't seen agents work very well with non-developer operators. They can produce working software, but they make more mistakes and are more likely to introduce regressions if the person writing the prompts is not familiar with the implementation details of the project.
As an example, I often run into circular dependency issues that Claude tends to solve with ad-hoc fixes that add complexity to the system and make future changes harder. It is not very good at stepping back and rethinking the problem unless explicitly asked to do so, and that is not something a non-developer would usually think to prompt.
But that might change in the near future. There are already several initiatives aiming to build fully automated software factories, with multiple AI agents supervising and correcting each other. Steve Yegge's Welcome to Gas Town is a very interesting read on this topic.
I don't think we are ready yet for code to become a complete black box, but I do see it becoming a less prominent part of the software industry.
And What About Programmers?
I've seen a lot of articles in the news, both specialized and mainstream media, talking about software engineers being replaced by AI or recommending that new generations choose different career paths that are harder to automate, like skilled trades such as electricians, plumbers and painters, or even the humanities and social sciences.
As I mentioned before, I do not imagine a future in which programmers are not relevant in the software industry. Software engineers are trained in several skills that I think are still valuable beyond operating the machine that writes the code. That includes system-level thinking, architectural knowledge, understanding trade-offs, debugging complex problems, and translating vague ideas into concrete implementations.
What is probably true is that there won't be much room in the industry for the lone-wolf, highly specialized programmer for much longer. Programmers in the AI era will have to wear multiple hats, taking on roles that include product thinking, QA, architecture, and more.
As for entry-level programmers, over the past ten years it was often enough to focus on learning one popular tool deeply and still find a job. That probably won't be enough anymore, and a broader and more complete education will become more valuable.