Things Get Difficult When More AI Gets Involved in Software Development

I use AI a lot in my day-to-day development work.

It helps me write code faster, explore unfamiliar technologies, generate tests, understand APIs, and get through repetitive tasks. As a developer, I like having that capability available.

But recently, I have also noticed something that bothers me. As more AI gets involved in software development, some parts of the job are becoming harder rather than easier.

The problem isn’t that AI writes code, the problem is what happens around that code.

Here are some things I have personally started noticing in my work.

One of the first things I noticed was code duplication.

A developer asks AI to implement something. Another developer asks AI to implement something similar like a expandable table rows or a charts. The AI generates a slightly different version.

A few weeks later, we have three implementations of almost the same logic.

This becomes more noticeable when teams start moving toward a common stack.

Earlier, teams often had clearer boundaries. A frontend developer focused primarily on UI and frontend architecture. Backend developers handled APIs, services, databases, and backend concerns.

Now developers are increasingly working across the stack.

I actually like this change. I started primarily as a frontend developer, then gradually worked with Node.js, Python, databases, APIs, and other parts of the stack. Having that broader understanding has made me a better engineer.

But it also means the amount of code being produced by each developer has increased. And when AI generates that code without enough architectural context, the repository can become messy very quickly.

You start seeing:

The code may work individually. The problem appears when someone has to maintain the whole system.

AI is very good at answering:

It is much harder to make it consistently answer:

That second question requires project context, architectural rules, existing patterns, and sometimes simply talking to another engineer.

Another change I have noticed is how people communicate technical decisions.

Actually, I ask my team member:

Previously, they might explain it for five minutes.

“The frontend sends this request, the API validates it, then this service updates the database. This component handles the state, and this is where the failure case is handled.”

That’s usually enough to get started.

Now, sometimes the response is a massive AI-generated design document.

It looks impressive. But I still don’t know the answer to my original question.

The problem isn’t documentation. Good documentation is extremely useful.

The problem is using a document to replace communication when a simple explanation would have been faster.

There are situations where I want the design document.

When I am implementing a complicated system, onboarding someone, reviewing an architectural decision, or documenting something that needs to live beyond the current team, detailed documentation makes sense.

But if I ask how a module currently works, I usually need the context first. Give me five minutes of explanation. Then give me the document if I need more detail.

AI makes it very easy to produce documentation. That doesn’t automatically make the communication better.

I have also noticed this on the UI side.

When AI generates interfaces, it tends to reach for familiar patterns.

The result is often perfectly acceptable.

But many applications start looking like they came from the same design system, even when they shouldn’t.

A product should have its own visual language. That doesn’t mean every application needs a completely unique design system. Reusing proven patterns is good engineering.

But teams still need to decide:

If we simply ask AI to “build a modern dashboard,” we shouldn’t be surprised when we get another modern dashboard.

The engineering challenge is becoming partly about knowing what not to generate.

This is probably one of the biggest practical problems for me. AI makes it easy to generate a large amount of code quickly.

That also means pull requests can become much larger.

A PR might contain:

The number of changed files grows quickly.

Tests are important, but they also increase the amount of code a reviewer needs to understand.

I use a PR review agent as well.

It works reasonably well when a new file is relatively self-contained. But when the change depends on several existing components and files, the agent can struggle without enough context.

It may produce generic feedback because it doesn’t fully understand why the surrounding architecture works the way it does.

There is another problem I have seen. If the PR changes after the agent has already reviewed it, the re-review does not always happen automatically.

So you can end up with:

That’s dangerous because the existence of an AI review can create a false sense of coverage.

AI review should reduce repetitive work. It shouldn’t become a substitute for understanding the actual change.

And manual review becomes increasingly difficult when a PR contains too much generated code.

To fix this issue, i build my own PR review Agent skill to review UI and BE code for my review pattern and added inline comments in that PR

This is the part that concerns me the most.

AI is often introduced with the expectation that developers can now accomplish more.

That sounds reasonable, but there is another interpretation: “If AI can help developers do more, maybe we need fewer developers.”

I have started seeing this thinking enter project discussions.

And then comes the question:

That’s a difficult question to hear if your role is primarily frontend.

The irony is that AI can generate a UI quickly, but building a production application involves much more than producing JSX/TSX.

If the team becomes smaller while the amount of work continues to increase, the result isn’t automatically better productivity.

Sometimes it simply means the remaining people carry more responsibility.

That directly affects work-life balance.

This is the change I personally find the most interesting.

I started mainly as a frontend developer.

Over time, I worked with JavaScript across the stack, Node.js, Python, APIs with Java and its frameworks, NoSQL databases, and other technologies.

Today, the expectation can be much broader.

You may be working on the frontend in the morning, debugging a backend service after lunch, looking at database queries later, and then dealing with infrastructure or an AI integration.

Personally, I like it.

I have always wanted to become more of a full-stack engineer, so being exposed to different parts of the system has helped me.

But I can also see why this can be overwhelming. There was a time when becoming good at one area could take years.

Now developers are being encouraged to understand multiple layers of the system while also learning how to work effectively with AI.

The breadth of knowledge expected from an engineer is increasing.

AI makes it easier to cross those boundaries, but it doesn’t remove the need to understand what is happening underneath.

In fact, I think that understanding becomes more important.

I don’t think the answer is to stop using AI. I use it, and I will continue using it.

The problem is that AI makes it extremely easy to move from an idea to a large amount of implementation without spending enough time thinking about the system around it.

That changes the bottleneck.

Earlier, writing code could be the slow part. Now, understanding the code can become the slow part and reviewing can become the slow part.

Keeping architecture consistent can become the slow part and explaining decisions can become the slow part.

And deciding whether the generated code should exist in the first place can become the slow part.

That means engineering discipline matters more, not less.

AI can help with implementation, it can help with exploration and it can help with repetitive work. But somebody still has to own the decisions.

For me, that’s the biggest lesson from working with more AI in software development.

I’m getting faster at producing code.

At the same time, I’m spending more time asking whether that code is organized properly, whether someone else can understand it, whether it fits the existing architecture, and whether we actually needed to generate it at all.

That trade-off is becoming a bigger part of the job and I don’t think we’re talking about it enough.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.