And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.
And if I break up an application then 9 coders with Claude Code can build that application in an unprecedentedly short period.
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)
Turtles all the way down.
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.
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.
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.
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.
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.
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.
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.
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?
If you think we’re still dealing with hallucinations or fake code, 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.
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.
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.
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?
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.
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.
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.
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.
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.