Ask HN: SWEs how do you future-proof your career in light of LLMs?

I do! I posted this a while down below but I guess the way the algorithm here works it got super deprioritized. Full repost:

I can chip in from my tech consulting job where we ship a few GenAI projects to several AWS clients via Amazon Bedrock. I'm senior level but most people here are pretty much insulated.

I think whoever commented once here about more complex problems being tackled, (and the nature of these problems becoming broader) is right on the money. Newer patterns around LLM-based applications are emerging and having seen them first hand, they seem like a slightly different paradigm shift in programming. But they are still, at heart, programming questions.

A practical example: company sees GenAI chatbot, wants one of their own, based on their in-house knowledge base.

Right then and there there is a whole slew of new business needs with necessary human input to make it work that ensues.

- Is training your own LLM needed? See a Data Engineer/Data engineering team.

- If going with a ready-made solution, which LLM to use instead? Engineer. Any level.

- Infrastructure around the LLM of choice. Get DevOps folk in here. Cost assessment is real and LLMs are pricey. You have to be on top of your game to estimate stuff here.

- Guard rails, output validation. Engineers.

- Hooking up to whatever app front-end the company has. Engineers come to the rescue again.

All these have valid needs for engineers, architects/staff/senior what have you — programmers. At the end of the day, these problems devolve into the same ol' https://programming-motherfucker.com

And I'm OK with that so far.

> I’ll continue using it to generate sed and awk commands,

The first example I gave was an example of someone using an LLM to generate sed & awk commands, on which it failed spectacularly, on everything from the basics to higher-level stuff. The emitted code even included awk, and the awk was poor quality: e.g., it had to store the git log output & make several passes over it with awk, when in reality, you could just `git log | awk`; it was doing `... | grep | awk` which … if you know awk, really isn't required. The regex it was using to work with the git log output it was parsing with awk was wrong, resulting in the wrong output. Even trivial "sane bash"-isms, it messed up: didn't quote variables that needed to be quotes, didn't take advantage of bashisms even though requiring bash in the shebang, etc.

The task was a simple one, bordering on trivial, and any way you cut it, from "was the code correct?" to "was the code high quality?", it failed.

But it shouldn't be terribly surprising that an LLM would fail at writing decent bash: its input corpus would resemble bash found on the Internet, and IME, most bash out there fails to follow best-practice; the skill level of the authors probably follows a Pareto distribution due to the time & effort required to learn anything. GIGO, but with way more steps involved.

I've other examples, such as involving Kubernetes: Kubernetes is also not in the category of "4 people in the world know": "how do I get the replica number from a pod in a statefulset?" (i.e., the -0, -1, etc., at the end of the pod name) ­— I was told to query,

  .metadata.labels.replicaset-序号

(It's just nonsense; not only does no such label exist for what I want, it certainly doesn't exist with a Chinese name. AFAICT, that label name did not appear on the Internet at the time the LLM generated it, although it does, of course, now.) Again, simple task, wide amount of documentation & examples in the training set, and garbage output.

It resulted in one less developer, but you're still using that tool, right? Didn't a human (you) point the LLM at this problem and think this through?

That fired developer now has the toolset to become a CEO much, much easier than pre-LLM era. You didn't really make him obsolete. You made him redundant. I'm not saying he's gonna become a CEO, but trudging through programming problems is much easier for him as a whole.

Redundancies happen all the time and they don't end career types. Companies get bought, traded, and merged. Whenever this happens the redundant folk get the axe. They follow on and get re-recruited into another comfy tech job. That's it really.

Beware of the miopia and gate keeping displayed on this thread.

There will be less SWE and DevOps and related jobs available in the next 24 months. Period.

Become hyper-aware of how a business measure your value as a SWE. How? Ask pointed, uncomfortable questions that force the people paying you to think and be transparent.

Stay on the cutting edge of how to increase your output and quality using AI.

Ie: how long does it take for a new joiner to produce code? How do you cut that time down by 10x using “AI”?