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.<p>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 suspect if people saw the handwritten code of many, many, <i>many</i> 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.<p>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 hack to make a customer or manager happy, and then replacing those hacks with better code just never happens.<p>For that matter, the first draft of nearly <i>anything</i> I write is usually not great. I might just be stupid, but I doubt I'm unique; when I've written nice, beautiful, optimized code, it's usually a second or third draft, because ultimately I don't think I fully understand the problem and the assumptions I am allowed to make until I've finished the first draft. Usually for my personal projects, my first dozen or so commits will be pretty messy, and then I'll have cleanup branches that I merge to make the code less terrible.<p>This isn't inherently bad, but a lot of the time I am simply not given time to do a second or third draft of the code, because, again, deadlines, so my initial "just get it working" draft is what ships into production. I don't love it, and I kind of dread of some of the code with my name attached to it at BigCo ever gets leaked, but that's just how it is in the corporate world sometimes.
This is the product that's claiming "coding is a solved problem" though.<p>I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.
Sure, but as I stated, even "professional" code is pretty bad a lot of the time. If it's able to generate code that's as good as professional code, then maybe it <i>is</i> solved.<p>I don't actually think it's a solved problem, I'm saying that the fact that it generates terrible code doesn't necessarily mean that it doesn't have parity with humans.
> crummy code, but not the very tool that's supposed to be the state-of-the-art coder<p>Why not? It is subject to the same pressures, in fact it is subject to more time pressure than most corp code out there. Also, it's the model that's doing the coding, not the frontend tool.
I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily.<p>I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like about writing a function that does one thing and only one thing.<p>Outside of small, personal projects, I am still really uncomfortable at having agents run wild. I see the result, and then I spend a bunch of time having to gain the context of what is going on, especially if I ask it to implement features in spaces I have general knowledge, but not expertise. So, the problem remains the same. These things still need handholding by people who understand the domain, but having people become glorified PR reviewers is not an acceptable path forward.<p>Arguing that there is lots of bad production code kinda avoids the actual issue that is going on here. Yes, a lot of sloppy code can and has been written by people. I’ve seen it myself, but it feels like the actual thing is that, we are now enabling that at scale and calling it “abundance” when instead we are really generating an abundance of completely avoidable security holes and logic errors.
No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.
"No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck.<p>As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve.<p>Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.
Nobody cares about costs until they pay them themselves.<p>Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements?<p>On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations.<p>It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.
It really shows that nobody cares about uptime at github or the jankiness of claude.<p>I wouldnt say that <i>customers</i> are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.
The bet is that it will be trivial for them to invest in cleaning up Claude Code whenever they face real competitive pressure to do so. My best guess is that it's a bad bet - I don't think LLM agents have solved any of the fundamental problems that make it hard to convert janky bad code to polished good code. But Claude Code is <i>capable</i> in my experience of producing clean code when appropriately guided, so it's not that there's no choice but jank. They're intentionally underinvesting in code quality right now for the sake of iteration speed.
> I suspect if people saw the handwritten code<p>Somehow, everyone has forgotten the terrible code quality that existed prior to 2020.<p><a href="https://www.youtube.com/watch?v=UjZQGRATlwA" rel="nofollow">https://www.youtube.com/watch?v=UjZQGRATlwA</a><p>Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.
> and then replacing those hacks with better code just never happens<p>Yeah, we even have an idiom for this - "Temporary is always permanent"
> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked.<p>Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.
Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in.<p>I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
> I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.<p>The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic.<p>Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
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."<p>For LLMs, I don't really know. I only have a couple years experience at that.
If you make a working and functional bad code, and put it on maintenance mode, it can keep churning for decades with no major issues.<p>Everything depends on context. Most code written by humans is indeed, garbage.
I define maintenance mode as: given over to different team, so not my problem anymore.
> Most code written by humans is indeed, garbage.<p>I think that this is the problem, actually.<p>It's similar to writing. Most people suck at writing so badly that the LLM/AI writing is almost always better when writing is "output".<p>Code is similar. Most programmers suck at programming so badly that LLM/AI production <i>IS</i> better than 90+% (possibly 99%+). Remember, a <i>huge</i> number of programmers couldn't pass FizzBuzz. So, if you demand "output", Claude is probably better than most of your (especially enterprise) programming team.<p>The problem is that the Claude usage flood is simply identifying the fact that things that work do so because there is a competent human somewhere in the <i>review</i> pipeline who has been rejecting the vast majority of "output" from your programming team. And he is now overwhelmed.
And it’s perfectly okay to fix and improve the code later.<p>Many super talented developers I know will say “Make it work, then make it good”. I think it’s okay to do this on a bigger scale than just the commit cycle.
<a href="https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast" rel="nofollow">https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast</a><p>Make it work, make it work right, make it work fast. In that order.
If you are a company founder, what scenario would you rather find yourself in?<p>a) a pristine, good codebase that follows the best coding practices, but it is built on top of bad specs, wrong data/domain model<p>b) a bad codebase but it correctly models and nails the domain model for your business case<p>Real life example, a fintech with:<p>a) a great codebase but stuck with a single-entry ledger<p>b) a bad codebase that perfectly implements a double-entry ledger
"Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box, and the issue with bad code is that it can make it extraordinarily hard to solve simple problems. I have personally seen tech-debt induced scenarios where "I want a new API to edit this field in an object" and "Let's do a dependency upgrade" respectively became multi-month projects.
> Perfectly implements" is doing a lot of work there. Enterprise software is very rarely perfect out of the box<p>Fair, by “perfectly implements” I meant to say that it correctly implemented the core invariant of a double entry ledger (debits = credits), not that it was 100% bug free
> Bad code works fine until it doesn't.<p>Who is to judge the "good" or "bad" anyway?
But tech debt with vibe coding is fixed by just throwing more magic at it. The cost of tech debt has never been lower.
The fix time horizon changes too, don't discard that.
> you can build a crazy popular & successful product while violating all the traditional rules about “good” code<p>which has always been true
Yes, and to add, in case it's not obvious: in my experience the maintenance, mental (and emotional costs, call me sensitive) cost of bad code compounds exponentially the more hacks you throw at it
Sure, for humans. Not sure they'll be the primary readers of code going forward
I'm pretty sure that will be true with AI as well.<p>No accounting for taste, but part of makes code hard for me to reason about is when it has lots of combinatorial complexity, where the amount of states that can happen makes it difficult to know all the possible good and bad states that your program can be in. Combinatorial complexity is something that objectively can be expensive for <i>any</i> form of computer, be it a human brain or silicon. If the code is written in such a way that the number of correct and incorrect states are impossible to know, then the problem becomes undecidable.<p>I do think there is code that is "objectively" difficult to work with.
All the good practices about strong typing, typically in Scala or Rust, also work great for AI.<p>If you make sure the compiler catches most issues, AI will run it, see it doesn't build and fix what needs to be fixed.<p>So I agree that a lot of things that make code good, including comments and documentation, is beneficial for AI.
There are a number of things that make code hard to reason about for humans, and combinatorial complexity is just one of them. Another one is, say, size of working memory, or having to navigate across a large number of files to understand a piece of logic. These two examples are not necessarily expensive for computers.<p>I don't entirely disagree that there is code that's objectively difficult to work with, but I suspect that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has much less overlap than you're suggesting.
Certainly with current models I have found that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has actually been remarkably similar, I suspect because it's trained on a lot of terrible code on Github.<p>I'm sure that these models will get better, and I agree that the overlap will be lower at that point, but I still think what I said will be true.
I wouldn't expect so. These machines have been trained on natural language, after all. They see the world through an anthropomorphic lens. IME & from what I've heard, they struggle with inexpressive code in much the same way humans do.
What do you think about the argument that we are entering a world where code is so cheap to write, you can throw the old one away and build a new one after you've validated the business model, found a niche, whatever?<p>I mean, it seems like that has always been true to an extent, but now it may be even more true? Once you know you're sitting on a lode of gold, it's a lot easier to know how much to invest in the mine.
It hasn't always been true, it started with rapid development tools in the late 90's I believe.<p>And some people thought they were building "disposable" code, only to see their hacks being used for decades. I'm thinking about VB but also behemoth Excel files.
Someone has to figure out how to make the experiences of the two generations consistent in the ways it needs to be and differ only in the ways it doesn't still.
I actually think that might actually be a good path forward.<p>I hate self-promotion but I posted my opinions on this last night <a href="https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-Pushing-AI-Generated-Code-to-Git" rel="nofollow">https://blog.tombert.com/Posts/Technical/2026/04-April/Stop-...</a><p>The tl;dr of this is that I don't think that the code itself is what needs to be preserved, the prompt and chat is the actual important and useful thing here. At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store <i>that</i> in Git.
> At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store that in Git.<p>Generating code using a non-deterministic code generator is a bold strategy. Just gotta hope that your next pull of the code slot machine doesn’t introduce a bug or ten.
We're already merging code that has generated bugs from the slot machine. People aren't actually reading through 10,000 line pull requests most of the time, and people aren't really reviewing every line of code.<p>Given that, we should instead tune the prompts well enough to not leave things to chance. Write automated tests to make sure that inputs and outputs are ok, write your specs so specifically that there's no room for ambiguity. Test these things multiple times locally to make sure you're getting consistent results.
> Write automated tests to make sure that inputs and outputs are ok<p>Write them by hand or generate them and check them in? You can’t escape the non-determinism inherent in LLMs. Eventually something has to be locked in place, be it the application code or the test code. So you can’t just have the LLM generate tests from a spec dynamically either.<p>> write your specs so specifically that there's no room for ambiguity<p>Using English prose, well known for its lack of ambiguity. Even extremely detailed RFCs have historically left lots of room for debate about meaning and intention. That’s the problem with not using actual code to “encode” how the system functions.<p>I get where you’re coming from but I think it’s a flawed idea. Less flawed than checking in vibe-coded feature changes, but still flawed.
> Write them by hand or generate them and check them in?<p>Yes, written by hand. I think that ultimately you should know what valid inputs and outputs are and as such the tests should be written by a human in accordance with the spec.<p>> Less flawed than checking in vibe-coded feature changes, but still flawed.<p>This is what I'm trying to get at. I agree it's not perfect, but I'm arguing it's less evil than what is currently happening.
Infrastructure-as-code went through this exact cycle. Declarative specs were supposed to replace manual config, but Terraform still needs state files because specs drift from reality. Prompts have it worse since you can't even diff what changed between two generation runs.
This is actually a pretty good callout.<p>Observability into <i>how</i> a foundation model generated product arrived to that state is significantly more important than the underlying codebase, as it's the prompt context that is the architecture.
Yeah, I'm just a little tired of seeing these pull requests of multi-thousand-line pull requests where no one has actually looked at the code.<p>The solution people are coming up with now is using AI for code reviews and I have to ask "why involve Git at all then?". If AI is writing the code, testing the code, reviewing the code, and merging the code, then it seems to me that we can just remove these steps and simply PR the prompts themselves.
> why involve Git at all then?<p>I made a similar point 3 weeks ago. It wasn't very well received.<p><a href="https://news.ycombinator.com/item?id=47411693">https://news.ycombinator.com/item?id=47411693</a><p>You don't actually need source control to be able to roll back to any particular version that was in use. A series of tarballs will let you do that.<p>The entire purpose of source control is to let you reason about change sets to help you make decisions about the direction that development (including bug fixes) will take.<p>If people are still using git but not really <i>using</i> it, are they doing so simply to take advantage of free resources such as github and test runners, or are they still using it because they don't want to admit to themselves that they've completely lost control?
> If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners,<p>does it have to be free to be useful? the CD part is is even more important than before, and if they still use git as their input, and everyone including the LLM is already familiar with git, whats the need to get rid of it?<p>there's value in git as a tool everyone knows the basics of, and as a common interface of communicating code to different systems.<p>passing tarballs around requires defining a bunch of new interfaces for those tarballs which adds a cost to every integration that you'd otherwise get for about free if you used git
> are they still using it because they don't want to admit to themselves that they've completely lost control?<p>I think this is the case, or at least close.<p>I think a lot of people are still convincing themselves that <i>they</i> are the ones "writing" it because they're the ones putting their names on the pull request.<p>It reminds me of a lot of early Java, where it would make you <i>feel</i> like you were being very productive because everything that would take you eight lines in any other language would take thirty lines across three files to do in Java. Even though you didn't really "do" anything (and indeed Netbeans or IntelliJ or Eclipse was likely generating a lot of that bootstrapping code anyway), people would act like they were doing a lot of work because of a high number of lines of code.<p>Java is considerably less terrible now, to a point where I actually sort of begrudgingly like writing it, but early Java (IMO before Java 21 and <i>especially</i> before 11) was very bad about unnecessary verbosity.
A series of tarballs is really unwieldy for that though. Even if you don't want to use git, and even if the LLM is doing everything, having discrete pieces like "added GitHub oauth to login" and "added profile picture to account page" as different commits is still valuable for when you have to ask the LLM "hey about the profile picture on the account page".
Yep.<p>Also, the approach you described is what a number of AI for Code Review products are using under-the-hood, but human-in-the-loop is still recognized as critical.<p>It's the same way how written design docs and comments are significantly more valuable than uncommented and undocumented source.
Entropy and path dependence are unavoidable laws of mathematics. Not even evolution can avoid them.
I think someday it will be completely unreadable for humans. Ai will have its optimized form.
AIs struggle with tech debt as much if not more than humans.<p>Ive noticed that theyre often quite bad at refactoring, also.
Because LLMs are designed as emulators of actual human reasoning, it wouldn't surprise me if we discover that the things that make software easy for humans to reason about also make it easier for LLMs to reason about.
Now with AI, you're not only dealing with maintenance and mental overhead, but also the overhead of the Anthropic subscription (or whatever AI company) to deal with this spaghetti. Some may decide that's an okay tradeoff, but personally it seems insane to delegate a majority of development work to a blackbox, cloud-hosted LLM that can be rug pulled from underneath of you at any moment (and you're unable to hold it accountable if it screws up)
Call me naive, but I don't believe that I'm going to wake up tomorrow and ChatGPT.com and Claude.ai are going to be hard down and never come back. Same as Gmail, which is an entirely different corporation. I mean, they could, but it doesn't seem insane to use Gmail for my email, and that's way more important to my life functioning than this new AI thing.
It’s also possible to sell chairs that are uncomfortable and food that tastes terrible. Yet somehow we still have carpenters and chefs; Herman Miller and The French Laundry.<p>Some business models will require “good” code, and some won’t. That’s how it is right now as well. But pretending that all business models will no longer require “good” code is like pretending that Michelin should’ve retired its list after the microwave was invented.
Are you saying Herman Miller chairs are uncomfortable?
Those high end restaurants are more like art and exploration of food then something practical like code. The only similarity is maybe research in academia. There's not real industry uses of code that's like art.
I used the extreme of the spectrum, I can’t imagine you’re arguing that food is binary good / bad? There’s a litany of food options and quality, matching different business models of convenience and experience.<p>Research in academia seems less appropriate because that’s famously not really a business model, except maybe in the extractive sense
Sometimes I think we're being argued against by LLMs. Critique of your example while missing the entire point of it.
There's no equivalent of experience and art in code. Writing code is not expressing your self, and you don't pay for pushing the limits and experimenting with it. That's what high end restaurants are along with service they provide.<p>As far as good or bad, how food is made is irreverent to the outcome if it's enjoyable.
Still, talk about "good" code exist for a reason. When the code is really bad, you end up paying the price by having to spend too more and more time and develop new features, with greater risk to introduce bugs. I've seen that in companies in the past, where bad code meant less stability and more time to ship features that we needed to retain customers or get new ones.<p>Now whether this is still true with AI, or if vibe coding means bad code no longer have this long term stability and velocity cost because AI are better than humans at working with this bad code... We don't know yet.
Not only true but I would guess it's the normal case. Most software is a huge pile of tech debt held together by zip-ties. Even greenfield projects quickly trend this way, as "just make it work" pressure overrides any posturing about a clean codebase.
Not according to some on HN. They consider it impossible to create a successful business with imperfect code. Lol
It depends on the urgency. Not every product is urgent. CC arguable was very urgent; even a day of delay meant the competitors could come out with something slightly more appealing.
See also Salesforce, Oracle, SAP
<i>Wordpress hides behind a cabinet</i>
1. "Vibe coding" is a <i>spectrum</i> of how much human supervision (and/or scaffolding in the form of human-written tests and/or specs) is involved.<p>2. The problem with "bad code" has nothing to do with the short-term success of the product but with the ability to evolve it successfully over time. In other words, it's about long-term success, not short-term success.<p>3. Perhaps most importantly, Claude Code is a fairly simple product at its core, and almost all its value comes from the model, not from its own code (and the same is true on the cost side). Claude Code is <i>relatively</i> a low stakes product. This means that the problems caused by bad code matter less in this instance, and they're managed further by Claude Code not being at the extreme "vibey" end of the spectrum.<p>So AI aside, Claude Code is proof that if you pour years and many billions into a product, it can be a success even if the code in the narrow and small UI layer isn't great.
The very definition of "vibe coding" is using AI to write software and not even look at the code it produces.
1 is definitely false right now. I gave specs, tests, full datasets, reference code to translate to an llm and still produce garbage code/fall flat on it's face. I just spent one week translating a codebase from go to cpp and i had to throw the whole thing out because it put in some horrible bugs that it could not fix even burning 500$ worth of tokens and me babysitting it. As i said it had everything at it's disposal: tests, reference impl, lots of data to work with. I finally got my lazy ass to inplement it and lo and behold i did it in 2 days with no bugs (that i know of) and the code quality is miles better than that undigested vomit. The codebase was a protocol library for decoding network traffic that used a lot of bit twiddling, flow control, huffman table compression, mildly complicated stuff. So no - if you want working non-trivial code that you can rely on then definitely don't use a llm to do it. Use it for autocomplete, small bits of code but never let the damn thing do the thinking for you.
Oh, I agree. Anthropic themselves proved that even with a full spec and thousands of human-crafted tests, unsupervised agents couldn't produce even something as relatively simple as a workable C compiler, even when the model was trained on the spec, tests, the theory, a reference implementation, and even when given a reference implementation as an oracle.<p>But my point was that I don't think the development of Claude Code itself isn't supervised, hence it's not really "vibe coded".
Still, it's probably true that Claude Code (etc) will be more successful working on clean, well-structured code, just like human coders are. So short-term, maybe not such a big deal, but long-term I think it's still an unresolved issue.
You can, but:<p>- Good code is what enables you to be able to build very complex software without an unreasonable number of bugs.<p>- Good code is what enables you to be responsive to changing customer needs and times. Whether you view that as valuable is another matter though. I guess it is a business decision. There have been plenty of business that have gone bust though by neglecting that.<p>Good code is for your own sanity, the machine does not care.
This product rides a hype wave. This is why it is crazy popular and successful.<p>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).<p>What did Viaweb's buyer do? They rewrote thing in C++.<p>If history rhymes, then buyer of Anthropic would do something close to "rewrite it in C++" to the current Claude Code implementation.
This is also why they had to release it quickly. They got the first mover advantage but if they delayed to make its code better, a competitor could have taken the wave instead of them.
I don't disagree with your general premise that eventually it'll just be rewritten, but I have to push back on the idea that Anthropic will be acquired. Their most recent valuation was $380B, and even if they wanted to be acquired (which I doubt) essentially no company has the necessary capital.
It is hard to find market shares of Viaweb and Yahoo at the time of Viaweb's purchase, the best I've found is that Viaweb was bought for 1/4 of Yahoo's net revenue at the time ($49M price/$203 net revenue in 1998). Viaweb was not profitable at the time of purchase, but it had about four people and quite modest hardware costs.<p>While there are no companies with $1.5 trillions (4*$380B) of net revenue, the difference is that Anthropic is cash net-negative, has more than 4 people in staff (none of them are hungry artists like PG) and hardware use spendings, I think, are astronomical. They are cash net-negative because of hardware needed to train models.<p>There should be more than one company able to offer good purchase terms to Anthropic's owners.<p>I also think that Anthropic, just like OpenAI and most of other LLM companies and companies' departments, ride "test set leakage," hoping general public and investors do not understand. Their models do not generalize well, being unable to generate working code in Haskell [1] at the very least.<p>[1] <a href="https://haskellforall.com/2026/03/a-sufficiently-detailed-spec-is-code" rel="nofollow">https://haskellforall.com/2026/03/a-sufficiently-detailed-sp...</a><p>PG's Viaweb had an awful code as a liability. Anthropic's Claude Code has an awful implementation (code) and produces awful code, with more liability than code written by human.
Any company worth more could (in principle) acquire it with a share swap [1]. Even a smaller company could buy it with an LBO [2].<p>[1] <a href="https://en.wikipedia.org/wiki/Stock_swap" rel="nofollow">https://en.wikipedia.org/wiki/Stock_swap</a><p>[2] <a href="https://en.wikipedia.org/wiki/Leveraged_buyout" rel="nofollow">https://en.wikipedia.org/wiki/Leveraged_buyout</a>
> ... but I have to push back on the idea that Anthropic will be acquired. Their most recent valuation was $380B, and even if they wanted to be acquired (which I doubt) essentially no company has the necessary capital.<p>isn't that pretty much why anthropic and openai are racing to IPO?
My understanding of OP was not a claim that "vibe coding doesn't work", but that the way Anthropic does it doesn't work. He seems to be specifically criticizing the "hands off the actual code, human" approach and advocating for keeping the human in the loop.
One truism about coding agents is that they struggle to work with bad code. Code quality matters as much as always, the experts say, and AI agents (left unfettered) produce bad code at an unprecedented rate. That's why good practices matter so much! If you use specs and test it like so and blah blah blah, that makes it all sustainable. And if anyone knows how to do it right, presumably it's Anthropic.<p>This codebase has existed for maybe 18 months, written by THE experts on agentic coding. If it is already unintelligible, that bodes poorly for how much it is possible to "accelerate" coding without taking on substantial technical debt.
i think you are conflating <i>anthropic (the startup)</i> with <i>claude code (the leaked source of one of said startup's products)</i><p>i.e., the <i>claude code</i> codebase doesn't <i>need</i> to be good right now [^1] — so i don't think the assumption that <i>this is an exemplary product / artifact of expert agentic coding</i> actually holds up here specifically<p>[^1]: the startup graveyard is full of dead startups with good code
This, 100x.<p>I do M&As at my company - as a cto. I have seen lots of successful companies' codebases, and literally none of them elegant. Including very profitable companies with good, loved products.<p>The only good code I know is in the open source domain and in the demoscene. The commercial code is mostly crap - and still makes money.
What I'm missing so far is how they produced such awful code with the same product I'm using, which definitely would have called out some of those issues.<p>Perhaps the problem is getting multiple vibe-coders synced up when working on a large repo.
Code quality is a tactical concern and products live or die on strategy.<p>I wouldn't recommend neglecting tactics if your strategy doesn't put you on the good side of a generational bubble though.
It kind of reminds me of grammar police type personalities. They are so hung up on the fact it reads “ugly” they can’t see the message; this code powers a rapidly growing $400B company. They admit refactoring is easy, but fail to realize they probably know that too and it’s just not a priority yet.
They won’t stay 400B for long, and Claude Code will have no effect on that.
> <i>And as for the critics, tell me I don't get it</i><p>> <i>Everybody can tell you how to do it, they never did it</i><p>> —jay-z
The underlying model powers the valuation.<p>Not the front end
It works, it is popular, sure. Claude's code may be barely old enough to have suffered through its true long-term maintainability problems. They probably also haven't had a lot of rotation/attrition in their staff.
You can send a submarine down to crushing depths while violating all the traditional rules about "good" engineering, too.
Not AI but perfect example is Cloudflare. They have implemented public suffix list (to check if a domain is valid) 10 different times in 10 different ways. In one place, they have even embedded the list in frontend (pages custom domain). You report issues, they fix that one service, their own stuff isn't even aware that it exists in other places.
Meta has four different implementations of the same page to create a “page” for your business… which is required to be able to advertise on any of their services.<p>Each one is broken, doesn’t have working error handling, and prevents you from giving them money. They all exist to insert the same record somewhere. Lost revenue, and they seem to have no idea.<p>Amazons flagship ios app has had at least three highly visible bugs, for <i>years</i>. They’re like thorns in my eye sockets, every time I use it. They don’t care.<p>These companies are working with BILLIONS of dollars in engineering resources, unlimited AI resources, and with massive revenue effects for small changes.<p>Sometimes the world just doesn’t make sense.
It's just lazy engineering. They get assigned a task, they must implement it or fix it to keep their job. Proper implantation takes more knowledge, more research and more brain pressure.<p>AI could play a big rule here. Husky (git hook) but AI. It will score lazy engineering. You lazy implement enough times, you loose your job.
I just can’t wrap my head around it.<p>Maybe there’s a reason Netflix makes you click on the ONE user profile on the account, repeatedly, even if it feels like sheer stupidity to their users. At least it’s not costing them revenue, directly.<p>Amazons ios app not properly handling state change after checkout, for years? Probably not directly costing them millions. Only second order disengagement.<p>But Walmart keeps pushing a thing you don’t want, because you looked at it once? Amazon solved this. It’s not a major fix, and it’s using a valuable slot that costs them money. Walmart just doesn’t fix it.<p>Meta refusing to take people’s advertising dollars because ALL of their page creation pages have unhandled breaking flows in them? That’s lost money for no reason at all. And you’re telling me they don’t realize how janky it is to try to maintain four implementations of that?<p>Apple App Store Connect and Ads platform? Don’t get me started.<p>Again, all with unlimited pools of the smartest people on earth, unlimited AI, and a billion people testing for them…
I mean, the core issue here is that proper engineering just isn't valued.<p>Social capital just isn't given out to people that fix things in a lot of these companies, but instead those who ship a 1.0a.<p>On the management/product side, the inevitable issues are problem for another quarter. On the engineering side, it's a problem for the poor shmucks who didn't get to jump to the next big thing.<p>Neither of those groups instructionally care about the mess they leave in their wake, and such guardrails they'd perceive as antithetical to releasing the next broken but new, fancy feature.
they prioritize bugs based on what impacts the largest amount ($) of customers — fixing every bug of a huge complex project rarely makes sense if the impact of the bug on revenue is tiny
It helps if the product is so revolutionary that people are willing to overlook bugs. Could you imagine a more mundane product with a TUI that flickered all the time where this wouldn't be a showstopper? I believe the bug is fixed now, but it seems crazy that it persisted so long given how obvious the cause was (clear before update). How many more bugs are in CC? As of a few weeks ago there were 5000 or so open issues against it on github.<p>The success is undeniable, but whether this vibe-coded level of quality is acceptable for more general use cases isn't something you can infer from that.
Yes, that is how Facebook, Yahoo and many other companies started out. But they rewrote their code when it became to big to be maintainable. The problem with shoddy code is not necessarily that it doesn't work but that it becomes impossible to change.
Makes me stare at mid nineties After Effects’ core rendering engine
ehh, as long as the overall starting architecture is decent, it's not hard to do tiny refactors across components<p>claude code, the app, is also not some radically complex concept (even if the codebase today is complicated)<p>but hey, that's why people do version breaking rewrites
I'd imagine the AI engineers on million dollar TC are not vibe coding the models though, which is the actual sauce.
It basically shifting work to future people. This mess will stop working and will introduce unsolvable obscure bugs one day, and someone actually will have to look at it.<p>It already costed many developers months and hundreds of dollars worth of tokens because of a bug. There will be more.
99.999999% of products can't get away with what Anthropic is able to - this is a one in a billion disruptive product with minimal competition, and its success so far is mostly due to Claude the model, not the agent harness
> <i>It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.</i><p>We already knew that. This is a matter of people who didn't know that or didn't want to acknowledge that thinking they now have proof that it doesn't matter for creating a crazy popular & successful product, as if it's a gotcha on those who advocate for good practices. When your goal is to create something successful that you can cash out, good practices and quality are/were never a concern. This is the basis for YAGNI, move-fast-and-break-things, and worse-is-better. We've know this since <i>at least</i> betamax-vs-VHS (although maybe the WiB VHS cultural knowledge is forgotten these days).
WiB is different from Move Fast and Break Things and again different from YAGNI though.<p>WiB doesn't mean the thing is worse, it means it does less. Claude Code interestingly does WAY more than something like Pi which is genuinely WiB.<p>Move Fast and Break Things comes from the assumption that if you capture a market quick enough you will then have time to fix things.<p>YAGNI is simply a reminder that not preparing for contingencies can result in a simpler code base since you're unlikely to use the contingencies.<p>The spaghetti that people are making fun of in Claude Code is none of these things except maybe Move Fast and Break Things.
VHS was not worse is better. It’s better is better.
Specifically, VHS had both longer recording times and cheaper VCRs (due to Matsushita’s liberal licensing) than Betamax did. Beta only had slightly better picture quality if you were willing to sacrifice recording length per tape. Most Betamax users adopted the βII format which lowered picture quality to VHS levels in order to squeeze more recording time onto the tape. At that point Betamax’s only advantage was a slightly more compact cassette.<p>Also to correct another common myth, porn was widely available on both formats and was not the cause of VHS’s success over Betamax.
Betamax was arguably better.<p><a href="https://en.wikipedia.org/wiki/Videotape_format_war" rel="nofollow">https://en.wikipedia.org/wiki/Videotape_format_war</a>
Not in ways that the market cared about.
Arguably better quality, but at the cost of being shorter. In the great trade off of time, size, and quality, I think VHS chose a better combination.
It depends which definition of "better" you use. VHS won the adoption race, so it was better there. While Betamax may have been technologically superior, in hindsight we can say it apparently failed to address other key aspects of the technology adoption lifecycle.
TBH Claude Code is surprisingly shit to use given the technical resources and the amount of money behind it. Looking past the bugs and missing features, it's so obvious it's not built by people who care about the product from a developer/craftsman perspective. It's missing all the signs of polish/care, it feels like someone shipped an internal PoC to prod and kept hacking on it. And now they are just tacking on features to sell more buzzwords and internal prototypes. Classic user facing/commercial software story.<p>But we (the dev community) are kind of spoiled, because we have a lot of great developer tools that come from people passionate about their work, skilled at what they do and take pride in what they put out. I don't count myself among one of those people but I have benefited from their work throughout my career and have gotten used to it in my tooling.<p>All that being said Opus is hands down the best coding model for me (and I'm actively trying all of them) and I'll tolerate it as long as I can get it to do what I need, even with the warts and annoyances.
> TBH Claude Code is surprisingly shit to use given the technical resources and the amount of money behind it.<p>What harness would you recommend instead?
> TBH Claude Code is surprisingly shit to use given the technical resources and the amount of money behind it. Looking past the bugs and missing features, it's so obvious it's not built by people who care about the product from a developer/craftsman perspective. It's missing all the signs of polish/care, it feels like someone shipped an internal PoC to prod and kept hacking on it.<p>I don't wholly disagree, but personally it's still the tool I use and it's <i>sort of fine</i>. Perhaps not entirely for the money that's behind it, as you said, but it could be worse.<p>The CLI experience is pretty okay, although the auth is kinda weird (e.g. when trying to connect to AWS Bedrock). There's a permission system and sandboxing, plan mode and TODOs, decent sub-agent support, instruction files and custom skills, tool calls and LSP support and all the other stuff you'd expect. At least no weird bugs like I had with OpenCode where trying to paste multi-line content inside of a Windows Terminal session lead to the tool closing and every next line getting pasted in an executed in the terminal one by one, that was <i>weird</i>, though I will admit that using Windows feels messed up quite often nowadays even without stuff like that.<p>The desktop app gives you chat and cowork and code, although it almost feels like Cowork is really close to what Code does (and for some reason Cowork didn't seem to support non-OS drives?). Either way, the desktop app helps me not juggle terminal sessions and keeps a nice history in the sidebar, has a pretty plan display, easy ways of choosing permissions and worktrees, although I will admit that it can be sluggish and for some actions there just aren't progress indicators which feels oddly broken.<p>I wonder what they spend most of their time working on and why the basics aren't better, though to Anthropic's credit about a month ago the desktop Code section was borderline unusable on Windows when switching between two long conversations, which now seems to take a few seconds (which is still a few seconds too long, but at least usable).
The most obvious sign to me from the start that somebody wasn't really paying attention to how the Claude app(s) work is that on iOS, you have to leave the app active the entire time a response is streaming or it will error out.
I never saw that bug, I don't think, but there was one where it had to <i>start</i> the response before you switched away. That's thankfully been fixed for a few weeks.
That has never happened to me. Did you try that a long while ago? I only had that issue with Gemini
Don't worry, the Gemini website does the same, at least on Firefox mobile. You switch apps and you lose the response AND the prompt.<p>Normally some software devs should be fired for that.
Isn't Anthropic basically a bunch of AI PhDs writing code? I'd imagine they had to be dragged kicking and screaming into actual software engineering.
Yes that plus having tens of billions of gulf money certainly helps you subsidize your moronic failures with money that isn't yours while you continue, and fail to, achieve profitability in any time horizon within a single lifespan.
Also Claude owes its popularity mostly to the excellent model running behind the scenes.<p>The tooling can be hacky and of questionable quality yet, with such a model, things can still work out pretty well.<p>The moat is their training and fine-tuning for common programming languages.
>> Also Claude owes its popularity mostly to the excellent model running behind the scenes.<p>It's a bit of both. Claude Code was <i>the</i> tool that made Anthropic's developer mindshare explode. Yes, the models are good, but before CC they were mostly just available via multiplexers like Cursor and Copilot, via the relatively expensive API.
Huh what moronic failure did Anthropic do? Every Claude Code user I know loves it.
I don’t know about moronic, but:<p><a href="https://github.com/ctoth/claude-failures" rel="nofollow">https://github.com/ctoth/claude-failures</a><p><a href="https://github.com/anthropics/claude-code/issues/42796" rel="nofollow">https://github.com/anthropics/claude-code/issues/42796</a>
I don't know if the comment was referring to this, but recently, people have been posting stuff about them requiring their new hire Jared Sumner, author of the Bun runtime, to first and foremost fix memory leaks that caused very high memory consumption for claude's CLI. The original source was them posting about the matter on X I think.<p>And at first glance, none of it was about complex runtime optimizations not present in Node, it was all "standard" closure-related JS/TS memory leak debugging (which can be a nightmare).<p>I don't have a link at hand because threads about it were mostly on Xitter. But I'm sure there are also more accessible retros about the posts on regular websites (HN threads, too).
Recently there was a bug where CC would consume day/week/month quota in just a few hours, or hundreds of dollars in API costs in a few prompts.
I've used and hate it, it's garbage.
The people who don’t love it probably stopped using it.<p>You don’t have to go far on this site to find someone that doesn’t like Claude code.<p>If you want an example of something moronic, look at the ram usage of Claude code. It can use gigabytes of memory to work with a few megabytes of text.
There’s a sample group issue here beyond the obvious limitations of your personal experience. If they didn’t love it, they likely left it for another LLM. If they have issues with LLM’s writ large, they’re going to dislike and avoid all of them regardless.<p>In the current market, most people using one LLM are likely going to have a positive view of it. Very little is forcing you to stick with one you dislike aside from corporate mandates.
There is right now another HN thread where a lot of users hate Claude Code.<p>To be fair, their complaints are about very recent changes that break their workflow, while previously they were quite content with it.
There have certainly been periods of irrational exuberance in the tech industry, but there are also many companies that were criticized for being unprofitable which are now, as far as I can tell, quite profitable. Amazon, Uber, I'm sure many more. I'm curious what the basis is to say that Anthropic could never achieve profitability? Are the numbers that bad?
your prediction is going to be wrong, even with all those caveats
> <i>It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.</i><p>A lot of dollars fix a lot of mistakes.
devaluing craftsmanship is fundamentally insulting.
It's also crazy more expensive to run than we thought. That doesn't bode well when their loss-leader period is over and they need to start making money.
"Wildly successful but unpolished product first-to-market with a new technology gets dethroned by a competitor with superior execution" is a story as old as tech.
It is amazing how much malice did author put into proving the world is stupid, and only few still stand guard of reason.
There's also a business incentive for code produced by LLM companies to be hard to maintain. So you keep needing them in the future.
Because or in spite of? Claude code works because of Claude being good and network effects. Agentic coding tools are maybe the dumbest code ever for the level of popularity they have.
Also, many of the complaints seem more like giddy joy than anything.<p>The negative emotion regex, for example, is only used for a log/telemetry metric. Sampling "wtf?" along would probably be enough. Why would you use an agent for that?<p>I don't see how a vibe-coded app is freed from the same trade-offs that apply to a fast-moving human-coded one.<p>Especially since a human is still driving it, thus they will take the same shortcuts they did before: instead of a formal planning phase, they'll just yolo it with the agent. Instead of cleaning up technical debt, they want to fix specific issues that are easy to review, not touch 10 files to do a refactor that's hard to review. The highest priority issues are bugs and new integrations, not tech debt, just like it always was.<p>This is really just a reminder of how little upside there is to coding in the open.
I think the thing is that people expect one of the largest companies in the world to have well written code.<p>Claude’s source code is fine for a 1-3 person team. It’s atrocious for a flagship product from a company valued over $380 BILLION.<p>Like if that’s the best ai coding can do given infinite money? Yeah, the emperor has no clothes. If it’s not the best that can be done, then what kinda clowns are running the show over there?
The difference here is that everyone else in this product category are also sprinting full steam ahead trying to get as many users as they can<p>If they DIDN'T heavily vibe-code it they might fall behind. Speed of implementation short term might beat out long-term maintenance and iteration they'd get from quality code<p>They're just taking on massive tech debt
> If they DIDN'T heavily vibe-code it they might fall behind<p>For you and I, sure - sprint as fast as we can using whatever means we can find. But when you have infinite money, hiring a solid team of traditional/acoustic/human devs is a negligible cost in money and time.<p>Especially if you give those devs enough agency that they can build on the product in interesting and novel ways that the ai isn’t going to suggest.<p>Everything is becoming slop now, and it almost always shows. I get why when you’re resource constrained. I don’t get why when you’re not.
I just think this is the nature of all software, and it was wrong to assume AI fundamentally changes it.<p>Seems like you're also under the impression that privately developed software should be immaculate if the company is worth enough billions, but you'd be wrong about that too.
I mean, that’s probably part of it. Many times when I have gotten a glimpse under the hood of load-bearing parts of the economy / technology i have been shocked by the mess that i see. Xkcd #2347 is somewhat applicable here. But the trend towards vibe coding is making the cracks in the surface bigger. Like, think why do we even have access to Claude’s source code?
Yes, you would expect a company paying millions in TC to the best software developers on the planet could produce a product that is best in class, and you would get code quality for free. Except it's regularly beaten in benchmarks and user validation by open source agents, some built by a single person (pi), with horrible code quality leading to all sorts of bad UX and buggy behaviour.<p>Either they're massively overpaying some scrubs to underperform with the new paradigm, or they are squeezing every last drop out of vibe coding and this is the result.
I read this posts and I wonder how many people are thisdelusional or dishonest. I am programmer for 40 years and in most companies 90% of coders are so called stack overflow coders or google coders. Every coder who is honest will admit it and AI is already better than those 90%.FAR better.
At least most influencer coder start to admit the fact that the code is actually awesome, if you know what you are doing.
I am more of a code reviewer and I plan the implementation, what is far more exciting than writing the code itself. I have the feeling most feel the way I do but there are still those stack ovwerflow coders who are afraid to lose their jobs. And they will.
While beeing in the center of a hype vortex which basically suspends market physics. But all that bad code eats serverfarms that are going to cost double when the bubble starts deflating.
The model is the product.<p>It shows that you can have a garbage front end if people perceive value in your back end.<p>It also means that any competitor that improves on this part of the experience is going to eat your lunch.
Do we know if the original code was vibe coded? It's like chicken and an egg dilemma.
Its a buggy pos though, "popular and successful" have never been indicators of quality in any sense.
I think this is a pretty interesting comment because it gets to the heart of differing views on what quality means.<p>For you, non-buggy software is important. You could also reasonably take a more business centered approach, where having some number of paying customers is an indicator of quality (you've built something people are willing to pay for!) Personally I lean towards the second camp, the bugs are annoying but there is a good sprinkling of magic in the product which overall makes it something I really enjoy using.<p>All that is to say, I don't think there is a straightforward definition of quality that everyone is going to agree on.
ok, well if youd like to trade in 14billion dollars of revenue for better quality feel free.
I think you're all fucking crazy. Or maybe I am?<p>I can literally see my teams codebase becoming an unmaintainable nightmare in front of my eyes each day.<p>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.<p>I probably get to the solution in the same time when all is said and done.<p>Honestly what is going on. What are we doing here?
Honestly for such a powerful tool, it’s pretty damn janky. Permissions don’t always work, hitting escape doesn’t always register correctly, the formatting breaks on its own to name a few of the issues i’ve had. It’s popular and successful but it’s got lots of thorns
I think it is crazy popular for the model and not the crappy vibe code.
Value to customer. Literally the only thing that matters.
Value isn't a one-shot, though. <i>Value sustained over time</i> is what matters.<p>Well, if unmaintainable code gets in the way of the "sustained over time" part, then that is still a real problem.
Hardly. Claude Code is basically just a wrapper around an LLM with a CLI.<p>Obviously it does some fairly smart stuff under the hood, but it's not exactly comparable to a large software project.<p>But to your point, that doesn't mean you can't vibe code some poorly built product and sell it. But people have always been able to sell poorly built software projects. They can just do it a bit quicker now.
This is a really wrong perspective on software. Short term monkey style coding does not produce products. You might get money but that is not what it is about.<p>This is similar to retarded builders in Turkey saying “wow, I can make the same building, sell for the same price, but spend way less” and then millions of people becoming victim when there is an earthquake.<p>This is not how responsible people should think about things in society
> This is a really wrong perspective on software. Short term monkey style coding does not produce products. You might get money but that is not what it is about.<p>Getting money is 100% what it is about and Claude Code is great product.
Nobody rewards responsibility though. It's all about making number go up.
> This is a really wrong perspective on software. Short term monkey style coding does not produce products. You might get money but that is not what it is about<p>You're not alone in thinking that, but unfortunately I think it's a minority opinion. The only thing most people and most businesses care about is money. And frankly not even longterm, sustainable money. Most companies seem happy to extract short term profits, pay out the executives with big bonuses, then rot until they collapse
There is already lots of popular software that is violates any concept of good software. Facebook messenger, instagram, twitter, minecraft, balena etcher, the original ethereum wallet, almost anything that uses electron...
We are all using Claude despite Claude Code. The day ChudCorp releases a superior model Chud, we are all gone in an instant. There is no moat.
Except for the part where it's constantly having quality and reliability issues, even independent of the server-side infrastructure (OOMs on long running tasks, etc).
I found that to be true years ago when I spooled the source of the Twitch leaks.<p>To me it said, clearly: nobody cares about your code quality other than your ability to ship interesting features.<p>It was incredibly eye-opening to me, I went in expecting different lessons honestly.
> It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.<p>That was always the case. Landlords still want rent, the IRS still has figurative guns. Shipping shit code to please these folks and keep the company alive will always win over code quality, unless the system can be edited to financially incentivize code quality. The current loss function on society is literally "ship shit now and pay your taxes and rent".
>. It shows that you can build a crazy popular & successful product while violating all the traditional rules about “good” code.<p>The product is also a bit wonky and doesn't always provide the benefits it's hyped for. It often doesn't even produce any result for me, just keeps me waiting and waiting... and nothing happens, which is what I expect from a vibe coded app.
[dead]
Yes, just get hundreds of billions of dollars in investments to build a leading product, and then use your massive legal team to force the usage of your highly subsidised and marketed subscription plan through your vibe coded software. This is excellent evidence that code doesn't matter.
> Yes, just get hundreds of billions of dollars in investments to build a leading product, and then use your massive legal team to force the usage of your highly subsidised and marketed subscription plan through your vibe coded software.<p>What? Your comment makes absolutely zero sense. Legal team forces people to use Claude Code?
Claude Code is the only coding harness you're allowed to use with fixed-price subscriptions as opposed to PAYGO API access. There's also rumors that the subscriptions are heavily subsidized compared to API, or at least cross-subsidized to the effect that the heaviest users of Claude Code (controlling for subscription level) end up paying vastly lower unit prices for their token use. These restrictions are enforced legally.
I know this isn't your point, but Anthropic has raised about $70 billion, not "hundreds of billions".<p>And they don't need a massive legal team to declare that you can't use their software subscription <i>with other people's software</i>.
I don't think anyone who used Claude code on the terminal had anything good to say about it. It was people using it through vs code that had a good time.
I have used Claude Code in the terminal to the tune of ~20m tokens in the last month and I have very little to complain about. There are definitely quirks that are annoying (as all software has, including vs code or jetbrains IDEs) but broadly speaking it does what it says on the tin ime
I prefer using it via the terminal. Might be anchoring bias, but I have had issues with slash commands not registering and hooks not working in the plugin.