zlacker

[return to "Cloudlflare builds OAuth with Claude and publishes all the prompts"]
1. paxys+A6[view] [source] 2025-06-02 15:04:53
>>gregor+(OP)
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 – could @kentonv have written this library quicker by himself without any AI help?

◧◩
2. gokhan+na[view] [source] 2025-06-02 15:23:43
>>paxys+A6
> Not software engineers being kicked out ... but rather experienced engineers using AI to generate bits of code and then meticulously reviewing and testing them.

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.

And the author is implementing a fairly technical project in this case. How about routine LoB app development?

◧◩◪
3. theweb+8d[view] [source] 2025-06-02 15:39:34
>>gokhan+na
> 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 everything transitioned from ClickOps to the cloud & Infrastructure as Code. Infrastructure that needed 10 sysadmins to manage now only needed 1 or 2 infrastructure folks.

The role still exists, but the quantity needed is drastically reduced. The work that I do now by myself would have needed an entire team before AWS/Ansible/Terraform, etc.

◧◩◪◨
4. kenton+Wo[view] [source] 2025-06-02 16:47:21
>>theweb+8d
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. another -- while a lot of the job is the same, there will always be parts that are significantly different. Those bespoke processes often involve manual labor because off-the-shelf accounting software cannot add custom features for every company.

But what if it could? What if an engineer working with AI could knock out customer-specific features 10x as fast as they could in the past. Now it actually makes sense to build those features, to improve the productivity of each company's accounting department.

It's hard to say if demand for engineers will go down or up. I'm not pretending to know for sure. But I can see a possibility that we actually have way more developers in coming years!

◧◩◪◨⬒
5. motore+PR1[view] [source] 2025-06-03 04:37:30
>>kenton+Wo
> 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.

◧◩◪◨⬒⬓
6. peters+9V1[view] [source] 2025-06-03 05:18:24
>>motore+PR1
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).
◧◩◪◨⬒⬓⬔
7. motore+TY1[view] [source] 2025-06-03 05:51:06
>>peters+9V1
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.
◧◩◪◨⬒⬓⬔⧯
8. peters+JZ1[view] [source] 2025-06-03 06:02:32
>>motore+TY1
I didn't frame it that way - perhaps you are thinking of the person you replied to?

Nevertheless, I don't think they are trying to frame it that way, either. The point is that making software development easier can actually increase the demand of software engineers in some cases (where projects that were previously not considered due to budget constraints are now feasible).

◧◩◪◨⬒⬓⬔⧯▣
9. motore+z22[view] [source] 2025-06-03 06:31:26
>>peters+JZ1
> 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 is that making software development easier can actually increase the demand of software engineers in some cases (...)

I think that's somewhere between unrealistic and wishful thinking. Even in your problem statement, "making software development easier" lowers demand. Even if you argue that some positions might open where none existed before, the truth of the matter is that at the core of your scenario lies a drop in demand for software engineers. Shops who currently employ engineers won't need to retain as many to maintain their current level of productivity.

◧◩◪◨⬒⬓⬔⧯▣▦
10. peters+S62[view] [source] 2025-06-03 07:16:33
>>motore+z22
> 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 be done with just 2 engineers, the company can now afford to tackle the project. Engineers used = 2.

That is the point that the person you were originally replying to was making.

> Even in your problem statement, "making software development easier" lowers demand.

Incorrect, as shown above.

> Even if you argue that some positions might open where none existed before, the truth of the matter is that at the core of your scenario lies a drop in demand for software engineers.

I see what you are trying to say, but it's not that clear cut. The fact is, no one knows what will actually happen to software engineering demand in the long run. Some scenarios will increase demand for engineers, others will decrease it. No one knows what the net demand will be, everyone is only guessing at this point.

◧◩◪◨⬒⬓⬔⧯▣▦▧
11. basfo+ot2[view] [source] 2025-06-03 11:11:30
>>peters+S62
> 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.

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

[go to top]