We have an instance where the non-tech team has started building tooling for themselves (because the technical team is overburdened with work).

Essentially a small application idea that interfaces with the larger system. It was POC built in 2-3 days, 3 or 4 commits.

Impressive - however the person that built it has now made 400 more commits over the last 3 months to this project as it has been modified, it’s essentially become his part / full time job to just build + maintain this new application.

They have become a software developer. An untrained one, one that doesn’t understand security or best practices. Maybe as Claude gets better the load will be lightened and it will not consume their day, but as it stands - at my company, all of these initial “vibe apps” are becoming maintenance for them, taking up more and more of their time. It’s obvious that they want MORE software, not less. So traditional software engineering is probably gone, but managing expanding platforms and handling security, complexities, documentation, business logic, all of that is still standing in the way for my company.

So you are correct saying that people can build projects with text, but I feel that “set and forget” has never been the case for all but the simplest software. Someone still has to manage all of it, I think. Whether trained in SE or not.

My guess is that developers who have experience can still outperform untrained people, though the builders who are curious by nature will quickly get up to speed. The game is changing but traditional developers have a huge upper hand, because we’ve always wanted to know how things work under the hood. I could have built the current vibe app that they built in a hour using AI, it’s taken them months.

▲

fragmede 8 hours ago | parent | next [-]

In that sense, AI is creating software jobs. Not very good ones, and they're being paid way less, but a jobs a job, I guess. We have to face the music. it's not that AI will take software jobs, it's that it will make them pay a janitor's wages.

But while the AI isn't good enough to do it all, While there's still a vibe code wall that non-developers run into, senior developers will still have a job scaling that wall. That walls getting shorter as models get better, but for right now, this second, even with Anthropic's Fable, our jobs are safe.

We have to step back and look at the bigger picture though. Stable Diffusion came out and suddenly I could generate images that I didn't have the patience to use Photoshop or a pencil to create. But after playing with it for a couple of days, I got bored of it and went back to coding. Sora came out and at my fingertips I had the power to be a movie director. A couple of days later, I went back to writing code. Or by that point, directing AI agents to write code. So after the last software developer loses their job, having been replaced by robots, I can't imagine I won't still be the same person underneath. I build things that are as complicated as they need to be, but no more. Sometimes I even succeed.

	▲	Kerrick 5 hours ago \| parent [-]
		That wall was detailed in 2003 in Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans, Chapter Four, "Smart UI Anti-Pattern." The context is the same, the problem is the same, the solution is the same. Even the advantages and disadvantages are the same as what you see in vibe-coded projects. > A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers. > [...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested. > Therefore, when circumstances warrant: > Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available. > [...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to. > Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI. > Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior. > [...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.

▲

bigfudge 5 hours ago | parent | prev [-]

https://xkcd.com/1319/

I think there will be a lot of this going on for the first few years, till everyone remembers this:

https://xkcd.com/1205/