We are beset on all sides with companies declaring agentic coding a failure and here you are stating as a matter of fact some teams “thrive” with this probabilistic expensive approach to approximating working code?

All the while concluding with “I have no evidence for any of this”.

We learned that some tasks don't really benefit from AI while others do. My team went from 7 people to 2 (went to new teams, no layoffs), and we're doing the same amount if not more work than we used to.

Is it more draining and lacking of focused work? Yes. Is it more money for the business? Yes.

In my world, when something is expensive and doesn’t meet expectations it called a failure. Especially when something has been as hyped, scrutinized, defended and attacked as vibe coding.

Honestly, if you are the director of robotics at a firm I think it’s time you took a cold shower.

I’ll rephrase, Zuckerberg would certainly enjoy agentic coding to be a wild success because it means less staff and more products he could fail to create.

“Wild success” and “going slower than expected”?

Wake me up when words have a meaning again.

Correct, they are not.

Consider: Someone who "expects" their bank account to have $100M in it before they turn 30 and "only" gets it to $10M.

From the point of view of a normal sane person, they are experiencing "wild success", and yet at the same time they are definitely "going slower than [they] expected".

In your case, if you have a goal and achieve 10% of it, you have failed the goal. Anything you have gained along the way is irrelevant.

The only point here is "not as fast as expected" can still be a lot.

Note, I never said boost “his” AI, that’s your reading comprehension. I said “these products” which are the same products that claim to save money, for high net worth individuals specifically in the Zuckersphere.

Who said the layoffs were a success? It's a short term fix (or correction from pandemic hiring) that may still nevertheless have long term consequences.

We're riding an exponential here for Pete's sake.

Until you factor in many large firms are interested in cheap Chinese models.

Are you a frontier lab booster by any chance?

just pointing out the obvious.

Now we just need to find those tasks. I want to believe.

> and we're doing the same amount if not more work than we used to

Zero evidence for this. It's programmers self-reporting their own productivity. (Have we not learned this lesson after 50 years of programming practice?)

If you claim 10x and deliver 3x, that is a failure. The 3x may still be impressive or a gamechanger or ..., but it still falls short of its promises.

Pay me 8x to get 10x, great. Pay me 8x to get 3x, nope.

There is increase in (not only perceived) value _somewhere_ - IMO depends on the organizational culture. At my work I found going over 100$ on OpenAI/Anthropic's API pricing does not produce any meaningful additional output. It might be much different in different companies.

To be completely honest, I’m living life right now. I love programming with my bare hands, but man I’m living just building a gajillion things a mile a minute with LLMs. I then come home and spend hours building stuff for myself using local models. I’ve never been so excited about just building shit, that I sometimes want to pull all nighters because I’ve been in the zone (a for work and at home).

Draining? Sorry… inject that LLM serum right into my veins

It’s absolutely 10x faster for coding. But coding is only 10% of my job. The other 90% is figuring out what to code.

Those two things are the opposite of each other (evidence, but only anecdotally; you cant be both).

Anyway.

More tangible to your argument; what is your argument that this will be more effective than just prompt engineering?

Ive long believed that prompt engineering is a losers game; if there is a trivial set of tricks that improve the output, they will simply be automatically applied.

We see this playing out with the system prompts in coding agents and image gen.

The value of learning “photo realistic studio lighting…” was non existent. The nano banana api is capable of taking a naive prompt and expanding it with these tricks.

People who devoted themselves to learning these “magical incantations” wasted their time and effort; and it was obvious, from the beginning this would be true.

Now.

With managing agents; if a trivial set of management tricks can drastically improve the results, why are you better off learning them now, rather than waiting for them to be baked into cursor/codex/claude in easy mode?

What makes you believe this is a valuable investment in time and effort?

Even if we accept that right now assigning personas to agents and managing them as a manager yields good results, the horizon for change right now is so short, it seems extraordinary to suggest mass management and leadership training for engineers.

We should just wait and see.

All in investments like this would just be tokenmaxing in a funny hat.

You see problems in the results? Simple, don’t check the results!

I doubt that. Management is mostly dealing with people, the actual "management"* part is not where developers moving into management roles typically fail, it's the people part. With agents you have the management part without the people part.

Whether we still need people in the coding loop is not a trivial difference

Good ones do. Reading the code someone is contributing is a powerful signal about how well they're doing.

ICs who manage swarms of agents should operate the same way. They set them off to do something, and then look at the output to see if it's going well.

That's the point I'm making here: managing a team of ICs and managing a swarm of agents has a lot of overlap in the systems and processes you can use to see if it's working well. By teaching ICs to be better managers I think they'd get better at using agentic AI.

There's such and such. In some companies, the leaf engineers report to a team lead, which might or might not be granted this 'manager' title. Those poor fellows essentially doing double-duty and are the most likely candidates for burn-out.

LLMs are driven by the text you enter into them and they are never fully autonomous unlike an actual employee.

You cannot train an AI and then at some point just let it loose.

For eg I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role. I’m able to spin up test harnesses, write throw away glue code, test against large datasets, etc

Man, if I had a dollar for every time someone said "I'm not good at X, but LLMs are so impressive at it". Like do you think there might be some connection between those two points?!

It seems that I don’t like coding when I read these kinds of statements. If I’m doing an experimentation, it would be a few lines at most. Because that’s all I needed before I can write a solution.

Writing code is the last tool to design with. Thinking and a bit of sketching is what I do mostly. Then I verify small bits with code (mostly for checking a library when the documentation is lacking or a stub when I’m focusing on another part). Otherwise, it’s just enough code to get it working well and refactoring when the requirements changes.

I disagree.

From ICs that I lead, I expect that they learn fast. On the other hand, LLMs are basically incapable of improving.

Another issue that I can see is that I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers. At the beginning, if you are uncertain, learn, and if you have questions that learning does not answer by itself, ask questions. But strongly avoid hallucinating answers. New colleagues can be taught that, LLMs not so.

LLMs can be 'taught' though. You can give them additional context or instructions. The difference is that they can't really teach themselves.

This is roughly what I'm saying - someone who's managing an IC can steer them on the right course, and someone who's managing an agent can also steer it on the right course, so teaching someone how to handle ICs well gives them skills that are also applicable to handling agents well.

It's not perfectly analogous obviously because ICs are people and need to be managed as people, but I really think the skills are quite transferable in one direction. I'll add that I don't think someone learning to manage agents would necessarily become a good people manager.

That's not teaching. Giving someone new information in the moment does not amount to giving them new long-term capabilities.

People are most likely to come up with suggestions and ideas earlier rather than later.

Often they’re not learning what is “correct” but just how to “fit in”. A fresh perspective can be good even if flawed. It can help others spark new ideas and think outside the box.

> E.g. you can spin up 1000 agents. Get them inti tight loops and get them more context and so on. A manager doesn't do that with people.

My dad had various work stories, one from when he interviewed applicants:

  "So, why did you leave your last job?"

  "After 6 months, the management discovered my entire floor and the one next to it had been hired to do the same task. One of the floors had to go, I got unlucky."

Do you mostly use agentic swarms? If so, I’d be curious of your use cases. People talk about “managing agentic swarms” a decent bit, especially on LinkedIn. I just don’t see how they are the best solution for majority of development use cases. At best they seem like using only a hammer to make sculpture.. or a sandwich.

I don't think it's this because the outcome you get from AI isn't controllable. You can give it the best prompts and design suggestions and it'll still give you completely wrong or horribly written code.

If you were a manager and one of your reports kept producing completely wrong and horribly written code that other folks on the team keep bringing up as problematic in PR reviews or privately, that developer would eventually be fired for someone better.

But in the AI case, there is no replacement because all of the LLMs have severe problems.

I don’t have a dog in this fight but it seems you’re not accounting for iteration. A horse will veer off of a road if not occasionally nudged to stay on it.

You can provide AI official sources to look at and dozens of prompts. I've lost track of the number of times where it didn't arrive at the right answer with tons of opportunities to correct itself based on feedback.

Just an endless of sea of "you're absolutely right to have brought that up, I didn't think about that" and other phrases it constantly uses when it fails to provide a solution. Fast forward 20 minutes later and it starts providing the same nonsense it did at the beginning because it forgot what it already said.

The code solutions it provides are so consistently bad but it's not limited to code. I recently tried a YouTube feature where it can generate AI thumbnails from your video. The results were really lackluster. It completely ignored my feedback like "use a real webcam photo of me that you see in the video", to which the AI recreated a completely different looking human that wasn't me. It even swapped out my real glasses with a rendering of glasses I don't have and kept on making incorrect assumptions about everything. After about 10 prompts and 20 minutes of waiting for thumbnails I gave up, it was really poor.

sorry if it's not the case but i have the feeling you still think AI coding involves talking to a chatbox and copypasting the answers

This bottleneck will always have to exist unless companies just accept AI defaults, with predictable outcomes.

I think what makes a dev well suited for AI isn't the same as managing a team. What really helped me get productive is having to write a lot of user stories and acceptance criteria with the wisdom of being a dev tasked with implementing them. Also, being on the refinement calls, answering questions, and updating requirements/AC is good feedback for authoring better requirements. If you're good at authoring requirements, checking output, and communicating corrections concisely then you can get the LLMs to sing.

Good AI managers are just running optimization loops at more declarative levels. Yeah, you need to get comfortable with less personal review of code for both, but I think the differences outweigh the commonalities - it's much easier for someone with a more 'traditional' IC model to be successful with agents then they would be with management, and I think most (good) management training would be entirely irrelevant. Parallels are maybe tighter to higher IC progressions.

The job isn't to write code. The job isn't to architect. Those are means to an end.

Anecdotally: it seems like the most principled developers are having the most trouble adapting to agentic workflows.