Open-weight plans are near the bottom (Launch section):
- Video and audio generation and editing through APIs and private weight access. (“FLUX 3 Video”)
- Action prediction through selected research and commercial partners, beginning with mimic robotics (“FLUX-mimic and FLUX 3 Action”)
- Image synthesis and editing through APIs and private weight access. (“FLUX 3 Image”)
- Open-weight access to a multimodal backbone, for content creation (video, audio and image) and action prediction. (“FLUX 3 Dev”)
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.
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?
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.
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%.
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.
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.
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.
The greatest trick that javascript ever pulled was to convince the latest generation of programmers that it was fast...