The huge apps that my coworkers build out with minimal human input makes me scared to be a web dev in this environment. Just way too much can get automated.
Yeah completely unmaintainable code that cant handle more than 1k users before it collapses on itself. And quite probably so ugly its literally impossible to use.
That only matters if you need to support 1k users. Tons of software doesn't and if you can spit out a web app in a few hours a lot of companies are going to do that.
I'm sure there is still a pot for really high quality stuff but it's a tradeoff a lot of companies don't care. But the interfaces - they aren't ugly, they're very usable and complete, which is the main reason I think web dev is in trouble. It'd take me 10x the time to do it myself.
Simple web apps, the kind you're describing have never been difficult, they were never what kept SWEs employed.
I'm not even sure what you're talking about when you say "web apps", because the kind of "web apps" that have kept SWEs employed are created by large organizations that have large requirements. You sound like you don't know what you're talking about. Companies also aren't going to just stop growing, iterating and improving, which requires expertise. Im worth more than ever with AI, my value as a SWE has only been increasing.
You people seriously need to stop using LLMs because your brains are devolving like taxi cabs drivers who had parts of their brains responsible for navigation atrophy after the advent of GPS.
> Simple web apps, the kind you're describing have never been difficult, they were never what kept SWEs employed.
I'd say the first part is right but the second part is statistically incorrect. I would even expand from "web-apps" to just about any kind of software, especially "business software" -- very little of it was ever too difficult.
Now the following will clearly not be true for all cases, and the boundaries are very fuzzy, but generally a huge part of software development has always been the relatively straightforward translation of high-level requirements into code. Crafting the high-level requirements was typically the challenging part, but that typically was done by the more senior devs / architects, whereas the actual implementation was done by more junior / mid-level engineers. And there were typically multiple junior / mid-level devs for every senior dev, say 3:1 or more. As such, it is correct to say that the simpler aspects of software development were what kept most SWEs employed.
Now AI has completely usurped the lower-level coding work. You as an expert dev are definitely getting worth more than ever with AI, but that's because you single-handedly can now do what an entire team used to do. You may even get paid much more, but that is eventually going to be at the expense of a bunch of other people who are not required anymore.
This is why people are seeing "jobs apocalypse" written on the wall.
I don't get why you're being so rude. What's the point?
For the record, I hardly use these models. I've simply seen that they can replace existing web apps. That hurts the market for web devs, most orgs aren't building out large apps they are building out smallish ones and generative models do that today.
Sorry, Ive been hearing these exact same arguments for 3 years now and its always extermely divorced from reality. Its starting to get very tiring, its hard not to be rude at a certain point.
Don't go around telling people their careers are in peril when you clearly have no clue what you're talking about. What do you expect?
You've identified a very specific type of web dev, one that works on perf critical apps in a corp environment and said corp cares about perf and quality. Tons of people simply don't work in those environments and unfortunately this threatens their career.
I work in an environment where we can vibecode 4/5 of our web apps because they are either small enough or the perf doesn't matter. Or, I've looked under the hood and these are writing endpoints that would take me 3x the amount of time it would take it to use the same libraries. You say it's divorced from reality, I'm saying it's just what I've directly observed.
I'm glad it doesn't affect you, but you don't have any kind of statistical measurement (nor do I) to know how much of the market this impacts. I do know for a lot of the web dev I did pereviously, I could do it viea these models today.
Yeah I've been at that stage since Opus 4.6 pretty much. There's still a lot of back and forth in the conversation on complex tasks, but I have not written any code. We are working on a MASSIVE project for our multi-billion dollar client and the whole team is completely using AI. Even the UX guys and our project managers are making the prototypes they want us to implement by vibe coding it first in a static app. I haven't seen Figma usage in months.
What if they ask you: and you? Are you actually building high quality software?
What are your quality gates? How many open bugs are there on production? How often you close bugs with resolution: won't fix(because of budget issues)? How often do you have production incidents? What is your testing strategy? How are you testing your requirements before assigning them to the developer for implementation? Do you hire external professionals for security testing?
Rabbit and most databases have their own failover strategy. Putting it all on k8s is fine for a toy app but idk why anyone would deploy a real system like that.
OK, I can only speak to my personal projects and 20+ years experience at work.
We run all of our stateful and stateless workloads on 10+ kubernetes clusters at work in multiple datacenters in multiple continents, and we serve 500 million users a month with it.
I wrote the first BORG version of DFP backend systems at Google, where we served billions of users billions of ads a day, and we used stateful infrastructure management on some of the first container runtime systems that inspired k8s during it's development.
Using rabbit and "most databases" native fallover strategy is fine for toy projects, but when you're operating at this scale, you need automated infrastructure provisioning and all of the automated tooling around it.
There are layers to this. At the simplest level, you only have K8s people (and aren't willing to use cloud services). So you install the RabbitMQ Helm chart, hope for the best, and fix any issues that come up.
Then you get a bit worried that the Postgres Helm chart, while good, doesn't do what you want. So you update to use a dedicated clustered Postgres, using some Postgres clustering tech.
Finally, you're at so much scale you can throw giant wads of advertising cash at the problem, and you can use anything you like and it'll work. You just need to choose the best thing for your particular problem.
They are cylindrical, grey, without apparent means of aerial propulsion, and prone to interfering with ultrasonic sensors...
Most dolphins are smaller than a compact car, but I bet they would break apart upon impact with a frozen sea after dropping out of the sky. This might be the correct answer.
With 1.5 fatalities per 100,000,000 miles[0], the benchmark to meet is 99.9999985% of the time it doesn't kill you. Injuries are going to be a lot higher, obviously. Still, I think most self-driving enthusiasts underestimate the bar that needs to be crossed wrt safety. And general vehicle safety isn't going to remain stagnant. I think it's going to be a cost vs injuries tradeoff for quite a while until we get human-level or better self-driving safety in all circumstances.
Captured the requests in a flash client used in a 6 hour defensive driving class to skip to the last page. Got my certificate. My friend did the same thing and the company reached out trying to figure out why they were getting all of these database errors...
reply