back
195 comments
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.

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.

> 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.

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.
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.
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.
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.

People seem to be conflating loss of control and predictable outputs with management. Maybe that's intentional spin or just wishful thinking.
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)
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.

The task is very simple: Thousands of super fast fairly good contractors show up at your company's front door. You can't really trust them with data, they do occasionally make mistakes, they have to learn everything about your organization and product from scratch, and btw they leave in 10 minutes again.

If you can design your organization to handle this, you gain superpowers. And of course this is a management problem rather than coding exercise.

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.
Not for me.

My head is in exactly the same place as coding - deep technical connection to the mental model of what is being built.

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.
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.

The words "management" and "leadership" are used to convey many kinds of meaning, so I think it is important to elaborate carefully what we mean when we say that "working with LLMs is more like <x>".

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.

Coding is dead, so do my joy of this profession. If I wanted to become full time manager - I would do it earlier

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

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.

I love the level of empowerment they unlock for super cheap. I have a personal assistant that's a Slack bot talking to ohmypy on an old Mac M1 turned into a server. It has access to my calendar, remembers the things I need to remember, and pulls data from a gym tracker—an app I vibecoded just for myself—to pull books and papers and create audio, and easy to digest introductions that help me understand a paper before reading it. Plus, the system leverages the Getting Things Done method to help me stay on top of things.

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!!

> As a leader, I can explain a task and get exactly what I asked for.

Doubt. This sentence reads strange and disconnected. The scan of the article results in 100% ai generated.

100% AI generated https://www.pangram.com/history/5b339a07-6a25-451f-b707-7d45...

flagged since AI generated content is against HN guidelines

Finally a post about agentic-coding that's aligned with my thinking.

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

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.
It puts a premium on your concurrency skills. I'm constantly setting up agents and moving from agent to agent; answering questions, evaluating work, providing feedback, finishing up items. Builds a different muscle and there's still more ways to improve workflow
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.

[1]: https://contraptions.venkateshrao.com/p/prompting-is-managin...

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

Working with LLMs feels more like management when I'm working with multiple LLM coding sessions on the same code base, either multiple LLMs making commits to the same repo, or LLMs doing code review on another LLM's work.

Leadership is more about setting vision and goals. The more agents are given agency to achieve goals, the more it feels like leadership.

Leadership is same as coding.

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 have found in my own experimentation, I create way more trash than I did before. If I'm 10X creating trash, then I'm WAY less productive creating the stuff that I actually use.

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.

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
If only leadership were so easy as telling AI agents what to do.

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 mostly feels like manual testing.

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.

It feels like controlling an infinite genie. if you control it well, it is extremely powerful, but it will take anything literally in many cases. But if you master it, and treat it as a compiler of intent, using Plan mode appropriately, you can accelerate and punch far above your weight class.
I listened to a podcast comparing coding with AI to ‘directing,’ in the sense of directing a film. But I guess it depends on the level of technical involvement vibe coders have with the project. For me, it’s still very close to coding, even though I don’t write most of the code.
Maybe we need an LLM interface that is less chatty and unpredictable and focuses instead on boring, predictable execution of commands.

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.

Well yeah, I thought this was pretty obvious. You're guiding the model from a desire to it's realization, helping to remove blockers along the way and facilitating improvement over time. That's leadership.
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.
Unfortunatly average 'leadership' never had the required skills to lead technically critical 'stuff', and, maybe counterintuitively, because, code is cheap now, right, AI amplified the incompetence.
Whoever thinks this is the case might have managed people but has never led them.
This has been my case. I feel like I am ordering them to do task and verifying that they do exactly what I tell them to do. Rinse and repeat. My empty mind wanders off into thinking what task can I ask them to do.
Leaving aside the quibbling over the meaning of the word leadership, I'll say I personally agree with this sentiment. I returned to a senior IC role after six years managing a small team just as agentic coding was starting to happen. The timing was perfect, I got about 8 months to get my chops back up by hand (I had never really fully stepped away from coding) before the good agentic tools became available at my company.

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.

Yes, i was thinking what was this feeling as im doing my MBA and this is it.

Its really interesting especially having different agents with different prompts and then having each one based on their reasoning, etc

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.
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.

Careful with the Hegelian master and servant dialectic. It does not always turn out the way the parasites want it to.