Worth Reading: LLM Prompts for Network Engineers
Tony Mattke put together a long list of recommendations that might help you get more out of your LLM tokens.
Definitely worth reading instead of yelling at the stupid AI.
Tony Mattke put together a long list of recommendations that might help you get more out of your LLM tokens.
Definitely worth reading instead of yelling at the stupid AI.
My problem with LLMs and articles like this is the incessant anthropomorphizing and assigning of intelligence where there is none - it reasons, it can/can't, etc. Sure, your use of LLMs might help you solve some issues quicker or whatever, but it's like working with radiation - you will get damaged over time, unless you are vigilant 24/7 for the rest of your life, which I'm unsure I want to expend the effort for. You outsource your thinking one time, then it gets easier and easier each subsequent use - boom, you get "irradiated" - how will I do my job when Claude is down (it will go down, we know this) or the bill from "LLM provider du jour" is over our yearly budget, etc Not to mention the bigger, longterm effects of "I'm ashamed to ask a fellow human, let's ask an LLM instead" - the imposter syndrome will absolutely ravage the growth of juniors. At least you can use enthusiasm about LLMs as a self-disqualifying indicator of who wants to use their brain and who will let it degrade. People had the same expectations about previous iterations of [insert tech here] - it will solve problems, don't be left behind, etc. And we got entshittification, rampant disinfo, social "media" and the other well known harms.
Thank you! Can't disagree with any of that ;))
I wouldn't worry about it; the days of human relevance on this planet will be over long before any of those effects would matter.
I largely agree with you, the atrophy risk is real. I'm sure my map reading skills have suffered after fifteen years of using GPS, and I don't think prompting is magically exempt. And I agree that the junior who's ashamed to ask a senior a "dumb" question and asks the model instead loses the relationship AND the correction... I just don't have an easy answer for that.
Where we part ways is your conclusion. "It reasons" in my post is shorthand for observable behavior. Hand it a routing table and it produces analysis I'd generally accept from a senior engineer, hand it little and it confabulates. Whether that clears anyone's bar for intelligence doesn't change what I do with it. The whole article is the vigilance you're describing... never trust recall, verify everything, keep the thinking on your side of the desk. That's not 24/7 heroics, it's the same discipline we already apply to every tool that's confidently wrong sometimes, which includes vendor docs, Stack Overflow, and me before my morning caffeine overdose.
As for what happens when it's down or the bill triples... the same thing as when any vendor tool dies. I can still do the job by hand, slower. Keeping that true is the actual discipline, and it's mine to keep, not the tool's.
We are in the early stages of the slop era. I saw a youtube video for an AI based tool for circuit design I thought was compelling at first but of course it was slop. However, what caught my eye in the context of the comments here was the user in the video used AI (chat gtp) to draft his full circuit design with BOM etc prompt to be used in the AI circuit tool. He used one AI to generate the "best" prompt for another AI to use. Talk about routing or L2 loops. sheeshe..