You're right, as I say, I no longer have skin in the game.

Retired, I have continued to code, and have used Claude to vibe code a number of projects—initially I dod so out of curiosity as to how good LLM are, and then to handle things like SwiftUI that I am hesitant to have to learn.

It's true then that I am not in a position of employment where I have to consider a performance review, pleasing my boss or impressing my coworkers. I don't doubt that would color my perception.

But speaking as someone who has used LLMs to code, while they impress me, again, I don't feel the threat. As others have pointed out in past threads here on HN, on blogs, LLMs feel like junior engineers. To be sure they have a lot of "facts" but they seem to lack… (thinking of a good word) insight? Foresight?

And this too is how I have felt as I was aging-out of my career and watched clever, junior engineers come on board. The newness, like Swift, was easy for them. (They no doubt have rushed headlong into Swift UI and have mastered it.) Never though did I feel threatened by them though.

The career itself, I have found, does in fact care little for "grey beards". I felt by age 50 I was being kind of… disregarded by the younger engineers. (It was too bad, I thought, because I had hoped that on my way out of the profession I might act more as mentor than coder. C'est la vie!)

But for all the new engineer's energy and eagerness, I was comfortable instead with my own sense of confidence and clarity that came from just having been around the block a few times.

Feel free to disregard my thoughts on LLMs and the degree to which they are threatening the industry. They may well be an existential threat. But, with junior engineers as also a kind of foil, I can only say that I still feel there is value in my experience and I don't disparage it.

and they only got really good like last December.

My "taste" (like perhaps all other "tastes") comes from experience. Cliche, I know.

When you have had to tackle dozens of frameworks/libraries/API over the years, you get to where you find you like this one, dislike that one.

Get/Set, Get/Set… The symmetry is good…

Calling convention is to pass a dictionary: all the params are keys. Extensible, sure, but not very self-documenting, kind of baroque?

An API that is almost entirely call-backs. Hard to wrap your head around, but seems to be pretty flexible… How better to write a parser API anyway?

(You get the idea.)

And as you design apps/frameworks yourself, then have to go through several cycles of adding features, refactoring, you start to think differently about structuring apps/frameworks that make the inevitable future work easier. Perhaps you break the features of a monolithic app into libraries/services…

None of this is novel, it's just that doing enough of it, putting in the sweat and hours, screwing up a number of times) is where "taste" (insight?) comes from.

It's no different from anything else.

Perhaps the best way to accelerate the above though is to give a junior dev ownership of an app (or if that is too big of a bite, then a piece of a thing).

"We need an image cache," you say to them. And then it's theirs.

They whiteboard it, they prototype it, they write it, they fix the bugs, they maintain it, they extend it. If they have to rewrite it a few times over the course of its lifetime (until it moves into maintenance mode), that's fine. It's exactly how they'll learn.

But it takes time.