Hacker News

Not if you turn off your brain. Never actually stop to question the path you're going down, because the speed is making you blind. Which is what I feel I see more and more. Or how do you even know it's the wrong answer if you didn't think it through before starting?

One example: setting the agent ablaze on some task, keeping it going, and after a few days of working with the agent you have a feature. But it's not what you were supposed to make. The agent didn't have all the context and made something slightly off, and you never internalized the problem enough to even spot it. If you actually stopped to think a bit on how the feature would have to work to tie it in with everything else, like you would have done before, you would've spotted it.

Second example: something wasn't feasible to do before, due to not being worth the time investment. Like a feature that would need a bigger architectural change to implement. You and the agent take a crack at it, and rewrite huge parts of the code, and it seems to work. But now no one understands how, and it might have been the wrong way to solve it, you just went with it. Before, you would've sat down and discussed and thought about the architectural tradeoffs. Now one decision was just made with little thought.

It is an anti-pattern that predates AI. Tester-driven development maybe.

The idea is that instead doing things correctly, you do "something", then, if it fails (it will), you change some random stuff until it passes. It typically results in code no one understands and that fails each time something unexpected happens.

AI makes the process much faster, but just as wrong.

What's easier to use as inspiration for coming up with a list of requirements?:

1. A blank sheet of paper

2. A one-shotted POC in the span of an hour with $4 of tokens that is clearly wrong in 20 different ways?

The thing is, AI is generating sooo fast so many outputs, its hard to review and evaluate all of them: Very often I encounter in design/architecture questions a situation where the model suggests 2 - 3 alternatives approaches,then asking a little bit and there you are with 30+ pages of content etc.

That depends on (A) verification being very low cost and (B) being able to infer the right answer based on wrong ones.

Those aren't always true. Sometimes it takes a while to see the fatal flaw in an approach, and sometimes having a bunch of failed attempts isn't enough to make the right way obvious, and thinking is still required.

I agree with both you and matsemann. Getting the requirements right by conducting a cheap POC is a good approach. Matsemann is highlighting the failure that creeps in when the POC is shipped as if it meets the requirements.

Someone has to sign off on the requirements and also what is released. So, two approval steps by a person. The first approval is for a plan and the acceptance criteria. The second approval is a check against the plan. The agents can do all the work of taking the plan, breaking it down into tasks, building, and then verifying it. A good orchestrator will include people in the workflow at the points where their decisions matter and maintain a record of it.

> The thing is it gets you the wrong answer so fast it’s now the best way to figure out the right requirements.

I guess that’s just the old “Build One To Throw Away” in a modern light, where prototyping more freely is now actually feasible. I think if you apply the good engineering ideas of the past decades to AI, the results can be really good!

Except I’d also add a lot of testing to the prototype, to bring up as many edge cases as possible.

I was talking about it for a while with colleagues. AI besides other benefits, needs to be treated as great interface for discovery, you have your features baked in, AI uses it via your users and MCP, then you figure out what are actual flows of my users and then you build it

> The thing is it gets you the wrong answer so fast

If oftentimes happens that you don't know that that's the wrong answer, or you don't realize it right away, for that matter, and hence that's I think that AI is a new (and very big and important) source of information entropy.

Just a recent personal example, yesterday I was curious about the historical figure that was present in an online photo taken in 1930s Romania. Google's Gemini was very quick to point out that that was (military dictator) Ion Antonescu [1], which it was obvious that he wasn't. I wrote down that that wasn't in fact Ion Antonescu, at which point Gemini was very quickly and very surely providing me the info that that guy indeed wasn't Ion Antonescu, but (former Foreign Affairs) minister Manoilescu. At this point I wasn't so sure myself, I don't have a visual image of Manoilescu in my head, so (ironically) I had to AI-dumb google for Manoilescu's available online images and it seemed like Gemini had been wrong a second time. I didn't bother asking it for a third time.

Just to put things into perspective, here in Romania it is illegal to mention Ion Antonescu's name (and propaganda image) in a positive matter, as in one risks prison for doing that, now, just imagine that the political powers that be here decide to use an AI-tool like Gemini in order to identify potential law-breakers in that respect. People would risk going to jail just because Google's Gemini was completely wrong in identifying a WW2 military dictator. Absolutely atrocious product(s).

[1] https://en.wikipedia.org/wiki/Ion_Antonescu

> erm, Claude, do it again but leave out the bad stuff and make it good this time, mmkay?

[flagged]

>The difference is one engineer can you work on many sequential tasks in parallel.

Then they aren't sequential.

> 9 coders

How do you do that? If I let just 2 agents work in parallel they keep stepping on each other, waiting for each other and the perf tests become super noisy (because they run them in parallel)

> Claude Code can build that application in an unprecedentedly short period

Yes, with the caveat that the application doesn't actually work.

P.S. If you wrote non-working applications even before the age of AI, then this is an upgrade, I guess.

There is a difference between building a product and building a product that sells. So, which one are we talking about here? In my opinion MMM talks about the latter

Right, the key being a fast feedback loop. I have full confidence that the same LLMs that can do these crazy math proofs could also do crazy biology, even cancer research, but they simply don’t have the cycle time low enough because they require actual physical experiments, often on living things, often over long time horizons. Even if you perfectly automated a lab, made thousands of them, you’d still be unable to match the speed of iteration that one gets with pure math and computing problems.

> Related thing is that LLMs are still notoriously bad at writing instructions for themselves (so managing themselves also).

Isn't this odd? This seems to be the #1 task that the major labs should be optimizing, since it makes agent so much more effective.

> They tend to overspecify. If I had a copy of myself I would tell him "do the thing", but agents say "do the thing like this and this, it must be such and such, use X and put it together that way". The subagent is just as intelligent but now it's constrained, sometimes as you start developing something you discover some things are better organized in a different way etc. So it spends much time figuring out how to deliver exactly what was asked even if it's not optimal because that's the task.

Isn't this just the planning pattern, common for agentic work? (first plan then implement.. with things like /plan, or a planning skill, with or without creating a PLAN.md). If this methodology is wrong when an agent prompt another agent, it's also wrong when the human runs /plan manually..

And Indeed, I always thought it was odd to constrain the implementing agent like that, because common sense is that we discover things as we implement. Perhaps we should prompt the agent to communicate back, as they implement, any shortcomings in the plan itself - such as things they learned while implementing that contradicts the plan.

Exactly, and a lot of times when I step back and discuss alternative approaches and architectures with the LLMs, they keep going back to say: "the code does not use this (currently), therefore this is fine to throw away", or "the code does this (currently), so this approach is not compatible" They are bad at stopping to ask "what should the code be doing"? It's like they love being constrained by current choices, even if there is nothing unchangeable about those.

> The subagent is just as intelligent

Isn't it a common practice to use cheaper models to do the grunt work?

I've noticed this myself and am not sure how to solve it yet. I think there is value in methodically specifying what needs to be done ("grill me"), but sometimes the resulting plan indeed becomes overly prescriptive, leading agents to chase goals that ultimately don't matter.

Reminds me of my wife chatting with this guy at a party and we were complaining about money problems and she says this proverb she had learned recently and said, "a man is rich if he has two hands".

Turns out the other person was Albie Sachs who was a hero and had his hand blown off during the apartheid era and took both arms out of his pockets and raised them up and said "I guess I'm not rich then" - that was some serious gallows humor :-)

I can't believe I'm nitpicking proverbs, but making a sound with one hand isn't witchcraft.

To the core message of it, if we really need to stick to one liners, "go alone to go fast, go together to go far" would be an easier philosophy to adhere to perhaps.

Your proverb holds up talking about complementary work.

I think the Mythical Man Month specifically refers to piling on workers of the same skill set (i.e. engineers)

I also think the context of building software matters quite a bit as well.

In a big corporation where ownership is fragmented and initiatives that are big enough for the mythical man-month problem to become tangible, big part of the problem becomes aligning the different engineering teams around why something should be built now, why team X and not team Y should do it, doing it securely and having enough confidence for a release.

In my experience, you choose the key difficult parts first, and build a small toy version. From that action, you learn which parts of the interfaces are common, and may undergo modularization with a clean design pattern.

Ultimately with sanity checking, sanitized marshaling, and constraint programming... the underlying security model is naturally enforced within the pattern itself.

The deceptively simple systems are more like an ant colony or bee hive. =3

Most people have no view on that, or dismiss it either as a cultish/outlandish topic or something so far into the future it's not worth discussing. The author most likely falls into these categories otherwise his point would be mute.

I don’t „talk” to my agents. I tell them what to do. If I need to „talk” it means something is going wrong and we need to figure out why agents are doing bad work - and this is intellectually challenging.

The effect you describe I had at times but with older/dumber models where you could spend a ton of time and the model was either too dumb to do it, or had a model dementia later in the context. Or when I didn’t really understand why it did a bad job and tried to stumble around in the dark - very mentally numbing.

Nowadays the model usually just had some bad tools or information required to do the job.

You need to switch into a product manager/QA/UI,UX mindset.

Is what is being built the right thing? Does it work? Is it usable? Has it been built in an appropriate way? (Note this is not a code thing, it’s an architectural question)

Traditionally developers have outsourced these things to other people.

There’s a further thing you should be doing - if the questions above didn’t pass - why not? What went wrong in your process?

Doing more, understanding more the tech of the project, exploring more ideas, the list is infinite

Who got more time thanks to AI ? I think a lot of us are working more instead

> keep your mind exercised

OK, so I'm still very low on the spectrum of "I just command it and sit back", but I think the final toolbox will at least include adversarial questioning of the bot. For example, "Why does that code do A, wouldn't B be better?" or "Would this code break if a C event occurred?"

Sometimes it reveals a bug or a questionable implicit assumption, other times it leads me to see another part of the code, and sometimes the thing just lies at me... But it does help you keep some critical-thinking practice.

Another task might be to find and refactor/rename parts of the code that are just... not easy for humans to grasp. Some readers are thinking: "No, the next edit will be by LLM anyway, leave it so the bot understands", however I think that's short-sighted: Either these things are going to become good-enough that they should cater to human comprehension, or else they've reached a plateau and we'll want something that can resist the chaos-rot.

Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.

>Here's a question, to people who delegate all their coding to AI agents now: What are you doing to keep your mind exercised in all this suddenly new free time you have?

If you have a lot more free time you're not taking full advantage of agents. The time saved coding allows working on 4-6 projects simultaneously, and the majority of work is the hard design/product decisions that the agents can't do well themselves. Working on the hard parts of half a dozen projects simultaneously is far more mentally taxing than just hand-coding a single project, and with that many agents there'll usually always be one with a question for you so you won't have much extra free time.

Which bits of tone felt AI to you? It didn't set off my internal "ai-detector", not that I'm an expert or anything.

To whit, 13,000 women can make a baby in one month. If you hire that many women, by the statistics, that's how many it takes for one of them to be 8 months pregnant.

Agents still have to communicate using tokens (for now). There are more advanced mechanisms being proposed, but for now, and until proven otherwise, the same scaling problems apply to agents communicating as humans, it just happens a bit faster, and with no HR issues because someone slept with the wrong person. Mesh networking, and thus agents too, are beholden to Gupta-Kumar scaling law.

It's a weird way to express that concept, in fact I don't think it ever appeared like this in the book (it has been a while).

It would be something like "nine women cannot deliver a baby in one month", which can be more easily transposed to "adding resources to a SW project does not make it faster".

The agrument is that adding people increase coordination and communication overhead, which gets bigger as the team grows. Moreover, some tasks cannot be parallelized that easily and create dependencies.

I have only worked with agents for personal projects, but I cannot say that explicity dividing the work between multiple agents and asking them to coordinate is inherently faster than having a single agent work on it (of course the single agent will spawn subagents in rencent harnesses.)

Are you aware of the original saying?

It's a metaphor for some tasks being inherently serial, so no amount of parallelism will make them complete faster.

I think it takes MORE attention and thought. I feel like a rope being pulled tight and fraying in the middle. Working with these things is very addictive and interesting but it is cognitively exhausting long term, even if invigorating in the short term.

I get a feeling that the best way we currently know how to use these tools is to not read their code at all. Models code and models review. Humans just ask questions and guide. Claude Code has no code editor on purpose.

Is this sustainable? I've got no idea.