[dataviz1000]

I'm running a server on AWS with TimescaleDB on the disk because I don't need much. I figure I'll move it when the time comes. (edit: Claude Code is managing the AWS EC2 instance using AWS CLI.)

Claude Code this morning was about to create an account with NeonDB and Fly.io (edit: it suggested as the plan to host on these where I would make the new accounts) although it has been very successful managing the AWS EC2 service.

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, but I was surprised it was hawking products even though Memory.md has the AWS EC2 instance and instructions well defined.

[dvt]

> 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]

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]

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

Mediocrity in, mediocrity out.

[logicchains]

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".

[xg15]

> 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.

[nikcub]

> Claude Code this morning was about to create an account with NeonDB

I had the same thing happen. Use planetscale everywhere across projects and it recommended neon. It's definitely a bug.