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.
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.
> 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.
On the contrary, I like the name. :) And while you might have something that works for your company, it most likely won't meet many other companies needs. You can check webhooks.fyi[0] by Ngrok for the various implementations and edge cases.
What you described seems to me like webhooks. :) Webhooks aren't anything new really, Jeff Lindsay [0] coined them way back in 2007 while at Twilio but they aren't well understood and implemented today.
Update: Nohooks Backend is now open source [0]. The goal is to collectively improve the polling system as well as generate more useful event types/payloads.
I also do not see a good reason providers should mitigate this because we work well within the rate limit. Users already do this for services they care about if you do not natively support webhooks. DigitalOcean provides a URL to poll to know when your resources are fully provisioned.
Definitely, I'd love to see this happen. There are a whole lot of events we can generate from DigitalOcean Resources - K8s resources, firewalls, block storage etc.
Yup. Even DigitalOcean still doesn't have webhooks despite several user requests see here [0]
My business is building a Webhooks Gateway for delivering webhooks at scale - Convoy [1]. We use Convoy Cloud to power Nohooks. The goal is to show what's possible with Convoy so more providers can easily provide webhooks.
FYI, I still use cursor for small edits and reviews.