jr conlin's ink stained banana " Getting Back to Basics by Abusing AI
What's good for the bot, is better for the junior dev." />
Oops! Something went sideways.
Looks like the styling got goofed up. Sorry about that, unless it's what<br>you wanted. If this isn't what you were looking for, try<br>force refreshing your page. You can do that by pressing<br>Shift + F5, or holding Shift and clicking on the<br>"reload" icon. (It's the weird circle arrow thing "⟳" just above this<br>page, usually next to where it says<br>https://blog.unitedheroes.net...)
unitedHeroes.net
jr conlin's ink stained banana
2026-06-18 18:10:15<br>:: Getting Back to Basics by Abusing AI
crap
geek
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:
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.
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.)
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....