◮ Email @ hn [ a t ] sebastianmellen [ d o t ] com // corp email is first name at mycompanysite
——————————
There is a tide in the affairs of men.Which, taken at the flood, leads on to fortune;Omitted, all the voyage of their lifeIs bound in shallows and in miseries.On such a full sea are we now afloat,And we must take the current when it serves,Or lose our ventures.
——————————
[ my public key: https://keybase.io/sebmellen; my proof: https://keybase.io/sebmellen/sigs/iwp1glP0DaEmYMDaW9pg2Syr_Kq5YULKX7AU68ovLCQ ]
Yeah, but as you say, this is another LLM rewriting it. The amount of noncontextual information is nauseating and destroys the point of a README (in my humble opinion).
A human might have written a disclaimer like this:
> When not using Fable, pxpipe may require additional follow-ups to precisely follow your formatting instructions.
This kind of garbled information dump is very inconsiderate of the reader, and all good writing is considerate of the audience consuming it.
It’s so painful to read the LLM-compressed explanations. I can’t exactly identify what it is, but it’s an immediate tell and literally requires twice the effort to comprehend.
For example:
> Honest caveat, visible in the clip: the pxpipe arm answered the count first and needed one follow-up nudge to also print the ledger balance in the requested one-line format; the plain arm followed the format on the first try. Legibility is solved on Fable — single-reply format compliance is the remaining rough edge.
If I reread this four times, I can sort of interpolate what happened, but it’s mostly pointless and confusing information.
In my experience all models do this to an extent, but Claude seems to be the worst at this. GPT 5.5 is a bit more terse but seems to compress more valuable information.
I’ve found unexpected success in using ephemeral NixOS VMs for local development… once you authenticate your agent you can let it run wild without worrying about permissions.
Do most medical students publish useless case studies trying to jockey for residency spots and signal hustle/devotion? No doubt!
But there are a good handful of medical students who are still (surprisingly) in it for the medicine and not the money. And that handful is exceedingly capable; no reason they can’t publish valuable work with the right collaborators and resources.
Just commenting for posterity… if this is what it claims to be, I am not looking forward to how it will empower the people who submit bug bounties to us.
Historically they’ve been people from certain identifiable countries (usually developing/poorer countries) using fuzzers with low-quality results.
Now, those same people use the current-day models to good effect, but they still don’t have a true security edge and oftentimes the reports are minor or duplicative.
Great, let me know when those models can run on-server and process/analyze streams of ID images with less than 100ms of latency. You’ll need to make sure you have a massive set of training data including all manner of slightly blurred and slightly distorted ID cards
If I'm interpreting this correctly, GitHub will use their existing actions infrastructure to run versions of the code in isolated worktrees. I think this could be a very beneficial process.
What I've done on my end is created a project where I have a remote Linux workstation. I can create multiple worktrees for each repo in that workstation, and then my agent can push PRs to GitHub and use the actions infrastructure to see if the integration tests that it writes for itself are successful without needing to run those integration tests on the local environment. It's expensive in terms of runner hours, but the automaticity of it is incredible.
The most frustrating thing to me is to receive a 5-paragraph-plus email that was clearly written with some AI that filled in the email with vapid and useless talking points, like "Let me know if you need any other blah blah blah; While there is clearly a need for system improvement, we are working hard to address the underlying and fundamental issue; This is a lesson that it's not just a feature, it's a critical path for our users, etc."
My theory is that people are fundamentally averse to the thought and effort it takes to write a good quality email. Then there’s probably some underlying belief that more volume shows more effort, which people will perceive positively. And finally, there's the worry that if you write the email yourself, you might make some embarrassing wording, grammar, or spelling mistake.
Quantum itself is the most scummy, grift-filled industry. Every quantum company is riding the AI/semiconductor hype wave with basically zero revenue prospects or long-term application of the tech. Companies trading at 200x earnings, IONQs CEO claiming to the “next NVIDIA”/“base case is Cisco’s market cap” — just ridiculous.
In my experience, the biggest benefit comes from having good quality integration and unit tests that are easy for the agent to run on its own to verify its work against.
Same here. You’d think they could at least separate out the GitHub-hosted and self-hosted runners, so you’re still able to dispatch jobs if the self-hosted runners are down.
◮ Website @ www.sebmellen.com
◮ Blog @ www.sebastianmellen.com
◮ Email @ hn [ a t ] sebastianmellen [ d o t ] com // corp email is first name at mycompanysite
——————————
There is a tide in the affairs of men. Which, taken at the flood, leads on to fortune; Omitted, all the voyage of their life Is bound in shallows and in miseries. On such a full sea are we now afloat, And we must take the current when it serves, Or lose our ventures.
——————————
[ my public key: https://keybase.io/sebmellen; my proof: https://keybase.io/sebmellen/sigs/iwp1glP0DaEmYMDaW9pg2Syr_Kq5YULKX7AU68ovLCQ ]
iWIkiiKk7w