One of the traits I see consistently in the strongest technology leaders is their ability to adopt a broader organisational aperture than their peers when facilitating engineering decision making.
Now for the sideways jump: Nascent literature¹ on the first successes for use of LLMs within software engineering practices has been using LLMs trained on the canonical texts that developers work with every day: Code Repositories. Github Copilot is the best known, and just this week Anthropic launched their native GitHub integration for Claude.
In the next year or two, I predict this will expand to dev teams adopting a single LLM integrated with all software-related text sources. Think beyond Codebase and Project Management, to Config Management, Build/Deploy, Monitoring/Logging, Design Documents and the like.
This will make software engineers that use these tools more effective, but as it will see wide and early adoption — a rising tide that lifts all boats — it’s what comes after that excites me.
I’m more interested in the software engineer who has an LLM at their fingertips that is ALSO trained on the Product & Design team artifacts like customer interviews and user story mapping workshops, that allow an engineer to get deep, contextually relevant answers to how the business sees the product growing around what they’re currently building.
I’m even more interested in the engineer with an LLM that is ALSO trained on what customers care about and struggle with — insights typical engineers rarely encounter. Think about the customer support tickets and livechat transcripts, the feedback forms, sales team emails and sales zoom transcripts, the list goes on.
We used to select a few engineers with strong people skills to communicate cross-functionally, synthesise and package this information for an engineering audience. I’m expecting a future where almost every engineer can have this broader aperture at their fingertips.
¹https://arxiv.org/abs/2308.10620v6