KI and Coding: Will We Become Faster, but Flatter?

A contribution from the KI-Kantine by Michael Busch

ChatGPT and Co. promise to revolutionize programming. A short prompt, and the AI spits out working code – whether for complex web applications or a small script on the Raspberry Pi. But while we celebrate this progress, an important question arises: What do we lose in the process?

The “Circle of Doom” as a Learning Process

Previously, the development process often looked like this: You wrote code, it didn’t work, you consulted documentation, corrected errors, and eventually – after many attempts – everything worked. This arduous, sometimes frustrating process could be described as the “Circle of Doom”. But precisely this cycle had a crucial advantage: You really learned something. With each iteration, your learning curve flattened and your understanding deepened.

The AI-Assisted Coding Process

Today the process often looks different: You write a prompt, the AI presents you with various solutions, you choose one, and the function is finished – ideally even functional. What initially seems like a pure gain, however, has its downsides.

A particularly apt quote from an article that recently made me think is:

“We are creating a generation of developers who are very quick at shipping, but they can no longer explain why the code actually works.”

The Navi Syndrome

This phenomenon is reminiscent of navigating with GPS: You arrive at your destination, but you have no idea how you got there. You couldn’t retrace the route from memory. chfahren. It is ironic that many AI assistants like GitHub Copilot actually call themselves “co-pilots” – because, just like with a GPS, constant dependence can lead to us losing our own navigational skills.

Why This Is a Problem

Things become particularly critical when something goes wrong. If code you don’t truly understand suddenly stops working, you’re faced with an unsolvable puzzle. The AI may try to fix the error – often through a series of “lucky shots” – but in doing so, it may alter so many other aspects of the code that the chain of functionality is even harder to trace.

Programming requires a mental model – an internal picture of how everything connects. Without this self-constructed understanding, debugging becomes a guessing game:

“You can’t debug something you don’t understand yourself.”

Finding a Balance

The solution, as often is the case, lies in the middle. KI is a valuable tool – a helpful colleague – but it doesn’t replace your own thinking. At the end of the day, you’re the developer who needs to understand why the Raspberry Pi is suddenly blinking or not blinking.

One approach could be to consciously choose not to take the easy way sometimes and write code without KI support – simply to not lose the feeling and understanding. Because, as the mentioned article correctly states: “Repetition is how you learn” – and it’s precisely this repetition that KI often takes away from us.

Conclusion

KI undoubtedly revolutionizes the way we program. It makes us faster and more efficient – but perhaps also more superficial in our understanding. The challenge is to use these powerful tools without sacrificing the depth of understanding.

Perhaps we should ask ourselves with the next KI-generated code: Do I truly understand what’s happening here? Or am I just copying? The