Note: Throughout this document, the terms LLM and AI are used interchangeably, both referring to Generative AI .

I have always been an early adopter of new technologies. As Barney Stinson once said, “new is always better. ”

By the time ChatGPT came out, I was already using GitHub Copilot beta. Before that, I had used Tabnine. I had also been following OpenAI for years, first through their Dota 2 reinforcement learning project, where their agents beat some of the best players in the world. Later, I used their Davinci models in the OpenAI Playground to help with essays and document completion. So when ChatGPT arrived, I did not need much convincing. I jumped in immediately.

At the time, I was an intern at Nokia, and I started using it for coding. I would paste blocks of code and ask simple things like “modularize this,” “rewrite this with better syntax,” or “what is the purpose of this code?” Those early days felt harmless. The model was useful, and I felt in control. I was the engineer, and the model was the assistant. But every few months, a stronger model or tool came out, usually announced with better benchmarks and louder claims. I have my own problems with those benchmarks, and I will write about that separately. Still, with every new release, the line moved a little. What started as asking ChatGPT for help became writing inside Cursor, then letting Claude Code handle larger chunks of work, then connecting tools, MCPs, Infra, and agents that would do more than just suggest code. None of it felt like a sudden change. It felt like adopting the next useful thing. Then, a week ago, I realized something that scared me: I no longer felt like a software engineer.

In this series of posts, I want to talk about how I got seduced by AI-assisted coding, how that slowly turned into careless dependence, why it scared me, and why I am now trying to step away from that pattern.

Note: Everything mentioned here is just my personal experience. It does not reflect or diminish the value of AI in software development. I am a big fan of AI, and I think it can be a great tool for engineers. I am also confident that many great engineers have found workflows that work perfectly well for them and help them thrive. This is just my story among many others.

Chapter One: The Art of Seduction

There were multiple reasons why I became addicted to AI and slowly started weakening some of my best abilities. They came in different shapes and forms, but they can mostly be summarized in one sentence:

I started asking models for more than I could understand, verify, and own.

I hoped that other strategies could make up for that gap: separate agent code reviewers, looking at the code from different angles, giving better context, using sub-agents, or simply using stronger models. All of those strategies are useful, and they did help me in various ways. But they did not eliminate the core problem: I was no longer the true owner of the code.

But why would someone go down that path?

I think the answer is simple: because it is easy.

1. Speed: The Obvious Temptation

Agents are lightning fast. They can generate an amount of code that would take a team of engineers days or weeks to write, sometimes in less than an hour. In extreme cases, this can mean hundreds of thousands of lines of code .

In today’s market, where everyone is trying to ship endless features and 9-9-6 culture is increasingly normalized, especially in startup environments, it is easy to give in. It feels like you are being left behind if you do not do it. That feeling becomes even stronger when you hear Garry Tan, CEO of one of the greatest startup accelerators in the world, say that one out of every four startups in the latest YC batch has 95% AI-generated code . You start to feel like you have to use agents this way just to keep up with the competition. So you open the agent and write, “Create my B2B SaaS app with $2M ARR. Make no mistakes.” And bam, you have your SaaS app. Just kidding.

2. Decision Making: The Relief of Not Choosing

There are numerous studies showing that decision making is hard and mentally expensive. But with agents, there is an extra layer: every time you face a decision you do not have the knowledge to make confidently, you also face another decision. Should I ask AI to do it, or should I research it myself? That is a decision in itself. Over time, it becomes more pleasant to just let the AI do it for you. In the meantime, you can scroll through Twitter and read Thariq’s latest prompt hacks . The agent removes friction at the exact moment when friction is supposed to teach you something.

3. The Short’cut’

As a software engineer, it is inevitable that you will face challenges that require new knowledge or skill. Sometimes that means learning a new language, a new framework, or a completely unfamiliar domain. In those moments, you usually have two options. You can learn it yourself, which is often time-consuming, frustrating, and uncertain at first. You might not know whether you are using the right syntax, the right pattern, or the right abstraction. Or you can ask an agent to do it for you . The second option becomes even more tempting now that everything has agentic documentation, Context7 , and other tools that can fetch and package the context for you. There is even a Hacker News discussion about Context7, which captures how quickly this ecosystem is forming around agent-friendly development.

This becomes a bigger problem if you are an early-career engineer and you are still building your foundation. Sometimes, like me, you are too eager to climb the ladder. You want to move fast, prove yourself, and deliver. So you end up asking agents to do things that you should probably be doing yourself.

Chapter Two: The Cost of Surrender

The problem with all of the above is that they are short-term benefits. They feel good in the moment, but they come with long-term consequences. They can weaken your engineering mind. The more I used agents, the more I relied on them. The more I relied on them, the less I questioned. The less I questioned, the more I lost ownership. And the more I lost ownership, the more the agent became the real owner of the work. At that point, it starts to feel like you are stuck.

You are midway through a project that now has 200K lines of code, and you have only a rough idea of how it works. You have some idea of how to fix things if something goes wrong, but not enough to feel confident. Meanwhile, there are already 10 new features that need to be built on top of existing features you barely understand. Any alternative feels scary, so you keep going back to writing more LLM-generated code. Then you start building practices that empower the agents more than they empower you… and the rabbit hole gets deeper.

1. First Goes Fluency

The more you ask agents to write code for you, the less you practice writing code yourself.

This means your learning slows down significantly, if it does not stop altogether. You also start to experience decay around syntax, patterns, and best practices. The scariest part is that this does not only affect your ability to write code. It also affects your ability to review the AI-generated code in front of you. You might be able to spot some obvious mistakes, which is where LLMs gets better actully, but you might miss more subtle issues.

2. Then Goes the Shape of Thought

This is similar to syntax decay, but it happens at a higher level. The higher you move in abstraction with agents, the less you practice the lower-level work yourself. You spend less time breaking complex problems into smaller parts. You spend less time sitting with ambiguity. You spend less time forming a model of the system in your own head. Over time, this becomes a loop. Because you are less practiced, you go back to AI more quickly. And because you go back to AI more quickly, you practice even less. That is the real cognitive decay.

3. Finally, You Slide Into Cognitive Surrender

There is a recently published paper called “Thinking: Fast, Slow, and Artificial ”.

It supports some of the ideas discussed above, including the idea that people tend to rely more on AI when time is limited. The paper also introduces a term that I think captures the danger well: cognitive surrender. Cognitive surrender is a psychological phenomenon where individuals outsource their reasoning to artificial intelligence and quietly adopt the AI’s output as their own without independent scrutiny or verification. To me, this is the most dangerous outcome. And as I mentioned above, it is usually not sudden. It is slow, gradual, and hard to notice while it is happening.

You start with cognitive offloading, which is the act of delegating specific tasks to external tools. This can be something as simple as using a calculator for complex math or relying on GPS for navigation. Cognitive offloading is not inherently bad. In many cases, it is useful. It can free up mental resources for more important tasks. But AI is different because it can be used for almost everything. When you combine AI with time pressure, lack of expertise in parts of your work, and the constant temptation to avoid friction, cognitive offloading can slowly turn into cognitive surrender. And once that happens, you may still be shipping software, but you are no longer fully practicing software engineering.

Chapter Three: Rehabilitation

Coming soon.

---

💡 Fun Fact: My favorite Persian food is kabab koobideh.