> It works, sure, but is it worth your time to use?
This is something I like about the LLM future. I get to spend my time with users thinking about their needs and how the product itself could be improved. The AI can write all the CSS and sql queries or whatever to actually implement those features.
If the interesting thing about software is the code itself - like the concepts and so on, then yeah do that yourself. I like working with CRDTs because they’re a fun little puzzle. But most code isn’t like that. Most code just needs to move some text from over here to over there. For code like that, it’s the user experience that’s interesting. I’m happy to offload the grunt work to Claude.
Every little detail matters though. In SQL, do you want your database field to have limited length? If so, pay attention to validation, including cases where the field's content is built up in some other way than just entering text in a free-form text field (e.g. stuffing JSON into a database field). If not, make sure you don't use some generic "string" field type provided by your database abstraction layer that has an implicit limited length. Want to guess why that scenario's on my mind? Yeah, I neglected to pay attention to that detail, and an LLM might too. In CSS, little details affect the accessibility of the UI.
So we need to pay attention to every detail that doesn't have a single obviously correct answer, and keep the volume of code we're producing to a manageable enough level that we actually can pay attention to those details. In cases where one really is just literally moving data from here to there, then we should use reliable, deterministic code generation on top of a robust abstraction, e.g. Rust's serde, to take care of that gruntwork. Where that's not possible, there are details that need our attention. We shouldn't use unreliable statistical text generators to try to push past those details.