Even Software Engineers: take all the swaths of engineers who were productive but didn't want / didn't make to a FAANG company and now are having to compete in a world where most companies can replace a lot of the people they don't need a team of 8 engineers because their team of 4 now can have Co-Pilot and most of their "middle management" roles could be effectively replaced by some cheap, off-the-shelf SaaS.
I'm literally in this scenario. I'm too old to be interested in competing with someone who is 20 years younger than me but can call themselves a "programmer", and whatever knowledge/experience I have can be had at a fraction of my "cost" by using a commodified service that automates a process. So, what is left for me? Either I need to go downmarket and work for "programmer" jobs (further increasing the supply and lowering salaries) or I need to find someone who is willing to invest in my "idea for a startup" (thus getting into the Silicon-Valley way of life), or I need to find a way to take my unique experience and repackage as something of value - and then get to be called "greedy" by people like you.
By the way, may I interest you in becoming a customer of my not-yet VC funded company (https://communick.com) and/or join the people sponsoring me for $4/month for my Fediverse work (https://github.com/sponsors/mushroomlabs)?
You can't just type in ChatGPT something like "write me GTA5" and you get running code, just seen today an example of someone complaining that he asked soemthing like "Create a website in PHP for a company that does X" and they were expecting that by magic a website will just appear.
What AI will do is leverage productivity of the individuals. Any new story will have its complexity reduced because the developer will be to use the existing codebase and say "hey, our current code is connecting with Foobar via the Zoberg SDK, now we are adding a customer that uses the BazBah platform and they need to change the order flow for 'deliver on payment' to 'deliver on invoice sent'. Show me what changes are needed to make this happen, and please write the integration tests to make sure that we are not breaking things from existing customers"
This goes from a one week task that will require three hour-long to something that can be done in an afternoon, reviewed by the developer and (most importantly) cheap to throw away if the original requirements change.
- uses bad code practices because there is more bad code on the internet then good
- hallucinates APIs , so it tells you to use X but X does not exist in the library/framework you asked for
- suggests wrong solution
- if your language is not precise it gives you the answer to the wrong thing, like you see the answer and you realize it did not understand you
In my experience if your developers are 20% more productive you do not fire 20% of them because there always is a big backlog of features or bugs to be handled.
Google's automatic translation was not good enough at the beginning to replace the translator's job, but by the time I was already graduated it was good enough for her to not need my proofreading and it was good enough for her to effectively get 60% of the job done. She has then effectively become the proofreader for a bad translator.
And nowadays, the bad translator is good enough to the point where her customers can just throw the original document on Google and do themselves the proofreading.
This is what will happen with programming tools. Code generation tools are still just at the "smart autocomplete" stage and the experienced programmer is still needed to act as reviewers, but as AI gets better, it will be cheaper to drop the "professional expert" altogether and let someone with tangential knowledge (maybe a product manager) in charge.
- what you call "garbage" might be someone else's "good enough for my needs". If I can go to Japan and a " garbage translator" still is enough for me to help navigate the city or poorly talk to a shopkeeper, then it's mission accomplished and I don't need to worry about a local guide.
- lots of "complex stuff" are dependent on context, and can be made less complex if we relax one single design constraint. E.g, centralized social media networks have a strong requirement for not losing user data. Distributed systems solve this by (a) duplicating data between every node and (b) letting it be deleted by users and node operators who do not want to have the data stored for long term.
It seems to me that you believe that what most software engineers is some dark magic that only a select few can master. It really isn't. The whole "software is eating the world" essay never mentioned what was going to happen after it ran of out of things to eat, now it is kind of obvious that it will gladly get into cannibalism.
A true intelligent AI sure could be a problem, but this stuff will just be an copilot, good enough to do basic stuff and maybe double check the programmer.
When you predict it would be possible I give the AI a JIRA ticked and it could open the application, reproduce the issue, update the ticket with details about the bug , then find the issue in a giant code base, fix it correctly etc .
Because today an AI can't do anything from the above. It can't replace a human.
> It can't replace a human.
If it provides enough leverage to today to make one person 20x more productive, then it is effectively replacing 19 humans. When it is effective to make one employee 200x more efficient, it will replace 199 humans.
And if you have enough hubris to think you are always going to be the lucky one out of the chopping block, it's not for lack of warning.
But this is not reality. Is this happening for your work? Or you read this somewhere ?
For "today", I've seen good engineers solving specific tasks in a third of the time already, but I won't make specific claims about absolute productivity multipliers.
Specific is the important word here. Some boring tasks that can be automated in all jobs will be automated though you still need to check the AI. I assume no competent developer was fired because of that productivity boost in that specific task
I really don't understand why you are being so obtuse about this. Do you honestly think that you can make the argument that software development (as an industry) is somehow immune to automation?
Very discouraging to many content creators when their work is just going to be buried in SEO chaff.
Also, the automation wave is just beginning. Soon the human run content farms will be overwhelmed by AI created crap.
This is likely to happen in software as well. Every product will need to compete with some AI generated piece of garbage that’s barely passable functionally, but being sold at a fraction of the cost.
Fun times!
Well at least this site isn’t created by a VC… oh.
Things are nuanced. VCs can fund valuable useful things sometimes.
We say screw to fooling your users that you're an OSS adopter and supporter, just until your project is big and you can say screw OSS.
Amazon can wrap an open source project in an AWS front end and create a paid for cloud service off the back of community effort. Or, key contributors can decide they want to take the existing code and change the license their contributions are released under going forward.
If the original license allows both these things to happen, then both are a risk and no one is being fooled.
I would love nothing more than for a project I built or contributed to wound up as an AWS service.
Writing the code is just part of the value, running it is also very difficult. Especially as the use increases and expose new code paths and bugs and what not.
What they can't - without giving the middle finger to OSS - is satisfy greed.
If you want to satisfy greed, fine, but be like Oracle. Sell a commercial license upfront. Don't pretend to be OSS.
The greedy people behind businesses managing OSS are concerned, because they are not satisfied with making money. They want to be THE ONLY ONES making LUDICROUS profits on top of community contributions.
The old code is there with the existing license still. Fork it and move on.
People, man.
There’s no issue here. Just whining. There is no lock in at all.
Even if it were OSI open source the maintainers like the very thread we are in could die. Then what? Oh you fork and maintain yourself, or the project rots.
License changes are irrelevant.
HN has monetary value to someone somewhere. Plus it’s cheap to run.
It’s also a good advertising and recruiting platform for YC.
There by the grace of VCs goes HN.
Don't tell them you have always been and always will be open source, just until you're big and give the middle finger to OSS in order to get richer.
There is no lie.
The phrase isn't "FooBar v3.11 is free and always will be".
There is no version number in the phrase, so the common understanding is that the product and every version of that product will always be free.
Same thing, same result. We are literally discussing this in a thread where a prominent maintainer died. Nothing is forever.
There is no way to guarantee something will be the same forever.
Again, fork and move on if things change to your dissatisfaction.
People built things because they loved it and wanted to help others , not to get rich. Now everyone just wants to get rich, and fast.