If you do backend blind, it will also almost certainly embarrass you. I’ve never had an experience beyond the most basic crud app where I didn’t have to somehow use my engineering experience to dig it out of a hole.
Works mostly fine for me on Rust backends. As long as I'm willing to accept tight contracts at the edges with spaghetti in the middle, or otherwise gate approval for everything it does.
If I want good abstractions, sure, I can set up approvals and babysit it with reprompting, because it will do stupid things that an experienced engineer wouldn't. But the spaghetti also works in the sense that it takes the input types and largely correctly maps them to the output types.
That doesn't emarrass me with customers because they never see the internals. On front-end, obviously they will see and experience whatever abomination it cooks up directly.
It’s easier not to have that separation, just like it was easier not to separate them before LLMs. This is architectural stuff that just hasn’t been figured out yet.
With databases there exists a clear boundary, the query planner, which accepts well defined input: the SQL-grammar that separates data (fields, literals) from control (keywords).
There is no such boundary within an LLM.
There might even be, since LLMs seem to form adhoc-programs, but we have no way of proving or seeing it.
There cannot be, without compromising the general-purpose nature of LLMs. This includes its ability to work with natural languages, which as one should note, has no such boundary either. Nor does the actual physical reality we inhabit.
Since GPS-OSS there is also the Harmony response format (https://github.com/openai/harmony) that instead of just having a system/assistant/user split in the roles, instead have system/developer/user/assistant/tool, and it seems to do a lot better at actually preventing users from controlling the LLM too much. The hierarchy basically becomes "system > developer > user > assistant > tool" with this.
Sometimes PRDs might be boilerplate, but there’s been times where I sat down thinking “I can’t believe these dumbasses want to foo a widget”, but when writing the user story I get into their heads a little and I realize that widgets are useless if they can’t be foo’d. It’s not the same if AI is just telling me, because amongst the fire hose of communication and documentation flying at me, AI is just another one. Writing it myself forces me to actually engage, even if only a little more than at a shallow level.
Do you only work on projects individually? Without project-specific environments I don’t know how you could share code with someone else without frequent breakages.
reply