Worried AI Will Take Your Software Engineering Job? Don’t Be.
If you’ve been following my blog for any amount of time, you’ll know that I have been working with AI as a software engineering tool for more than two years now. At least a couple of times a year we hear about AI taking over people’s jobs. I cannot count how many times I’ve read or heard someone claim that AI has already solved the software engineering task and that those jobs are going to go away en masse. While there has been significant progress with AI agents and the quality of their software engineering output, they are still unable to complete even moderately complex software engineering tasks.
While I’ve seen market improvement in the quality of work that AI agents produce, there is still a lot of room for improvement at this stage. I would absolutely not be replacing junior or senior level software engineers with an AI agent. Even the best trained AI agents continue to make mistakes that I would consider questionable from an intern level engineer, and unacceptable for junior or senior level software engineers. Granted, many of these errors are cosmetic. However, there are plenty of cases where foundational incorrect decisions are made and implemented. These foundational issues are the type that will become nightmares to maintain, manage, and patch in the future if not caught early in the development process. If you are using AI agent to write your software and are not checking the output, you are likely to have significant issues when the production application is launched.
Years Of Testing AI As A Software Engineer
For the past couple of years, I’ve been using AI agents as software engineers in two distinct situations. The first has been to write simple applications or algorithms with the sole purpose of testing the capabilities of the AI agent. Most agents today can handle this and do a decent job, though some of their design decisions are clearly based on the massive amount of subpar code they have been trained on coming from public repositories.
The solutions might work, but they are ugly at best. The other situation has been helping me maintain a 10 year-old legacy, SaaS application, Store Locator Plus®. Over the past couple of years I have seen AI struggle significantly with making meaningful modifications to this application. I learned fairly early on that sizable tasks need to be broken down into much smaller digestible components for AI to have a chance a producing usable output. In one use case I attempted to replace a legacy PHP page with complex interactions that was using jQuery with a modern React interface. Despite having ported several other modules to React and directing AI to use those as a template, the AI agent spent hours trying to do the page rewrite. After hours of a single agent interaction processing the request, the result was all my tokens for the entire month were burned. The AI agent spent hundreds of dollars trying to port one page to React. When it ran out of the token budget the parts it did write were complete garbage. Nothing worked and the UI was far worse than the 10-year-old PHP code it started with.
Since that time I’ve seen notable progress with AI Agents. Newer agents using the latest foundry models have been able to manage smaller tasks without issues. ChatGPT 5.3 and Claude sonnet were particularly adept at generating first-pass usable output if the tasks are spoon fed to the AI agent. I started to think that part of the issue with subpar results was due to the fact that my main use case included years of inherited technical debt. I decided to embark on a new AI driven project. This project would be started from scratch with a new SaaS application I had been considering for years. Maybe if AI started with a clean slate it would perform far better in architecture and engineering tasks. For the new project, I would also flip my normal AI interactions on its head and make AI the project lead and I would be the helper. For the legacy project I would take lead and relegate the AI Agent to an assistant only role.
As it turns out it is only marginally better at that as compared to working on a project that included the technical debt.
Software Engineering Clean Slate Project
With this new project, I decided to start with a partly trained AI agent and use the latest AI tools available in my coding environment. I chose to use only the latest foundational model models; In this case working with OpenAI’s ChatGPT 5.5 in high reasoning mode.
The project started with dozens of hours of an interview process between myself and the AI agent. I followed the same process I have used for major client projects. Perform an interview to set the goals of the project, determine use cases, and figure out the primary criteria to deem the application a successful project.
After defining the business goals, the technology stack was determined based on the results of these interviews. Most of the stack definition came from the AI agent. It did a fairly decent job of picking the stack. I provided minimal guidance here mostly ensuring it stay tuned to AWS solutions so I wouldn’t need to be trained on standing up other cloud services. While I want AI to do a lot of the work, I was not willing to open the Pandora’s box of letting AI freely launch AWS services without my setting roles and restrictions on that interaction.
Personally, I’ve followed this same interview and technical stack definition process in the real world for years. It is a proven model that has led to successful cloud application launches for a variety of clients. Before setting the agents into motion on actually developing the application and in-depth review of the dozens of business and architecture documents was performed. The documents are sufficient enough that I would hand them off to an outsourced development team and be confident that with limited additional input a usable alpha version of the SaaS application would be possible.
AI Software Engineer : The First Milestone
With the project training and interview process complete and a development plan that was well documented, I started the AI agents on building out the platform one milestone at a time. The milestones have multiple steps that make continued progress toward a goal of a functional SaaS application. The milestones and sub-level checkpoints are small enough for today’s AI agents to handle in a single context. This helps reduce potential failure due to drift or other loss of context issues when working with an AI agent.
The initial application created by the AI agent has some nice design features on both the UI and backend side of the application that I may not have come up with on my own. I , admittedly, am not great a user experience design and the AI has a lot of good examples for that. However, during the processing of the first milestone there were numerous times where I’ve had to stop progress. It was necessary to continue training the agent on how to write quality software or build resilient architecture due to some fundamentally poor design and implementation decisions. The first user interface, for example, would put some buttons on the main page for primary functionality but hide similar functionality in a text menu. Even worse, they were not grouped together with the menu on the top left and buttons down the right side.
In addition there were multiple times where the application would break due to overly brittle designs. The AI agent made poor decisions that follow typical patterns I’ve seen when working with junior developers or subpar contracting firms versus following best practices. In several cases, I had to manually edit code to show the AI agent how to construct code that would not be brittle. Several times I had to inject architecture feedback that was overly detailed as the AI agent would spend multiple turns trying to guess how to do it right instead of asking for instruction or clarification.
Progress Toward Milestone 4
I am nearly 45 days into this project and have spent the last couple of days, as we embark on the fourth milestone, continuing to train the AI agent to do a better job. Earlier today, the AI agent was working on a part of the milestone that deals with setting up email services through AWS. Simple email service to invite users to the application. The AI agent made the right decision to use publicly available node modules to connect to the email service. While this is an improvement from the “I’ll write it myself” decisions that the agent was making during the first milestone — I am a big fan of not re-inventing the wheel when it comes to reusable software modules, the agent failed at a basic level to handle this task correctly.
In this case, the AI agent wrote code to interact with the email service and decided to use a specific AWS package. The agent selected the proper package within the code itself. However, in configuring the project, the node package manifest was written to include a non-existent no library. As such when the application started up it failed immediately with an error message. This indicates several primary failures in the AI agent reasoning. Even more concerning is this was a fresh context loaded with a bootstrap set of knowledge files, a methodology that had proven successful for the second and third milestone of this project. This method keeps context drift or pollution at bay as the session loads an AI written handoff file to pick up where another session left off. A “condensed context of understanding” to see the new session without eating up all of the system memory.
The first problem is significant and one that I would not accept from an intern level software engineer. The agent told me the task was complete and ready for deployment. Clearly, this was not the case as starting the app server immediately generated an error message. The AI agent never tested its own work to see if the server was running after the code updates. This was odd since dozens of turns in the past milestones as well as the first steps of the same fourth milestone had proven that the AI agent was good at testing its own work before telling me the task was complete. If an intern level software engineer came into my office and told me that job is done and this happened, we would have a long discussion about proper software development lifecycles and quality control. This is something you would never see from my junior or senior level software engineer. If an intern did this twice they’d no longer be employed.
Just as concerning was my interaction with the AI agent about the issue. When I pointed out that the agent referenced a nonexistent module in the package.json manifest the agent first indicated that this was an issue due to the fact that the app was running in a Docker container. While the app. does run in a Docker container, that is not why the package name was not resolving. The real issue was the package is not real. When I asked where it got that package name from the agent replied that it found that package name in the AWS SDK V3 code. Another fabrication. When I followed up that claim with the fact that that package does not exist the AI agent then told me that it intended to use a different package name, but put wrote the wrong package name. The AI agent said there was no external source for the incorrect name. The agent then went on to explain that it had done the other parts right calling the right package name inside the code, but it never checked that against the manifest. Despite my asking if the agent had made up that name or hallucinated and asked for the source of where that name came from it said that it “corrected the dependency and wrote a new lesson about how to be a better software engineer by checking its work and testing the application before claiming a task was complete”.
At least my self-improvement skills and feedback loop was working for the AI agent.
Only after pushing several times for an explanation of where that package name came from did it finally give me a truthful answer. What the AI agent said was “the best explanation is in or originated from my generated text not from a real package source… an accidental splice of client and NPM in ESV2…” in other words, hallucinated and introduced it into the code as a primary package for the application. At least it owned the hallucination after I pushed it several times to explain itself.
My Insight Into AI As A Software Engineer
What is my take away from all of this?
Despite the hype that we’re hearing in the media from multiple AI companies that artificial general intelligence is only a few years away or that they figured out the software engineering problem, my real world experience shows otherwise. Maybe I’m not training my agents properly. Maybe I don’t have enough experience on how to write applications using AI. Whatever the reason is, I am left scratching my head trying to figure out how these companies can claim that AI is capable of writing viral software applications with minimal or no human assistance.
My guess they need to sell more shares of their companies or gain more interest from the public as they prepare for IPO’s. It is all the same type of smoke and mirrors we saw back at the dawn of the Internet. That is not to say that AI will not get there just that it is not there today. Every day I see the same things I saw over 20 years ago at the dawn of the Internet; Companies spending too much money, pushing out as many updates as they can to beat the competition to market and all the while generating mountains of garbage that is not truly useful for the general public. Eventually the bubble will burst and more than a couple of these companies will no longer exist. Sadly they will get to their IPO and leave the general public holding the bag of debt left behind by the hype engine and broken promises.
Sure AI is impressive. We see all kinds of interesting things out there with the deep fakes, crazy images often with the right amount of fingers now but filled with tells that the photos or graphics are not real and we’re not curated by a human. AI does some cool things, but if it wasn’t for the fact, that half of the use of AI is creating social media slop purely for entertainment,AI would be far less interesting to a lot of people in the general public.
Can AI help do useful things in business? Definitely. Do I feel Software Engineers need to worry that AI will outperform them? Not today; If AI is writing better code than you are on a consistent basis then you may want to consider becoming a cook instead.
As a software engineer, I am using AI to accelerate development. However that development cannot be done in an uncontrolled environment. AI output in this situation always needs to be reviewed and verified. The agents do accelerate my work and they are a force multiplier, but even with the spring 2026 releases of foundational AI models you still need to babysit it if you want quality output. Someday software engineers may need to worry about their job security but not today. We’re already seeing companies that that bet heavily on AI walking back their AI budget and re-hiring employees they let go less than a year ago. The expectations of what AI agents could do and the reality do not align.