AI Made Coding Easier. It Made Software Harder.
AI made generating software incredibly cheap. But as code becomes easier to produce, maintaining quality, understanding complexity, and knowing what should exist have become harder than ever.
Something about software development feels different now.
We can write code faster than ever. We can generate entire features in minutes. We can create components, APIs, database schemas, tests, documentation, configuration, and even entire applications without writing every line ourselves. The amount of code being produced is incredible. But I keep coming back to one uncomfortable thought:
I think good software has actually become harder to build.
Not because AI is incapable of writing code. Because AI has made writing code so easy that the amount of bad code being produced has exploded. And the scary part is that a lot of it looks perfectly fine.

Code has become cheap
There used to be a natural relationship between the amount of code you wrote and the amount of work you had done. That relationship is gone. You can now generate hundreds or thousands of lines of code without spending much time actually writing them. You can create ten files with a prompt. You can refactor an entire feature with another prompt. You can ask for tests, types, validation, error handling, documentation, and a "clean architecture" on top of it. And suddenly your pull request has changed 2,000 lines. But did you really do 2,000 lines worth of engineering? Not necessarily.
A commit is not a unit of engineering quality. A pull request is not a unit of engineering quality. Lines of code are definitely not a unit of engineering quality. We have simply become much better at producing output. That does not automatically mean we became better at producing software.
The amount of slop has exploded
This is probably the part that bothers me the most. AI makes it incredibly easy to generate code that looks professional. The naming is reasonable. The formatting is correct. The types are there. The functions are nicely separated. There are comments. There are tests. There are abstractions everywhere. It looks like software. Sometimes it is even technically correct. But that does not mean it is good software. I have seen AI create abstractions for problems that did not exist. I have seen simple logic turned into multiple layers because someone asked for "clean architecture." I have seen straightforward components turned into generic systems that are harder to understand than the original problem. And this is where things get dangerous. Bad code used to announce itself. Now bad code can arrive looking polished.

We are starting to confuse more code with more progress
I think this is one of the biggest traps of AI-assisted development. You ask an AI agent to build something. It creates files. Then it creates more files. Then it notices another thing that needs changing. Then it refactors something else. Then it adds a utility. Then another abstraction. Then tests. Then more tests. And at the end, you have a lot of activity. It feels productive. The Git history looks busy. The diff looks impressive. The application might even work. But somewhere along the way, the original problem that needed solving has disappeared underneath everything that was generated around it.
More code does not necessarily mean more software.
Sometimes it just means there is now more software to maintain.
The bar has gotten dangerously low
There is another problem I think we need to be honest about. People have started expecting software to be incredibly easy to build. A client sees an application and thinks: "Can't AI just build this?" A user requests a feature and assumes it should take minutes. A developer sees a complicated problem and immediately thinks: "I can just ask AI." And because generating the first version is so easy, we have started lowering our definition of what "done" means. If the button works, ship it. If the API returns the expected response, ship it. If the dashboard looks good, ship it. If the AI says the implementation is correct, ship it. But production software has never been about the happy path. What happens when the request fails? What happens when the database is under load? What happens when two users perform the same action at the same time? What happens when permissions change? What happens when the input is malformed? What happens when the user retries? What happens when there are 100,000 records instead of 100? What happens six months later when another developer has to change the thing?
"It works" is an incredibly low bar.
The hardest part is no longer writing the code
This is what AI has changed for me. The difficult part of development increasingly isn't producing the implementation. It is deciding what the implementation should actually be. Should this abstraction exist? Do we need another dependency? Does this belong in a separate service? Is this state necessary? Do we need this database table? Should this be asynchronous? Does this query scale? Is this API boundary actually useful? Are we solving a real problem or an imagined future problem? These are engineering questions. And they are much harder to answer than: "Write me a service that does X." AI is extremely good at the second question. The first one is still ours.
AI has made reviewing more important than ever
This is probably the biggest shift I have noticed. When AI generates code, someone still has to take responsibility for it. And that means reviewing it properly. Not just reading enough to see whether it looks reasonable. Actually understanding it. If an AI agent generates 3,000 lines of code, you cannot magically review those 3,000 lines because they were generated faster. The responsibility did not disappear with the typing. You still need to understand the database queries. You still need to understand the state transitions. You still need to understand the error handling. You still need to understand the security implications. You still need to understand why the abstractions exist. And if you cannot explain the code, you probably should not be shipping it.
AI reduced the cost of producing code. It did not reduce the cost of understanding it.

That difference is massive.
The junior developer problem is more complicated than AI replacing jobs
I don't think the biggest danger is simply that AI will replace junior developers. There is another problem. AI can let developers skip the struggle that teaches engineering judgment. There is value in writing the bad implementation yourself. There is value in discovering that your abstraction was terrible. There is value in debugging something for three hours because you misunderstood the problem. There is value in discovering why your database query suddenly became slow. There is value in breaking something and having to understand exactly why it broke. Those experiences build intuition. They teach you what good architecture feels like. They teach you when something is over-engineered. They teach you when a simple solution is better. If AI constantly solves the problem before you have a chance to struggle with it, you might produce more software while developing less judgment. That is a tradeoff worth thinking about.
The senior engineer's job is changing
I don't think AI makes experienced developers less important. I think it makes engineering judgment more important. When code is expensive to produce, knowing how to write code is extremely valuable. When code becomes almost free to produce, knowing which code should exist becomes much more valuable. The best developer on a team might not be the person who generates the most code. It might be the person who looks at a generated implementation and says:
"We don't need this."
That might save the team more time than generating another thousand lines ever could. Knowing what to remove is engineering. Knowing what not to build is engineering. Knowing when a simple solution is enough is engineering.
The bar should go up, not down
I am not against AI. I use it. I think these tools are incredible. They are fantastic for exploring ideas, learning unfamiliar technologies, reviewing code, finding edge cases, debugging problems, generating repetitive code, and challenging my assumptions. But I don't think we should confuse the power of the tool with the quality of the result. AI has made software incredibly cheap to produce. That should not mean that our standards become cheaper too. If anything, the opposite should happen. If machines can generate the obvious implementation, then our expectations should become higher. We should care more about correctness. More about maintainability. More about security. More about performance. More about architecture. More about the actual product. More about whether the code needs to exist at all. Because when anyone can generate software, the ability to generate software stops being the differentiator. Judgment becomes the differentiator.
I think coding is harder now
This might sound strange after everything I have said. AI can absolutely make me faster. But I think becoming a good developer in the age of AI is harder. There is more code to review. More generated complexity to question. More plausible mistakes to catch. More abstractions to challenge. More pressure to ship faster. More people assuming software is now easy. And more temptation to accept the first thing that works. The responsibility has increased even if the typing has decreased. That is the part I don't think we talk about enough.
The code is getting cheaper. The expectations are getting higher. And somewhere in the middle, the engineer still has to make sure the thing actually makes sense.That job has not become easier.If anything, it has become more important.So yes, I will keep using AI.I will keep generating code.I will keep letting machines help me build things.But I am going to be much more careful about what I let them build.Because the goal was never to produce more code.The goal was to build better software.
And those two things are becoming increasingly different.

