Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's the right trade-off, IMO. Most projects won't succeed and the ones that do can be refactored - by real engineers if needed.


You make it sound like it’s a binary situation where in one case it doesn’t matter and in the other it’s No Problem. I think both are wrong.

An unsuccessful project might be unsuccessful because it got eaten by costs before it became successful.

A wildly successful project is risky to migrate.


The YC crowd seems to think the only worthwhile businesses are worth $1 billion+ otherwise why bother


I strongly disagree with this.

Most startups fail. Optimizing for getting revenue is more important than optimizing cost in the beginning.

If you get revenue you can solve the cost problem. If you don’t, it doesn’t matter.

Anything that gives you more shots at the goal is a win in a startup.


If you are trying to commercialize something, a popular project with bad margins is a better spot to be in than an unsuccessful project with good margins. If it's a personal learning project, that might not be the case.



I don’t think that’s a counter example. If hood maps shows a lot of potential then the $11k is something to figure out.

If not, then it’s poor price controls.

IIUC Pieter Levels talks a lot about not prematurely optimizing engineering solutions because most ideas will flop.


These cloud back and stacks are very cheap at low volume and honestly I expect them to remain so or even go down in price.

I've seen many colleagues bootstrap something - even if they're not themselves very technical - because they've leveraged these well integrated low cost platforms.


I do think it’s binary. The project either shows potential to meet your goal or it doesn’t.

I think it’s rare that fails to show potential because of the underlying technology that’s chosen.

Sure, Vercel is relatively expensive. But I just don’t see how you’d throw in the towel because the costs are too high without first evaluating how to lower them.

If you’re saying that the evaluation is likely to show that you’re stuck - I have never seen that be the case personally.


I’m a “real engineer” and I don’t want to do all that until I have to.


As a "real engineer" you'd likely use LLMs differently. I save my conversations, have chats and codebase exegesis summarized into .txt files, and constantly refactor LLM output. I have an increasingly reliable sense of when to dip in and write things myself and when to let the LLM rip. My LLM-assisted code is better than my hand-written code; how could it not be? I'd have to be committing raw LLM output without even reading it to end up somewhere worse. If I did that, how much of a "real engineer" would I be?

All this is to say: even if all progress on AI halted today, it would remain the case that, after the Internet, LLMs are the most impactful thing to happen to software development in my career. It would be weird if companies like Supabase weren't thinking about them in their product plans.


Have you found any good resources on how to get a good process going? That would be an interesting read.

I have two main issues, first the tooling is changing so rapidly that as I start to hone in on a process it changes out from under me. The second is verifying the output. I’m at like 90% success rate on getting code generated correctly (if not always faster than I could do it) but boy does that final 10% bite when I don’t notice.

An aside, I think the cloud ought to make your (perhaps especially your) list. At least for me that changed the whole economy of building new software enterprises.


I haven't, besides Carlini's piece, which is already kind of obsolete:

https://nicholas.carlini.com/writing/2024/how-i-use-ai.html

The Internet, LLMs, open source, high-level languages, the cloud --- that would be my top 5.


Yeah I think it depends on what I’m doing.

For “real work” done by a “real engineer”, I approach it almost exactly as you say.

For side projects/personal software that I most likely would have never started pre-llms? I’ll just go full vibe code and see how far I get. Sometimes I have to just delete it, but sometimes it works. That’s cool.


Regarding refactor: My understanding is that vibes codebases are effectively write-only due to their structural incoherence.


That’s my understanding also. I think a project that’s vibe coded could easily be recreated by a programmer using coding assistance.


Agreed. And you can take a lot of the supabase code and try and host yourself if you get there.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: