The interesting thing nobody's talking about here is that cheap code generation actually makes throwaway prototypes viable. Before, you'd agonize over architecture because rewriting was expensive. Now you can build three different approaches in a day and pick the one that works.
The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.
I think the prototype thing is absolutely true but breaks down like all prototypes at the level of collaborating, sharing and evolving while handling entropy throug simplicity UNLESS you know what you're doing or the agent steers you with very opinionated tooling customized to your context. I'm thinking about empowering people to be builders and less so a software developer who can make the right tradeoffs.
Empowering people to work Tracer bullet style after they've selected their prototype of choice and thrown it away might be a powerful pattern that actually gets us into a nice collaborative space.
This feels to me like peak sfba mentality on par with "move fast and break things". Outside of trying to create a unicorn, is this really how people create things?
It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't. Like a painter needs to paint a bunch of crappy paintings to learn how to create a good painting. If you have the LLM create these throwaway prototypes, how will you even know when you come across a good idea and how will you be able to build it.
> It seems to me that in order to obtain the ability to build things that other people like, you need to go through the process of creating things they won't.
Okay, granted. What does that have to do with how the code is written? Do people generally care if a web app is running from nicely formatted JS or minified JS? Is a product manager not getting better at building things people like because they're not iterating on the code themselves?
Without agreeing or disagreeing with the premise, I think a relevant metaphor* here is that the painter can practice and iterate and go from creating crappy paintings to creating good paintings, without needing to make their own paint and canvas and brushes. If they're particular, they can have their assistant go to the supply shop and get just the right things they want, with increasing specificity as needed, but they don't need to manufacture them by hand.
* Like most metaphors, it's not perfect; please try to understand the intent.
I agree mostly with your metaphor, I think perhaps I disagree slightly on how it's applied. You don't need to create your own tools to create art, but I don't necessarily map the "tools" to code. The act of programming is mapping information to hardware, the value is in the information, and using LLM's to bypass the phase where you obtain, synthesise, and extend that information is the part where you lose the benefits of iteration. If you're just using the LLM as a mechanical tool to output code, it's mostly not different from, say, using speech-to-text to output code. When you start hearing things like "I don't care about the quality of the code, just it's outputs" that starts sounding like someone isn't iterating on the information which is the crucial bit.
But you need to actually be the one doing the iterating, you can't outsource it. The entire point to doing the iteration is the process, not the artefacts.
Hmm interesting, I didn't realise people were using it as a typing replacement instead of having it work agentically. Does that mean when you want to change a line of code somewhere, you just prompt the LLM to replace line 334 with your changes etc? So do you not use the LLM autonomously at all then? Sounds like it since you're still doing the iteration yourself.
I do both. A lot of changes are "autonomous" like "add a new Django model to record a change every time the title or body is edited in the admin", but I also do more fine grained edits like "have the import script truncate to 400 chars" (instead of 250.)
Sometimes I'll make edits like 400 to 250 by hand, but if I'm prompting on my phone it's faster to have the model do it as navigating code in an editor and changing it at the exact right point is fiddly on a mobile keyboard - models can spot and account for typos, direct code editing can't.
The real cost was never the code itself. It was the decision-making around what to build. That hasn't gotten cheaper at all.