Live data from Hacker News

Cloudlflare builds OAuth with Claude and publishes all the prompts

github.com

161–170 of 552 posts

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#161
post #95

Earlier quoted context omitted.

I would say it ended up being much faster than had I written it by hand. It took a few days to produce this library -- it would almost certainly have taken me weeks to write it myself.

does reviewing have the same fidelity as writing ? reminded me of my university classes where i took my own notes vs studied someone else's notes. you can guess which one was superior.

It's certainly true that my own recall of the code would be better if I had written it by hand.

But I don't think the final code is all that far off from what I would have written.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#162

Earlier quoted context omitted.

> But what if you only need 2 kentonv's instead of 20 at the end? Do you assume we'll find enough new tasks that will occupy the other 18? I think that's the question. This is likely where all this will end up. I have doubts that AI will replace all engineers, but I have no doubt in my mind that we'll certainly need a lot less engineers. A not so dissimilar thing happened in the sysadmin world (my career) when everyt…

I think there's a huge huge space of software to build that isn't being touched today because it's not cost-effective to have an engineer build them. But if the time it takes an engineer to build any one thing goes down, now there are a lot more things that are cost effective. Consider niche use cases. Every company tends to have custom processes and workflows. Think about being an accountant at one company vs. anoth…

It's interesting that you bring up accounting software as an example. In jurisdictions where legal requirements around it are a lot more specific than in e.g. US, accounting suites usually already come with a lot of customization hooks (up to and including full-fledged scripting DSLs), and there are software engineers and companies who specialize in using those to implement bespoke accounting requirements.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#163
post #96

Earlier quoted context omitted.

But there very well might be a time very soon where human's no longer offer economic value to the software engineering process. If you could (and currently you can't) pay an AI $10k/year to do what a human could do in a year, why would you pay the human 6 figures? Or even $20k? Nobody is claiming that human's won't have jobs simply because "we have accomplished everything this is to do". It's that humans will offer z…

You run into knowledge collapse because nobody is socially reproducing that knowledge.

This seems an important thing that somebody should be concerned about. How do we get the next generation of engineers? And how will they even be able to do the senior engineer work of validating the LLM output if they haven't had the years of experience writing code themselves?

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#164
post #42
post #24

Earlier quoted context omitted.

Thanks for weighing in here If I might make a suggestion, based on how fast things change, even within a model family, you may benefit from saying Claude what . I was especially cognizant of this given the recent v4 release which (of course) hailed as the second coming. Regardless, you may want to update your readme to say It may also be wildly out of scope for including in a project's readme, but knowing which of th…

I believe it's important to say when AI was used so heavily in building a library -- it would feel dishonest to me to claim I wrote it all myself. I also think it's just a pretty interesting thing to know about. So I think it belongs in the readme. (But I'm not making a moral judgment on what anyone else does.) It was almost entirely Claude Sonnet 3.7. I agree I should add the version to the readme.

That's interesting. My experience with Sonnet 3.7 early this year was pretty poor: It simply couldn't reach the correct solution alone, even when explaining the issues explicitly. The proposed invalid solution was not too far from the correct one, so you could fix it manually if you knew what you were doing, but then the way the code was structured was not something that I would like to maintain in a real project. All this on top of the usual UX issues like hallucinated APIs. The experience refactoring was even worse.

I guess your mileage is highly dependent on the domain of your problem? In my case was GIS by the way

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#166

Earlier quoted context omitted.

I think there's a huge huge space of software to build that isn't being touched today because it's not cost-effective to have an engineer build them. But if the time it takes an engineer to build any one thing goes down, now there are a lot more things that are cost effective. Consider niche use cases. Every company tends to have custom processes and workflows. Think about being an accountant at one company vs. anoth…

It's interesting that you bring up accounting software as an example. In jurisdictions where legal requirements around it are a lot more specific than in e.g. US, accounting suites usually already come with a lot of customization hooks (up to and including full-fledged scripting DSLs), and there are software engineers and companies who specialize in using those to implement bespoke accounting requirements.

I admit I have no specific knowledge of accounting and just meant to reference any random department that isn't engineering.

(Though I think it's true of engineering too. We all have our own weird team-specific processes for code reviews and CI and deployments which could probably use better automation.)

But even where lots of customization exists today (such as in engineering!), more is always possible. It's always just a question of whether the automation saves as much time as it took to build. If the automations can be built faster, then it makes sense to build more of them.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#168
post #40

Earlier quoted context omitted.

> They can get halfway there and then struggle immensely. Restart the conversation from scratch. As soon as you get something incorrect, begin from the beginning. It seems to me like any mistake in a messages chain/conversation instantly poisons the output afterwards, even if you try to "correct" it. So if something was wrong at one point, you need to go back to the initial message, and adjust it to clarify the promp…

I thought Claude still has a problem generating the same output for the same input? That you can't just rewind and rerun and get to the same point again.

> can't just rewind and rerun and get to the same point again

Why would you want to? The whole point of a retry is that your previous conversation attempt went poorly.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#169
> This is a TypeScript library that implements the provider side of the OAuth 2.1 protocol with PKCE support.

What is the "provider" side? OAuth 2.1 has no definition of a "provider". Is this for Clients? Resource Servers? Authorization Server?

Quickly skimming the rest of the README it seems this is for creating a mix of a Client and a Resource Server, but I could be mistaken.

> To emphasize, this is not "vibe coded". Every line was thoroughly reviewed and cross-referenced with relevant RFCs, by security experts with previous experience with those RFCs

Experience with the RFCs but have not been able to correctly name it.

Re: Cloudlflare builds OAuth with Claude and publishes all the prompts

#170
post #40

Earlier quoted context omitted.

> They can get halfway there and then struggle immensely. Restart the conversation from scratch. As soon as you get something incorrect, begin from the beginning. It seems to me like any mistake in a messages chain/conversation instantly poisons the output afterwards, even if you try to "correct" it. So if something was wrong at one point, you need to go back to the initial message, and adjust it to clarify the promp…

Chatbot UIs really need better support for conversation branching all around. It's very handy to be able to just right-click on any random message in the conversation in LM Studio and say, "branch from here".

AI Studio has this, I usually ask it to plan and I do some rounds of refining until the plan covers all my requirements, then I branch this conversation, a branch for each feature, none of the branches get polluted this way.
Post reply on HN