dps

Yeah, I really should have included <> :-)

Fun to see this post from the deep archive get some interest - thanks for reading!

Author here… I wrote it, I used Claude for proofreading/editing as mentioned at the end. Anyway point is, real human here!

I do still read the code _except_ when I am consciously vibe coding a non production thing where I will know empirically that it worked or not by using it.

I’m definitely not using agents to do all my coding (as I hope is reasonably) clear from the post. But they have crossed this line from pointless to try to genuinely useful for many real world problems in just the last couple of months in my experience.

Author of the piece here :-). We are not building coding agents and focused on quite different stuff… I am just trying to share my personal experience as a software person!

Author of the post here… Cool to see this back on HN! I was trying to provide instructions that anyone could use regardless of platform, hence the choice of web tools (both those linked process the data locally). If you know of a base32 decoder that’s easily available on Windows, Mac and Linux I’d be delighted to update the post.

admin/admin worked for me

I added an 'almost' caveat to the text - thanks for the note.

Hi folks, article author here. I just wanted to stop by to say I'm delighted so many folks enjoyed the piece. I really did have a lot of fun :-)

(Stripe CTO here)

That's a reasonable question. We wrote this RCA to help our users understand what had happened and to help inform their own response efforts. Because a large absolute number of requests with stateful consequences (including e.g. moving money IRL) succeeded during the event, we wanted to avoid customers believing that retrying all requests would be necessarily safe. For example, users (if they don’t use idempotency keys in our API) who simply decided to re-charge all orders in their database during the event might inadvertently double charge some of their customers. We hear you on the transparency point, though, and will likely describe events of similar magnitude as an "outage" in the future - thank you for the feedback.

(Stripe CTO here)

Thanks for the questions. We have testing procedures and deploy mechanisms that enable us to ship hundreds of deploys a week safely, including many which touch our infrastructure. For example, we do a fleetwide version rollout in stages with a blue/green deploy for typical changes.

In this case, we identified a specific code path that we believed had a high potential to cause a follow-up incident soon. The course of action was reviewed by several engineers; however we lacked an efficient way to fully validate this change on the order of minutes. We're investing in building tooling to increase robustness in rapid response mechanisms and to help responding engineers understand the potential impact of configuration changes or other remediation efforts they're pushing through an accelerated process.

I think our engineers’ approach was strong here, but our processes could have been better. Our continuing remediation efforts are focused there.

I'm Stripe's CTO and wrote a good deal of the RCA (with the help of others, including a lot of the engineers who responded to the incident). If you've any specific feedback on how to make this more useful, I'd love to hear it.

(stripe head of engineering here) I hosted the open house in Dublin, thanks for coming and sorry to hear about your experience; even if it doesn't end up being a fit, we always want candidates to feel respected rather than demoralized. Without knowing the specifics of your situation, I do want to be clear that there are obviously a lot of factors for us to consider when evaluating candidates, but age isn't one of them.

Does the combination of hypothermic state and medically induced coma (“hibernation”) have a prolonging impact on life expectancy? The lower metabolic rate would intuitively suggest that’s a possibility. It’s interesting to think about how this technology, even ahead of use in travel to deep space could be used as a forward only time machine.