Are you writing code for end-user applications, or for tools or libraries that other stuff is built with?

adamtaylor_13 3 hours ago | parent | next [-]

Both. And internal tools. And infrastructure scaffolding a la terraform. And visual design.

And frontier models routinely crush all the above in a way I couldn't, at speeds unattainable to mere flesh and blood like me.

	▲	adamddev1 3 hours ago \| parent [-]
		I still think internal tools are kind of in a category closer to end-user applications. They are limited in how widely they are used, and therefore they don't have to be as solid as say libraries used by millions.

▲

grim_io 3 hours ago | parent | prev | next [-]

Not the guy you asked, but honestly, I'm not sure which one of those I'd consider better use cases, not worse.

▲

adamddev1 3 hours ago | parent [-]

I ask because I think there's a huge difference between the two.

People making end-user applications might think they can tolerate more errors and bloat from AI.

Just because they can get away with doing that with AI (and that's debatable) does not mean that people can also get away with that in developing tools, libraries, languages etc. The errors, bloat and instability bubbles up exponentially as people build on it.

There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore."

	▲	orangecat 3 hours ago \| parent [-]
		There seems to be this fallacy of "I don't have to write code anymore, therefore nobody will have to write code anymore." I see a lot more of "AI coding doesn't work well in this specific case, therefore it's entirely useless".

▲

m_w_ 3 hours ago | parent | prev | next [-]

Generally end-user applications, depending on how you classify internal tools. I'm generally very happy with the output of Opus 4.X with a moderately structured CLAUDE.md and some investment in detection/avoidance of anti-patterns (Next.js+ts). I imagine that the bitter lesson is true here, and these heuristic guidelines will become increasingly unnecessary w/ smarter models.

Library-type work has mostly been side/toy projects, although fwiw, with a standard/spec on hand (CommonMark for example), I'm also happy w/ the output. It's often possible to "close the loop" and have the coding agent autonomously iterate until the standard is adhered to.

	▲	adamddev1 3 hours ago \| parent [-]
		Thanks for the answer. From what I can see, most people who are enthusiastic and optimistic about AI use are producing end-user apps, internal tools (limited use) or just hobby libraries. The fuzziness may be tolerable on the edges of immediate use. Creating something that is solid enough for widespread, reliable building is just in another category. And I wish people recognized this distinction more when they say we don't need to look at code anymore.

▲

devin 3 hours ago | parent | prev [-]

Judging by parent's CV, it kind of looks like they are relatively new to the industry and working in areas where they are heavy on the greenfield side of the equation. I get the sense that they've probably had some good success on smallish projects where they are in charge of keeping it all in their head. That's not to say that isn't earned or otherwise valuable experience, but it surely is not the way a lot of software projects are situated. Parent: I hope you won't take my comment here as a slight. I mean no offense, just pointing out what I think is probably valuable context.

	▲	m_w_ 3 hours ago \| parent [-]
		Yes - this is certainly true. I would have to concede that I could not speak to how my thesis would map onto a truly colossal codebase. That said - I would (again, maybe naively) suppose it's not hugely different - much of the work I do occurs in code where many people have and will work on it, and where the size of the codebase dwarfs model context windows. In that case, I feel the same - current frontier models, when properly oriented to a task, with some assist on the big-picture thinking - are more than capable of generating good code that can slot into big codebases with many moving pieces. Of course, I'd have to point to other people's work to defend this, but I think that's still pretty reasonable especially against the declared "LLMs are worse than useless for generating code".