AI can now build working software from a prompt. Developers can generate and refine code in seconds. QA engineers can use AI to explore test coverage, identify potential gaps and improve automation.

So, is software engineering becoming easier?

It’s a question worth asking as AI in software development becomes part of the everyday workflow for software teams. The technology is clearly making some things faster. It’s lowering the barrier to building software and changing how developers and QA engineers spend their time.

But the reality is more complicated than simply saying AI is making developers more productive.

We asked two people who actually build and test software what they think. Alex Hovy, Senior Developer at Bluegrass Digital, and Hendri Esterhuysen, QA Engineer, both use AI as part of their day-to-day work. Their experiences point to an interesting shift:

AI may be making software easier to build, but it isn’t necessarily making software engineering easier.

Where is AI actually useful in day-to-day software development?

For Alex, AI has become useful across almost every part of his working day, not just when he’s writing code.

“One of the biggest benefits is understanding things quickly. Whether it’s a new codebase, a Jira ticket, a piece of documentation or a technical concept, AI helps me consume and process information much faster.”

That’s an important distinction. AI isn’t simply helping developers produce code more quickly. It can help them understand an unfamiliar codebase, investigate a problem, summarise information and identify things they might have missed.

It’s also become a way of challenging ideas. Alex can use AI to explore an approach, consider different trade-offs or look at a problem from another perspective before deciding how to proceed.

For him, the biggest benefit isn’t necessarily about writing code faster. It’s about changing where he spends his time.

“Writing code is the obvious example. It can generate code significantly faster than I can type it. But speed isn’t really the biggest benefit. The biggest shift is that I spend less time writing code and more time thinking about the problem I’m solving, how the solution should be designed, and whether it’s the right approach overall.”

For Hendri, the value is more focused on the QA process. He uses AI to help refine automation code and examine scenario coverage. For example, AI can look at the code behind a particular function or widget, assess how well it’s covered, identify potential gaps and suggest areas where testing could be improved.

In both cases, AI is being used as part of the process rather than simply being handed the process.

Is AI making software development easier?

This is where things get interesting.

One of the biggest misconceptions Alex sees is that AI can replace software engineers because tools such as Lovable, Replit and similar platforms can now build applications from a prompt.

To a certain extent, he agrees. These tools are incredibly powerful, particularly for prototyping ideas and building an MVP. They lower the barrier to entry, and that’s an exciting development.

But there’s a significant difference between building something that one person can use and building something that thousands or millions of people can rely on every day.

“Once you start thinking about scalability, security, maintainability, testing, performance, architecture, and having multiple developers working on the same codebase, that’s where engineering really begins.”

That’s the part of the AI conversation that can sometimes get lost. Getting software to work is not the same as building software that can be trusted.

AI can help build the first version. It can even produce surprisingly good results. But the engineering decisions that determine whether that software remains reliable, secure and maintainable over time still require experience and judgement.

Hendri sees a similar misconception from the QA side: the idea that you can simply “let AI do it”.

His view is that “garbage in, garbage out” has never been more relevant.

AI is powerful and fast, but it needs to be actively managed. The more complex the task, the more specific and well-structured the explanation needs to be. The quality of the output is closely linked to the quality of the input. In other words, knowing how to use AI effectively is becoming a skill in itself.

Has AI changed how software teams work, or just made them faster?

For Alex, it’s both, but it really depends on how the team uses it.

One thing Alex has noticed is that, with enough experience, you can often tell how effectively someone is using AI just by looking at the quality of their work. People who know how to guide AI well tend to produce better first iterations, need fewer revisions and spend more time solving the actual problem rather than wrestling with the code.

Poor use of AI can create more work for everyone else. It can generate too much code, overly verbose documentation or solutions that technically work but don’t follow the team’s standards or architecture. Someone else then must spend time reviewing, understanding and often rewriting it.

“In those cases, AI hasn’t made the team faster. It’s simply shifted the workload to someone else,” he says.

Interestingly, Alex has also found that experience isn’t always the deciding factor. He’s seen developers with less industry experience produce fantastic results because they use AI as a learning tool, asking better questions, validating their understanding and using it to improve their thinking. He’s also seen experienced developers get weaker results when they rely on AI too heavily or don’t guide it effectively.

The bigger lesson? AI doesn’t automatically make a software team more productive. It amplifies the habits that are already there.

Teams that establish good engineering practices and use AI intentionally can become much more productive. Teams without those foundations can actually become less efficient, despite generating more code or documentation.

AI is also surprisingly good at helping turn ideas into something tangible. Alex’s biggest positive surprise has been the quality of the first iteration when the problem has been properly planned and the AI has been given enough context. It’s possible to go from an idea to something that can be explored or prototyped in a fraction of the time it might previously have taken.

Hendri has experienced a similar benefit, particularly in terms of what AI makes possible. One of the things that has surprised him most is being able to take an idea for a very specific piece of software, something he wouldn’t previously have known where to begin building, and actually develop and use it.

That’s a significant shift. AI is not only accelerating existing workflows. It’s opening up the possibility of building things that may previously have felt out of reach.

But there is a catch.

Can AI actually make you slower?

AI can generate a huge amount of output in minutes. But that doesn’t necessarily mean the work is finished.

Hendri has found that the speed can sometimes work against you. You can generate a significant amount of code quickly, only to spend hours debugging, correcting or reworking it afterwards.

The result is a strange productivity paradox.

AI can make an individual task dramatically faster while potentially creating more work elsewhere in the process. And as teams become capable of delivering more, expectations tend to increase alongside them.

So the question isn’t simply whether AI makes us faster. It’s whether we’re using that speed to do better work, or simply to produce more of it.

Where does human expertise still matter?

For both Alex and Hendri, the answer is clear: quite a lot.

Hendri sees AI as a useful second pair of eyes. It can help identify gaps, challenge assumptions and improve coverage. But he doesn’t think it should be left to make critical QA decisions on its own. At most, he sees AI as a way to “double check the homework” of QA. The person with the experience and understanding of the product still needs to make the final call.

Alex takes a similar view from the development side. AI can produce incredibly high-quality code when it’s given good direction and enough context. But it can also produce what he calls “AI slop”: code that technically works but isn’t maintainable, readable or designed according to good engineering principles.

There’s also a risk of becoming complacent. AI is often confident and frequently correct, which can make it tempting to trust the output without reviewing it critically. But “usually correct” isn’t good enough when you’re building software that people depend on.

As Alex puts it, AI is a tool rather than an autopilot. It amplifies good engineering, but it can also amplify bad habits if it’s used blindly.

So what does AI mean for the future of software engineering?

Perhaps the biggest change isn’t that AI is replacing software engineers. It’s that it’s changing where their expertise is needed.

Developers can spend more time on architecture, design, scalability and long-term reliability. QA engineers can use AI to automate certain tasks, explore test coverage and identify potential gaps, while still relying on human judgement to understand risk and decide what matters. And businesses can increasingly move from an idea to a working prototype faster than ever before.

That’s all genuinely exciting.

But there’s a difference between making software and engineering software. AI is lowering the barrier to building something that works. The challenge is still building something that can scale, remain secure, perform reliably and be maintained over time.

The organisations that get the most value from AI may not be the ones that automate the most. They may be the ones that understand where AI adds genuine value, where it needs human oversight and where experience still matters most.

AI may be changing how we build software. But it hasn’t made knowing how to build good software any less important.