The change is happening fast – and those in the middle of it sometimes barely notice. I want to share an honest perspective on how I experience the transformation from a classical engineer to what is now called an AI-Native Software Engineer.
The Beginning: From Small Automations to Team of Agents Workflows
It started with tools like Cursor or Windsurf – useful, but at their core just assistants for manageable tasks. With targeted prompts, certain workflows could be automated, but the possibilities remained limited. That has fundamentally changed. Tools like Claude Code, combined with well-crafted Skills and the “Team of Agents” approach, open up an entirely different dimension today – both in terms of the complexity of automated tasks and the maturity of the workflows themselves.
An important part of this transition was also the budget question: without the right investment, engineers cannot truly unlock these new possibilities. Only when the financial headroom exists does the creative and technical potential fully unfold.
The Productivity Paradox
More productivity does not mean less work – that is one of the central experiences of this transformation. Quite the opposite: the overall workload increases significantly. Because everyone delivers faster, more requests come in. Because processes get automated, new processes emerge that need to be managed in turn. A cycle that accelerates itself.
Claude Code and similar Skills help structure this chaos. But that does not solve a different, deeper problem: the problem of human core competency.
Why Deep Understanding Matters More Than Ever
What easily gets lost in all this speed is genuine understanding of what you are actually working with. Business logic, architectural decisions, process interdependencies – these are not nice-to-haves. They are the foundation for being able to meaningfully evaluate AI outputs at all.
A concrete example from practice: Claude Code sometimes produces incorrect statements about the number of tests executed daily. This is not because the tool is bad – it is because the context needed to interpret the numbers correctly is missing. A typical pitfall: the repository for Large Tests – browser-based end-to-end tests using tools like Selenium or Playwright – also contains unit tests that cover test support code. These unit tests do not belong to the Large Tests, even though they live in the same repository. If you do not know this, you count them anyway – and draw the wrong conclusions. Claude Code makes exactly this mistake when the relevant context is not explicitly available. And that is precisely where the engineer’s responsibility lies: knowing why a number might be wrong – even when it looks plausible at first glance.
One response to situations like this is “just build better Claude Skills” – and yes, that is right and important. But even the best Skills do not solve the fundamental problem: in an environment where everyone works three times faster, switches context more frequently, and is constantly under time pressure, mistakes become harder to catch – not easier.
Thinking Fast and Slow – Applied to Engineering
This brings me to a concept I consider essential: Daniel Kahneman’s “Thinking Fast and Slow.” The book describes two cognitive modes – fast, intuitive thinking and slow, deliberate thinking. What Kahneman describes for the human mind translates directly to working with AI tools.
Fast mode is exactly what Claude Code is built for: rapid feedback, quick suggestions, fast iteration. In most cases the results are good – and you can be genuinely productive. But slow mode is equally necessary: deliberately pausing, actively switching your brain on, and not simply letting everything run on autopilot.
A concrete example from my own practice: I use Claude Code to analyze whether the last production deployment caused any issues – but I do not let it run blindly end to end. I execute the queries myself, actively read through the logs, question the results, and ask myself whether what I am seeing is actually what I would expect. Only once that process has been thought through and validated does it become a Skill – so that this exact log inspection tour can be run in an automated and repeatable way going forward. Slow mode is therefore not the opposite of automation. It is the prerequisite for automation that actually makes sense.
Those who operate exclusively in fast mode will eventually find that they get answers quickly – but no longer know whether those answers are correct.
The Black Box Trap
This brings me to a final point that I feel strongly about. When colleagues build Skills that automate certain processes like magic, the temptation is strong to simply use them – without understanding what is actually happening underneath.
And that is exactly what increasingly happens in practice: in the accelerated pace of day-to-day work, Skills get run on autopilot – without really thinking about them. In most cases that works fine – the automation does what it is supposed to do and saves valuable time. But the slow mode principle applies here too: it matters to understand at least the concepts and the rough mechanics behind a Skill.
Because ultimately, it is domain expertise that makes the difference. Only those who genuinely understand the subject matter can make a qualified judgment about whether a response from Claude Code is correct – or whether it is a hallucination. Without that foundation, there is simply no benchmark to distinguish right from wrong.