# AI Made Software Development Easier. Here’s What Got Harder.

AI-assisted development has changed how we build software. We can explore unfamiliar codebases, work across languages and frameworks, debug problems, write tests, understand existing implementations, and build features significantly faster than before.

Software development **is easier because of AI**. But making something easier doesn't mean removing all the challenges. Sometimes it means replacing old ones with completely different ones.

After working this way for a while, I've realized there are quite a few new things we're learning to deal with.

## The productivity bar keeps getting higher

AI makes developers faster, but as AI increases how quickly developers can deliver, expectations around productivity increase with it. If something used to take a week and can now be done in three days, eventually three days becomes the expectation.

The time AI saves doesn't necessarily become extra time for understanding an implementation, improving tests, reviewing architecture, or learning something new. Sometimes it just creates room for **more work**.

When the expectation is to continuously produce more, deeply understanding everything you're shipping can start feeling optional. The feature works. The tests pass. AI can explain the implementation whenever you need it. Do you really need to understand every piece of it?

Probably not. But understanding almost none of it isn't a great alternative either. **The challenge is finding the right balance between understanding every line of code AI produces and having only a high-level understanding of what you're shipping.** Where that balance sits will depend on the change, its complexity, and the risk involved.

## We can produce code faster than humans can review it

AI can generate a substantial amount of code incredibly quickly. But when a human reviews that code, they still need to understand what changed and whether it makes sense.

That can mean more PRs, larger PRs, and more code for reviewers to process. **The amount of code we can produce has increased much faster than our capacity to deeply review it.**

## AI reviewers can make "done" harder to reach

AI code reviewers can help us keep up with the increasing amount of code being produced by identifying vulnerabilities, missing validations, defects, unhandled failures, and edge cases we might otherwise miss. **They don't replace human reviews, but they add another valuable layer of review—and another layer of feedback to get through.**

Fix comment. Push. New review. Fix another comment. Push. New review. Now there are three more things to consider.

Eventually you're wondering: **Are we meaningfully improving this feature, or are we just trying to make the bot happy?**

An implementation that handles the most common cases and provides value can be exactly the right engineering decision. We can ship, learn from how the feature is actually used, and address additional edge cases as we iterate instead of trying to solve everything upfront.

## We can build things we don't fully understand

Historically, implementing something generally required you to understand it well enough to write it. Those two things are no longer tightly coupled.

Today you can work in a language you barely know, use an unfamiliar framework, or implement a pattern you only partially understand. AI can explore the codebase, propose a solution, write the implementation, generate the tests, and fix the errors.

That's incredibly powerful, but it creates a strange situation: **our ability to produce sophisticated solutions can exceed our ability to independently evaluate them.**

## Being polyglot is easier. Being an expert isn't.

AI has dramatically lowered the barrier to working across technologies. Need some Python? Terraform? A Kubernetes configuration you've never written before? AI can get you surprisingly far.

But there's an important difference between **being able to build something with a technology** and **understanding that technology well enough to recognize when something is subtly wrong**.

The further we move outside our areas of expertise, the more we're relying on AI not only to produce the implementation but sometimes to tell us whether its own implementation is good.

## Giving AI the right context is now part of the job

The solution AI proposes can change dramatically depending on the context available to it. Give it access to one repository and it may propose a perfectly reasonable solution. Add another repository involved in the same flow, and the right solution might look completely different.

**AI can reason about the context it has, but it doesn't necessarily know what important context it's missing.**

Even when you start with the right context, keeping it throughout a complex implementation can be challenging. Conversations get long, context gets compacted, and important requirements, architectural decisions, or conventions can get lost.

Part of AI-assisted development is now **context management**: making sure AI has the right information to begin with and that important context isn't lost along the way.

## Sometimes you have to look beyond AI

AI can be incredibly good at debugging, but I've run into difficult issues where it keeps pointing me toward the same set of possible causes and solutions. You try them, provide more information, and somehow end up back in the same place.

At some point, you have to break that cycle. I've had to step away from the AI conversation, search the web, dig through Stack Overflow, or read documentation to find information that leads to a different hypothesis or potential root cause. **From there, you can bring AI along again, this time in a new direction.**

## AI can be confidently wrong

Sometimes AI confidently tells you that a library behaves a certain way when it doesn't. Sometimes it describes functionality that doesn't exist. Sometimes the answer is mostly correct but misses the piece of nuance that actually matters for your problem.

The more frequently AI gives us correct answers, the easier it becomes to trust the incorrect ones too. Knowing when **not** to trust the answer is becoming an increasingly important engineering skill.

## We're becoming less familiar with our own codebases

When I manually explored a codebase and implemented something, I naturally built a mental map along the way. I remembered where things lived, which service called what, and that weird piece of logic because I had spent two hours debugging it.

An agent can now search the repository, identify the relevant files, explain them, modify several of them, run the tests, and get the feature working. I understood what happened at the time, but ask me two weeks later where that logic lives? I might have to ask AI again.

We can interact with much larger portions of a codebase without necessarily developing the same familiarity with them. We can ship more changes while accumulating **less knowledge per change**.

## Understanding something doesn't mean we'll remember it

AI explains something. I read it. Everything clicks. *Ahhh. That makes perfect sense.* At that moment, I genuinely understand it. A few weeks later? I barely remember it.

Some of the friction AI removes—searching through documentation, experimenting, getting something wrong, debugging it, trying again—is also the friction that used to make concepts stick.

Removing that friction makes us faster, but there's a tradeoff there that I don't think we fully understand yet.

## Our debugging skills are getting less practice

When something breaks now, one of my first instincts is to ask AI. And why wouldn't it be? AI can inspect logs, trace execution paths, search the codebase, generate hypotheses, and frequently find the problem faster than I could manually.

But debugging, reading unfamiliar code, forming hypotheses, and knowing where to look when the obvious solution isn't working are skills developed through repetition. **If AI performs more and more of those repetitions for us, what happens when we encounter the problem it can't solve?**

## Technical debt can move faster too

Outdated documentation, poor abstractions, inconsistent conventions, and technical debt all existed long before AI-assisted development. **What AI can change is the speed at which they accumulate.**

When a team can generate and ship significantly more code, bad patterns can spread faster too. Documentation can become outdated faster, architectural inconsistencies can multiply faster, and developers working across technologies they don't deeply understand can unintentionally introduce patterns that don't quite belong.

AI didn't invent these problems but It can accelerate them.

## Final Thoughts

AI-assisted development has made our jobs easier, but it has also introduced challenges we didn't have before.

The interesting question now is **how we navigate those challenges without losing the engineering judgment and skills we still need.**

That's something I'm still figuring out—and perhaps something we need to talk more about.

**What about you? What challenges have you run into since you started using AI for development? Do any of these resonate? I'd love to know.**