If I were a stronger man, I would make a comment about dealing with people vs dealing with code and having to route around bugs that are both fundamental to the problem and a POV, along with some inherent in how I setup the program and simply someone else problem I've inherited to simply being burned into the hardware and will never be neatly papered over.
I think this comparison holds up. I've noticed that a lot of people I know who get really good results from LLMs and agents are people with significant people management experience.
Companies like Anthropic seem to understand that too. It's impressive how many CTOs and CEOs Anthropic have hired for individual contributor positions, which I think is because those leadership skills transfer surprisingly well to working with agents.
Of course, managing agents is massively easier than managing humans! You don't have to consider the agent's own desires, goals, opinions, or emotional state when telling them what to do. Humans have agency; agents (despite the name) do not.
but managing humans is simpler in many ways, too: there's accountability for one. and it's much easier to reason about the capability boundary of a human.
I agree completely. Maybe binge vibe coding is "management" or "leadership" but for actually building production applications all the classic low-level concerns still apply. VIM keybindings didn't change that, autocomplete and syntax highlighting didn't change that, and having an LLM write the actual lines of code doesn't change that.
I feel like I'm the crazy one these days for using LLMs as tools. I don't write code anymore, but I still do the same level of engineering. I get fantastic results with minimal slop, and I feel it's because I still use my goddamn brain and engineering skills.
The way I use LLMs seems to be most analagous to the way vibecoder's LLMs use subagents. They exist to solve a bounded task or to write specific code in support of the engineering model in my head. I intentionally never did much research into how others were using LLMs before starting myself, and it seems like that was a good thing. It seems like the majority of people have given up on thought and just slam "do my job with no mistakes or hallucinations" into a prompt and then get confused and angry when it doesn't work. Or worse, don't check if it worked and ship anyway.
These days I have a good intuition as to where an agent can actually do what I want as opposed to creating spaghetti. The best analogy I have come up with is that LLMs are like water and will take the shape of the bowl you build.
The upside is that there's way more water than bowl. The catch is that you have to be the type of person who could build the bowl in the first place.
The word is "management", not "leadership". This comes across as a LinkedIn post filled with vague notions and weak writing.
The conclusion also completely contradicts a previous point, which is that managing an LLM is not like managing a human. So the skills are, in contradiction to that LLM-ism of a conclusion, new. The author isn't using their people management skills, they're using new LLM-management skills. They think the two are similar, but didn't bother breaking down how they're the same vs where they contrast. It's just a lazy observation expanded out to a short essay that says nothing interesting.
Sure sure, but it is surprisingly like managing an intern, or a fresh engineer where there is a pre-existing language barrier. At least in my experience it is. There might be a dash of carefully negotiating with the devil himself in the mix to make sure you ask for precisely what you wish to have built or you get something that meets the spec of what you told it but it isn't what you wanted.
> The conclusion also completely contradicts a previous point, which is that managing an LLM is not like managing a human.
For small scale stuff, it seems very much like managing a human. I've been using Grok and Claude for some small GUI apps, and it's incredible how accurate Claude in particular is for handling vague instructions.[1] I can take a screenshot of some part of the UI and drop it into the chat and say ("The spacing here looks weird, give me a few recommendations on how to fix it."). You can also say stuff like "make this look more modern and conform to modern AppKit guidelines." You don't have to micromanage it, at least when you break things down into small features. (But that's true of humans too.)
[1] Claude is significantly better than Grok at doing Mac UI app development. Interestingly, Grok is significantly better than Claude at legal research and summarizing/analyzing non-code documents.
If it is like management, it’s like the most low effort version of management.
You just blindly tell it what to do without any regard for its motivations or morale. If it does something wrong, you just delete it and slightly rephrase your instructions and have it try again.
I will offer a perspective on a currently incomplete thought. It is management, but it is management of how management imagines managing a human, which, lets face it, is not that great. In a weird way, management as a group now has almost exactly what they have always wanted: an answer presented in a cheerful and serious way that requires expertise to disprove as bs.
Management is following a defined repetitive process to coordinate a team across some or all of projects (who should do what and how long should they spend on it), skills (is their work up to scratch and how can they improve) and HR (do they need to be paid more to not quit and do they need to be told to take sick leave to recover).
"Leadership" is more LinkedIn thought leadership BS but I think it's a useful distinction to make from management and is more about inspiring people to work towards a common goal, making difficult decisions with imperfect information and finding creative solutions to business problems.
To me working with AI does feel more like the latter, there isn't yet a clear path and set of processes for everyone to follow and getting the agents to do what you want does take similar skills in terms of inspiration (finding the right prompt) and creativity (figuring out how to join all the shiney new toys into reliable systems)
Yeah, if anything it’s more like product management meets tech lead (with the social part of both roles removed), not people management. The meat of good prompting is good requirements gathering and clear descriptions of things like acceptance criteria, then setting up systems and tools your agents can use to verify how well they are meeting your product and technical requirements.
It's an AI-generated post on another ephemeral AI-generated blog, now a multiple-times-a-day occurrence on HN. We're taking issue with what a chatbot thinks about "leadership". And some people will probably show up and say it shouldn't matter who wrote it, but it obviously does. There's just some undeniable comedy in this.
While I don't love the article, its wording and the rather pompous
"/notes$ cat working-with-ai.md" gimmick ... oh you know what cat does?
I agree with part of the thesis, a lot of the skill set (not the people management bit) of being a team lead is like working with LLM agents. Purely in a technical sense. Having a plan of overall direction, guiding agents that go off track, overseeing progress and maintaining the high level direction of whos doing what and whats upcoming. Also sometimes learning from a agent/team member and sometimes correcting really dumb ideas.
No, you don't need to rewrite the app in newest JS framework, just use postgres and be happy.
If you're working for someone else, this is true. For people who are building for themselves, it's 100% leadership because managers don't decide what to build or how (at healthy organizations, anyhow)
Not for me. By asking it to interview me, and then working through the options and their consequences, it feels more like the whiteboarding-with-a-colleague part of engineering. I don't have to remember to specify everything. The agent asks me things that it's unsure about, still ambiguous, or open questions. I have it write down all the decisions we made.
The resulting decisions are fed into the coding loop with guardrails derived from those decisions. The agent one-shots features once it goes into the coding loop.
So software engineers weren’t already dealing with requirements gathering and contextualizing a problem from real humans or describing work to be done to other people on their team?
This isn’t leadership, it’s just communication. Suddenly realizing that real SWE is full of soft skills isn’t a novel epiphany.
It feels like managing an egregious liar who speaks exclusively in corporate pyschobabble, is completely unpredictable, makes you want to blow your head off in most interactions, but yet is regularly good enough and cheap enough that you can't justify not working with this person - despite wanting desperately not to.
Working with AI feels like dealing with a bureaucracy. There seems to be rules but they're negotiable and illogical. Rules change constantly for no reason. Decisions are capricious and unappealable. But you can sometimes get your way if you carry on enough. It works better depending on the time of day, or some days it doesn't work at all, and when it's not working you're entirely blocked without a workaround.
Just astounding we decided to put a DMV in our IDEs.
Maybe if you weren't really coding to begin with, or didn't enjoy it. There's a ton of "temporarily embarrassed CEOs" who seem to be unable to think about LLMs as anything but their employees, which is an incredibly limiting perspective in my view.
Anyone who's fallen in love with programming itself and doesn't see software production as a means to an end is not really likely to see things like this.
I see AI as an accelerator of implementing my own choices. I'm generally opposed to metaphors, designs or strategies which excessively anthropomorphize it; it seems completely wrong-headed and counterproductive.
I agree with the OP's point. But if you've worked in a corporate environment, isn't that just how it is? Like how programming work and getting promoted to a manager are essentially different careers—they feel like fundamentally different things.
They're different kinds of work, and both are interesting in their own way. But in the freelance market, LLMs have already become the baseline, so I have to use them whether I like it or not. There are both pros and cons.
It's good to be able to read code and understand its structure, but writing code and reading it to transform it into a different structure are different skills. There's definitely some decay in raw coding ability, though. So I use LLMs for professional coding and for tasks that I couldn't do before, while I keep hand-coding smaller things that feel manageable.
Honestly, I think most people who hate LLM coding actually hate being forced to use it under workplace pressure. And when LLM output looks bad, it's often because managers tend to be strict about their subordinates' work but lenient about their own. Once an LLM generates something, people tend to get attached to it and become more forgiving—since it feels like they made it.
It's tough that LLMs have made deadlines tighter. But these days, compared to the old days when I had to go through interviews and conversations to build a proposal, I actually find it more convenient that clients send me proposals written by LLMs. There are pros and cons to everything.
Perhaps some of the people who got into traditional leadership roles got there due to factors besides their raw leadership abilities. LLMs are an equalizer, and with them, the inability to lead them simply becomes a "skill issue", for the lack of a better term.
This hasn't been my experience whatsoever. Maybe I just don't vibecode, but it still feels like coding, I'm just not typing the letters. I'm still thinking about the domain, the separation of concerns, all that software architecture jazz.
I actively do it in a way, where i steer and understand the important bits. Because otherwise the cognitive and technical debt would annoy me to a point, where i would want to do software at all.
For me, it's more like natural language coding, or maybe technical management of envs, states and tools. Leadership is about humans, feelings, personal differences or soft skills
Built a production API almost entirely AI-assisted recently. Didn't feel like leadership to me, felt more like code review at a much higher volume. I wasn't delegating decisions, just constantly checking the generated code actually did what I needed lol.
I was already in a management position when this started. But I also have 20 years of development experience. So for me it has been a super power. I do feel bad for all the devs trying to break into the industry right now though, it must be hard. I’ve basically stopped hiring devs for my company. I haven’t fired anyone but I have no plans to expand the team, even as our workload increases as the companies keep growing.
My Eng lead has no coding experience, 25 years of management experience, yet has driven 3 separate projects into technical bankruptcy to date.
He just accepts anything that Claude says as truth. He vibecoded over 60,000 lines of code in 3 weeks, but couldn’t get it to do what he want and made a project overrun for 3 extra months. When the pissed off stakeholders called a meeting to ask what was going on he didn’t show up and sent his junior engineer to answer questions and take the blame. Now thats leadership.
I first saw this point made by Venkat Rao more than a year ago in "Prompting is Managing" [1]. It was written in response to the "Your brain on ChatGPT" paper that was then making the rounds, about how LLM use is supposedly making people stupid.
Venkat argued that the study subjects did poorly not because LLMs were dulling their minds, but because the study subjects were freshman students with no management skills being tested on tasks that required delegation, quality gating and exception handling. The study put people in a situation that created role confusion and concluded that the poor outcomes were due to "cognitive debt" induced by LLM use.
In my view, it has aspects of both leadership and development.
You need to direct agents to do work worth doing and then you need to understand the output. Some of the emotional parts of management are gone since agents don't care if you tell them to throw everything away and take a different approach. Some of the therapeutic parts of development are gone since you don't need to hand craft a clever code structure.
I wouldn't say it's more like one or the other though. One of the most important jobs of a leader is finding work worth doing for their team. One of the most important jobs of a developer is ensuring system cohesion. Both of these are hard jobs.
To me, AI failure cases look like doing either of these jobs poorly:
1. Writing a big pile of tools that really provides no user value
2. Not reading the code and ending up with broken systems
To me, working with AI feels a lot like the previous experiences of “working in a sprawling enterprise codebase spanning multiple systems each with emergent behavior”, except now I can outsource the introspection and validation loops to something that never gets bored instead of spending 2h hyping myself up to concentrate for a 3h stint.
105 comments
[ 4.4 ms ] story [ 138 ms ] threadCompanies like Anthropic seem to understand that too. It's impressive how many CTOs and CEOs Anthropic have hired for individual contributor positions, which I think is because those leadership skills transfer surprisingly well to working with agents.
Of course, managing agents is massively easier than managing humans! You don't have to consider the agent's own desires, goals, opinions, or emotional state when telling them what to do. Humans have agency; agents (despite the name) do not.
My head is in exactly the same place as coding - deep technical connection to the mental model of what is being built.
/wayfinder: Nothing is too big to plan anymore
https://www.youtube.com/watch?v=F3lL98Pj90o
The /wayfinder Demo
https://www.youtube.com/watch?v=251hsWgoTPM
The way I use LLMs seems to be most analagous to the way vibecoder's LLMs use subagents. They exist to solve a bounded task or to write specific code in support of the engineering model in my head. I intentionally never did much research into how others were using LLMs before starting myself, and it seems like that was a good thing. It seems like the majority of people have given up on thought and just slam "do my job with no mistakes or hallucinations" into a prompt and then get confused and angry when it doesn't work. Or worse, don't check if it worked and ship anyway.
The upside is that there's way more water than bowl. The catch is that you have to be the type of person who could build the bowl in the first place.
The conclusion also completely contradicts a previous point, which is that managing an LLM is not like managing a human. So the skills are, in contradiction to that LLM-ism of a conclusion, new. The author isn't using their people management skills, they're using new LLM-management skills. They think the two are similar, but didn't bother breaking down how they're the same vs where they contrast. It's just a lazy observation expanded out to a short essay that says nothing interesting.
I find LLM's to be very easy to manage since they at least to me, appear more rational the humans. Myself included.
For small scale stuff, it seems very much like managing a human. I've been using Grok and Claude for some small GUI apps, and it's incredible how accurate Claude in particular is for handling vague instructions.[1] I can take a screenshot of some part of the UI and drop it into the chat and say ("The spacing here looks weird, give me a few recommendations on how to fix it."). You can also say stuff like "make this look more modern and conform to modern AppKit guidelines." You don't have to micromanage it, at least when you break things down into small features. (But that's true of humans too.)
[1] Claude is significantly better than Grok at doing Mac UI app development. Interestingly, Grok is significantly better than Claude at legal research and summarizing/analyzing non-code documents.
You just blindly tell it what to do without any regard for its motivations or morale. If it does something wrong, you just delete it and slightly rephrase your instructions and have it try again.
"Leadership" is more LinkedIn thought leadership BS but I think it's a useful distinction to make from management and is more about inspiring people to work towards a common goal, making difficult decisions with imperfect information and finding creative solutions to business problems.
To me working with AI does feel more like the latter, there isn't yet a clear path and set of processes for everyone to follow and getting the agents to do what you want does take similar skills in terms of inspiration (finding the right prompt) and creativity (figuring out how to join all the shiney new toys into reliable systems)
I agree with part of the thesis, a lot of the skill set (not the people management bit) of being a team lead is like working with LLM agents. Purely in a technical sense. Having a plan of overall direction, guiding agents that go off track, overseeing progress and maintaining the high level direction of whos doing what and whats upcoming. Also sometimes learning from a agent/team member and sometimes correcting really dumb ideas.
No, you don't need to rewrite the app in newest JS framework, just use postgres and be happy.
The resulting decisions are fed into the coding loop with guardrails derived from those decisions. The agent one-shots features once it goes into the coding loop.
This isn’t leadership, it’s just communication. Suddenly realizing that real SWE is full of soft skills isn’t a novel epiphany.
Just astounding we decided to put a DMV in our IDEs.
Anyone who's fallen in love with programming itself and doesn't see software production as a means to an end is not really likely to see things like this.
I see AI as an accelerator of implementing my own choices. I'm generally opposed to metaphors, designs or strategies which excessively anthropomorphize it; it seems completely wrong-headed and counterproductive.
They're different kinds of work, and both are interesting in their own way. But in the freelance market, LLMs have already become the baseline, so I have to use them whether I like it or not. There are both pros and cons.
It's good to be able to read code and understand its structure, but writing code and reading it to transform it into a different structure are different skills. There's definitely some decay in raw coding ability, though. So I use LLMs for professional coding and for tasks that I couldn't do before, while I keep hand-coding smaller things that feel manageable.
Honestly, I think most people who hate LLM coding actually hate being forced to use it under workplace pressure. And when LLM output looks bad, it's often because managers tend to be strict about their subordinates' work but lenient about their own. Once an LLM generates something, people tend to get attached to it and become more forgiving—since it feels like they made it.
It's tough that LLMs have made deadlines tighter. But these days, compared to the old days when I had to go through interviews and conversations to build a proposal, I actually find it more convenient that clients send me proposals written by LLMs. There are pros and cons to everything.
To go anywhere serious you have to lead people, but even the ones who should be leading people are heads down talking to the LLM
it'll pass, but until then we'll be subjected to a litany of dumb hot takes.
Pointless, stupid article. Digital garbage, as garbage as LLM slop. So many words to say nothing.
Its really interesting especially having different agents with different prompts and then having each one based on their reasoning, etc
He just accepts anything that Claude says as truth. He vibecoded over 60,000 lines of code in 3 weeks, but couldn’t get it to do what he want and made a project overrun for 3 extra months. When the pissed off stakeholders called a meeting to ask what was going on he didn’t show up and sent his junior engineer to answer questions and take the blame. Now thats leadership.
Venkat argued that the study subjects did poorly not because LLMs were dulling their minds, but because the study subjects were freshman students with no management skills being tested on tasks that required delegation, quality gating and exception handling. The study put people in a situation that created role confusion and concluded that the poor outcomes were due to "cognitive debt" induced by LLM use.
[1]: https://contraptions.venkateshrao.com/p/prompting-is-managin...
You need to direct agents to do work worth doing and then you need to understand the output. Some of the emotional parts of management are gone since agents don't care if you tell them to throw everything away and take a different approach. Some of the therapeutic parts of development are gone since you don't need to hand craft a clever code structure.
I wouldn't say it's more like one or the other though. One of the most important jobs of a leader is finding work worth doing for their team. One of the most important jobs of a developer is ensuring system cohesion. Both of these are hard jobs.
To me, AI failure cases look like doing either of these jobs poorly:
1. Writing a big pile of tools that really provides no user value
2. Not reading the code and ending up with broken systems