mattmanser

It's not my thoughts, it's simple facts.

All the studies show it's not an over-reaction, you're 400% more likely to have an accident. It is extremely dangerous and it's not an over-reaction, the more people do this, the more people die. It's simple maths. If you're doing extended programming sessions, you're not paying attention to the road like you should be.

And no, talking to a passenger is not as dangerous as it's a different cognitive load.

It'll take you 20 seconds to google this, please do and stop putting everyone else in jeopardy.

Comments like this boggle my mind.

The model which everyone else raves about and is wildly successful with legions of programmers virtually demanding access while abandoning ChatGPT and Copilot in droves, is rather dumb?

Have you considered that it's more likely that you're doing something wrong?

This is extremely dangerous and you should stop doing it.

https://etsc.eu/tiny-proportion-of-drivers-understand-danger...

The models were already much better before Claude Code came out, let's not rewrite history here.

I think you're pretty wrong here, but I'm no expert so anyone who wants to correct me please do so.

As I understand it, there's post-training step that does exactly that, they get real developers to select good and bad code and help the AI figure that out. AFAIK it's the reason why Claude was able to leap-frog OpenAI in coding last year, they did this refinement step a lot better.

And now they've taught the older models this, they can use existing models to bootstrap the newer models without humans involved, and bring humans in to just assess the trickier stuff.

Is that gen z humour?

As it reads more to me like it's Douglas Adams humour, i.e. 1980s humour.

British, post-Python absurdist humour or whatever you'd call it.

Last time I used Codex it would make loads of assumptions, often quite big ones, without asking.

Did they fix that, as that for me was what actually made codex worse.

No thanks.

DTOs are one of the big code smells of a code base that does little but will be full of boilerplate. As soon as you see an automapper or a folder of DTOs you know you're in for some serious pain.

On the plus side you also know you can reduce the codebase by about 75%.

Maybe for the other stuff, but not Redis.

It's not that your domain is different, it sounds more like you don't know how to use ORMs. ORMs don't have to manage migrations, they don't have to even write into the database. When dealing with a bad database design, it can be a legitimate tactic to use ORMs in read-only mode and have writes still as hand-rolled SQL. You can do database-first ORMs, as well as code-first, where the database design is king, not the POCO.

The domain deals with a lot of things that are not in the database.

You can have non-serialized properties. You can even can over-ride serialization/de-serialization of individual properties

The domain is one of many and deals with just a fraction of what is in the database

You can use different ORMs for different parts of your domain, you could even wrap multiple ORMs in a wrapper repo pattern if you want

The domain deals with things stored in several databases

As above.

The database was designed in the 90s and the domain is new

Tons of solutions for this, one easy one is using SQL Views, just ask Claude. The weird thing here is that I've now dealt with this IRL like 5 times and came to the opposite conclusion of you. I found wrapping a bad DB design with an ORM a great first step in fixing it, as the ORM effectively acts as an easy strangler pattern.

It's not my database so I can't change it

You can still use ORMs, ORMs don't have to manage migrations. Though I feel sorry for you working somewhere you still have a DB guy gatekeeping the database design in 2026.

The point is, every one of your objections are pretty trivially solvable with many mature ORMs, because everyone else had the same problems two decades ago and instead of throwing up their hands and hand-rolling their SQL, the ORM tooling was improved.

And I saw a "senior" engineer make a database table without foreign keys just 3 years ago.

Some people are just bad.

Doesn't change my point that the debate is long settled, SRP is incredibly well known and the de-facto way of coding today.

The trouble with SOLID is that it's mainly an artifact of old languages and paradigms.

3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time.

So what's the value here? Single responsibility?

That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.

Concepts that are worth explaining to beginners, but most code will follow it by default.

Seeing it in job descriptions is more an indicator that a company has an inexperienced lead more than anything else.

Speaking from a UK perspective global warming is now noticeable, hot days are hotter and there's more likely to be a heat wave, and that's changed in the last decade.

I assume Germany is the same, many years ago really is different to today.

Bad architects favour microservices over monoliths.

YAGNI almost always applies to microservices, and the coordination overhead and boilerplate they add introduces immense costs, especially for smaller companies.

This homogenisation of architecture around Netflix size engineering has really cost our industry a lot.

It's robots all the way down.

That's a quant 4 which the thread OP specifically called out as rubbish.

The Q4_K_XL bit for those not in the know.

Yeah and you've said yourself, you've already done the hard part.

You're overestimating how hard it would be just to copy what you did and apply it rote manually.

I think a problem here is you're overestimating how hard it is to rewrite something when you have one example of how to do it right. Even in the 2000s, I remember a junior essentially rewriting our entire codebase from old school asp vbscript to .Net in a few months. A 100 or so pages back then.

Your team could have done it pre-AI, but you just thought it was hard so you didn't try.

I remember migrating a code base from MySQL to SQL Server in the 2010s. I thought it would take me weeks, if not months. It took me a couple of days.

Immediately made me sour on the "hot" idea in the 2010s that your data layer should be provider agnostic so you could switch if you needed to. That was never a real thing, it was a made up justification for unnecessary over-engineering, by people who had clearly never tried to port an app from one data source to another. There are other reasons for a clear separation, but switching a few hundred SQL statements is not it.

In reality, mechanical ports are not that hard, you can sit down, put some music on and blitz it in a few days. Programmers just over-estimate how hard they will be.

There's absolutely no way I'd be advising friends or family to run a site vibe coded themself, that's nuts.

This is more a problem of your Mum mismanaging her contractors. She should be threatening hellfire down on this contractor for withholding the admin username + password.

Generating the site with Claude would be a pretty stupid choice for her right now, if she needs something more than a basic info site, word press is still king, but she should be able to do info updates herself.

OTOH, you might be able to ask Claude to do the changes for you.

It sometimes says that even if it hasn't though, so like everything with LLMs, you can't actually rely on that.

I think it's the same throughout startup software to be honest. It's just easier to point out when there's clear rules.

Security, GDPR, backups, build pipelines, disaster recovery, most of it will be faked, half-heartedly done once or ignored entirely.

Then there's the more abstract things like scalability, idempotency when integrating with external APIs, error recovery, accessibility, UX, etc.

Almost always that sort of stuff will have been entirely ignored, or there will be a fig leaf over a real mess of misunderstood standards or manual intervention steps.

Startup developers usually have to be generalists as they often wear many hats, so things that need deeper domain knowledge get done to a bare minimum.

That era is already long gone. Those things have been built in Wix for over a decade. And since then, I haven't had any friends or family ask me for a simple site. The low-value work is already automated.

Your comment is valid, but not for the reason you think. What you should be talking about is the grunt work done in our field to non-trivial applications. Adding a search box to a table, or add an extra field to a form, etc.

So you think about a ticket that often might take a few hours, but in badly architected system might take a week, add a field to a class, edit the DB structure (maybe manually, maybe through via an ORM generated migration), add it to DTOs, add a validator, add it to the FE definitions, edit the page layout, etc..

Low value work that until now had to be performed by high-value employees.

I re-read something I did 6 months ago doing this.

It's so obviously AI and had much less value than I thought now I look at it with fresh eyes.

Worse it doesn't read like I wrote it, I don't recognize myself in the doc.

With stuff like this, do you honestly not feel that you've probably been tricked and that someone else actually did this?

Don't get me wrong, I think AI can do some surprising things, but with stuff like this, often it just stole the code and the steps without attribution, it didn't figure it out.

There'll probably be a blog post detailing exactly how to do this somewhere and Claude just copied the steps and code.

And worse, Google search would have found it 10 years ago, but Google search today would claim there are no results?

I think incredibly specific stuff like this often won't pass the 'did Claude just steal this?' test when you dig into it.

https://github.com/dotnet/maui/wiki/Using-AI-to-Work-on-.NET...

The languages I use the IDE literally does this for you, perfectly, deterministically.

And instantly, certainly when compared to AI.

It really isn't. No-one wants to maintain these things, they'll be back on an out-sourced provider within 5 years, if they survive that long.

This is technically correct, but practically false.

They can't stop training as then the AI's knowledge will become out-of-date very quickly. Their knowledge stops the day you stop training.

I had a similar thing where they were going through my code from a takehome.

It was with an architect and a lead developer and the architect was really rubbing me up the wrong way. Stupid nitpicks that were all style preferences. Not at all talking about the actual code. I start pushing back and he starts getting a bit combative, which sets me off a bit too as these were the days jobs were plentiful.

At some point he offhandedly mentioned I didn't need a particular line of code in the startup config. So I say, "Yes, that's required, it initializes the routing". He quips back, "No, that line's not necessary at all, you don't need it". The lead dev is looking completely exasperated at the architect at this point.

I paused, started a screen share. Went to the line. Commented it out. Ran the program and it fell over.

I then said, "I'm not interested in working with you, thanks for your time, bye"

It's happening here too, I saw dang hint that they're not even responding to a lot of questions about it anymore because of the volume of the problem.

If you browse with showdead on you'll be seeing a lot more of what look like reasonable comments greyed out.