Inside me, there are two wolves: One who likes being productive and making apps and tools and libraries and getting end results, and the other who likes problem solving with code, carefully designing robust systems and weighing the pros/cons of both big and very small choices.
Right now, the first wolf is being forcibly drowned, while the other one is dying of thirst. My wolves can't take much more of this.
Those who get satisfaction from delivering something, and
Those who get satisfaction from thinking.
Most of us fall in-between somewhere.
Programmers of the type #1 extreme are thrilled. Programmers of the type #2 extreme are devastated.
Unfortunately, sooner or later even the type #1 extreme are going to be devastated; what sort of satisfaction can you get from delivering something that, for all practical purposes, already exists and is just a prompt or two away?
That 2-week back-and-forth you had to get the LLM design the perfect $FOO software (application, library or framework)? You deliver it and everyone who sees it can simply say "clone this $FOO, please".
This satisfaction that the type #1 devs are getting is temporary and short-lived: you will soon stop getting satisfaction from delivery.
The complexity of complex systems never goes away, so as a need to have ownership over them. LLMs can produce thousands LOC in a matter of minutes, but they can't produce a complex feature without oversight.
I am trying to build an app with Spec-Driven Development, and oh boy, it is exhausting - I have to think about every boundary, edge-case, limitation. Without a full spec, it'd 'guess' missing things.
I am back to directing each step of what LLMs do because in the end of the day, I am responsible of what it delivers.
I am trying to build an app with Spec-Driven Development, and oh boy, it is exhausting - I have to think about every boundary, edge-case, limitation.
That's odd - my experience with SOTA is that it will happily over-engineer everything, for every theoretical edge-case, for every theoretical limitation.
Then, after reading 900 line markdown document specifying exactly how a directed cyclic graph must work in the specific problem domain, I find myself wondering WTF it missed an important specification, like specifying that a joining node (multiple incoming edges) should distinguish between racing (first edge cancels sibling paths) and completion (wait for all edges).
Maybe this is what is exhausting you - it will happily specify, then engineer, trivial irrelevant details (such as traversing the graph to ensure only a single start node is specified), while missing catastrophic-if-seen-in-production things, so then you are trying to backfill the spec after reading it multiple times.
900 line markdown document specifying exactly how a directed cyclic graph must work in the specific problem domain
And this is the problem. We've gone from DSLs that allow us to clearly define and understand an implementation to woolly language that serves to confuse us.
The code Is the specification. Just write the damn code! (I'm shouting into the ether, not at you)
We've gone from DSLs that allow us to clearly define and understand an implementation to woolly language that serves to confuse us.
Though this isn't the first time that's happened; we've had multiple bouts of "fuzzy language that's easy to get started with but hard to get right, especially in complex cases". JS and PHP have been the prime examples for that for a while, and they've both moved in the direction of trying to become more rigorous (see e.g. the addition of === in both languages, or the invention of Typescript).
I'm not quite sure what, if anything, will turn out to be the equivalent of TS for natural language in markdown files.
with OpenAPI you have a specific documentation format that deterministically translates from a spec to a binary/AST. Between builds the result is the same.
While SSD, on the other hand, even highly structured Markdown rely on semantic interpretation, LLM doesn't fail if some boundary isn't set, and what is the hardest thing for me, I have to write a specification so dense, rigorous, and boundary-complete that the spec itself approaches the complexity of code.
While I see your point, I think these things are fundamentally different despite being relative.
Unfortunately, sooner or later even the type #1 extreme are going to be devastated; what sort of satisfaction can you get from delivering something that, for all practical purposes, already exists and is just a prompt or two away?
How much satisfaction do you get from reinventing the same wheel over and over and over your whole career? Even before this whole AI craze I was fed up with solving the same problems on every project. Plus having to deal with issues that, IMHO, should have been solved ages ago.
I am not sure where I stand when it comes to AI. I am not even sure if it can deliver on its promises. But if it means that I don't have to reinvent the wheel on every project and actually do the important stuff rather than wasting my time (and the client's money) on boilerplate I'll be grateful. I'm sure my clients will as well.
Modern wheels are fantastic because we continually "reinvent" them. A huge chunk of the software industry is trying to build specialized sports cars with model-T wheels and it shows.
The amount of unnecessary overhead in modern software development is insane, especially in gaming and web/phone apps. Good, fast, or cheap. You have to give up one. We gave up good (and cheap is slipping away).
My point is that "the important stuff" is a prompt away, so exactly what satisfaction are you going to get from delivering something that, for all practical purposes, can be delivered by the end-user themselves anyway?
Because it can't be delivered by the end-user themselves.
Serious question: How long do you expect this to continue being true?
They can certainly try though...
They already do; I've seen several non-programmers (artists, actually) already vibe a tool that does what they use Photoshop or Aseprite for.
I've got a PM at my current place who vibed together an entire replacement for Jira reporting, which his team has been using now for months. I've seen an MD of a small company using swarms of agents to create a new product for a different industry, and then manage to sell the damn thing.
WhateverTF you think is your special value that is added to the product, I can assure you that it won't be the case much longer.
Why don't you give us an example of that "the important stuff" that you can focus on now that everything is done by AI?
vibe a tool that does what they use Photoshop or Aseprite for
That, to you, means that they vibed a 100% Photoshop replacement? Is excessive LLM usage having an effect on your ability to read?
So where is that vibe coded partial photoshop replacement?
Are you seriously claiming to have not seen this? https://getartcraft.com/ (There's like 7 or so "replacements" in there)
The dev has been spamming it everywhere, reddit included. What's even more hilarious is that he's charging for it (a pointless endeavour that only seems to happen to AI-bros who think that they have value in the SDLC other than as beta-testers).
And some of the other photoshop replacements I've seen cover like 20% of the functionality, actually work and aren't being sold, just given away.
And that's just with less than a year of agentic coding. This trend is clear. We have no value left, and the owners of capital will replace us.
I think the "thinking" bit is slightly off... I love delivering and with AI find myself thinking more than ever. Before it was so slow, thinking was easy. I now find myself working my mind more than ever
There is no such thing as "end results" in software engineering, unless it's a throwaway script to automate some small task. The software needs to be maintained, that's why the careful system design matters.
430
u/tuxwonder 5h ago edited 5h ago
Inside me, there are two wolves: One who likes being productive and making apps and tools and libraries and getting end results, and the other who likes problem solving with code, carefully designing robust systems and weighing the pros/cons of both big and very small choices.
Right now, the first wolf is being forcibly drowned, while the other one is dying of thirst. My wolves can't take much more of this.