Live data from Hacker News

Cloudlflare builds OAuth with Claude and publishes all the prompts

github.com

321–330 of 552 posts

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

#321

Earlier quoted context omitted.

Is it though? Would someone of author's caliber even be working on trivial slog item like Oauth2 implementation, if not for the novel development approach he wanted to attempt here ? For the kind of regular jobs a engineer typically is expected to do, would it give 100% productivity jump ?

Many tools make lesser developers more productive (to a point) but they fail to improve the productivity of talented professionals. Lots of "no/low" code things come to mind. But here's a tool that made kentonv 2x productive at a task that's clearly in his wheelhouse. It seems under the right conditions it can improve the productivity of developers at the opposite end of the spectrum. What other tools could do that?

To answer your question explicitly, we do have existing tools that help on that end, but they are nerdy and not hyped by beginners.

Type systems, LSPs, tests, formatters, Rust’s borrow checker, logs and traces, source control are examples of things that make experts go faster. This space is hardly neglected (but could always be better).

It is really nice to see LLMs helping on all skill levels.

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

#322

Earlier quoted context omitted.

> but rather experienced engineers using AI to generate bits of code and then meticulously testing and reviewing them. My problem is that (in my experience anyways) this is slower than me just writing the code myself. That's why AI is not a useful tool right now. They only get it right sometimes so it winds up being easier to just do it yourself in the first place. As the saying goes: bad help is worse than no help a…

> My problem is that (in my experience anyways) this is slower than me just writing the code myself. How much experience do you have writing code vs how much experience do you have prompting using AI though? You have to factor in that these tools are new and everybody is still figuring out how to use them effectively.

> You have to factor in that these tools are new and everybody is still figuring out how to use them effectively.

I think that the skills required are highly overblown.

The user should be aware of what each model excels at, its context size, temperature, and other parameters; how to communicate well, set system prompts and phrase tasks in a clear, succinct yet informative way; how to refocus the session when it veers off track; keep up to date with the latest (All of this is trivial for a competent software engineer. The idea that it requires some specialized training that couldn't be attained by experimentation and reading a blog post is absurd. "Prompt engineering" just isn't a thing.

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

#323

Earlier quoted context omitted.

Could you imagine typing the words "write an oauth library in typescript" into a computer and it actually working even 5 years ago? This is literally science fiction.

yeah, I remember putting this sort of query into Google 5 years ago and the computer produced it! "literally science fiction"

If you're not willing to have a good faith discussion I won't bother.

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

#324
post #185

Earlier quoted context omitted.

> "I believe AI is not good enough to replace humans, and I am pro" is a weird position to take Huh? The recipe how to be in this position is literally in the readme of the linked project. You don’t even have to believe it, you just have to work it.

I mean at the most extreme: that it can NEVER do so. Someone who holds this position would point to commits like https://news.ycombinator.com/item?id=44159659

To that I can only respond with never say never. Not this year? Yes. Not next year? Sign me up. Not in the next 10 years? Let’s say I’m looking at my hardware career options after 20 years in software.

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

#325

Earlier quoted context omitted.

It took me a few days to build the library with AI. I estimate it would have taken a few weeks, maybe months to write by hand. That said, this is a pretty ideal use case: implementing a well-known standard on a well-known platform with a clear API spec. In my attempts to make changes to the Workers Runtime itself using AI, I've generally not felt like it saved much time. Though, people who don't know the codebase as…

> It took me a few days to build the library with AI. ... > I estimate it would have taken a few weeks, maybe months to write by hand. I don't think this is a fair assessment give the summary of the commit history https://pastebin.com/bG0j2ube shows your work started on 2025-02-27 and started trailing off at 2025-03-20 as others joined in. Minor changes continue to present. > That said, this is a pretty ideal use cas…

> (...) your work started on 2025-02-27 and started trailing off at 2025-03-20 as others joined in. Minor changes continue to present.

Your analysis is far too superficial to extract anything meaningful. I know for a fact that I have small projects that took me only a couple of days to get done which have a commit history ranging a few months. Also, software is never done. There's always room to refactor, and LLMs turn that into trivial problems. Lastly, is your project still under development if your commits are README updates, linter runs, and renaming variables?

There is a reason why commit history is not used to track productivity.

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

#326

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…

> 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. That's definitely an interesting area, but I think we'll actually see (maybe) individual employees solving some of these problems on their own without involving IT/the dev team. We kind of see it already - a lot of these problem spaces are being solved with complex Ex…

If we shiver at the sight of some of those accounting-created excels, which we only learn about when they fail and they can't understand them anymore, wait for them to hand over a vibe-coded 200k loc Python codebase "which is not working anymore" and nobody had ever reviewed a single line of code.

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

#327

Earlier quoted context omitted.

It took me a few days to build the library with AI. I estimate it would have taken a few weeks, maybe months to write by hand. That said, this is a pretty ideal use case: implementing a well-known standard on a well-known platform with a clear API spec. In my attempts to make changes to the Workers Runtime itself using AI, I've generally not felt like it saved much time. Though, people who don't know the codebase as…

> Though, people who don't know the codebase as well as I do have reported it helped them a lot. My problem I guess is that maybe this is just Dunning-Kruger esq. When you don't know what you don't know you get the impression it's smart. When you do, you think it's rubbish. Like when you see a media report on a subject you know about and you see it's inaccurate but then somehow still trust the media on a subject you'…

> My problem I guess is that maybe this is just Dunning-Kruger esq. When you don't know what you don't know you get the impression it's smart. When you do, you think it's rubbish.

I see your point. Indeed there are two completely different points of view regarding the output of LLMs:

* Hey, I managed to vibecode my way into a fully working web service with a React SPA after a couple of prompts, and a full automated test suite to boot.

* This project is nowhere as clean as I would have written it, and doesn't even follow my pet coding conventions.

One side lauds LLMs, the other complains they output mainly crap.

The truth of the matter is that the vast majority of software engineers write crap code, as the definition of "crap code" is "something I would have done differently". Opinionated engineers look at the output of LLMs and accuse it of being crap code. Eppur si muove.

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

#328
post #10

This is exactly the direction I expect AI-assisted coding to go in. Not software engineers being kicked out and some business person pressing a few buttons to have a fully functional app (as is playing out in a lot of fantasies on LinkedIn & X), but rather experienced engineers using AI to generate bits of code and then meticulously reviewing and testing them. The million dollar (perhaps literally) question is – coul…

> This is exactly the direction I expect AI-assisted coding to go in. Not software engineers being kicked out and some business person pressing a few buttons to have a fully functional app (as is playing out in a lot of fantasies on LinkedIn & X), but rather experienced engineers using AI to generate bits of code and then meticulously reviewing and testing them. There is a middle ground: software engineers being kick…

I'm not so sure that would work well in practice. How would the inexperienced developer know that the code created by the AI was correct? What if subtle bugs are introduced that the inexperienced developer didn't catch until it went out into production? What if the developer didn't even know how to debug those problems correctly? Would they know that the code they are writing is maintainable and extensible, or are they just going to generate a new layer of code on top of the old one any time they need a new feature?

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

#330

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…

> 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. LLMs don't change that. If a business does not have the budget for a software engineer, LLMs won't make up budget headroom for it either. What LLMs do is allow engineers to iterate faster, and work on more tasks. This means less jobs.

If a business has the budget for 1 or 2 engineers though, they might be able to task them with work that previously required 5-10 engineers (in theory, anyways).
Post reply on HN