Technical leaders should have the largest AI exhaust | Hacker News Reader

Technical leaders should have the largest AI exhaust

schipper.ai

10 pointsschipperai16 comments

Do:

- LOC matter?

- Do PRs?

- Do Tokens?

I’ve never looked up a KPI to figure out who the best engineer is. It’s always obvious to everyone who the best engineer is

Natural leaders inspire. They don’t need KPIs

Great for a small startup. Now do this for 1000 people team.

naively, isn't that how you end up with a pyramid structure with layers of management? You have an engineering manager managing a dozen or whatever is the right number that they are able to identify the high output engineers, and then they report that up the line to a director and a VP and then the SVP and the CTO and then the CEO.

follow through with that logic, understand how these people would coordinate, and you'll understand KPIs and why you can't just rely on "leaders inspire".

ELI5, please. I'm not good at the people stuff.

Not ELI5-able (by me atleast)! It's essentially MBA level, or generally organization building as a topic. Pickup any of the classic management books (Andy grove's high output management). They can probably give an idea of how you measure performance in lage organizations.

Lost me at “low AI exhaust from those setting technical direction should raise questions”

Wonder what Linus Torvalds’ AI exhaust is??

I’d agree Linus is an exceptional leader. And I don’t think most rules apply to him.

Linus used it to make some toy software I believe.

[Disclaimer: no AI whatsoever was used in any part of the following; sorry if you can't verify that, though]

I've come to think that one unequivocal upside of "affordable ASI" would be to bring about a world of discourse where discursers would hesitate to think of (not to mention carry) themselves as experts. What would be the point? Everyone already knows that everyone has direct access to an expert.

[Perhaps it reminds me of Le Guin's thoughts on tech X power, especially as represented in The Dispossessed ]

it would seem to be not just rude, but even snide, to bias your interlocutor towards not carefully verifying the dependencies of your exhaust!

[In your example, Linus, as a sneak preview of that alt-world in ours, is probably totally OK with not being regarded as an expert in making toy software]

Widely dispersed and affordable AI would help because it (certainly, imho) makes the alternative, "trust but verify", so easy

[No need to think about the downsides of checking out and pointing Claude at lines of Linus' toy!]

And it would be strictly easier than using cloud chatGPT to sow misinformation because there are extra steps in that (--- nonsockpuppets would be inclined to verify the gist of everything they are about to say as indeed misleading)

[As a bonus, this seems compatible with TFA, non-ideological anti-anti-intellectualism, and

https://engines.egr.uh.edu/episode/1495

if, in that "non-anarchist" alt-world, we all assume that technical leaders should be different (not more, not less) than expert engineers

Should exceptional technical direction setters strive to stay anonymous..? Or use sockpuppets? Moral as well as practical quandaries..! ]

Wow what a terrible article, just awful stuff lol

It was written by the LinkedIn Cringe bot

> Here are some conclusions I’ve reached through experimentation:

...a bunch of stuff specific to certain models the author is currently using.

Experimentation is good for technical leaders, but you want to be focusing on approaches and understanding the fundamental constraints, not detail.

Many of the things that have completely changed in then last year will completely change in the next year.

Author here. Thanks for the comment.

I did refer to some specific models, though a lot of these learnings are from experience over the past 6 months or so, and continue to generalize as frontier models improve.

Curious if there’s a specific point you feel is too detailed?

Fair - some of the points in these examples will rot. What I think transfers are the failure modes: context rot, agents filling in decisions, whether a codebase is greppable. Those can turn into team principles, and you can only learn this through experimentation.

Reply on news.ycombinator.com