Earlier quoted context omitted.
That is how LLM:s should be used today. An expert prompts it and checks the code. Still saves a lot of time vs typing everything from scratch. Just the other day I was working on a prototype and let claude write code for a auth flow. Everything was good until the last step where it was just sending the user id as a string with the valid token. So if you got a valid token you could just pass in any user id and become…
> Still saves a lot of time vs typing everything from scratch No it doesn't. Typing speed is never the bottleneck for an expert. As an offline database of Google-tier knowledge, LLM's are useful. Though current LLM tech is half-baked, we need: a) Cheap commodity hardware for running your own models locally. (And by "locally" I mean separate dedicated devices, not something that fights over your desktop's or laptop's…
Cloudlflare builds OAuth with Claude and publishes all the prompts
381–390 of 552 posts
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#382Earlier quoted context omitted.
> 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? Not a problem. The industry has evolved to tolerate buggy code that barely works. In fact, in some circles that's what's already expected from the baseline. LLMs change nothing in this regard. In fact, they arguably improve upon this problem as it becomes trivial to implement ext…
I disagree strongly with this conclusion. I've seen firsthand what happens to large software projects that collapse under their own weight of tech debt. The software literally could not function as intended - customers were lost, the product went under. Low quality being "expected" (which isn't true in my experience, either) is irrelevant when the software doesn't work at all. The chances of all of that happening are…
Yep, fully agree. We're going through this ourselves at $CURRENT_JOB, where the instability of the platform and product as a whole due to the immensely bad decisions made in the project's past is leading to massive churn from every single customer other than the smallest ones that make us no money anyway.
And it's not just the customers, the devs are feeling it too. There's constant fires and breakages all over the place because management doesn't care to give us any time to focus on quality, and people (myself included) are getting tired of having to read through some 10kLOC monstrosity that not even God Himself could understand, and it's made worse by the clueless management saying "Have you tried having AI find the bugs for you?" like a bunch of brainless sheep being injected with that sweet ol' VC hype machine.
Sure, people will put up with some bugs from time to time, and I'm not even saying I could've or do make perfect choices as well. But there's only so many times people will put up with a broken experience before they cut ties and quit, and in this vibe-coded hallucination world we're entering, are people really going to be okay with the products they use day-in, day-out changing behavior drastically every single day based on whatever the AI decided to hallucinate this time around to "fix" that 1 persistent bug that can't seem to die?
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#383I don’t see any prompts?
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#384Earlier quoted context omitted.
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
#385The commits are revealing. Look at this one: > Ask Claude to remove the "backup" encryption key. Clearly it is still important to security-review Claude's code! > prompt: I noticed you are storing a "backup" of the encryption key as `encryptionKeyJwk`. Doesn't this backup defeat the end-to-end encryption, because the key is available in the grant record without needing any token to unwrap it? I don’t think a non-expe…
That is how LLM:s should be used today. An expert prompts it and checks the code. Still saves a lot of time vs typing everything from scratch. Just the other day I was working on a prototype and let claude write code for a auth flow. Everything was good until the last step where it was just sending the user id as a string with the valid token. So if you got a valid token you could just pass in any user id and become…
An expert reasons, plans ahead, thinks and reasons a little bit more before even thinking about writing code.
If you are measuring productivity by lines of code per hour then you don't understand what being a dev is.
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#386Earlier quoted context omitted.
> On the other hand, where I remain a skeptic is this constant banging-on that somehow this will translate into entirely new things - research, materials science, economies, inventions, etc Does it even have to be able to do so? Just the ability to speed up exploration and validation based on what a human tells it to do is already enormously useful, depending on how much you can speed up those things, and how accurat…
So isn't the heuristic that if your job is easily digestible by an LLM, you're probably replaceable, but if the strong slowdown factor presents itself, you're probably doing novel work and have job security?
Yeah, that sounds about right to me. I wasn't talking about wholesale replacement though, but as a tool/augmentation, I'm not very confident an LLM would be able replace a software engineer, but I can definitely see many workflows of a software engineer being sped up, like the exploration and validation process.
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#387Earlier quoted context omitted.
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).
Right, but even the way you opted to frame this discussion is based on the idea that there is a drop in demand for software engineers. You need less engineers, not more. A few can get more done, but you need fewer to accomplish your tasks too.
But what has happened instead is that we are now building much more buildings and much more complex ones than we ever would have even conceived of back then. The Three Gorges dam required the work of thousands or even tens of thousands of people when it was built, and it would have required the work of millions in the year 1000. But it didn't actually generate millions of jobs in the year 1000: it was in fact never even conceived of as a possibility, much less attempted.
Of course, the opposite can also happen. The number of carpenters has reduced to almost nothing, when it used to be a major profession, and there are many other professions that have entirely disappeared.
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#388Earlier quoted context omitted.
The way the input doesn't match the output should imply that it's not just statistics. As soon as compression happens, optimization happens which can lead to rules/learning of principles which got feed by statistics.
That's "just" more statistics though.
For me a compressed model learning rules through statistics is not statistics anymore.
Physic rules are not statistics.
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#389Earlier quoted context omitted.
> I didn't frame it that way - perhaps you are thinking of the person you replied to? You did. You explicitly asserted the following. > 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 your own words, a project that would take 5-10 engineers is now feasible to be tackled with 1 or 2. Your own words. > (...) The point…
> In your own words, a project that would take 5-10 engineers is now feasible to be tackled with 1 or 2. Your own words. That statement != lower demand for software engineers. If a firm needs to perform project X that previously cost 10 engineers to do, but they only have the budget for 2, they will not tackle that project. Engineers used = 0. However, if due to productivity enhancements with AI, the project can now…
0 on that Project, but those 2 engineers will still be used on a different Project that needs just 2 Engineers.
BUT a company that sees that project as a critical part of the bussines and MUST tackle that project, will only need the 2 engineers in the payroll. Or hire just 2 instead of 10.
Engineers not hired = 8
Or.. maybe they don't really need that project that needs 10 engineers. They are ok as they are today, but they realize that with AI, they don't need those 2 engineers anymore to produce the same output, probably can be handled by just one with AI assistance.
Engineers fired = 1
Re: Cloudlflare builds OAuth with Claude and publishes all the prompts
#390Earlier quoted context omitted.
That is how LLM:s should be used today. An expert prompts it and checks the code. Still saves a lot of time vs typing everything from scratch. Just the other day I was working on a prototype and let claude write code for a auth flow. Everything was good until the last step where it was just sending the user id as a string with the valid token. So if you got a valid token you could just pass in any user id and become…
I really don't agree with the idea that expert time would just be spent typing, and I'd be really surprised if that's the common sentiment around here. An expert reasons, plans ahead, thinks and reasons a little bit more before even thinking about writing code. If you are measuring productivity by lines of code per hour then you don't understand what being a dev is.
They didn't suggest that at all, they merely suggested that the component of the expert's work that would otherwise be spent typing can be saved, while the rest of their utility comes from intense scrutiny, problem solving, decision making about what to build and why, and everything else that comes from experience and domain understanding.