I would like to see how things will be when using AI would require half of a devs current paycheck.
The next two years of software engineering
111–120 of 403 posts
Re: The next two years of software engineering
#112>The flip scenario: AI unlocks massive demand for developers across every industry, not just tech. Healthcare, agriculture, manufacturing, and finance all start embedding software and automation.
I find this one hard to believe. Software is already massively present in all these industries and has already replaced jobs. The last step is complete automation (ie drone tractors that can load up at a hub, go to the field and spray all by themselves) but the bottleneck for this isn't "we need more code", it's real-world issues that I don't see AI help solving (political, notably)
Re: The next two years of software engineering
#113The most important question is who will get paid the most? I don't think the future of software engineering will be attractive if all you do is more work for same or even less pay. A second danger is too much reliance on AI tools will centralise knowledge and THAT is the scariest thing. Software systems will need to perform for a long time, having juniors on board and people who understand software architecture will…
The people who don't lose their jobs will also not be in a great spot, there wont be a guarantee that they will never lose their jobs, they will continue to live on the wobbly and uncertain foundation, will get fired for first no they say to the management. If software engineering falls, all the related industries will fall too, thus creating a domino effect, that none of the execs can imagine right now.
> there wont be a guarantee that they will never lose their jobs, they will continue to live on the wobbly and uncertain foundation
The people who lose their jobs prove this was always the case. No job comes with a guarantee, even ones that say or imply they do. Folks who believe their job is guaranteed to be there tomorrow are deceiving themselves.
Re: The next two years of software engineering
#114Funny that he mentions people not pivoting away from COBOL. My neighbors work for a bank, programming in COBOL every day. When I moved in and met them 14 years ago, I wondered how much longer they would be able to keep that up. They're still doing it.
The market can stay irrational longer than you can stay solvent
to be fair, that cobol program has been working for probably 30 years (maybe even longer than that) - thats unusually reliable and long-lived for a software project.
the only real contender in this regard is the win32 api, and actually that did get used in enterprise for a long time too before the major shift to cloud and linux in the mid 2010s.
ultimately the proof is in the real-world use, even if its ugly to look at... id say, even as someone who is a big fan of linux, if i were given a 30 year old obscure software stack that did nothing but work, i would be very hesitant to touch it too!
Re: The next two years of software engineering
#115The outlook on CS credentials is wrong. You'll never be worse off than someone without those credentials, all other things equal. Buried in this text is some assumption that the relatively studious people who get degrees are going to fall behind the non-degreed, because the ones who didn't go to school will out-study them. What is really going to happen generally is that the non-degreed will continue to not study, an…
The fundamentals of CS dont change and are more valuable to learn for the long term. Vibe coders think they can just bypass everything because they can ask a machine to write them a todo list.
I think you're right but it's more like the theory and other thinking skills are harder to pick up on your own than particular technologies. You definitely still ought to learn both theory and particular tech skills, as they are not interchangeable. A person who only knows pure CS is difficult to employ as an engineer because programming entails particular technological skills.
Re: The next two years of software engineering
#116Sometimes I wonder if I made the wrong choice with software development. Even after getting to a senior role, according to this article, you're still expected to get more education and work on side projects outside of work. Am I supposed to want to code all the time? When can I pursue hobbies, a social life, etc.
Since you're getting into a senior role, learn the mantra, it depends :D
The usual trade-off of a well paid software development job is lack of job security and always learning - the skill set is always changing in contrast with other jobs.
My suggestion, stop chase trends and start to hear from mature software developers to get better perspective on what's best to invest on.
And why the mantra is always true?
You can find stable job (slow moving company) doing basic software development and just learn something new every 4 years and then change companies.
Or never change company and be the default expert, because everyone else is changing jobs, get job security, work less hours and have time within your job to uplift your skills.
Keep chasing latest high paid jobs/trends by sacrificing off time.
What's the best option for you? Only you know, it's depends on your own goals.
Re: The next two years of software engineering
#117I mean it's pretty simple: management will take bad quality (because they don't understand the field) over having and paying more employees any day. Software engineer positions will shrink and be unrecognizable: one person expected to be doing the work of multiple departments to stay employed. People may leave the field or won't bother learning it. When the critical mass is reached, AI will be paywalled and rug pulle…
This is truly the problem: You either get fired or you get to work 10x more to survive. Only question is how many of us will be in 1st group and how many in the 2nd group, its a lose lose situation.
Exactly. Some jobs moved from database, backend, frontend and devops to "fullstack", which means 4 jobs with the pay of one. People do that job, but with only 8h-10h in a day the quality is as expected. I think overall people will try to move out of the field, no matter how much of a force multiplier AI might be. Its simply a worse trade to carry so much responsibility and burden when you can work in IT or outside of IT in a less cognitively demanding field with set hours and expectations for the same pay (in EU, very hyperbolic statement tbh). Especially when the profit you bring dwarfs the compensation with all the frustrations that come with knowing that and being kept down in the corporate ladder.
Re: The next two years of software engineering
#118My experience hasn't been LLMs automate coding, just speeds it up. It's like I know what I want the solution to be and I'll describe it to the LLM, usually for specific code blocks at a time, and then build it up block-by-block. When I read hacker news people are talking like it's doing much more than that. It doesn't feel like an automation tool to me at all. It just helps me do what I was gonna do anyways, but with…
You can think of LLMs as a higher level language for whatever programming language you are using, but informal with ambiguous grammar.
On the foolishness of "natural language programming". - prof.dr.Edsger W.Dijkstra
https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
Re: The next two years of software engineering
#119The next two years of software engineering will be the last two years of software engineering (probably).
I don't see the market flooded yet with software that was "so easy to build using LLMs". Last year was, as it seems, just a normal year in terms of global software output.
This is such a stupid argument. A very significant amount of code never makes it into the public sphere. None of the code I've written professionally in the last 26 years is publicly accessible, and if someone uses a product I've written they likely don't care if it was written with the aid of an LLM or not.
Not to mention agent capabilities at the end of last year were vastly different to those at the start of the year.
Re: The next two years of software engineering
#120Earlier quoted context omitted.
> It’s almost impossible to discuss LLMs on HN because everyone is busy attacking the vibecoding strawman all the time. What’s “the vibecoding strawman”? There are plenty of people on HN (and elsewhere) repeatedly saying they use LLMs by asking them to “produce full apps in hours instead of weeks” and confirming they don’t read the code. Just because everyone you personally know does it one way, it doesn’t mean every…
I'd assume the straw-man isn't that vibe-coding (vbc) doesn't exist, but that all/most ai-dev is vbc, or that it's ok to derail any discussion on ai-assisted dev with complaints applicable only/mainly to vbc.
Neither of those would be a strawman, though. One would be a faulty generalization and the other is airing a grievance (could maybe be a bad faith argument?).
https://en.wikipedia.org/wiki/Faulty_generalization
Though I get that these days people tend to use “strawman” for anything they see as a bad argument, so you could be right in your assessment. Would be nice to have clarification on what they mean.