At a recent event, someone asked me two questions. I could not answer them well at the time:
How do you decide which tasks to give to Claude Code, and which ones to do yourself? And are you afraid that the AI will do all the creative work, so your only job becomes managing agents?
I gave a generic answer at the moment. But after thinking about it, I believe the answer is simple.
Let me start with a statement: software engineering is a craft, not creative work. We practice and develop our skills, repeat the same routines, and learn from our mistakes. But most of the time, we use building blocks that other people invented and tested before us: design patterns, infrastructure tools, etc. The most useful thing we can do is learn from others’ experiences and find a way to use them in our own projects. So we can divide our work into three groups:
Routine — the daily, mechanical work. Writing code and tests based on a design that already exists. Using the patterns already established and proven on the project.
Engineering — this is where the constraints matter. There are often several possible solutions. Your job is to pick the one that fits the project best, or to see that any of them will work and choose the simplest one. When the design is right, the task is almost finished. You just need to write it down.
Creativity — making something that did not exist before. Many engineers, including me, may never do this in their whole career, and that is completely fine: the value of our profession is in execution, not invention.
Here is an example. The idea of Claude Code as an agentic tool in the terminal was creativity. The level of abstraction is exactly right for this kind of generic developer tool. It is a simple idea, but I had always used IDEs, and I never thought that coding using the terminal could be more efficient. The first time I tried it, I understood right away that this was the right direction. Everything after that idea is engineering and routine.
With this framework, the two questions become easy to answer:
→ Claude Code can reliably do all of the routine. As an engineer, you should give this work to it (or any other similar tool), because it is simply the most efficient way to do it. You can also build workflows where non-technical people complete this kind of work on real projects.
→ In the engineering part, Claude Code is a strong assistant. You can brainstorm with it and find solutions you would have missed. But the decisions are still your job. "Teaching" the tool to make good choices by clearly describing your constraints is itself a great engineering task. This is an area where you draw the line between the tool’s job and your own.
→ I do not expect these tools to create real creativity any time soon. By their nature, they can only reproduce what existed before.
So, to use Claude Code well, you need two things. First, the experience to separate engineering from routine — in this way, you’ll do more engineering and fewer routine tasks. Second, the judgment to give the tool the right amount of freedom in the engineering part, based on the needs of your specific project.
That's how I think about it now. How would you answer these two questions?