I would trust an LLM with backend much more than front-end. Especially if we're talking monolithic and good type system. Ideally compiled. When I say trust I mean it's not going to break the user-facing API contract, probably, even if internally it's a mess. If you let it do front-end blind, it will almost certainly embarrass you if you care at all about user experience.

▲

viktorianer 3 days ago | parent | next [-]

Rails is a good example of why. One correct place for migrations. One expected controller structure. Validations on the model, callbacks with a defined lifecycle. When the framework defines where things belong, you can write automated rules that catch bad AI output: "no business logic in controllers," "no conditional assertions in tests." Each rule works because Rails narrows what "correct" means.

Frontend has no equivalent constraint. A component can be structured a hundred different ways, and "does it look right" requires vision the model does not have.

▲

clickety_clack 4 days ago | parent | prev [-]

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.

	▲	0x3f 4 days ago \| parent [-]
		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.