I have opinions about LLMs. They're not good opinions, but they're opinions none the less. There are also a few things that I completely understand:

1. Massive LLMs are not profitable, sound for the economy or ecology, and are, at best, a temporary cash grab by billionaires with really bad objectives.

2. LLMs are new tools, and like any new tool, should be treated with caution until we know what they're capable of, and the damage they can do. (Think table-saw, lathe, glass furnace, etc. These are amazing tools used every day, but they require attention and caution on every use.)

3. LLMs operate by finding averages, and thus, produce average things. They are also phenomenal at using average language making things reasonably understandable to the average person.

When I started working, I had a job that was, classically “Waterfall”. We didn't call it that, because to us it was called “development”. The project I worked on was a critical system, where literal lives were on the line and It Had To Work. A group of systems architects took 6 months working in isolation where they literally defined every input, action, and result for a given system, how those systems interacted, expected outcomes, and wrote them all in MILSPEC-20 format[1], with each requirement specified by dot numeric (e.g. "2.1.3.2.5 SYSTEM ALERT: DISK OVERFLOW”). These hung on walls until everyone agreed, then they were collected into binders where work was divvied up and passed down eventually to junior devs like me to implement. We knew exactly what to build. We knew how to test it. The documentation was clear and precise and written in parallel. When design mistakes happened (and they did) or some need changed (which also happened) it was trivial to see the system impact and know the costs of that change. Honesty? It wasn't bad.

This is why it was hilarious to me when I was talking to a friend (a really smart colleague of mine who did and does system engineering) and he told me of the design documents he was putting together to get Claude to build something. In that design document, he defined the system inputs, actions, and outputs so that the LLM could construct the code correctly. I took one look at his document and realized, this is a requirements document. It's missing some of the MILSPEC-20 formalities, but it's pretty much the exact same thing that was in those binders I was pulling back in the 90s.

This got me thinking hard about a lot of things. So let me give a bit of history:

Like I said before, once the general needs of a system were defined, stuff started with the System Architects, lead by a Principle Engineer. They would gather and cross consult to build what they believed would be the system needed to address and fulfill the needs defined. This would take quite some time, because they had to identify all the inputs, functions, and outputs, how things interacted, etc., sometimes down to the button press and UI result.

Once they got a sign-off, the system design document would be handed to the Staff Engineers. Their role was to review the Architecture plan to make sure it made sense, then determine which teams (staff) would be responsible to deliver what parts of the system. They did this because they knew the various teams strengths, specialties, and weaknesses. You'd be forgiven for thinking that this was managerial, because it kind of was, but it was also a question of technical prowess. (Turns out, different teams have different skills and people nor their experiences are fungible.)

Each team consisted of one or more Senior Developers with a group of Junior Developers beneath them. Those teams were responsible for implementation, with the Juniors learning how to construct the code, the Seniors guiding and reviewing the development to make sure things work on track.

The brilliance of this system was that Juniors would learn how to code to the point where they became peers, or could even direct younger devs how to work, which makes them Senior Devs. Senior Devs would cross coordinate between their team and others as they learn those teams skills and interests, making them grow into Staff Engineers. Staff Engineers eventually see enough systems plans that they learn what works and what doesn't growing them into the Architect's role.

This is all traditional Engineering. (Note the absence of burn charts, scrums, or other Agile stuff. Not because it's not needed, but because it's tangential. I also didn't describe office furniture or snacks, for the same reason.) So, where does LLM fit in? I view it as being the editor for the System Architecture plan. Coming up with a prompt to allow it to check for mistakes, note potentially missing elements or interfaces, or conflicting areas is right up it's ally. Why? Because it's good at ensuring normality.

At the staff level, it'd be again useful for ensuring that tasks are properly divided, that no team is doing something redundant or that things aren't being missed. Not that it should decide which teams get what, because that still requires a specialized skill that something trained on general normalcy will not have (the LLM will never know that Dave really loves to work on encryption, and is good at it, so he should deal with the privacy bits), but make sure that in the general chaos, nobody forgot about making sure the system has a common clock, or whatever.

At the lowest level, things probably get a little fuzzier. I'd probably recommend that the LLM be used for initial code reviews or for some light work but nothing like “Ok Robot, build me a secure encryption system!” Not because it can't do that, but because you're essentially killing your ability to do future work, as well as loading up tech debt that you're unaware of.

Basically, you're not using finger guards and secured braces while using an LLM, which leads to expensive noises and hospital visits.

Is any of this feasible? Probably. Is any of this ever going to happen in the modern workplace? No idea. I fully expect that cost optimizing leadership will focus on the three month window and not give a shit about things like “will you have a viable work force in 2 years” because they'll be on their third gig by then.

But that gets into a very different discussion that involves a different type of math.

Possibly set theory.

Definitely unions.

[1] While I can't find the original for that online anywhere, this is a good update that shows what those documents looked like. That document does more to describe the process of building the requirements, software, tests, etc than the actual project stuff, but notes the many parts that should be considered and how they relate.