Hacker News Reader

Absurd.

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

Agentic coding is absolutely not a failure. It's just not the 10x that CEOs really wanted it to be.

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.

Friend, you are commenting on a thread where one of the most prominent figures in tech (rightly or wrongly) is saying something did not meet expectations. As far as we can tell this is a man with every incentive to exaggerate and boost these products.

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.

Why are you assuming Zuck's expectations for progress of _his_ product have anything to do with the impact of that category of product for its users?

I’m sorry, what’s the question? Genuinely not sure.

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.

Again, Zuck's success criteria don't necessarily align with that of others. In fact, I'd expect his success criteria are substantially different to most.

Making money? Seems to be the common success criteria for all.

It can both be a wild success and not what he expected.

These two not mutually exclusive?

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

Wake me up when words have a meaning again.

> These two not mutually exclusive?

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

Pretty sure Zuck was talking about agents in general, not specifically Meta agents.

More importantly, he's really probably talking about 'superintelligence', rather than just building genuinely useful and monetizable models.

Why would Zuckerberg want to boost their AI, they have none to speak of after Llama really? Zuckerberg actually has every expectation to downplay AI so as to save face that Llama failed compared to frontier models.

On the other side of this you have two companies growing revenue literally the fastest ever in any market segment, just for said tech. Somebody is spending this money and thinks it's worth it. Let's check back in six months.

Sure thing, just like I’ve been checking back on people over the last 3 years. I’ll hit you up too.

Past performance is not indicative of future results.

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

We all know the future results of a lame horse.

Judging by his account he’s a big time booster suffering with psychosis

not sure what this means. should I be worried?

I dont care about your well being TBH

just pointing out the obvious.

you care enough to respond, shouldn't have bothered.

These all sound like nice sound bites.

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

Are you a frontier lab booster by any chance?

> Agentic coding is absolutely not a failure. It's just not the 10x that CEOs really wanted it to be.

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

From my experience with daily stand-ups, I think they can be a significant boost to that, too. Though you will absolutely have to wear a manager hat with their estimates and breakdowns, not just fire-and-forget, as they're often as not wildly over-optimistic about task complexity.

Being a "failure" means it fails to meet its success criteria.

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.

10x is a marketing gimmick in development, AI and pretty much everywhere

So what? Who cares about such a binary claims?

People making decisions.

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

I have not seen reasonable claims that people are paying 8x the salary of a SWE to get those 2-3x results.

Directionally, that's why companies are getting rid of token leaderboards and imposing limits on LLM costs. There's a diminishing marginal return to tokens

That's true and it's also very easy to game.

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.

I am also leading a small team of myself and 2 others and we're getting a lot done. The short lines of communication of being a small group + the power of agents has been great for us.

> Is it more draining and lacking of focused work?

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

> while others do

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

Because this companies defined the goal to replace humans with AI what didn't happen. What happened is that the humans can work faster and have more coffee breaks while the AI iterates for the next review and iteration round by that human.

And the human will not bother to review that mass of code and will just approve so the real test will happen in production.

why would companies who build tools for developers say they'd want to replace humans with AI? it was never the goal, it was never stated like that. they said that by the end of 2026 most of the code being output would be generated by LLMs, and is pretty much true.

are we tho? i don't really see anyone going back to planning and coding by hand, that ship has sailed and it's not coming back. people ditching agentic workflows altogether would be failure, people figuring out it's not a miracle tool and has uses for which it's not as productive is correction.

The bit I don't have evidence for is whether or not teaching ICs to be managers would improve how they use agentic AI. I have plenty of evidence for the efficacy and effectiveness of AI itself (although not qualitative or obviously causal unfortunately.)

> plenty of evidence … although not qualitative or obviously causal

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.

> Some devs just 'get it' and thrive, leading a team really well and building a great culture.

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.

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

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

> I don’t have a dog in this fight but it seems you’re not accounting for iteration and feedback

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.

None of that supports the claim that it "isn't controllable," though. A curious mind should probably find it interesting that it can be fallible in those ways yet still be useful for producing work, and ask how both can be true at the same time.

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

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

> If the team (or agent swarm) isn't performing well it often isn't a problem with them. It's a problem with the new manager still trying to stay on top of everything and micromanaging all the things.

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

Let codex review Claude output and the contrary. Win for everyone involved, more code, more features, more token usage, promotions, code to be debug by juniors and the cycle of life can continue.

Yes, an agent does feel like a very eager and very knowledgeable but also very clueless junior developer sometimes. But no, working with agents is not like leading a team of developers. You don't have to make sure an agent stays motivated, give it the feeling that its work is valued (I can let an agent spend some time building a prototype and then decide not to use it, if I did the same thing with something a junior developer took a week to build, that probably wouldn't be a good idea) etc.

> I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them.

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.

> I don't particularly like eager new colleagues who come up with (hallucinate) wrong answers.

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.

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.

> LLMs can be 'taught' though. You can give them additional context or instructions.

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

> Some devs just 'get it' and thrive, leading a team really well and building a great culture.

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.

I get why you think this but you are incorrect. Why? Because managing a team of people is very very different from managing outsourced contractors, and LLMs are much more like the latter than the former.

"I strongly suspect that developers moving from writing code to managing agents to write code for them is very similar to developers moving into leadership and management roles and managing ICs to write code for them."

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.

I think you are confusing manager with ICs. Managers don't really read or review the codes. What you are describing is where agents are doing all the coding and reviewing without people in the loop. I don't think the op is working with the code as black box. He is more about describing the higher IC workflow.

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

Managers don't really read or review the codes.

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.

> Managers don't really read or review the codes.

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.

I agree there is a skill change but agents aren't people so managing them is very different. 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.

Agents aren't people, but they anthropomorphise themselves real hard.

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

Completely agree.

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.

In my experience, it's the opposite. People who become dependent on AI agents are avoiding human contact, and people who become managers are seeking it out (for better or worse).

I disagree with your 2nd assertion. Even engineers who are less tech lead style engineers, can gain a significant boost in productivity by being able to quickly run through POCs and build an understanding of surrounding areas of their work, so they are able to contribute more.

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

> I am able to make React changes much faster and the changes are higher quality, given frontend dev has never been my job role

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

> I’m able to spin up test harnesses, write throw away glue code, test against large datasets, eTc

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.

> make them much better at using agentic swarms.

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.

The problem often is that the new manager can teach their hires to write better code and train them to be new managers. Given that a team leader in such a scenario is often checking for correctness, I am not sure if current LLM based AI will ever be able to do it. We need new AI for it.

There's just no escaping from making decisions. Agents can't reliably make them as many rely on tacit knowledge which isn't written down.

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

I find it interesting that when drawing this parallel you mention that some devs 'get it' and 'build a great culture'; I think this is exactly where the analogy breaks down. Good managers get great results from people (and for people! they are linked).

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.

Nothing you said makes any sense.

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.