Opinion

AI Engineering Has Made Me More Interested In Software Development, Not Less

About a week ago, I was scrolling through my LinkedIn after coming back home. I noticed a post from a LinkedIn user, who stated their intention to quit the tech industry due to the rise of AI. The next day, I began noticing more and more posts on my feed from people questioning whether they chose the right path, especially given the scarcity of software developer roles and the enormous difficulty entry-level candidates are experiencing in today's job market.

Their concerns are valid. The market is very difficult right now, and as someone who was in the same situation from May 2023 to February 2025, I won't pretend that it has been smooth sailing for me. But I think the conclusion some people are drawing from all the talk about AI misses the bigger picture.

For me, AI has had the opposite effect, but responsible usage is always #1 for me. The more I have incorporated it into my work as a software developer, the more interested I have become in software development itself. It's certainly made some parts of my work faster, but simultaneously, it has also made me very cautious about surrendering my experience and judgment to a model that frankly lacks the nuances of human thinking.

That concern was voiced by MIT professor Samuel Madden, who recently described this phenomenon as cognitive surrender. To put it plainly, cognitive surrender occurs when a person heavily relies on AI to help them solve a task or come up with ideas, which can potentially lead to overdependence on the tool and a reduction in critical thinking and the development of foundational skills.

Because of these concerns, that is exactly why I use AI as a tool that supports my thinking rather than replacing it. I use it to help me brainstorm, troubleshoot, or move through repetitive work quickly, especially on deadline days, but I still want to fully understand the code I am working with, what decisions are being made underneath the hood, and the consequences those decisions will have in other parts of a system, especially those that are interconnected.

In software development, that distinction matters a lot. A model can generate code that may appear correct, compiles successfully, and passes an entire test suite, whether it was generated by the model or written entirely by a human. That doesn't necessarily mean that it understands the broader architecture, the business logic behind every feature, or the unexpected edge cases that can appear once the software is deployed to production and used by real people.

My point is: generating code is not the same as applying software engineering practices.

While writing the implementation is one thing, someone still has to understand whether it belongs in the system that was written, either by the developers themselves or by someone else on their team. They would also have to decide whether it satisfies the actual requirements of the system, how it will behave when something goes wrong, whether it will introduce security risks, and how maintainable and scalable it will be in the months and years following its original deployment.

A perfect example of this situation would involve the use of API endpoints. Let's say, for example, an endpoint was developed using FastAPI to pull a list of users. Normally, the endpoint would need several safeguards in place, such as checking whether the request has a valid authorization header and bearer token, verifying the identity associated with it, and determining whether the user has the privileges to pull such information. Of course, the exact implementation will vary depending on the company's policies, the user's role, and the business logic used. The endpoint should also be able to handle unauthorized or forbidden requests appropriately.

Now, what would happen if the endpoint was generated with AI? It would initially work until a situation presents itself where either the database is not available, an authenticated user gets access to information they're not supposed to see, or a token expires or is malformed. The real problem occurs only if those edge cases were never accounted for, even if the logic and implementation themselves appear complete.

My point is that if a developer were to blindly accept the code without verifying it first and/or adding the necessary adjustments before testing it out and adapting it to security and business requirements, it would increase the risk of events mentioned in the previous paragraph, especially during a major breach or downtime event. The same goes for any event that can unexpectedly occur in production.

The same principle applies to endpoints that modify data. If two requests attempt to update the same record at the same time, the developer has to account for concurrency. Not only that, but the developer would also have to account for a race condition that could leave the system in an inconsistent state.

While concerns regarding AI-generated code are valid, individuals such as Java champion Markus Eisele have cited findings from Veracode's 2025 GenAI Code Security Report, which found that 45% of AI-generated code it tested failed security checks, with Java having a 72% failure rate across the tasks it assigned it to do.

These numbers are concerning, yes, but that doesn't necessarily mean that AI doesn't have a place in software development. If anything, the statistics should serve as a stark reminder and reinforcement for software developers in the industry to start taking standards seriously. They need to understand the code they accept, review it from beginning to end, and apply the same security standards as they would with code written manually.

I have made this argument before in my article, Agentic AI: Who's Responsible? The AI? Or the Developer?. In that piece, I argued that that responsibility ultimately falls on the developers and organizations that build, approve, and deploy these systems. The reason: AI cannot take accountability for the consequences of its own output. Companies who provide these models, such as OpenAI, Anthropic, and Meta include an acknowledgment stating that it can make mistakes, and the user must verify the outputs it provides.

That's the case when a developer blindly writes and/or accepts AI-generated code: they integrate it and deploy it to production for real users. Once that part is done, the responsibility no longer lies with the AI model that generated the code; it lies with the developer. If the application begins receiving complaints from users, it is an indication of security, reliability, or operational problems happening underneath the surface, which can create a chain reaction later down the line.

That is why, as I stated earlier: the dangers of AI didn't push me away from software development. It made me more interested in it. The more capable these tools are, the more important it is for developers to understand what is happening underneath the hood. Knowing how to generate code is useful, but there also comes responsibility to understand how systems behave, why they fail, and how to design them responsibly. This helps separate convenience from engineering, and the latter is more important than the former.

If AI continues making code generation faster and more accessible to anyone who uses it, then the skills that make someone a well-rounded developer will also have to evolve. That doesn't mean that they have to abandon the basics in favor of more convenient solutions, which frankly, would amount to cutting corners with no valid reasoning or justification.

It's one thing using a tool to become more efficient and do the hard work that helps forge our skills, and it's another when using it as an excuse to not understand the work purely for convenience. The former can make someone a better developer long-term. The other will lead to dependency and will weaken the very skills the developer is supposed to exhibit while writing the code.

For example, an API endpoint was developed for an airline to keep track of passengers who got their flight got delayed or cancelled. A flight attendant will have to pull the list to see which customers got affected. Suddenly, they get an error saying that they're not allowed to see the data, even though they are well within their duties to access it. At first glance, it may be a minor permissions configuration. But underneath the surface, it could mean that the developer misunderstood the authorization requirements, that the employee was assigned the wrong role or permissions, or that the developer accepted logic generated by the model without verifying how the airline's access-control rules were supposed to work.

In a real operational environment, this type of mistake affects employees, who will be unable to assist passengers. This contributes to overwhelmed customer-service lines, delayed rebooking, and inconsistent information for travelers who are already frustrated by the inconvenience. That is why what may seem like a small mistake can create a larger problem.

None of these change the fact that entering software development today is difficult. In an article by KIRO 7 News Seattle, which was reposted by Yahoo! Finance, entry-level tech postings represent approximately 7.5% of jobs in the industry, while senior-level roles have risen to 43%. Today's graduates are going to enter in a market that looks very different from the ones developers before them entered a few years ago, and AI has understandably added another layer of doubt. As I've stated in the beginning of this article, a difficult job market doesn't necessarily mean that the profession will go away in the next few years.

Right now, for those who are reading this and are currently looking for a new job in the field, what I would recommend doing is the following:

1. Never stop learning the fundamentals. They are key to our problem-solving abilities and creativity to solving solutions. Just because AI makes development faster, it should not replace the understanding that is needed when an implementation is wrong. Going over data structures, algorithms, databases, networking, security, testing, debugging and system design are crucial foundations that every software developer must focus on. The stronger we are on those, the easier it is for us to evaluate AI-generated code instead of depending on it blindly.

2. Use AI responsibly. In today's job market, employers are increasingly expecting developers to be able to properly use AI, but that doesn't mean that we should let it think for us. This is what I would recommend: use it to brainstorm, speed up repetitive work that would normally take hours to minutes, explain concepts that you want to better understand or do not understand, and to troubleshoot. Of course, you still have to be able to explain and defend the decisions behind what you submit.

3. Build projects that demonstrate your judgment, not just based on coding. You can have an excellent portfolio with amazing projects, but can you explain how you handled authentication, authorization, database design, testing, and anything that you applied to your project? If someone asks you questions regarding any of these topics, always be prepared to explain why you made those decisions.

4. If you are working with code that you did not write, become comfortable reading and reviewing it. AI-generated code is becoming more common these days, and the abundance of it will only continue to increase in the next few years. Developers will have to start understanding code that they didn't personally write. Learn how to trace execution from beginning to end, similar to a maze. Learn how to identify assumptions, spot security problems, and determine whether the implementation that AI provided fits your system's architecture.

5. Do not apply to jobs to just one role. Widen your horizons. That's the mistake I made when I first entered the job market in May 2023. I only applied to positions that carried the title of either "Software Engineer" or "Software Developer". Developer, programmer, application developer, systems analyst, you name it. They don't have to be exactly what you're looking for, but those roles will give you the necessary and valuable experience you need to expand your career as you continue to go up the ladder. And as personal advice: never let anyone tell you that you should go to sales just because it's difficult. It's lazy advice, and it's a huge downer if they hadn't considered the many adjacent roles that can still build your experience.

6. Get real world experience wherever you can. It doesn't matter if it's freelance, internships, open-source projects, or contract work. Building software for real users, solving real problems, and maintaining something is still experience, even if some employers take a dogmatic view that only paid employment is considered "real" experience, when the reality is far more nuanced than that.

Following this advice for the past 3 years has also made me realize how much more there is I want to understand. The more experience I gather, the more I find myself asking questions on what is happening underneath the hood on the systems I use every day, either on my computer or on my phone. That growing curiosity is exactly why I have recently started to consider pursuing a master's degree in computer science and artificial intelligence.

Contrary to the popular belief circulating in the media, social media feeds, and online forums, AI has not made me less interested in software development. Not even in the slightest. If anything, it has made me more interested in understanding what separates simply generating code from actually understanding and developing reliable and efficient systems.

I don't know exactly how the industry will look several years from now, and I don't think anyone truly does, even if they have an idea. What I do know is that I would rather continue learning, adapting, and strengthening my understanding than assume that the rise of AI means the end of software engineering.

For me, that curiosity is only going to continue to grow.