For many days this past year, like many devs, friends and stories I heard, I was discouraged. Suddenly that joy of solving a problem that had been blocking you for days was gone. So was the pride of presenting an elegant solution to a complex problem. And that flow state that made you skip meals. You just typed what you wanted, and a piece of software wrote in minutes code that would take you days, sometimes even better.
And then the profession got boring.
Not that I didn't expect that day. I was even hoping for it, especially when my wrist hurt from so much typing. I just didn't imagine it would come so fast, or that it would come with this feeling that my work had lost its fun.
And there was also the terror of reading and hearing everywhere on the internet that your profession is obsolete. Even though I don't believe that, and I have good arguments against it, it's impossible for this uncertainty about the future not to affect us somehow. After all, we spent years investing time and effort in a career.
But is it really over? Or will it be over one day?
Well, I'm Maxsuel, and I've been passionate about programming since 2006, when I wrote my first hello world in C. I created this journal to document this change in public: what I learn, my ideas and my experiments (the ones that work and the ones that don't). Why now? Because it's too big a change to go undocumented. And I'm already late to the party. I don't know if a single soul will read this, but if you do, I'm flattered.
My view is neither apocalyptic nor starry-eyed. I'd call it pragmatic. Some will say I'm "in denial". Others will have to face the reality knocking at the door: software development has changed.
So far, nothing different from what everyone says. The talk of the moment is that "developers will become product engineers". I still prefer to say software engineer, absorbing a lot of the product engineer.
I know someone will say software engineering has been around for decades. It has, and it has always been one of my favorite subjects. But for most of my career it shared my time with typing code, and it often lost. Now that AI writes the code, engineering stops being part of the job and becomes the job.
That's why I believe this profession will stay in demand, resting on three technical pillars: competence, responsibility and innovation.
Competence because, yes, it still takes a lot of knowledge, hours of study and years of experience to build quality software. As much as a model like Claude Opus has been trained on a lot of software engineering content, it learned from what has already been done. And software engineering is a controversial subject that changes all the time. Yes, we have established practices, like unit and integration tests, SOLID principles and so on. But what if the product targets a niche tied to specific hardware? Or it's a product that uses agents, which nobody really knows how to test yet? These and many other situations, even some we don't know about today, will need a new kind of engineering. AI can very well apply SOLID, write tests and help you in the process. But deciding which architecture to adopt and how the software should be built still takes a developer's head.
And you can tell when that knowledge is missing. Just as we can spot a website that "looks AI-made" at a glance, an experienced dev can tell when software was vibe-coded. On the outside, screens that look nice at first glance but forget error and loading states and ignore patterns everyone already knows. On the inside, the same problem solved three different ways, validation only on the front end, exposed API keys and routes with no permission checks. And even when it works with no obvious flaws, something is missing. To be honest, I can't always explain what it is. It's a feeling. But that feeling has a name: experience.
This brings us to the second point, responsibility. To explain it, I'll start with what won't need an engineer anymore. I strongly believe that many features will come from the users themselves, and that software will fix itself. Imagine an ERP where the finance team needs a notes field on every transaction. In the near future, it will be enough to suggest the change, have colleagues approve it, and in a few hours it will be live.
However, critical changes will still need a professional. You don't hire an engineer to replace a door or put up hammock hooks in your backyard. You follow their guidelines. Software will be the same: the engineer defines the rules, and small changes happen within them. Something I've repeated to myself and to others over the last few years is that "software will become much more complex than it is today". A legacy system nobody understands anymore, a portal that shows data to customers, an integration, or kinds of software we can't even imagine yet: that's where engineers will spend their time. These changes carry risks. And risk is a word directly tied to responsibility.
You don't pay a civil engineer just to put up a building. You also pay so that, if the building collapses right after it's done, someone answers for it. In Brazil, that's what the ART is for, a technical responsibility record: the name of whoever signs off on the work. Software engineering is the same (even without a license or an ART for us). Someone has to answer for leaked data, for security flaws or for an outage that can cost millions. Someone has to foresee these risks before they become problems and, when they happen, be there at 3 a.m. bringing the database back up and writing the post-mortem afterwards. AI doesn't do that. And believe me: the project manager and the CEO won't want to take that on alone. It's much better to pay an engineer.
And finally, innovation. With AI as a service, software is changing. AI is becoming as essential to some tools as a Postgres or MySQL database. Software we thought was impossible not long ago exists today.
And we're just at the beginning. To use a web analogy, we're still in the days when "we built crude sites in HTML and used tables for layout". The truth is we're still far from discovering the full potential of these tools. That's why new frameworks, kinds of software, tools and architectures will emerge, and the ones who'll create them are engineers.
With that in mind, I decided to focus over the next months not only on how to use LLMs to build software, but on how to use them to create these new kinds of software. Software that adapts easily, that fixes itself on every New Relic or AppSignal alert, and that grows and scales well. In my view, knowing how to integrate LLMs, build a RAG and develop agents inside a system will be like knowing how to build for the web was over the last 20 years. And I plan to share here what I learn (and get wrong) along the way.
This isn't the first time the field has changed like this. I have 15 years of professional experience, but I've been programming for 20, and I've seen many changes like this. I've seen job titles appear and disappear, technologies adopted en masse and abandoned soon after, and the market maturing. People who have been in the field for 30 or 40 years have seen much more.
And I don't believe this will end the profession. The demand for software seems endless, even with AI. If a team starts shipping twice as much, the software doesn't get done sooner: it gets more features, more integrations and handles more situations. In a market as competitive as software, who gets ahead? The company that cut its engineering team down to one person, or the one that kept the team and took its product to another level? Not every company will make that choice, and in some places teams will shrink, yes. I also don't deny that the bar for people starting out has gone up: it will take much more education and technical knowledge than it did when I started. But I think the complexity of what we build will take a leap, just as in the 90s nobody imagined the systems we have today. To me, AI is a revolution as big as moving from assembly to high-level languages and the arrival of the web, all at the same time.
That's reality: the era of writing code is ending, and there's no point crying about no longer bit-twiddling. And what cured my discouragement, in the end, was precisely starting to use AI on my personal projects. I had lots of abandoned projects on my GitHub, because I'd spend weeks just building a few screens. These last few days, what I found myself doing was thinking more about engineering: planning the software's future and making technical decisions, instead of typing yet another <div> block.
And honestly? I found it wonderful.