Comment by theshrike79
2 days ago
I'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.
> 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.
> 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?
Vibe coding the "feel" and flows of the app - if they know how to do it and what they want.
These are for highly specific stuff like a tool to help a copywriter work on game dialogue for example.
It's a fuckton faster for the actual expert in the field to do it than me first learning enough of their craft to know the terms and how they work to get there eventually.
The actual code that does anything meaningful is made by Actual Programmers. As well as everything beyond that, where it's run the CI pipelines, tests, infrastructure to run it etc.
It's like an architect asking a client to draw and describe their dream home and using it as a basis for the final product.
> 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?
Not just specs and prompts, tests, actual procedural limits. No program will ever be perfect[0], but you need to get it good enough for the problem at hand.
A human defines the checks (the mold) that give the agent the limits. They can be TLA+ definitions, linters, cyclomatic complexity checkers, unit tests, integration tests, end to end tests etc. And usually some written docs - made in a way that's specifically targeted at agents. Those define the limits the agent has to stay inside of.
There will always be work for human QA too, an AI can't determine if something feels off in an app's flow, it has no taste or concept of usability beyond the purely mechanical rules.
[0] Not talking about health, aerospace or nuclear stuff here naturally.