I've been through a handful of "anyone can do this" epiphanies since the 90s and have come to realize the full statement should be "anyone can do this if they care about the problem space".
I'm sure I could hack together some simple SaaS products with goals and features I'm defining myself in a weekend with these tools all on my own (no communication/coordination overhead, too!), though. I mean for an awful lot of potential products I could do that with just Rails and some gems and no LLM any time I liked over the last 15+ years or whatever, but now I could do it in Typescript or Rust or Go et c. with LLMs, for whatever that's worth. At work, with totally different constraints, the results are far less dramatic and I can't even feasibly attempt to apply some of the (reputedly) most-productive patterns of working with these things.
Meanwhile, LLMs are making all the code-adjacent stuff like slide decks, diagrams, and ticket trackers, incredibly spammy.
[EDIT] Actually, I think the question "why didn't Rails' extreme productivity boost in greenfield tiny-team or solo projects translate into vastly-more-productive development across all sectors where it might have been relevant, and how will LLMs do significantly better than that?" is one I'd like to see, say, a panel of learned LLM boosters address. Not in a shitty troll sort of way, I mean their exploration of why it might play out differently would actually be interesting to me.
These are cases where I've seen agentic solutions perform the best. My most successful and high impact projects have been at work, getting multiple "obscure industry-specific systems" talking to each other in ways that unblocks an incredible amount of project work.
Yeah, for those you can just relax and trust the vibes. It's for complex software projects you need those software engineering chops, otherwise you end up with a intractable mess.
Honestly this is where most traditional engineers get stuck. They keep attacking the old problem with new tools and being frustrated. I agree that agents are not a great way to build "complex software projects" but I think the problem space that is best solved by a "complex software project" is rapidly shrinking.
I've had multiple vendors try to sell my team a product that we can build the core functionality of ourselves in an afternoon. We don't need that functionality to scale to multiple users, server a variety of needs, be adaptable to new use cases: we're not planning to build a SaaS company with it, we just need a simple problem solved.
But these comments are a treasure trove of anecdotes proving exactly my point.
This feels a bit like a strawman. How do you assess it to be bad software without being an engineer yourself? What constitutes successful for you?
If anything, AI tools have revealed that a lot of people have hubris about building software. With non-engineers believing they're creating successful work without realizing it's a facade of a solution that's a ticking time bomb.
When did I say I'm not a software engineer? I have a software engineering background (I've written reasonably successful books on software), I've just done a lot of other stuff as well that people tend to find more valuable.
> What constitutes successful for you?
The problem I need to solve is solved? I'm not sure what other measure you could have. Honestly, people really misunderstand how to use agents. If you're aim is to "build software" you're going to get in trouble, if your aim is to "solve problems" then you're more aligned with where these tools work most effectively.