It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work. If anything, it’s the exact opposite. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.
This product rides a hype wave. This is why it is crazy popular and successful. The situation there is akin to Viaweb - Viaweb also rode hype wave and code situation was awful as well (see PG's stories about fixing bugs during customer's issue reproduction theater). What did Viaweb's buyer do? They rewrote thing in C++. If history rhymes, then buyer of Anthropic would do something close to "rewrite it in C++" to the…
I haven't heard of anyone that's using vibe coding to rewrite what they have. Most of what I hear is to create new things, and to accelerate development of existing projects.
Mind sharing that prompt? This is one of my favorite uses for AI too, but I’m just using it to fix the stuff that’s already top of mind for me.
For sure. This is a straight copy-paste of my prompt which references my architecture, codebase, references folder (God, that's so golden -- .gitignored, but saving the tokens of googling or cloning and just having the codebases we depend on locally is killer) so this is not ready to be copy pasted. However, with the context that this is an interface for a peer-to-peer encrypted radio mesh client (for MeshCore; my co…
Thank you for sharing this! I love how writing prompts like this forces us to clarify our own values and sense of engineering taste. I’m really curious to see what an agent would find in our code base with this.
It’s truly strange that people keep citing the quality of Claude code’s leaked source as if it’s proof vibe coding doesn’t work. If anything, it’s the exact opposite. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.
I think you're all fucking crazy. Or maybe I am? I can literally see my teams codebase becoming an unmaintainable nightmare in front of my eyes each day. I use copilot and Claude code and I frequently have to throw away their massively verbose and ridiculously complex code and engage my withering brain to come up with the correct solution that is 80% less code. I probably get to the solution in the same time when all…
Sounds very similar to my experience with colleagues before AI. It just goes even faster now.
Bad code works fine until it doesn't. In my experience, with humans, doing the right thing is worth it over doing the bad thing if your time horizon is a few months. Once you're in years, absolutely do the right thing, you're actually throwing time away if you don't. And I don't mean "big refactor", I mean at-change-time, when you think "this change feels like an icky hack." For LLMs, I don't really know. I only have…
If you are a company founder, what scenario would you rather find yourself in? a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model b) a bad codebase but it correctly models and nails the domain model for your business case Real life example, a fintech with: a) a great codebase but stuck with a single-entry ledger b) a bad codebase that perf…
Since most won't actually deal with fintech (I don't know the stats on HN, but I'm talking devs as one industry), your first "a" example might actually be better than your first "b" example, depending on the complexity of the software. In lots (probably most) of industries, having a good codebase would mean architecture decisions were solid, but the domain/service layer is bad. Maybe my experiences don't match most of the HN crowd, but usually I get stuck with very detailed domain/service rules, but the architecture is a problem where too much memory or CPU is being used, just to abstract away the actual rules of the application (the purpose). Usually when I've been brought in to rebuild an application, the client is fine with the results, but they are upset over performance and/or cost to run the application. For anything of actual complexity, it's usually the supporting code that is the biggest failure, because complex apps usually have decent requirements. Now, if the requirements were bad, and the architecture was bad, AND the domain/service layer is bad, I don't know if there's anything to fix that.
You’re missing the group of high performers who love coding, who just want to bring more stuff in the world than their limited human brains have the energy or time to build. I love coding. I taught myself from a book (no internet yet) when I was 10, and haven’t stopped for 30 years. Turned down becoming a manager several times. I loved it so much that I went through an existential crisis in February as I had to let g…
Yes I'm exactly like you as well. I've been coding for 30+ years, I still love coding and system building etc, but sometimes the level of frustration to find the information and then get something working is simply too high. Over a weekend, I used ChatGPT to set up Prometheus and Grafana and added node exporters to everything I could think of. I even told ChatGPT to create NOC-style dashboards for me, given the metri…
Are you making this complaint about the AGPL-licensed Grafana dashboard, or the licensed Enterprise edition?
I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, and a lot of the terrible code that makes it to production was shocking when I first started. This isn't a dig at anyone, I've certainly shipped my share of bad code as well. Deadlines, despite my wishes sometimes, continue to exist. Sometimes you have to ship a…
It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.
Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up.
Once you show PMF though the balance changes to long-term sustainability and maintainability.
What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code.
I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, and a lot of the terrible code that makes it to production was shocking when I first started. This isn't a dig at anyone, I've certainly shipped my share of bad code as well. Deadlines, despite my wishes sometimes, continue to exist. Sometimes you have to ship a…
It's an unpopular truth for our industry, but the point of commercial software development is not to write good code; it's to write profitable code. There are some cases where the most profitable code is also good code. We like those. But in most (99%+) cases, the code is not going to survive contact with the market and so spending any time on making it good is wasted.
To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it.
Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.