I was here a few weeks ago, but I'm now on the CC train. The challenge is that the terminal is quite counterintuitive. But if you put on the Linux terminal lens from a few years ago, and you start using it. It starts to make sense. The form factor of the terminal isn't intuitive for programming, but it's the ultimate.
FYI, I still use cursor for small edits and reviews.
Why do we all of a sudden hold these agents to some unrealistic high bar? Engineers write bugs all the time and write incorrect validations. But we iterate. We read the stacktrace in Sentry and realise what the hell I was thinking when I wrote that, and we fix things. If you're going to benefit from these agents, you'd need to be a bit more patient and point them correctly to your codebase.
My rule of thumb is that if you can clearly describe exactly what you want to another engineer, then you can instruct the agent to do it too.
"They're not only awkward, but a 30 minute call takes up hours of my headspace." This is so apt. I've found that I have the best calls with people who provide specific notes about what they want to discuss—the more specific the note, the less headspace the call requires.
Maybe it could be done via email which is the point of this blog, but I never had the confidence to try that.
We have a saying in my home country, roughly: 'spoken words fly away, written words remain'.
For reliable and specific matters using calls is unfit for the purpose. I avoid talking about those as a primary medium, being only suplementary. Something not written down never existed in the end.
In matters I do not know to the slightes, where to begin with, talking to a person is better starting with. Then after getting my bearings step back to the reliability of written words and written discussions and written agreements and such is the way.
And those insist on speeking instead of providing written info is a big warning sign about something fishy (intent of misdirection, incompetency, cluelessness, confused internals, ...) is hiding there.
Reading this, I had an epiphany about why open-source software is essential. How do you peak under opaque abstractions? It's just not possible.
Imagine if Kubernetes was closed source & binary distribution only. Understanding abstractions is, I think, why being open source has become table stakes for infrastructure software.
That's not really true, obfuscating JavaScript can be quite effective at making it difficult to study the program's workings. It can't be perfect at this, of course, but neither is conventional ahead-of-time compilation to machine code.
> Adopting a non-compete license isn’t problematic in itself, it’s the trend of switching from an open source to a non-compete license after gaining significant success that is causing distrust in commercial open source software.
I shared a similar sentiment here [0]. The future of open source companies is taking a serious posture for it and clarifying as best as possible to all stakeholders involved what this stance is. Love this piece.
Paul, please write the article. I *want* to read it.
Hard agree. It's why I also believe that more & more companies will be more strategic with their licensing choice from the beginning. The common wisdom is to give it all away and grow at all costs, then switch licenses when there's brand value and the business needs revenue. This is poor because the license changes aren't bad in themselves because they still enable the individual developer to take enormous benefits, but they come with significant disadvantages like community drama, bad pr etc.
FYI, I still use cursor for small edits and reviews.