Post #3626696

One thing I think we're underestimating in the age of code LLMs is the value of senior engineers' internal models. A code LLM doesn't build your architecture; it builds the most statistically plausible architecture from the evidence you give it. The problem is that the most important evidence often isn't in the repository, tickets or documentation (honestly it's RARELY in documentation and almost never CURRENT there). It's the accumulated understanding of why the system is the way it is: which patterns failed under load, which constraints are non-negotiable, which abstractions are deliberate, and which "obvious improvements" break the product six months later. That's the ground truth the model needs to be steered against. Think; do you capture ANYWHERE parseable by your code LLM what you tried before and didn't work? Ironically, that makes indiscriminately removing (RIF / VRP / straight up sacking) senior technical staff uniquely risky right now. You're not just reducing headcount - you may be deleting the very mental models needed to guide increasingly capable code generation. Without those anchors, the organisation risks converging on code that is internally consistent and perfectly plausible...but no longer reflects the architecture, trade-offs and intent that made the system successful in the first place. You've made the CLASSIC 'expensive senior people hold no intrinsic value' mistake and blown away the *very grounding layer your Code LLM needs to remain coherent*. I think THIS is what will be the big story now; the 'these features look great' (aka the startup MVP ) phase is done; congratulations. NOW you have to make this something your business can depend on...secure, able to be extended and modified *safely* etc... Hope you didn't fire the people wo know how to do that!