I've done startups and side projects as well as enterprise across a lot of industries, from design to dev to product. Now working for myself as a Studio, not a single startup but a portfolio of bets. Australian, lived in Paraguay and Japan. Deep interest in learning and cognition. Kendoka.
Hard no, but for context, I discuss books with AI all the time. I wouldn't discuss Hemingway with an AI, completely pointless. His work is not about the content, it's about the beauty of the prose. By comparison, The Timeless Way of Building, I have ruminated on and used AI to explore. It wouldn't make me want to interact with a synthetic version of Christopher Alexander.
That's not to say the backstory of an author isn't something I would go for either. The Undoing Project was the perfect bookend to Kahneman's work.
For the public facing consumer functionality I have Gemini Flash running on guardrails directed by a state machine that calls it statelessly everytime. For that, it's strictly locked to a version. I can't afford to suddenly get responses that the SM is not tuned for.
As for which model does the building... I'm not at all attached. Enough logic, and CI gates/tests live outside the whims of the LLM to be able to hotswap them any time.
I wrote my own ORM for exactly this reason. It's far from enterprise grade but it solves for 1) the domain model needs to stay clean and properly normalised and 2) that's not a job that can be distributed across the whole team.
One lesson I've carried for years is that most of the time the client needs denormalised views on the data model. That's the boundary; the server has the clean domain model, and the client works with views on that model. Isn't that exactly what an ORM is for?
I built mine in Dart because I want the server and client to share DTOs. Then I built a visualizer for clientside devs to be able to explore entity relationships (DDD style) and generate a JSON contract. The end result is no REST back and forth, no GraphQL complexity, just everyone in the team focusing on what they're good at.
I think the theme that ORMs are easy to start, but you pay for it with the edge cases, so good devs end up back at SQL does not apply when you're thinking about how to build a platform. Everyone has their strengths and weaknesses. Aligning the team on playing to their strengths was my goal when I reached for yet another ORM as the solution.