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.
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.
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.
"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.
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.
If you can design your organization to handle this, you gain superpowers. And of course this is a management problem rather than coding exercise.
My head is in exactly the same place as coding - deep technical connection to the mental model of what is being built.
This isn’t leadership, it’s just communication. Suddenly realizing that real SWE is full of soft skills isn’t a novel epiphany.
For me, one of the most important aspects of leadership is having a long-term vision, and being able to communicate it. In other words, it answers the question of WHAT.
One of the most important aspects of management is being able to organize resources to materialize that vision. In other words, it answers the questions of WHO and WHEN.
We still need to answer the question of HOW -- which require the expertise -- architecture and implementation.
All of these elements are necessary when doing anything -- even by myself -- but become even more important when using many external resources to do it -- be it a team of people or a team of LLMs.
Ok, guys, it's been fun 10 years. Yes, I am silly nerd who enjoyed understand problem and create HIS OWN solution
Agentic coding is like playing chess with an engine and telling it what opening to use. I guess some do enjoy it
Honestly surprised how many people feeled relief becoming managers instead of coders. I guess we - people who enjoyed coding - always were just a loud minority
And please, don't reply to me with this nonsensical bs about "ye ye I am still owner of my code and I just scaled my knowledge". I worked with ai too much and seen too much people to believe it
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.
I can save ideas and ask a CLI terminal to work on them. If I want to do something advanced, I can use Zed, but even from my phone via remote control, I can talk to agents. I always approve the plan before handing off the task.
It's crazy, it's like having a personal assistant and an army of junior engineers. And you can just use a ZDR provider and an open-source harness to stay private and not share your data.
And the models keep getting better and better!!
Doubt. This sentence reads strange and disconnected. The scan of the article results in 100% ai generated.
flagged since AI generated content is against HN guidelines
I treat the experience like I'm managing adolescent Kal-El in a junior dev role. The kid's strong, fast and smart and does best when I do best by providing clear instructions and guidance in prompts and reference docs.
I also say hello, please/thank you and ttys
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
Leadership is more about setting vision and goals. The more agents are given agency to achieve goals, the more it feels like leadership.
Leadership: Given task to produce something someone wants (B), get an expert (A->B) who knows how get it from something you have (A). If such expert doesn't exist, build a team of experts A->C and C->B, for a suitable intermediate product C.
Coding: Given task to calculate something user wants (B), find a function (A->B) that calculates it from user input (A). If that function doesn't exist, build it from functions A->C and C->B, for a suitable intermediate result C.
I found a funny thing before. I'm in the 2100 block of Github IDs, meaning I was OLD SCHOOL. This got me thinking about how I was probably one of the first users of the first GPT model to be in a major product, Copilot. According to Grok, Copilot was GPT 3. I figured it as earlier because it SUCKED at generation other than auto-complete.
I'm now thinking the best way is to use these models to create the scaffolding and keep my brain in the architecture with strict reviews and small PRs. Slower, but less slop. Basically, just using AI for a bump or two above what I used Copilot for back in the day. Less running agents all day creating slop that I'll never look at. More with serious focus on what I bring my full attention to. Increased productivity, less BS.
Maybe that's just rearranging chairs on the deck on the Titanic. But it's what I'm thinking. And hitting send! ;) That's probably not the win, but I think that path could reveal it.
With an AI agent, I can literally brain dump to a prompt and say turn this into a great prompt that includes a goal, implementation details, and an acceptable quality target. Then just say, okay now execute. Try that with a person and you'll quickly find, you've got no leadership skills.
It's already ok at describing tasks. Not great yet, but it wasn't great at coding a year ago. I can see, in 2 or 3 years, AI taking over management tasks fully.
At this point, I don't think we're far from it being able to look at some non-technical descriptions of a problem and come up with its own plan to execute.
I know, weird idea: what if an LLM just shut up and did what we asked in as predictable a way possible?
Working with an LLM often feels like herding cats.
It was interesting to observe the other engineers around me, none of whom had ever managed people. They tended to try to "program" the agent to produce exactly the code that they envisioned, and were very cautious, seemingly quite afraid that the agent would do something unexpected.
Having managed engineers, I was much more comfortable with asking someone to do something and having them do something more-or-less different from what I was expecting or had envisioned. Sometimes that was worse, sometimes better, than what I'd had in mind, but it was very rare that I would ask an engineer to do something and they would produce exactly the thing I'd imagined.
Having had that experience, I was quite comfortable giving a task to an agent and saying to myself, "Okay, let's see what you come up with," and then evaluating the result. And as with people I knew I had to learn the right way to talk to the agent in order to make myself understood, just as I'd had to learn the right way to talk to each person on my team.
The big differences were that (a) I didn't have to wait days or weeks to see what the agent came up with so the cost of being misunderstdood was much lower, and (b) the agents generally had much, much better reading comprehension than they typical engineer, so in fact I was misunderstood less often.
Its really interesting especially having different agents with different prompts and then having each one based on their reasoning, etc
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.