Working with AI Feels More Like Leadership Than Coding

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.

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.

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

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.

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.

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.

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.

How about “Orchestration”?

It’s designed to “feel” that way. It’s a computer program, not a person. People made it.

Don’t get fooled into treating these systems like they’re people or intelligent collaborators.

At the best of times these chat/agent/loop systems are gambling machines. Very expensive and heavily subsidized machines. Don’t forget to keep building your own skills. You never know when the bubble is going to pop and you don’t want to be left unable to do you job just because some big tech corp goes under.

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.

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.

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

Except nothing is at stakes, there are no failure modes beside shitty vibecode output, and noone is responsible for nothing.

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

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

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.

It’s a management of management position I’d say. You’re not just managing AI, if you were already in a management or lead type role then now you’re managing people, the LLMs they manage, and any LLM you’re managing.

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.

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.

I agree with this piece and, also,... I suspect that's why people end with "management brain" (brain rot): it operates by having you bark orders at it, like a micro-managing boss; you're not doing the work, but telling others what to do and how to do it.

Whoever thinks this is the case might have managed people but has never led them.

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.

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.

...and browsing HN these days feels more like cringing than informing oneself. This is a LinkedIn-level "insight", upvoted presumably because it's about "AI"?

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.

"Not predictable" is cope for the true failing. "AI" is not reliable.

As for the purported upside of the random variability in output... seriously? Who would want an RNG in a C compiler's code generator. Or worse, its parser?

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.

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.

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 don't have good leadership or good management or good people skills. I can use AI just fine as run of the mill software engineers.

Pointless, stupid article. Digital garbage, as garbage as LLM slop. So many words to say nothing.

Why are LLM users such poor leaders then?

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

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.

Yes, the Führerprinzip. Slop coders will meet their Stalingrad soon due to technical debt and so will AI corporations due to financial debt.

[flagged]

[dead]

[flagged]