Dopamine, Debugging, and the Dopamine-Loss of AI-Assisted Coding

Circa 2014, back when I was working for Demac Media, I recall a Black Friday incident when a client’s site’s checkout process ground to a halt. Every order submission started to timeout at around 3am, right when traffic was starting to pick up (yes kids, people woke up early in the morning for Black Friday deals).

Cue Panic. For hours, we scrambled—combing through logs, deploying desperate hot-fixes, watching them fail. The pressure was immense; every minute of downtime cost thousands of dollars.

Finally, after what felt like an eternity, we found it: a subtle race condition in a third-party plugin. The fix itself was trivial—a single line of code to adjust the lock timing. We deployed it, and the system started recovering. The feeling was not just relief. It was a euphoric, adrenaline-fueled rush. We fought a fire and won.

Contrast that with another memory: the quiet satisfaction of a long, uninterrupted afternoon spent refactoring a complex shipping calculation module. There was no fire, no panic. Just a tangled knot of logic and hours of deep, focused work. I remember the moment the last test passed—a clean, green wall of confirmation. It wasn’t a rush; it was a profound sense of accomplishment, of having brought order to chaos.

Now, consider what today's developer experience is like. You are working on a small, non-trivial problem involving data serialization. Instead of diving in, you describe the issue to an AI assistant.

# lib/my_app/worker.ex
def handle_cast({:process_data, data}, state) do
  # The `data` is a mix of structs and plain maps, but Jason
  # needs everything to be serializable. Some structs don't
  # derive the Jason.Encoder protocol.
  json_string = Jason.encode!(data)
  # ... send to external service
end

The AI Agent responds almost instantly.

The error occurs because some structs in your data do not implement the Jason.Encoder protocol. You can fix this by creating a protocol fallback implementation that converts any struct to a map before encoding.

Add this to lib/my_app/jason_fallback.ex:

defimpl Jason.Encoder, for: Any do
  def encode(value, opts) when is_struct(value) do
    value
    |> Map.from_struct()
    |> Jason.encode!(opts)
  end
end

This implementation catches any struct that doesn't have a specific Jason.Encoder implementation and converts it to a map, making it serializable.

The code is correct, working on the first try. And while there is a certain satisfaction in the efficiency of getting the answer, something is missing; there is no dopamine rush, no satisfaction in the struggle, no sense of accomplishment. It's a mechanical, almost sterile, experience.

Developers and feedback loops

A quick search online, and a few conversations with friends tell me that I'm not alone in this feeling. The emotional range of the work has narrowed. The feedback loop that once defined the craft of programming has been irrevocably broken.

There is this concept called Reward Prediction Error (RPE) in neuroscience. It suggests that the dopamine response is strongest not when we receive a reward, but when we receive an unexpected reward.schultz-2002

This kinda maps very well to the traditional coding loop. Trying different solutions and eventually succeeding produces a significant dopamine spike. Through each failed attempt, we dug the hole deeper. When the solution finally worked, the resulting reward signal was enormous because the outcome so dramatically exceeded the expectation.

The AI assistant does the opposite. It makes the prediction of success near 100%. I give it a problem; I expect a solution. When it delivers, the outcome matches the prediction. No error, no surprise. No rush.

Struggling and cognitive work

The AI isn't just "writing code" (or as some call it, generating slop). It's replacing the entire feedback loop of manual debugging that creates the potential for reward. It removes the intermediate steps, the struggle, the cognitive work that forces a deeper understanding of the system.

In essence, it removes everything that makes the eventual success feel like a victory. Think about the process of debugging a failing test without an AI:

$ mix test test/my_app/calculator_test.exs:12
..

  1) test calculates the correct tax (CalculatorTest)
     test/my_app/calculator_test.exs:12
     Assertion with `==` failed
     code:  assert Calculator.calculate(order) == %{total: 120.0, tax: 20.0}
     left:  %{total: 120.0, tax: 0.0}
     right: %{total: 120.0, tax: 20.0}
     stacktrace:
       test/my_app/calculator_test.exs:14: (test)

My tax is 0.0. It should be 20.0. Why? My first hypothesis is that the tax rate is wrong. I'll inspect the rate being applied.

# lib/my_app/calculator.ex
def calculate(order) do
  rate = get_tax_rate(order.shipping_address)
  IO.inspect(rate, label: "Applied tax rate")
  # ...
end

I run the test again. The console shows Applied tax rate: 0.0. The rate is zero. Now, why is the rate zero? I have to trace get_tax_rate/1. This process of hypothesis, investigation, and feedback continues—sometimes for minutes, sometimes for hours—until I build a mental model of the code, find the flawed assumption, and fix it.

That is all gone with AI assistance. It eliminates the friction. And while much of that friction is just wasted time waiting for slow tests or deployments, some of it is useful cognitive work that forces a deeper understanding of the system.

Dulling of expertise

Aside from the dopamine loss, outsourcing the cognitive work to AI has more serious and long-term consequences. As developers, we are constantly building and refining our mental models of the systems we work on. This is how we become experts.

But now we are outsourcing that cognitive work to AI. We are no longer forced to build and refine our mental models. We are no longer forced to understand the systems we work on. We are no longer forced to think critically about the code we write.

There is an interesting analog in the research on GPS use and spatial memory.dahmani-2020 A 2020 study tracked the lifetime GPS habits of 50 drivers and found that the more someone relied on GPS, the worse they did at spatial memory when they had to navigate on their own. Retested three years later, the heaviest GPS users showed the steepest decline in the hippocampal-dependent memory that builds a mental map of a place.

There is not a lot of research on the effects of AI-assisted coding on cognitive work, but it is reasonable to assume that the same effect is happening. In the 2023 study "Grounded Copilot: How Programmers Interact with Code-Generating Models"barke-2023 the authors watched twenty programmers work with an AI assistant and found the interaction was bimodal. In acceleration mode the developer already knows what to write and uses the model to get there faster; in exploration mode they are unsure how to proceed and use it to feel out the options.

In both modes, a large part of the work becomes reading and validating what the model suggested rather than writing it from scratch.

A 2025 survey of 319 knowledge workers found the same pattern outside of coding.lee-2025 The more people trusted the AI, the less critical thinking they reported doing; the more they trusted their own judgment, the more they did. The effort that stayed had shifted toward verifying the output, integrating it into the task, and supervising the result instead of producing it.

In effect, the developers stop being the sole author and become the editor/reviewer of the AI's output. I've noticed a similar change in my own work. My time is now spent less on "how do I solve this?" and more on "is this the right solution?" or "how does this correct solution fit into the broader system?". This is definitely a change in the way we work.

Where does this leave us?

Based on all the above, it is not unfair to say that AI is drastically changing the software industry and what it means to be a developer. And it is impossible to predict how much more things will change as these tools keep evolving, and as people learn new ways to work with them.

I expect that the next few years will be a period of rapid change and adaptation. The tools will get better, the workflows will evolve, and the skills required to be a successful developer will shift.

As a final thought, I have found that managers, CTOs and in general people who had to do a lot of people management are having less trouble adapting to this new reality. They are used to managing people and processes, and they are used to a different reward loop, considerably more context switching, and less direct feedback.

So maybe the future of software development is not about writing code, but about managing the process of writing code. The AI is just a tool, and like any tool, it can be used well or poorly. The question is not whether AI will replace developers, but how developers will adapt to this new reality.