alt Hacker NewsI've came up with the same basic analogy as you.
What it boils down to is that the future of coding is more about creating the mold where the code is poured in and knowing how exact of a mold is "good enough" for the problem at hand.
When the mold is done, you let the agent pour in the code in any format you like. It can create a Swift version, Rust version and a web assembly version in "half a soda" as you put it =)
The people for whom the only enjoyment in programming was molding the perfect item from scratch will still be needed, but less and less as we get better and faster in defining the molds for the agent to pour the code in.
Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec we can use as a reference to build the actual tool.
Replies
> Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec we can use as a reference to build the actual tool.
What are they paying you for if you’re just having your clients vibe code their own apps?
> What it boils down to is that the future of coding is more about creating the mold where the code is poured in and knowing how exact of a mold is "good enough" for the problem at hand.
> When the mold is done, you let the agent pour in the code in any format you like. It can create a Swift version, Rust version and a web assembly version in "half a soda" as you put it =)
Unless you use code, that mold is at best a formless bag.
The reason people use software is because there's a need to manipulate some data/information, transfer it, and interact with it (input or output). All those actions needs to be done correctly, and if not possible the error should be reported. To get to that level of correctness, we need to be formal with how we express the process, which means essentially going from a non-zero amount of ambiguity (natural language) to zero (programming language).
Using AI to translate specs/prompt to code is just asking it to randomly resolve any ambiguity found in the specs. And as any experienced dev knows, some of those are just tradeoffs where there no right or wrong answers, just contextual ones that evolves over time and space.
> Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP
I wonder if there's actually been conversation with the client before? Where you use some prototyping tools like RAD or Sketch to resolve UI issues, get in touch with the actual domain experts,... or was it just a telephone game full of politics?
> When the mold is done, you let the agent pour in the code in any format you like.
Exactly. And the mold could be a spec, an MVP or even one of the implementations (e.g. the Swift one) acting as the source of truth for the other versions.
> "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP but in more cases is just an interactive UI spec
That's a great example of what malleable code unlocks. You let the client to create the mold themselves, refine it and then use it to properly build the product.