
An engineer's perspective on adapting to AI without losing the creativity, curiosity, and satisfaction of building software.
I remember the days when there were no large language models (LLMs) or agentic tools to code for us. The days when we used to Google our problems, look for answers on Stack Overflow, or reach out to developer communities to find solutions.
Sometimes someone had already encountered the same problem and shared a solution. Other times, we had to open a new question, explain what we were trying to achieve, and wait for someone to help. And when someone else had a problem, we would do our best to help them.
For decades, this was one of the primary ways engineers and developers learned, worked, and shared knowledge. And honestly, one of the crucial parts of becoming a senior engineer was being good at finding solutions to problems faster and more effectively.
It wasn't always easy. We had to investigate, experiment, read documentation, understand other people's code, and sometimes spend hours debugging something that would take seconds to explain to an AI today.
But there was something rewarding about that process. We learned along the way. We developed a deeper understanding of the problems we were solving and the technologies we were working with. And, most importantly, we had the satisfaction of figuring things out ourselves.
The following chart gives us an interesting perspective on how much the landscape has changed:

Everything changed in November 2022 with the introduction of ChatGPT, initially powered by GPT-3.5.
At first, it seemed like just another chatbot. We could ask questions, get explanations, and generate some code. But as we explored it further, we realized that we were looking at something much more significant.
Fast-forward to today, and we've gone from chatbot-like environments to AI-powered IDEs such as Windsurf and Cursor, and agentic coding tools such as Claude Code and Codex. These tools have fundamentally changed how we approach software development.
And if we're being honest, many of us don't spend as much time manually writing code as we used to. AI can generate boilerplate, implement features, write tests, refactor existing code, investigate bugs, and even work across entire codebases.
The pace of development has become insane.
Every morning, we wake up expecting something new that might make a tool we started using just a few weeks ago feel outdated. New models, new capabilities, new workflows, and new approaches keep emerging.
Whether we like it or not, this is the current state of the software industry: everything revolves around developing faster and shipping faster.
Of course, this comes with its own advantages and disadvantages, and we'll get to those throughout this article.
But there's a more interesting question here.
Are we still enjoying programming, or are we gradually turning into AI operators?
Are we becoming engineers who use AI to build better software, or are we simply becoming people who describe what they want and accept whatever the machine produces?
That's what I want to explore.
Throughout this article, I'll share some thoughts on finding the right balance between taking advantage of AI, understanding its limitations, and continuing to enjoy programming without allowing these tools to make our minds lazy.
I don't want us to become Vibe Coders who no longer understand the code they're producing, or simply operators who tell AI what to do without understanding the engineering behind it.
This is my personal perspective, based on around nine years of engineering experience and being actively involved in this industry.
Before going any further, we should establish something: Who are we as developers and engineers?
Were you someone who mostly copy-pasted code, followed tutorials, and focused on getting things working without caring too much about the engineering behind them?
Or did you actually care about architecture, clean code, scalability, security, performance, best practices, and all the other things that make software engineering more than simply writing code?
These are two very different mindsets, and AI has made that difference even more important.
If your professional value has always been limited to translating relatively straightforward requirements into code, I've got some bad news for you: AI is making that kind of work increasingly replaceable.
A Vibe Coder can already accomplish many tasks that previously required a developer. And if we're being more precise, writing code has never necessarily been the hardest part of building software.
Understanding what needs to be built, making the right architectural decisions, dealing with complex business requirements, ensuring reliability, and maintaining a product over time are often much harder.
The difference is that, for a long time, businesses had to hire developers to handle a considerable amount of implementation work, including tasks that were repetitive or relatively straightforward.
Now, AI can take over an increasing portion of that workload.
This doesn't mean every developer without strong engineering skills will immediately lose their job. But it does mean that relying solely on the ability to write code is becoming a much weaker professional advantage.
And that's a distinction we should take seriously.
Unfortunately, we're already seeing the effects of this transformation in the job market.
It's not just about changes in the overall number of job postings. Opportunities for junior developers have also become a growing concern.
Historically, companies hired junior developers to contribute to implementation tasks, learn from senior engineers, and gradually develop the skills needed to take on more complex responsibilities.
It was a natural progression: juniors handled less complex tasks, seniors provided guidance and architectural direction, and everyone gained experience along the way.
But imagine a company that can now assign a significant portion of those straightforward tasks to AI agents while having one or two experienced engineers review and guide the output.
From a purely short-term business perspective, some companies may find that approach more attractive than hiring, training, and managing additional junior developers.
And that's a serious problem for the next generation of engineers.
Because if companies reduce opportunities for juniors to gain practical experience, where will the next generation of senior engineers come from?
It's a question I don't think the industry has properly answered yet.
We've also witnessed layoffs across companies of different sizes. AI isn't necessarily the only reason behind these decisions, and it would be inaccurate to attribute every layoff to automation. Economic conditions, overhiring, changing business priorities, and other factors also play significant roles.
However, AI has introduced another way for companies to increase productivity while potentially operating with smaller teams.
And naturally, this changes what businesses expect from developers.
At the same time, we've seen enormous amounts of money flowing into AI startups and companies since 2023. But the expected returns and sustainable business models haven't materialized as quickly or as universally as some initially anticipated.
Personally, I think it's reasonable to question whether parts of the AI market are overheating, much like the Dot-com bubble.
This doesn't mean AI itself is a bubble or that its impact isn't real. The technology is already transforming industries. But not every AI startup will become a successful business, and not every company building an AI-powered product has a sustainable competitive advantage.
Think about it: a small startup might build an entire business around a particular AI feature, only for a much larger company such as Google, Meta, or Anthropic to introduce a similar capability as part of its existing products.
Having a good idea and building a working product is no longer enough on its own.
And this brings us back to software engineering.
Now let's talk about the second category: developers who care about the engineering side of software development.
At the time of writing this article, agentic coding tools have become incredibly capable. They can develop complete applications, implement complex features, refactor existing codebases, and handle tasks that would previously have required considerable development time.
We shouldn't underestimate that progress.
However, even powerful models and tools still have limitations when it comes to areas such as architecture, scalability, security, maintainability, and understanding complex business requirements.
This doesn't mean they can't produce good-quality applications. They absolutely can.
The important distinction is that producing good code and making good engineering decisions aren't always the same thing.
An AI agent might successfully implement a feature based on the instructions you provide. But does that feature fit the existing architecture? Is it consistent with the business requirements? Will the implementation remain maintainable as the product grows? Does it introduce security vulnerabilities? What are the trade-offs?
These are questions that require judgment, context, and a deep understanding of the system.
Someone needs to define the requirements, establish the constraints, guide the implementation, evaluate the output, and take responsibility for the final result.
And that someone should be an engineer who understands what they're building.
There's also an important distinction worth understanding about LLMs themselves.
They don't understand concepts in exactly the same way humans do. At their core, these systems are trained to identify patterns and generate likely continuations based on their training data and the context they receive. They process information as tokens and use enormous computational resources to predict what comes next.
This doesn't diminish their capabilities. The results can be genuinely impressive.
But it does explain why they can sometimes produce an implementation that looks convincing, follows the immediate instructions, and even passes a basic test while still being fundamentally wrong for the system.
They don't automatically know your business priorities, the unwritten architectural decisions behind your codebase, or the long-term consequences of a particular implementation. You have to provide that context, and even then, you need to verify the result.
This is where engineering knowledge becomes incredibly valuable.
The more you understand architecture, design principles, security, performance, and maintainability, the better you can guide these tools and identify problems in their output.
In fact, I would argue that the value of knowing how to engineer software is increasing, even while the value of manually writing every line of code is decreasing.
If AI is becoming increasingly capable of implementing software, what should we focus on as developers?
I don't think the answer is to learn every new AI tool or chase every new model release. Those tools will keep changing.
Instead, we should invest in skills that allow us to use any of them effectively.
AI can suggest solutions, but you need to understand the problem well enough to know whether those solutions make sense.
Sometimes the hardest part of development isn't implementing a feature. It's identifying what the actual problem is, understanding why it exists, and deciding which solution is appropriate.
Building something that works today is one thing. Building something that can evolve, scale, and remain maintainable is another.
Understanding how components interact, how data flows through a system, where responsibilities belong, and what trade-offs you're making will remain essential.
Clean code isn't just about formatting or following a particular style guide. It's about making software understandable, predictable, testable, and easier to change.
AI can generate code, but someone needs to make sure that the codebase doesn't gradually turn into an unmaintainable collection of individually functional implementations.
A feature that works isn't necessarily a feature that's safe or reliable.
Authentication, authorization, data validation, error handling, race conditions, data consistency, and security vulnerabilities are areas where blindly trusting generated code can become extremely expensive.
You shouldn't just understand how to implement a requirement. You should understand why it exists.
What problem is the business solving? Who is the user? What happens when something goes wrong? Is the proposed implementation actually the right solution?
The ability to connect technical decisions with real business needs is a significant advantage.
Working with AI doesn't eliminate the need to communicate. In fact, it makes clear communication even more important.
You need to express requirements, define constraints, explain existing systems, review proposals, and communicate decisions with other engineers and stakeholders.
The better you are at these things, the more effectively you can leverage AI.
This is probably the most important practical part of the article.
I'm not suggesting that we stop using AI, go back to writing everything manually, or pretend these tools don't exist.
That would be both unrealistic and counterproductive.
Instead, I think we should change how we use them.
Before asking an AI tool to implement something, take some time to understand the problem yourself.
Think about possible approaches, identify potential edge cases, and consider how the feature should fit into the existing system.
You don't necessarily need to come up with the perfect solution before using AI. But having your own understanding gives you something to compare its suggestions against.
Don't assume that an answer is correct just because it sounds confident or the implementation looks impressive.
Review the code, question architectural decisions, validate assumptions, and ask for alternative approaches.
Treat AI-generated output as something that needs engineering review, not something that automatically deserves approval.
This is particularly important when working with agentic coding tools.
Don't blindly accept enormous changes simply because the tests pass or the agent says the task is complete.
Read the diffs. Understand the important changes. Run the application. Verify the behavior. Check edge cases. Make sure the implementation follows the project's standards.
If you can't explain what a significant part of your application does, that's a warning sign.
When an agent implements something unfamiliar, ask it to explain the approach, compare alternatives, and describe the trade-offs.
Don't just take the result and move on.
Use the opportunity to understand a new technology, explore an unfamiliar part of the codebase, or learn a better way to solve a problem.
Sometimes, try solving a problem without AI.
Read the documentation, investigate the issue, write a small implementation, or debug something yourself.
You don't need to do this for every task, and you certainly don't need to make your workflow unnecessarily inefficient.
But maintaining the ability to think independently is important. Otherwise, you risk gradually losing confidence in your own problem-solving skills.
Frameworks, libraries, IDEs, and AI tools will come and go.
The fundamentals of computer science, software engineering, networking, databases, operating systems, algorithms, and system design provide a foundation that makes adapting to new technologies much easier.
The better you understand the fundamentals, the less dependent you become on any particular tool.
Now, let's get back to the original question.
Can we still enjoy programming in the AI era?
I think we absolutely can. But perhaps we need to reconsider what makes programming enjoyable in the first place.
For many of us, the satisfaction of programming was never exclusively about typing code.
It was about solving problems, discovering how things work, experimenting with different approaches, building something from scratch, and seeing an idea turn into a working product.
Sometimes, it was spending hours investigating a difficult bug and finally finding the missing piece. Sometimes, it was discovering an elegant solution to a complicated problem. And sometimes, it was simply learning something new and realizing that you could build something you couldn't build before.
AI doesn't have to take those experiences away from us.
In fact, it can make them more accessible.
We can spend less time on repetitive implementation tasks and more time exploring ideas, experimenting with technologies, improving architecture, and building products that would previously have required much more time and effort.
But there's a catch.
If we allow AI to make every decision, solve every problem, and implement everything without our involvement, we might become more productive in the short term while gradually losing the very skills and experiences that made us enjoy this profession.
And that's something we should avoid.
Don't measure your productivity by how many lines of code you generate or how many tasks an agent completes. Focus on what you're actually building, the problems you're solving, and the quality of the result.
Keep working on personal projects. Explore technologies you're curious about. Contribute to open-source projects. Read documentation. Experiment. Build something just because you find it interesting.
Not everything needs to be optimized for productivity, business value, or delivery deadlines.
Sometimes, it's perfectly fine to enjoy the process.
One thing I think we should accept is that the software industry is changing permanently.
The applications we build today and in the future aren't necessarily going to be simple TODO apps, personal dashboards, or basic CRUD applications.
These kinds of applications are already relatively easy to build with a good prompt, even using freely available AI models.
Non-technical people can now build many personal projects, prototypes, and relatively simple applications through Vibe Coding.
And that's a good thing. Making technology more accessible is not something we should be against.
But it also means that simply knowing how to turn a basic requirement into a working application is becoming less valuable as a professional advantage.
The bar is moving.
Companies still need engineers who can understand complex problems, make good decisions, design reliable systems, and build products that solve real problems.
They need people who can use AI to accelerate development without sacrificing quality, security, maintainability, or the actual needs of the business.
In other words, the competitive advantage isn't going to be how many prompts you can write or how many AI tools you know how to operate.
It's how effectively you can combine your engineering knowledge, problem-solving ability, creativity, and the capabilities of these tools to deliver something valuable.
And that requires much more than prompting.
I don't know exactly what the future holds.
Perhaps AI will become much better at architecture, system design, security, and handling complex engineering decisions. Perhaps some of the limitations we're seeing today will become irrelevant in the coming years.
We should be open to that possibility. Underestimating the pace of AI development would be a mistake.
But we shouldn't let uncertainty about the future become an excuse to stop thinking, learning, or developing our own skills.
We have to adapt. That's part of being an engineer.
Learn the tools. Use them. Experiment with them. Take advantage of what they offer. But don't let them take away your curiosity, creativity, and ability to solve problems independently.
AI should make us better engineers, not turn us into people who simply operate AI.
And perhaps that's the most important thing to remember:
We don't have to compete with AI at writing code. We have to become better at understanding problems, making decisions, and building things that genuinely matter.
So, can we still enjoy programming in the AI era?
Absolutely. But let's make sure we're still the ones doing the thinking.

Strict TypeScript is now the default, Metro sheds weight, Swift Package Manager sneaks in as a CocoaPods alternative, and AGP 9 support lands.

React Native 0.86 lands with zero user-facing breaking changes, full Android 15 edge-to-edge support, powerful new DevTools tracing, and a brand new home.