> Claude Code likely is correct that I should start to use NeonDB and Fly.io which I have never used before and do not know much about

I wouldn't be so sure about that.

In my experience, agents consistently make awful architectural decisions. Both in code and beyond (even in contexts like: what should I cook for a dinner party?). They leak the most obvious "midwit senior engineer" decisions which I would strike down in an instant in an actual meeting, they over-engineer, they are overly-focused on versioning and legacy support (from APIs to DB schemas--even if you're working on a brand new project), and they are absolutely obsessed with levels of indirection on top of levels of indirection. The definition of code bloat.

Unless you're working on the most bottom-of-the-barrel problems (which to be fair, we all are, at least in part: like a dashboard React app, or some boring UI boilerplate, etc.), you still need to write your own code.

▲

drc500free 2 hours ago | parent | next [-]

I find they are very concerned about ever pulling the trigger on a change or deleting something. They add features and codepaths that weren't asked for, and then resist removing them because that would break backwards compatibility.

In lieu of understanding the whole architecture, they assume that there was intent behind the current choices... which is a good assumption on their training data where a human wrote it, and a terrible assumption when it's code that they themselves just spit out and forgot was their own idea.

▲

hinkley 2 hours ago | parent | prev | next [-]

How do you make an LLM that’s was trained on average Internet code not end up as a midwit?

Mediocrity in, mediocrity out.

	▲	ipaddr an hour ago \| parent [-]
		Mediocrity means average.

▲

xg15 an hour ago | parent | prev | next [-]

> they are overly-focused on versioning and legacy support (from APIs to DB schemas--even if you're working on a brand new project)

I mean, DB schema versioning is one of the things that you can dismiss as "I won't need it" for a long time - until you do need it, at which point it will be a major pain to add.

	▲	vessenes an hour ago \| parent [-]
		I second this. Especially with a coding assistant, there's no reason not to start out with proper data model migration. It's not hard, and is one of the many ways to enforce some process accountability, always useful for the LLMs

▲

logicchains 2 hours ago | parent | prev [-]

From what you said it sounds like the conclusion should be "you still need to design the architecture yourself", not necessarily "you still need to write your own code".

	▲	parliament32 2 hours ago \| parent \| next [-]
		But he did design the architecture: > even though Memory.md has the AWS EC2 instance and instructions well defined I will second that, despite the endless harping about the usefulness of CC, it's really not good at anything that hasn't been done to death a couple thousand times (in its training set, presumably). It looks great at first blush, but as soon as you start adding business-specific constraints or get into unique problems without prior art, the wheels fall off the thing very quickly and it tries to strongarm you back into common patterns.
	▲	dvt 2 hours ago \| parent \| prev [-]
		Yeah, I actually wanted to write an addendum, so I'll just do it here. I think that going from pseudocode -> code is a pretty neat concept (which is kind of what I mean by "write your own code"), but not sure if it's economically viable if the AI industry weren't so heavily subsidized by VC cash. So we might end back up at writing actual code and then telling the AI agent "do another thing, and make it kinda like this" where you point it to your own code. I'm doing it right now, and tbh working on greenfield projects purely using AI is extremely token-hungry (constantly nudging the agent, for one) if you want actual code quality and not a bloated piece of garbage[1][2]. [1] https://imgur.com/a/BBrFgZr [2] https://imgur.com/a/9Xbk4Y7