> There seems to be a strong bias where using AI feels like you're making a lot of progress very quickly, but compared to manual coding it often seems to be significantly slower in practice.

This metric highly depends on who uses the AI to do what, where strong emphasis is on "who" and "what".

In my line of work (software developer) the biggest time sinks are meetings where people need to align proposed solutions with the expectations of stakeholders. From that aspect AI won't help much, or at all, so measuring the difference of man hours spent from solution proposal to when it ends up in the test loops with and without AI would yield... very disappointing results.

But for troubleshooting and fixing bugs, or actually implementing solutions once they have been approved? For me, I'm at least 10x'ing myself compared to before I was using AI. Not only in pure time, but also in my ability to reason around observed behaviors and investigating what those observations mean when troubleshooting.

But I also work with people who simply cannot make the AI produce valuable (correct) results. I think if you know exactly what you want and how you want it, AI is a great help. You just tell it to do what you would have done anyway, and it does it quicker than you could. But if you don't know exactly what you want, AI will be outright harmful to your progress.

the venn diagram of people who say "AI produces useless results I have to 100% throw away" and people who say "I've never successfully delegated parts of large software development to junior programmers" is a circle

Junior programmers learn and provide a wide value, AI does not

I get a lot more done with lot less frustration giving my work to Claude than to a junior dev quite frankly and I've managed many groups over my career.

the value of the junior dev is the hopes that they'd be a senior dev someday, I dont have a solution to that problem. But in my current capacity where the only devs I'm "managing" these days are via open source contributions, they're already gone - 100% of what I get is through their own work with LLMs (which I have to spend more time correcting than if I used the LLM myself).

This struck me as odd too. 7 months? It wouldn’t take that long to write it in a new language.

Another thing I don’t see mentioned is code quality.

Vibe-coded code bases are an excellent example of why LLMs aren’t very good at writing code. It will often correct its own mistakes only to make them again immediately after and Inconsistent pattern use.

Recently Claude has been making some “interesting” code style choices, not inline with the code base it’s currently supposed to be working on.

Seems to be baked into the GPT- produce text- aka to produce language and code is life and purpose. So the whole system is inherently internally biased towards "roll your own everything?" unless spoke too in a "Senior-dev" language, that prevents these repetitions.

This was made in two days of vibe coding. It has flaws, but it's impressive as hell:

https://tinyskies.vercel.app/

It's got a fun Zelda-inspired mechanic (I won't say which one), and you'll have to unlock abilities and parts of the world over several quests and modes to "win".

It's also multiplayer.

This ran at ~1fps for me

Runs smoothly for me in Zen (FF) on Linux.

Turning didn't work for me. Impressive as hell indeed! The author is probably already busy 100xing other projects, no time to fix such a minor nuisance.

I guess? Yes. But I played for like 20 seconds and lost interest.

Unless there is a way to see or check the whole prompt that made this game, it is hard for me personally to say if this is impressive or not as I don't know what percentage of this was vibe coded. I also see there is an incentive to skew the truth here, as there is a substantial prize pool and that usually makes people become very creative.

In the past, I was trying to reproduce vibe coding results when I managed to get all the information from Youtube videos (model version, ide version, same input data and prompt) and never was I able to reproduce something impressive even after multiple runs of the same thing.

He's been fairly forthcoming about his process:

https://x.com/DannyLimanseta/status/2052040017007251946

Here are the direct links:

https://github.com/dannylimanseta/tinyskies

https://github.com/dannylimanseta/tinyskies/blob/cursor/glob...

https://github.com/dannylimanseta/tinyskies/blob/cursor/glob...

Thanks for that. I skimmed through provided links, only thing I can conclude was, it was a process of do something and let's hope for the best. I also see references to files not linked to Github, so I don't know what is contained inside of it: "Here’s what was added to the paintball_replaces_barrel_roll_19e450df.plan.md"

It's more complex than that, I think the reality is that there's a lot of code that's just not that deep bro. I have some purely personal projects that have components that I don't understand anymore, I wrote that shit by hand, they still work but I haven't touched that shit in years. There's a lot of code that AI can write that's like that that helps me, the stuff I would forget about even if I wrote it by hand. I think you have to have discipline in it's use, it's a tool like any other.

AI, and especially agentic AI can make you lose situational awareness over a codebase and when you're doing deep work that SUUUUCKS, but it's not useless, you just have to play to it's strengths. Though my favorite hill to die on is telling people not to underestimate it's value as autocomplete. Turns out 40 gigabytes of autocomplete makes for a fucking amazing autocomplete. Try it with llama.vim + qwen coder 30b, it feels like the editor is reading your mind sometimes and the latency is so low.

You nailed it, I came to the same conclusion recently. When people show me what have they done with LLM, I am left unimpressed as mostly they show things that can be done manually in a very short time. I also failed to observe the rise in availability of impressive software, which coincides with the fact that LLMs are currently being used to solve simple problems, instead of important ones.

> LLMs are currently being used to solve simple problems, instead of important ones

Which is still cool. I just wish people were more honest about this.

Absolutely correct.

This is probably because the people who feel like they receive the most benefit from LLMs never actually knew much about or were just incapable of writing good software before they started using LLMs.