Working with AI feels more like leadership than coding

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.

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

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

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

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

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?

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

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.

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.

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

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.

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

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.

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

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.

Generally speaking, leadership is quite unlike issueing others that others follow unquestionably.

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

Foolish human.

You know who I definitely don't trust to maintain and operate production software systems? the coding agents my teams use.

As a manager I require my employees to understand what they are building and maintaining as engineers, not as managers. There is no viable alternative to that today.

You are training an eager intern.

Sometimes the AI actually gives you value, many times it does not though. And you are training an intern that simultaneously works for another company and is gunning to replace you next year.

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

flagged since AI generated content is against HN guidelines