I've been thinking about this quite a lot since AI coding tools started becoming part of my everyday workflow.
A few years ago, being a good software engineer often meant being very comfortable with the code itself. You needed to understand the language, remember the framework APIs, know your libraries, debug strange errors, search through documentation, and spend a ridiculous amount of time figuring out why something that looked completely reasonable refused to work.
I went through that phase too.
There were plenty of times when a seemingly simple feature turned into hours of debugging. A dependency behaved differently than expected, an API returned something undocumented, a frontend component broke because of some tiny state issue, or a deployment failed for a reason that wasn't obvious until much later. You gradually become faster because you have seen more problems, collected more patterns, and learned where to look when something goes wrong.
At some point, though, something changes.
You stop measuring your ability as an engineer by how quickly you can type the implementation.
You start thinking more about whether the implementation is actually the right one.
And that distinction has become much more obvious to me since AI started writing code surprisingly well.
The Interesting Part Isn't That AI Can Write Code
When people talk about AI coding, the conversation often starts with how much code a model can generate.
That makes sense. It's easy to demonstrate.
Give an AI agent a requirement, let it work for a few minutes, and suddenly there are hundreds of lines of TypeScript, Python, Go, C#, PHP, or whatever happens to be in the stack.
A task that might previously have required an hour of implementation can sometimes be reduced to a few minutes.
The first time you experience that, it feels almost unfair.
But after using these tools repeatedly, I think the more interesting question is not whether AI can write code.
It clearly can.
The more important question is what happens when writing the code becomes the easiest part of the job.
That is where I think the conversation around AI and software engineering becomes much more interesting.
I've Started Looking at Code Differently
One of the biggest changes AI has caused in my own workflow is that I no longer feel the same attachment to manually writing every piece of code.
And honestly, I don't think that's a bad thing.
There are plenty of things in software development that are intellectually interesting, but there are also plenty of things that are simply repetitive. Creating similar CRUD operations, wiring predictable API endpoints, writing boilerplate validation, generating types, creating standard components, preparing migrations, or implementing another variation of something I've already built dozens of times doesn't necessarily make me a better engineer.
If an AI agent can handle some of that work while I focus on the architecture and the actual problem, I'm happy to let it.
The important part is that I still need to understand what it produced.
That's the difference.
I don't want AI to replace my understanding of the system. I want it to reduce the amount of time I spend expressing that understanding through repetitive code.
In that sense, AI hasn't made me less interested in engineering.
It has made me more interested in the parts of engineering that were always difficult.
Five Minutes of Coding Can Hide Four Days of Engineering
I've encountered situations where the actual implementation was almost trivial once the decision had been made.
Imagine a client asking for a relatively small change to an existing application. From the outside, it might sound like a straightforward development task. Change the behavior, update the interface, modify the API, and ship it.
The actual code might take an AI agent a few minutes.
But before that happens, someone still has to answer a much harder set of questions.
What should the behavior actually be?
What happens to existing users?
Should this change live in the frontend, backend, or both?
Does the current architecture support it cleanly?
What happens to existing data?
Does another part of the system depend on the current behavior?
What are the edge cases?
What happens when the external service fails?
Does the client actually want the technically simplest solution, or is there a business reason for doing something differently?
Sometimes those questions can take days.
And during those conversations, the answer can change several times.
This is something I think gets lost when we compare developers and AI purely through coding benchmarks.
A benchmark can measure whether an agent can implement a defined task.
Real engineering often starts before the task has been defined properly.
The Specification Is Becoming Part of the Engineering Work
This is one reason I keep coming back to specification and system design.
When implementation becomes cheaper, the quality of the specification becomes more important.
An AI agent can take a well-defined requirement and turn it into working code remarkably quickly. But if the requirement itself is incomplete, ambiguous, or based on the wrong assumption, the agent can simply produce the wrong solution faster.
That creates an interesting relationship:
Better specification → better implementation → less correction → lower engineering cost
You can even think about the rough economics of AI-assisted development this way:
Total Engineering Cost = Specification + Generation + Review + Integration + Maintenance
AI is particularly good at reducing the Generation component.
But the other components don't automatically disappear.
In some cases, they become more important.
If generating a feature used to take 8 hours and AI reduces that to 1 hour, that's a huge improvement.
But if the team then spends 6 hours reviewing, testing, discussing, integrating, and correcting the implementation, the total process hasn't suddenly become a 1-hour task.
The bottleneck simply moved.
And I think that is one of the most important things engineers need to understand about AI-assisted development.
Passing Tests Doesn't Mean You Built the Right Thing
This is another area where I think experienced engineering judgment becomes extremely important.
AI can write tests.
AI can run tests.
AI can fix failing tests.
AI can even produce a beautifully structured pull request where everything appears to be green.
But software correctness isn't identical to test correctness.
You can have 100% passing tests and still build the wrong product.
Maybe the requirement was misunderstood.
Maybe the workflow doesn't match how the customer actually works.
Maybe the architecture creates an operational problem six months from now.
Maybe the system technically handles an edge case but creates a terrible user experience.
Maybe the implementation works perfectly in a development environment but becomes expensive when traffic increases.
Those aren't necessarily coding problems.
They're engineering problems.
And they're difficult to solve if you don't understand the system beyond the code being generated in front of you.
AI Is Probably Going to Level the Playing Field
There is another side of this that I actually find quite exciting.
Software engineering has always had a large gap between people who are extremely fast at implementation and people who are slower but exceptionally good at understanding problems.
AI reduces part of that gap.
Someone who isn't particularly fast at writing code can now describe what they need, generate a reasonable starting point, inspect the result, iterate on it, and eventually produce something that would have taken much longer manually.
That doesn't mean everyone suddenly becomes a great engineer.
It means the cost of translating an idea into code is falling.
And I think that's a good thing.
A developer who understands the product, communicates well, makes sensible technical decisions, and knows how to validate AI-generated work can become incredibly productive even if they aren't the fastest typist in the room.
In fact, I suspect that combination will become increasingly valuable.
But There Is a Catch
The uncomfortable part is that this also means some traditional developer skills will become less differentiated.
Knowing how to write another CRUD endpoint from memory is useful.
Knowing how to manually construct boilerplate configuration is useful.
Being able to remember every framework API can save time.
But these advantages become less significant when an AI agent can retrieve the documentation and generate the implementation in seconds.
The valuable question becomes:
What can you contribute that still requires judgment?
Can you understand an ambiguous business requirement?
Can you design a system that will survive growth?
Can you recognize when the obvious implementation is actually the wrong architecture?
Can you identify security risks?
Can you understand the consequences of a database decision?
Can you explain a technical trade-off to someone who isn't an engineer?
Can you look at AI-generated code and recognize that something is fundamentally wrong even though every test passes?
Those abilities become much harder to automate.
The Engineer's Job Is Moving Up the Stack
I don't think software engineers are disappearing.
I think part of the job is moving upward.
The closer your work is to repetitive implementation, the more likely AI will be able to absorb a significant portion of it.
The closer your work is to understanding problems, making decisions, designing systems, coordinating people, managing constraints, and taking responsibility for outcomes, the harder it becomes to replace with simple code generation.
This doesn't mean developers need to become managers.
Quite the opposite.
I think the future engineer can still be deeply technical.
But being technical will mean more than knowing how to write code.
It will mean understanding how systems behave.
It will mean understanding why a particular architecture exists.
It will mean knowing when simplicity is better than abstraction, when a database query is acceptable, when caching is necessary, when an external service introduces too much risk, and when a five-line solution is actually going to create a five-month maintenance problem.
AI can help with those decisions.
It can even make suggestions.
But someone still needs to own the decision.
The Real Skill Is Knowing What to Ask For
This is why I'm increasingly interested in the idea of engineers becoming better at expressing intent.
The better I can describe a system, the easier it becomes to work with AI.
Instead of saying:
"Build me a login system."
I can describe the authentication model, user roles, session behavior, security requirements, failure states, database constraints, API boundaries, testing expectations, observability requirements, and deployment environment.
Now the AI has something meaningful to work with.
That sounds like a small difference, but it changes the relationship completely.
The engineer isn't simply asking AI to write code.
The engineer is communicating a system design and using AI as an implementation partner.
That is a much more interesting future to me.
I Still Want to Code
Despite everything I've said, I don't want to stop coding.
I actually enjoy it.
There is something satisfying about taking an idea, opening an editor, and gradually turning it into something that works. I still spend plenty of time inside codebases, debugging difficult problems, designing APIs, experimenting with technologies, and figuring out why something behaves differently in production than it did locally.
What has changed is what I consider valuable work.
I don't need to prove that I'm a good engineer by manually writing every line.
If an AI agent generates a piece of code that saves me an hour, I'd rather spend that hour thinking about something that actually requires my attention.
And if the generated code is wrong, I want to be experienced enough to recognize why.
That's the part that matters.
Coding Is Becoming Cheaper. Engineering Isn't.
I think we're going to see a strange period over the next few years.
Software will become dramatically cheaper to produce.
Small teams will build products that previously required much larger engineering organizations. Individual developers will be able to experiment with ideas that would once have been too expensive to implement. Businesses that couldn't justify building custom software may suddenly be able to afford it.
That's incredibly exciting.
But it also means the definition of a good software engineer will continue to change.
The engineer who only knows how to produce code may struggle because code production is becoming increasingly abundant.
The engineer who understands problems, systems, people, trade-offs, and technology has a different advantage.
They can decide what should be built before asking how it should be built.
And when AI produces the implementation, they can still tell whether the result deserves to reach production.
That's not a smaller role.
If anything, it's a bigger one.
Conclusion
AI becoming better at coding doesn't make software engineering less valuable.
It makes coding itself less scarce.
And when something becomes less scarce, the things surrounding it become more important.
For years, writing code was one of the biggest bottlenecks in turning an idea into software. AI is rapidly attacking that bottleneck.
I'm not worried about that.
I'd rather have a tool that handles the repetitive parts of implementation while giving me more time to think about architecture, business requirements, reliability, scalability, and the problems that actually matter.
The interesting future isn't one where AI writes all the code and developers disappear.
It's one where the cost of implementation falls enough that engineers can spend more of their time doing what engineering was supposed to be about in the first place: understanding a problem, designing a solution, making difficult trade-offs, and taking responsibility for what eventually gets shipped.
AI may become better at writing code than most developers.
I'm okay with that.
Because being a software engineer was never supposed to be about typing the most code.
It was always about knowing what code should exist in the first place.
Building Something With AI?
I also work with founders, startups, businesses, and teams that need help turning ideas into real software, whether that's an AI-powered application, an AI agent, a web or mobile platform, backend infrastructure, automation workflow, or a custom business system.
Sometimes the challenge is writing the code. More often, the harder part is figuring out what should actually be built and how it should fit into the rest of the system.
If you're working on something and need another engineer to help think through the technical side, feel free to reach out.
Fastwork:
https://fastwork.id/byob/7pFhYwWqZd?openExternalBrowser=1&source=byob
About Me
I'm Restu Ananda, a Software Engineer, Applied Researcher, and Open-Source Enthusiast. I spend most of my time somewhere between software engineering, AI, cloud infrastructure, system design, and building digital products.
I like the coding part, but what keeps me interested is everything around it: understanding messy requirements, figuring out why a system behaves the way it does, choosing between imperfect technical options, and turning an idea into something people can actually use.
Outside of commercial work, I'm also open to contributing my technical skills to selected educational, research, community, and non-commercial projects whenever I have the capacity to help.
If you're building something interesting, have a difficult technical problem, or simply want to talk through an idea before turning it into a product, my inbox is open.
Top comments (0)