| ▲ | paimapi 12 hours ago | |
leadership as a category functions on low-to-minimal subject matter expertise. you don't want c-suite merging code into production, they should be handling the business interests and direction based on their training and general, high-level, trickled-up understanding of how teams are cohering on strategy that generalized, trickled-up understanding is also something that's much more easily replaced by an LLM. it was easy for me to spin up a program governance skill paired with a deterministic set of tests in a few weeks. it crawls team channels, project trackers, etc, identifying date drifts, updates, and missing milestones. add an analytical layer of why and how it all fits together in the roadmap and you've functionally obsoleted a lot of the non-technical bureaucrats whose only purpose is to tell someone what other people are doing - from Director to C-Suite, from C-Suite to shareholders of course you want to keep the people around with the technical depth to construct a roadmap but when was the last time senior leadership in your org actually did any of the substantive work on roadmaps? it's all team leads with the leadership layer serving as the arbitrary rubber stamp on the plans someone else created when it comes to knowing that there's a dependency on the component you're altering the data contract on, the LLM is useless unless there is pre-existing context or unless you command the LLM to burn your pile of tokens on it tracing every bit of logic in your codebase. unless you want to do nothing but this level of discovery all of the time, you'll need an engineer with lived experience of working in the codebase. here this averaged understanding is useless - you need context, you need granular expertise, all things an LLM fundamentally lacks for your specific codebase and your specific requirements | ||