There Is Still No Silver Bullet · cekrem.github.io
Conversation activity · last 21 hours presspostscomments the crowd ↓
Every item, in order 17
Clustered from 17 items across 3 sources. Not yet parsed — the coverage below is the raw record.
Social posts 3
The conversation unedited, verbatim
16 comments claimed on the threads · 14 collected here from 1 site · 13 voices below over time ↑
- Yesterday
-
it usually takes more than a couple hours for the person that wants the task to explain to the engineer what even is the problem to solve
-
> Does it even matter though? for a huge majority of software, it doesn't. There's much, much more software in the world used once and thrown away (for instance, medium excel sheets, programs just written once in a REPL to do one computation) than durable and reusable. AI simply makes it easier to raise the scale of the "throwable-away" stuff
-
Yes, I was referring to popular discourse. I am conflicted because on one hand, I've seen first hand how excited non-technical folks are of coercing an LLM to build something practical that they would have otherwise not been able to do. They get to experience a myriad of feelings that we technical folks take for granted. And yet, I perceive no…
-
Just deciding to spend engineering time on something is expensive. There are thousands of kinds of tasks done manually every day that can be easily automated if only someone who knew how would be assigned to do so.
-
If it's the type of thing that can be vibe coded in a couple hours by someone with no knowledge, I doubt it would've taken much engineering time without AI either.
-
Yes but also dev time is often too expensive to spend on these flows even when we know about them.
-
Oh, let me be straight: the "naive LLM" solution to this problem is completely ridiculous. It's the total wrong way to go. The spirit of my comment was that the failure to properly implement end-user programming in the direction it was heading decades ago is, in part, to blame for the situation where regular people are trying to build apps this way
-
You acknowledge that interoperability and a user-centered design were dropped not because of technical reasons alone but because of the economic incentives to build silos. I am not convinced things will change for the better when the purported solution is predicated on a trillion and a half dollars in investment looking for a return.
-
I feel like we have sort of gotten a silver bullet of sorts, in the shape of "every time a problem is solved in code, add it to a universal library so that it's just a lookup away next time"
-
In today's computing world, "applications" -- whether they be online or on the computer -- are unfortunately siloed. It's been this way for a long time now. There was a lot more promise in the late 80s and 90s, where end user programming as a technique was taken quite seriously (I'm thinking of things like HyperCard, or how the desktop publishing…
-
except it's anything but trivial workflows: it's very specific, individual workflows that match pretty much each individual's way of working and tasks at a given point in time.
-
One thing it probably means is that we've done a terrible job identifying opportunities where someone's workflow could be trivially improved with software, so they had to do it themselves.
-
> So the sales pitch (“let AI write the code so you can focus on what matters”) lands exactly backwards for the people it’s aimed at; it is, quite precicely, wrong. so what does it mean when I have people on my team that are complete non-programmers and that are now able to have AI build for them the exact tools they need to make their actual job…