We still need software engineers

... for now, at least.

I've wanted to write this post for a while. Long before Opus 4.5 (and now 4.6) and GPT-Codex 3.5 came out.

Those models are really on another level. Working with them feels like quantum leaps in assisted programming. Hell, sometimes I even feel I'm becoming the assistant.

Still, we need software engineers. And I'll explain why.

But before I go too deep, I'll just back up a bit.

Since ChatGPT and the GPT3.5 models came out a couple of years ago, different large language models (LLMs) have helped programmers with their work. 

And LLMs are uniquely qualified to help with programming, because at the end of the day, all programming is a bunch of 1's and 0's. That's something computers can easily understand.

In the early days (like 1,5-2 years ago), the LLMs could help with code completion. I'd start writing a function, and it'd guess how to complete it.

Sometimes it was a help. Many times it was rubbish.

As the LLMs became smarter and able to handle bigger context windows (think of the context window of how much information it can hold "in memory" at the time), they could understand the context they were working in, thus giving more relevant answers.

For example: What kind of project is this? How is it structured? What do the different functions or references mean? Etc... All the context that programmers use when writing new code.

Fast-forward to today, with the latest LLMs.

In my IDE (the program I use when writing new software), there's a built-in agent named "Junie". It's an alternative to Claude code, Cursor, Windsurf, etc... I'm using it with Opus 4.6 right now. In my experience, it's the best available right now.

I'll give two examples of tasks it has helped me solve this week, to give you an understanding of how it works and thinks (and yes, I do mean: Thinks!)

Example one: Create a new feature.

I give it an instruction in "human words" (like this post). Describe what the feature should do, where in the application it makes sense to put it, what other components it should talk to, where to find them and how to implement it. 

The agent then starts working in multiple steps. I can follow it, step by step, as it opens the other components I referenced to understand how they work, how it scans the entire code base for similarities, and then it starts building. I can see how it thinks, what it does, what it finds and its reasoning why it does as it does.

Within 5 minutes it has created 4 new files, modified 3 existing ones (fx adding a new menu item to link to the new feature) and completed the task.

I test it, instruct it on the modifications I want, and we go back and forth like this for a few iterations before I take over myself and polish the code myself.

It just writes the code! Like magic...

Example two: Fixing a bug.

This is where it really shines. I give it a copy of the error message the code generated, along with a description of what I think the issue is and where to look.

Then it goes to work.

Scanning all files and libraries in the project.Writing temporary test scripts to test different scenarios.Executing bash commands to sign into my Docker containers to execute the tests in the right php environment.Re-iterating 3-4 times based on its findings.

Before, at the end, figuring out that the fix is two lines that need modification.

This took about 10 minutes. It would have taken me hours to do. 

The increase in productivity when using these AI agents is mind-blowing.

So, now that we have something that can write code itself, why do we still need software engineers?

Why not just build all the software ourselves by prompting these amazing LLMs to build it?

Three reasons: 

One: Architecture and code quality. As the codebase grows, so does the complexity and the need for a clean, high-quality codebase. I've seen this get messy really quickly if you just let the LLMs loose and do their thing unsupervised. It becomes unmaintainable.

Two: Review and quality assurance. While the feature it builds often works, I've often seen it fail to account for side effects. Changing one thing that affects something else.

Three: We still need to instruct the LLMs on what to do and how we'd like it done, to ensure it meets our needs. And when shit hits the fan, we need to understand how everything works to fix it.

At Herodesk, we're at a point where it's tremendously helpful. It's why we can deliver what 10+ developers would have done only a few years ago, with just 3 on the team.

We use it as much as possible while ensuring high quality and long-term maintainability in our work.

All of the above is why we still need highly skilled software engineers to steer these incredible tools as we build Herodesk.

That's why we still need software engineers.

That's why we hired Berkay 6 weeks ago, who's already put 10+ tasks into production (including several big ones).

And that's why we'll probably hire more in the future, too.