Hey, Luca here, welcome to a weekly edition of the💡 Monday Ideas 💡 from Refactoring! To access all our articles, library, and community, subscribe to the full version:
Resources: 🏛️ Library • 💬 Community • 🎙️ Podcast • 📣 Advertise
❌ Stop doing work about work
This idea is brought to you by Steady!
55% of your engineering team’s time is spent doing busywork—chasing status updates, hunting for information and managing the mechanics of work.
All that work about work pulls devs out of flow, threatening focus, productivity and velocity.
The guys at Steady, who I have known for a long time (here is my interview with Henry!) have created an awesome guide for what they call continuous coordination:
The proven system that gives teams time back
How to increase autonomy and accountability
Advanced techniques for reducing coordination overhead
Check it out below 👇
1) 🖥️ From IDEs to CLI tools
When you open up Cursor, or VS Code with Copilot, it feels like a normal IDE with AI bolted on top.
This is obvious from the UI: 70% of the screen is traditional IDE real estate—editor, file sidebar, terminal—while the AI chat gets a column on the right.
Sure, you can tweak the layout, but the karma of the tool remains that of an IDE.
Why is this a problem? When I’m not writing code, most of this interface is noise—context I don’t need, at the expense of context I do need: what is the AI doing? What commands is it running? What’s the plan?
These two types of context are fundamentally different. I’d call the first engineer context, and the second manager context.
So, if I had to summarize the difference between Cursor and Claude Code in one line:
Cursor treats me as an IC
Claude Code treats me as a manager
Which leads me to this slide you may have seen on Linkedin, which made me laugh — but also reflect.
This is vibe coding via humans — also known as management. In the picture it’s not great management maybe, but management nonetheless.
In fact, the developers I know who are having the most success with AI are, first and foremost, good managers of themselves.
Now, I think CLI tools make this transition easier because they spare you from the cognitive pull of the code itself. You can still jump into your IDE whenever you need to, but the terminal keeps focus on the sequence of actions and instructions.
In other words, it defaults to manager mode, while IDEs default to engineer mode.
I have written more about this shift in this recent article 👇
2) 🔨 Bring me solutions… but also problems!
I keep getting back to this article that Anna Shipman published on Refactoring at the end of last year. It’s full of small gems that I think about often.
One of them is about the cliché that execs want solutions, not problems. Like many cliches there is truth in it, but also nuance.
As an exec, I would much rather know about problems than never find out because you didn’t want to tell me without a solution, so this shouldn’t become a reason not to flag areas where your leaders should be concerned.
However, you do not want to pass all decisions up to your boss either.
You probably have great ideas about how to solve issues you see, and generating good solutions is a skill that definitely improves with practice. If you want your proposal to land, it needs to cover not just “we should solve this problem” but “and here’s one way we could do that”. It’s also useful to include some options you considered and discarded.
Your initial proposed solutions may not align with business value, but you will get feedback and learn and improve. If you never try, you will never get better and you will find you are senior and still making similar suggestions that do not get adopted.
You can find the full (awesome) piece here:
3) 🎙️ The Forest & The Desert
I keep using this analogy all the time. It was created by Kent Beck and it explains how software teams often live different realities.
Teams that work in the desert have strict processes and limited resources. There is no room for error, and everything feels unsafe and ready to kill you.
In the forest, instead, things just work. There is collaboration, flexibility, and things are built in small, safe steps. People share a clear goal and feel great about their work.
I also talked about this with Martin Fowler on the podcast last year, and he said something that stuck with me:
“It’s hard to communicate what you can do in the forest, and how fast you can move, to people who’ve never lived in that world.”
These worlds are not only different — each one hardly understands the other, which is why practices from one camp are often met with resistance and skepticism from the other camp.
Here is the full interview with Martin:
You can also find it on 🎧 Spotify and 📬 Substack
And that’s it for today! If you are finding this newsletter valuable, subscribe to the full version!
1700+ engineers and managers have joined already, and they receive our flagship weekly long-form articles about how to ship faster and work better together! Learn more about the benefits of the paid plan here.
See you next week!
Luca