Today I listened to a talk, followed by a discussion, about mastery in the times of AI and agentic engineering. Mastery is one of my company’s core principles, besides Autonomy and Purpose.

The presentation

The main theme of the talk was essentially the question, how to master the skills of software engineering, when AI takes away most of your tasks. My colleague mentioned activities such as “writing code, thinking about edge cases, debugging, reading documentation to understand languages and frameworks and also creating software architectures”. All of these activities would have a different meaning, when AI takes them over. What should we “master” instead?

He also showed innovation cycles and argued that in each cycle, the (hard) skills needed to work with a certain technology have become simpler, also called de-skilling. He said up until now, only the manual skills were affected, but this time it’s thinking. He finished this talk by showing studies and quotes confirming his argumentation.

Rhetoric & presentation

From a rhetorical perspective the presentation mainly relied on studies from academia supporting his position. I don’t know if he also looked for other studies, challenging his arguments. I believe these exist and in my opinion belong to a well-balanced presentation.

His presentation was very authentic, because it was addressed as an open question, and you could feel, that my coworker doesn’t have an answer to the question. He was interested in the discussion and his presentation served just as a door opener for that.

Innovation Cycles

I want to pick up his argument from above and rephrase it a little bit. I think the cognitive load required to work with a technology has become simpler in each innovation cycle. Take now carriages, cars and autonomous EV vehicles as example. While you need definitely hard skills to go by carriages (if you’re the driver), the requirements and also the cognitive load decreased in each innovation step. For car driving, you need fewer skills and also less mental activities as for carriages and in autonomous vehicles it’s even less. So the “thinking” (mental or cognitive load) already decreased in each innovation cycle, not just only by the new innovation cycle of AI. It has always been like that.

AI takes away tasks from humans

The whole discussion was just focused on the aspect of coding itself, but the job profile of a software engineer is very broad. AI can be used for many different tasks. Me personally, I use it to write stories, to debug issues, to generate prototype implementations, to write and polish documentation and to generate PlantUML diagrams, too. Not only for agentic engineering to write code.

The purpose of a software engineer is not to write code. It is providing solutions for customer problems. The more time I can spend solving these problems, the better. I’m happily delegating away all cumbersome and manual tasks to focus on understanding business problems, creating solution proposals and turning it into code together with AI agents.

And that’s where I believe the real productivity gains lie. Not by generating faster code, but rather by focus on more important problems and faster iteration to a problem solution.

Mastery

I think Mastery still has its place in times of AI and agentic engineering. In the past, you had to master skills such as “writing code, thinking about edge cases, debugging, reading documentation to understand languages and frameworks and also creating software architectures”.

Today, it’s different. You need to master the agentic engineering process including the tools and model usage per use case and code review. You need to have the curiosity to try out new approaches and to think out of the box. Automation got even cheaper and there are endless possibilities out there, just waiting for you.

The focus and the impact of your work shifts more towards business and skills the AI can’t master such as understanding ambiguous requirements and turning them (with the help of AI) into customer solutions. Good software engineers have never only focuses on code, but on solving business problems. This is more true than ever.

---