But it’s not a man-month anymore. It’s like half a day.

And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.

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

Plans and git worktrees. If you (or anyone else here) want more info than that, give me a way to reach out and I'm happy to help. I regularly run 40+ subagents sustained in parallel (productively) without toe-stepping or any significant rework.

Stepping on each other how? I find each agent needs to spin up N worktrees for each task, and I use hooks to prevent them working on the same substrait.

You’re not running tests in CI? The agent should only run the minimum tests necessary and then idle and wait for feedback from a CI run.

Better planning, specs, and defined agent tasks with skills and logical and technical separation.

We build modular systems with plans. One developer (not agent) with Claude Code executes their portion of the plan and everything else is normal monorepo business.

You obviously need another agent that is the only one that can run perf tests.

Turtles all the way down.

Because agents != coders

Man-month or man-minute doesn't make any difference.

Can you add 27 more coders and cut the app build period down to 25% of what it was?

9 isn't a large number of people and its fairly well agreed on maximum limit for productive team size (the limit can be lower than 9) due to the number of possible communication channels. All that has changed is that a 9 person team can now do more with AI assistance then they could without it.

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

These replies are getting exhausting. We’re well-passed generating high quality code using GenAI.

If you think we’re still dealing with hallucinations or fake code, then you’re experiences are about 8 months behind.

> then you’re experiences are about 8 months behind

I've been hearing this excuse for the past five years, bro.

When will AI finally be a real boy? Gimme a real date so I can make fun of you.

I have a team of devs proving a significant increase in velocity while maintaining quality.

But it’s private corporate work so I can only suggest you keep an open mind and actually research the effectiveness of GrnAI in application construction.

I mean, 8 months ago Anthropic made Claude build a C compiler autonomously, and the crowd came to the autonomous repo and threw a shitposting party making fun of the build failing for some time (it fixed itself in a few days but nobody cared anymore, partying was the entire point). Half a year later we had people porting huge million-LoC projects to different platforms, they run and literally have bug-to-bug parity. It's tedious work that doesn't need deep thinking but has clearly defined goals and can be iterated upon, so it's a good fit for current AI. If your expectation of vibecoded software is it doesn't actually work (as you said above) then you really need to update it. Internals might be a horror, but it does work and it's not broken. This wasn't the case a few months ago.

And yet here I am, playing a full-fledged first-person shooter written from scratch by an LLM as a proof of concept. It has enemies I sketched on paper, everything else is 100% procedurally generated in code. In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.

As soon as your spec has a clearly defined reachable goal and non-contradictory constraints, and doesn't require taste or judgement, current agents are pretty good at reaching it, because it's all they're optimized for. Writing that spec in a non-contradictory manner is not trivial, though.

> It's not very good, it's not optimized for maintenance or extension

Well yeah. Prototypes are not products, the last 10% takes 90% of the time, and so on.

Practically half the wisdom written about software in the last 20 years has been about the fact that just because you can make something that kinda looks like the thing at a glance very much does not mean you can make the thing. All those "small tweaks" you think you need to be finished usually turn out to require large redesigns, else you'll tank performance, stability, security, usability, or all four at once.

Meditate on the fact that people used to (and still do!) go to game jams and code games with freshly made assets in a day. I just did one myself without llms at the weekend. Whats the difference between that and making a game that people buy? Why does it take so much longer?

Also, FPS is a done to death concept that has plenty of repos for LLMs to take snippets from. A better test would be trying to vibe-coding an original game (e.g. something like Miegacure) and see how well LLM does, even when you give it well-defined goal and constraints. My guess is that would fail miserably.

I am "creating", at least designing, games with my kids. It's not that I couldn't possibly do it before, but I certainly would never have the time to.

I explored frameworks and engines, and landed on Bevy, I asked for a rudimentary arena, isometric perspective, 4 players, xinput support, portable desktop and wasm targets.

After that part done we've made the characters into chickens using no assets, only primitive mesh, having a trail of feathers, flapping wings on jump/double jump as well as gliding, picking animation, bite/grab, zenith shadows on characters (despite being unrealistic, in favor of platforming), physics objects, a few game modes like soccer, bowling, etc.

Each of these were iterative additions, so it's like previous development, only the coding/debugging time is largely removed. Is there bloat? Absolutely. But it still works, and while it's not a "real" game yet, I do believe it's original, it's certainly evolving exactly to our design, however confused it is.

>In what way does it not work? It's not very good, it's not optimized for maintenance or extension (that would take a complete rework which is also cheaper with it), but it does work and is not broken because the agent tested the most obvious scenarios. It took it a few hours.

Was your purpose to "make a basic FPS template that barely works", or "make a fun game that can sell and appeal to a specific audience"?

If more people were honest about the former reason and not trying to play it off as the latter, then maybe LLM's wouldn't have its reputation among comsumers as "slop". Making a protoype of a basic functional FPS was never the hard problem to solve. UE5's sample project does that for you. These days Roblox/UEFN also does that for you.

As I implied with "proof of concept", the purpose was to see if it works at all, not to make a game. It made mistakes and autonomously fixed them. Just a few months before, agents weren't able to do this. Now they're able to reach the goals you set, as long as they're definite, you're not making immovable objects collide with unstoppable forces, and the search space is not very diverse.

Disposable prototypes were the goal in some cases.

> In what way does it not work?

It doesn't fulfill its primary purpose of being a (fun) game.

> It doesn't fulfill its primary purpose of being a (fun) game.

A fun game isn't made when you're working on the engine & tech.

It is only made when everywhere else has been done, & when the feedback mechanisms are tightened. This will never happen in the prototyping stage, because the point is to make the thing exist in the first place.

------

This comment is the same Reddit-style one-off critique that makes no actual sense when placed at the grindstone, made by people that have never actually tried to make one with OR without.

TL;DR - you didn't make a game, but lied on the Internet that you did.

??? I don't see anyone claiming they made a game, let alone a "fun" one, you're replying to something that is not in this thread. The claim was that the agent wrote a program with clearly defined constraints and it works according to spec because it dutifully tested it and iterated on incorrect code. It's not bugged, it doesn't crash or anything like that.

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

If you've got 9 coders, you've at least got a business idea and some financial backing.

Get it out quickly, market it, iterate it. That hasn't changed. Just the speed of iteration before you go from product to product that sells.

Once you know what sells, then again, it takes far less time to rebuild it well if you need to.

This does not apply in all cases.

Case in point: I am building a digital files archive organizer platform.

This is simply not the kind of product you do a quick prototype of, get it to market quickly, and iterate on based on any failures or issues.

There are an almost infinite number of ways to get the product wrong, in a technical, architectural, and business/market sense. It requires a lot of deep thinking and internal prototyping to even get at what would actually be useful and address the walled-content-silos problem tech vendors love to foist on us. it requires careful implementation to not mess up user data. It requires a ton of architectural and UX design to get a performant product that is easy to understand. I have mulled over architectural decisions for months and thrown them out totally after mounting evidence they were not right, without a single user yet (except myself).

Just quickly coding up the first ideas that come to mind in this space is almost guaranteed to be wasted effort, because I could try a 100 approaches in the market and all could be bad. Do not let the users do your work for you. Make sure you actually understand what you are building and why it is important. Then let the user's experiences tell you how to tweak it to be better.

If you can vibecode a product that sells, I can vibecode a free open source one just as easily, probably even easier since I can just ask the AI to copy the existing one. Software is trending towards being free and open source.

Yeah, and then who maintains it?

Maintaining vibe coded software is going to become hours spent with Claude not your users.

That's going to be the difference. It takes nothing to rebuild the software, but listening to users, iterating, handling issues. That's boring.

The ones that win will be the ones that stay the course, not the ones that were built the quickest.

I mean, you can also use agents to listen to users and handle issues automatically.

But I guess you mean the discovery part? Yea, agents are not going to totally replace that anytime soon. Though, Claude voice mode is pretty good these days, so I’m sure it’s on their mind.

Not sure what you mean by “stay the course.” I think the winners will be those with the most effective marketing strategies. Surely that will require automation.

Half of the value in open source was that it was used by lots of people and all of the nasty edge cases and bugs have been ironed out.

If LLMs were performing according to hype then yes, virtually all paid software would be gone by now and there would be a high quality FOSS equivalent of all of it.

[deleted]

In the good old days that was called 'piracy'.

Unclear if this is that. If someone makes their own FOSS Photoshop, that's not piracy, it's GIMP. Training a AI on things that one otherwise has lawful access to (and not, e.g., pirating the material which Meta is being sued over and Anthropic settled over) has been ruled lawful.

Is asking an LLM to "make an open-source Photoshop clone" more like GIMP, or more like opening someone else's photo in Photoshop and clicking the menu option for the filter to make it look like a stained glass window and claiming the stained glass window version is your own IP that doesn't need permission from the original creator?

We may need new IP laws. Or, to the horror of many software developers 20 years ago, software patents.

And "new IP laws" doesn't mean "stronger": the justification for giving creators a monopoly on their works (the right to copy, or copyright) is to encourage more. If we've got a machine to automate this, there's suddenly no reason to encourage more.

Decompiling binaries and building something very similar is surely an act of piracy.

That’s only really done for video games where you want an identical clone. The vibecoded photoshops aren’t decomps. They are just asking LLMs to build photoshop from scratch in rust.

You can't prove that point,because model training data is opaque.

It might be, depending on what the LLM used the binary for. Patented algorithms? Yes. File format compatibility? Quite possibly not.

But what about when they're only given the user manual and told to implement it?

And extra "fun", given that "hack HuggingFace" wasn't part of the thing being tested when OpenAI's LLM did exactly that: what happens when the LLM decides the best way to implement the user manual is to decompile the binary?