Remix.run Logo
enobrev 2 days ago

> it doesn't seem to be making me any more efficient

That's been my experience.

I've been working on a 100% vibe-coded app for a few weeks. API, React-Native frontend, marketing website, CMS, CI/CD - all of it without changing a single line of code myself. Overall, the resulting codebase has been better than I expected before I started. But I would have accomplished everything it has (except for the detailed specs, detailed commit log, and thousands of tests), in about 1/3 of the time.

fourthark 2 days ago | parent | next [-]

How long would it have taken if you had written “the detailed specs, detailed commit log, and thousands of tests”?

veber-alex 2 days ago | parent | next [-]

-1 time because it would have never have happened without AI

enobrev 2 days ago | parent | prev [-]

The specs would not likely have happened at all, since this is a solo project; although this experience has led me to want to write these things out more thoroughly, even for myself. It's impressive how little work I need to put in going this route to have fairly thorough actionable specs for pretty much every major decision I've made through the process.

The commits - some would be detailed, plenty would have been "typo" or "same as last commit, but works this time"

The tests - Probably would have been decent for the API, but not as thorough. Likely non-existent for the UI.

As for time - I agree with the other response - I wouldn't have taken the time.

theshrike79 a day ago | parent | prev [-]

I'm not calling bullshit here, but something smells.

If you really can write a full-ass system like that faster than an LLM, you're either REALLY fucking good at what you do (and an amazing typer), or you're holding the LLM wrong as they say.

enobrev 10 hours ago | parent [-]

I'm ok on speed. Not 10x or anything, but I've been writing full-stack web apps and websites from scratch for a quarter century.

The issue is getting the LLM to write _reasonably decent_ code without having to read every line and make sure it's not doing anything insane. I've tried a few different methods of prompting, but setting up a claude sub-agent that's doing TDD very explicitly and ensuring that all tests pass after every iteration has been most effective.

My first attempt was so fast, it was mind-bending. I had a "working" App and API running in about a day and a half. And then when I tried to adjust features, it would start changing things all over the place, LOTS of tests were failing, and after a couple prompts, I got to a point where the app was terribly broken. I spent about a day trying to prompt my way out of a seemingly infinite hole. I did a more thorough code review and it was a disaster: Random code styles, tons of half-written and abandoned code, tests that did nothing, //TODOs everywhere, and so, so many tweaks for backwards compatibility - which I did NOT need for a greenfield project

At that point I scrapped the project and adjusted my approach. I broke down the PRD into more thorough documentation for reference. I streamlined the CLAUDE.md files. I compiled a standard method of planning / documenting work to be done. I created sub-agents for planning and implementation. I set up the primary implementation sub-agents to split up the spec into bite-sized portions of work ("30-45 minute tasks").

Now I'm at the opposite side of the spectrum - implementation is dog slow, but I rarely have to read what was actually written. I still review the code at large after the primary tasks are finished (comparing the feature branch against main in my IDE), but for the most part I've been able to ignore the output and rely on my manual app tests and then occasionally switch models (or LLMs) and prompt for a thorough code-review.