YHK - yet another hacker news clone

Is this "allow" or "encourage"? If "allow", how do you do that deterministically or at least fail-closed?

Suppose that subsidies lead to the price of Ubers falling close to zero, with drivers also being incentivized to drive more to support the (artificial) increase in demand -- artificial because it is driven by subsidies funded by new money creation. Traffic increases and in response, new roads are built.

It’s more likely they used an earlier version of Claude to write v1, then a later version of Claude rewrote it.

Unless Anthropic engineers were writing code by hand prior to Mythos

Maybe that'll change in the future, but while AI can make awesome images without a good "director" they're pretty cookie-cutter and bland.

A 10 minute CI pipeline is great and fine, but everyone absolutely cares if you can bring it down to 30 seconds. This software, by its very nature, is measured by speed.

As many of you know, I'm a big fan of jj. The jj project used to have a comparison to Pijul for informational purposes, but the Pijul folks took offense, and so it was removed: https://github.com/jj-vcs/jj/commit/0525dc9d860a5fff6a97d134...

As such, I generally just decline to comment on Pijul, as I want to be respectful of them. As the linked commit says, it's not super clear what exactly they do not like, and so I don't want to accidentally cross some line.

In general I wish the project well, seeing a new VCS in Rust is very cool.

Some are already public, like my replacement of Nix (https://nest.pijul.com/elpe/elpe). Others aren't public yet, but are even much bigger in terms of scope and difficulty.

It seems Anthropic didn't understand the difference between a distributed file system and version control. They should have asked Claude ;-)

> if the vibe coding idiots like it,

The organizations that have these problems are general large enterprises, not vibe coders. Large enterprises are more used to talking to people and do not make decisions solely based on the contents of a web page.

Tangled is doing the social coding thing, and they're jj-native as well. Been a big fan of their work for a while now.

I have not personally considered that, no. I'm a bit skeptical of the idea, as you'd need to understand a lot of different things, and at different versions of those things, in high fidelity. But maybe someone will make it work.

I think one thing is consistent across all of these visualizations: they moved the needle. Hard to say what that needle points at or where the redline is, but fleet change is afoot.

It can be cheaper to do a full clone than a shallow one, because with the shallow one, you can't re-use packfiles. GitHub has fairly regularly asked people to stop doing shallow clones because it's harder on their servers than full ones.

What a weak response, just release the version you use and others will decide if it's useful.

ref: https://news.ycombinator.com/item?id=49768575

This is one of the core reason that I dislike the LLM hyping. People are just reinventing stuff and when you ask them, it's actually a very subjective reason. Ok, anyone can do what they want with their time, the issue is that they want people to follow in their steps.

Not saying that you need a novel idea to be worthy, but those random projects have no guarantees behind them other than some cursory testing. All software have bugs, but I can't interact with something that is randomly built.

That used to be called "time wasting". If you want to build software that will be used, you need to interview the users. Maybe a few things does require research to nail things right. But most software are user-facing, the research side is about optimization.

> Most things are becoming the understand the problem "shape".

Then should we be so reluctant about "trialing" invented solutions. It's the same thing with most AI projects, they're trying to justify the project after the facts while being very reluctant to get user insights.

My suspicion is that this simply won't go away as the models get better, because it isn't a question of how good the models are. It's a question of the human operators knowing exactly what they want. Which is, I conjecture, usually impossible until you try something and critique it properly.

- they have implementation cost.

- they are usually born from arrogance mixed with lack of understanding of existing solutions and their tradeoffs, and typically end up being a net negative.

Before LLMs, the cost is what primarily used to stop us from building them, it used to be a natural filter for bad ideas. Now that the cost is gone, it's nearly impossible for most teams to stay disciplined and not be building those.

Why wouldn't you build a software factory? If you succeed, the ROI is infinite. Who cares about immediate customer needs, we're building a utopia here. Once it's done, all customer needs will be solved. Just one more month, I promise.

In the early/mid 2010s there was a similar hysteria about "deployments per day/week" metric. People were comparing products or teams by saying "My team deploys twice a week", "oh, yeah? we deploy 3 times a day". People viewed the north star of the CD part in CI/CD as pushing to production. The concept was simple, you push your code to main. CIs start churning, deploying it to test environments, then promoting it to staging, the pre-prod, then into blue/green prod deployment, then into prod. All automated, all touchless, happening on every merge, 5-10 times a day. That's engineering efficiency.

Many tried to follow that. It works great if your project is a Jekyll blog of course.

https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExbmt6M2FkMW...

Here is the prompt they can use:

Comvert this repo to a platform specific binary that's hyper performant. Make no mistakes.

Also, as tech companies grow, a significant portion of the dev body count is for internal tooling. I was always flabbergasted at Twitter's headcount growth back in the day when it seemed like the only innovation increasing the number of characters in a tweet.

Right now we are in a weird spot where a lot of people are flailing around inside corporate America trying to figure out how to leverage AI. Few have enough vision to see what the companies of the future will look like and work towards that.

I don't use Anthropic products at all, so I was not really sure myself but apart from the models they pretty much only have Claude Code afaik.

And now they're publishing a blog post about writing their own vcs because they have 30000 commits a day. For what? Isn't Claude still based on react?

Do they need this many commits just for claude? Or is that about the model, do they develop that much extra internal tooling?

I admit it is very much possible I am wrong, but without further information this seems a bit like a red flag to me.

I do think that the lgtm gut feel looking at a PR requires quite some years of writing code and reason about it, so not sure how a junior can get that intuitive understanding if they start with agentic coding however.

But regarding the compute, I disagree a bit. I think the bottlenecks were cognition and ideas, not compute. Given that models are able to outperform humans in output by thousand folds, the differentiation would be the quality of the tokens produced and the ability to scale across different domains.

If they have enough compute to supply the entire globe, I'm sure they can redirect some of it to whatever use case they (or their super AI) deem worthy and loop on it, and if they have the best software engineering systems/methodology to build and release it, then they can out compete any other supplier without those resources.

We are already seeing single developers attempting to rebuild entire corporations history worth of output. We are also seeing the labs dumping hundreds of solutions to math problems.

All the others seem necessary. Maybe you don't need branches at all, of course we do! Things have to have names.

This is true, but at 30,000 merges a day we're talking about nearly 1 million merges a month, and purely autonomous agentic merges tend to be noisy. Is this still a tractable problem, even for an agent? Do revisions older than a few days, other than perhaps release snapshots, have any relevance for such a process?

This is a great idea, now they just have to use/do it. Maybe they can use it effectively by cloning the repo and having all the history at hand, rather than continuously scraping web pages with git content formatted for human brwosing.

most of the harnesses are checkpointing most of the data of a git commit aside from the formal release and messaging, anyway; thats why they all have a similar problem with SQL dbs exploding in size after a bit of time.

Right now we're in this weird transition where most of the harness systems are layering git tool use w/ the constant snapshotting AND a memory subsystem often, probably leaves a lot on the table in saving wasted token use to just ditch the vcs all together and rely on the already persistent and existent checkpoints and memories for reconstruction.

Or code comments which they are already doing a lot of. I used to get annoyed by their verbose comments but at this point I've seen them help a few times and it's not like I'm actually maintaining the code myself anymore so it doesn't really bother me

We built all this tooling because it's useful. If you replace the human with an agent the tooling doesn't stop being useful. If anything it becomes more useful, since AI Agents excell at reading tool output but struggle with maintaining long-term state

I'm not saying that Anthropic here close their eyes and tell Claude to ship and that in the future there will be no code review at all, but that if we have 30K merges/day, human review seems to need to be done at some higher level, likely AI assisted like it seems to be done with their Antique code review tool mentioned in the post.

I might be completely out of context, but why is it only 4x compression? Do they commit a lot of binaries? I just don't understand why would code compress so badly.

Gives me a vaguely creepy feeling, but it's reasonable.

For how the Linux Kernel, a highly decentralized, completely open source project, with a single monotonic product, tyrannically lead (a good thing) - is developed.

Permissions, Partial Checkouts, Sub Repos, Vendoring, pub/sub... How many companies bought into git and then had to buy more tooling (like artifactory) because their 3rd party dependency's needed a home. Thats a feature that git does not support because git, as designed, did not need it.

Think about how much better your life would be if every time you typed npm,pip,goget,cargo it fetched THROUGH your repo. If those updates triggered code reviews of whatever changes you're going to consume. You are code reviewing those updates aren't you (someone is, cause supply chain attacks don't last that long)

Git has some weak points, Google doesn't use it for a reason. Epic created lore for a reason, This exists for a reason. Im not sure that any of them are the next thing that replaces GIT but it's getting to be time. Tools like this are going to keep popping up till someone gets it right.

There are orgs that are moving to not including names at all as the next step on that trajectory.

Does it, though?

What problem do they actually have that requires redesigning a whole new vcs?

Merge conflicts? That's not exactly a vcs problem but a "we changed the same code at the same time" problem. No tooling on earth eliminates the need to verify conflict resolutions if agent A renames int foo to int bar while agent B renames int foo to int baz.

Growing repo size? They should take a long hard look at what they are doing. How is their software architected? Is every single little change and half-baked AI churn commit pushed to the main repository, or does the main repo only receive the deliverable? Is everything under the sun tracked in a mono repo or are projects stored independently?

Do they take any precaution at identifying churn and taking steps to minimize it?

Frankly, this reads like a bullshit PR stunt, much like the bullshit curl vulnerability findings. They have a self-inflicted problem, and their solution is to persist the problem and mitigate the problems by rolling out ad-hoc tooling? It reads like "if all you have is a hammer" kind of situation.

This doesn't make everything secure. It turns the universe into what we see in Star Trek, where everything is hackable all the time by everyone just by trying hard enough, or, in the real world, spending enough. A lot of the utility of hacking systems can be obtained in running off with the data so the inability to use a break tomorrow is not necessarily a problem, especially if I just ask my magic code fairy for another break tomorrow and the remote system has, to a first approximation, learned nothing from the previous breach as it busily churns away.

This is not the way. In fact for secure software I'd happily testify in court as an expert witness that this would be criminal negligence.

As for how closely it matches what Anthropic is doing, no comment. I'd need a lot of time to look at that and decide. That they can write code easily I do not question, whether they have 100GB of problems or 2GB of problem and 98GB of garbage that is slowing down even their AIs is not something we can get from a happy PR puff piece. I'm just speaking to the idea of letting code mutate wildly and constantly.

A big motivator of thinking architecture through really well is that although the software may work just fine now, a good architecture will make it easy to add a feature a year from now, whereas a bad architecture will necessitate significant rewriting.

But significant rewriting is cheap nowadays, so in code reviews I put a lot more weight on whether it works today, and a lot less weight on whether we'll need to change it when making a different change.

Entire classes of things like "should this be in this component or split out into its own" just don't matter anymore because no matter how tedious changing that might be once there's a ton of things depending on it, that's the kind of thing AI can do no problem.

a proper git, my things:

itostr->iToaster

It seems to me like the AI labs are just pushing the envelope with blind faith that”something” will happen if they just get enough development speed. Nobody seems to have a coherent idea of what that something is.

Yeah I wish this whole energy was towards optimization and improving hardware.

One thing that people are finding hard to believe is that the frontier labs are cultists who want to "create god". Hence the focus on improving intelligence so they can get to recursive AI, as well as the fear-mongering.

Aanthropic-openAI duo cannot go bankrupt soon enough. This industry is going to flourish with those two out of the picture. They're the pets.com of 1999 trying to have a say how the internet should be.

All that busy work was for going from zero revenue to $50B in revenue in about 3 years, and releasing AI systems that are getting better and better at a ridiculous rate. AI isn't solving all the world's problems but you can't deny that they are extremely successful with this method of operating.

"A world where starting is incredibly easy and finishing is more complicated than ever"

LLM's do allow you to oneshot huge starting bits of work in record short time. The frontier of the amount of work they can oneshot is clearly getting larger and larger. But I am still not convinced that they allow you to maintain existing work at a cost that is below a human being.

But, if the frontier of what you can oneshot continues to grow unbounded, then it really will not matter. We will eventually oneshot all software and maintenance will be a thing of the past.

... But that is a very big bet.

Who decides what the "real problems" are?

Imo most of the economy and wealth creation is around activity that is not solving a "real problem", but who am I to say if someone else is willing to pay for it? Presumably, for said person, the problem is "real" enough.

"Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative."

"Don't be snarky."

https://news.ycombinator.com/newsguidelines.html

There's plenty of room for thoughtful criticism and skepticism in HN threads, including the present one, but please don't post like this.

i really don't want to brick my camera, so the deterministic emulator stack lets me do integration tests end-to-end. if i was doing this by hand with no ai, i'd probably have to run stuff on the camera just to test it. but because ai, i get deterministic simulation testing, at the cost of needing to burn $100 of subscription on it.

ai code is more like clay you gotta continuously keep shaping over time, but you can also get very very far, very quickly if you decide the code itself doesn't matter and all you care about is results.

What does that remind me of?

The input to this is not just the preexisting code, the prompt you provide, and some random seeds. It’s also the output from every single tool invoked, which means you need to record the state of every single tool and every file that was read, every API that was called. It means that you can’t upgrade Claude. It means that you can’t upgrade the compiler. If you change anything in the state of the world you no longer have replicability.

Aside from all that, I don’t know why you would want this anyway. Storing a bunch of prompts doesn’t seem to actually gain anything even if it worked.

Bad analogy, cause this is not how tooling works. Tools beget more tools - there's value in specifying "these are the sets of tools we need to make", but unlocking new capabilities doesn't happen unless you... make the tools. And use them. And keep them stable. And watch them break, or become obsolete, and build on top of that. The world has state and path dependent.

If LLMs were deterministic, like compilers, you would have a point.

And by the way things are done at this company, it's almost a given their whole codebase are litter'd with embarassing shit like hardcoded paths, server secrets, weirdo comments picked up from some random chat context and immortalized through Claude speak, etc. There's no way they'd be able to open source anything.

But all of this is besides the point -- the product was never a source control system (who cares about that anymore?), the product is _the narrative_. It does not matter if everything withers and dies as long as the narrative survives, and by that measure I'd say the goal has been achieved.

Most big tech have a lot of stuff around SDLC that’s theirs and they couldn’t realistically release it given how specific its deployment, configuration and management is. The marginal benefit to generalizing it is so low that it’s negative.

This is almost certainly worse given the vibed out state of it.

And actually, the lack of an artifact server and some sort of proper knowledge of compatibility requiring a CI pull across hundreds of different projects with every merge is probably the explanation. Seems like there is an innovation waiting to happen there.

However, I can tell you someone who fits all those criteria: Levi Strauss. Strauss founded a company to sell dry goods, as well as tents and jeans, and eventually specialized in those denim jeans. Levi Strauss became a household name and an enduring success of the Gold Rush.

Therefore, I say that this motto is flawed; so let's correct it: "In a gold rush, sell the work clothes!"

The good ones do.

Citadel Securities, Renaissance, Jane Street, HRT, Jump, consistently do 50%+ annual returns over the past 15-20 years. They obviously don’t accept outside investor money.

Now, hedge funds that accept outside money like DE Shaw, Bridgewater and shit, yeah, they barely outperform S&P500 after their fees.

Then at the bottom, you have financial advisors who underperform S&P500 after their fees, but these advisors provide emotional support, so that’s what you’re paying for.

Because fees as a manager of someone else’s money can be higher than the full amount of the returns if it were just your own money.

Fees on someone else’s capital: 1% of 20% of 1bn = 2m

Returns on your own capital: 20% of 1m = 200k

Maybe that's their way of becoming Google?

Imagine how much money they'd raise if they just said one day "we are going after salesforce bottom line now." It would be like chumming the water.

As many in the industry say now - writing code was never the hard part

Surely they can't manage to have a performant binary versionnof claude code and they're stuck with JS runtime

--

[0] - If you can even call anything built before modern petrochemical industry a "bicycle".

But then Anthropic doesn't get the PR, so...

Doesn’t this make it less profitable to be an R&D company, since there is less market share available?

Even if you can write a lot of code with LLMs, what is that code actually doing?

Clearcase was way ahead of it's time, the main issues there were really just cost (mostly licensing cost, and a little on how many sun servers you needed to serve it and keep state of the vobs)

Perforce was way ahead of it's time, everyone still wants a monotonically increasing changelist identifier too.

I never got caught into the monorepo fad, I'm glad I didn't, and I still don't see a point in having monorepos. Let's say in ruby on rails, I have the host app and 3 mounted gems in it. That's 4 repos. It could be all merged into one monstrosity but separate repos help keep complexity down, and help define interdependencies cleaner and simpler.

The monorepo idea was just a fad. Each package should be its own repo. Each package should be meaningfully useful, e.g. one package for string utils, not one package for trim, one package for pad, etc.

Everything works like this in the end at some level. I assume people with monorepos don't retest their project on every Linux kernel commit - it's pointless, you are never going to run against exactly that commit. But you will do it when you do upgrade Linux versions, etc.

Besides, agents really fly when the whole project fits comfortably in their context window. You get all these nice interfaces to bound context with if the API's and public types are defined and versioned separately from each team's repo.

For the rest that do, the vast majority of them are going to buy some Perforce licenses instead of vibe coding their own solution.

Unless you are Google/Meta where your company is large enough and its revenue supports paying a team of engineers (a lot of money) to do that, or you are Anthropic who is just vibe coding everything which can turn out to be good PR, you simply don't have the resources or can afford the risk to develop your own VCS solution.

This may be inspiring but out of question for most companies.

I do accept the argument that a distributed architecture has inherent costs which can be managed better using a client-server architecture because you don't have to replicate state across all nodes. I have worked with both git and Perforce and see the appeal of both.

made me throw up in my mouth a little bit.

Well-configured agents do, in comments and commit messages and docs.

But many people are just stuck thinking in GPT-3 era, where the prompt was all there was to it. It's not. You write a 1000 token prompt describing what you want, and the agent pulls in 10k tokens of system prompt, then spends time exploring the codebase and calling tools and attending to 100k of more tokens from this, possibly including output of sub-sessions that do the above, and somewhere along the way, having read lots of code, run lots of tests, perhaps doing a spike or two, the agent then decides some chunk of code needs to be written in this way, and not in some other way.

The reason is not contained in your original prompt at all. It's almost entirely based on what the agent learned about the current state of your codebase and environment.

Nope you are 100% correct. All of the models will code themselves into local maxima then spend more and more time chasing their tails as every change introduces new bugs, the agent adds more complexity, and the code base just spirals. Best case you end up with a bunch of parallel implementations that all work slightly differently.

It helps a lot of you pay attention to what it is doing and impose order, then regularly spend time refactoring - even if you are having claude do the work itself - you have to spend the time on the overall architecture and design.

I just experienced this with an internal productivity tool. Without claude this tool wouldn't exist - there would never be the justification to take the required time to build it. On the other hand all the interlocking refreshing rules for sourcing data from its inputs got so byzantine it was impossible to add new features or change anything without causing new regressions. Claude built a web of ad-hoc timers, refresh kick-offs, monitors, etc to solve each feature problem or fix some bug but the whole thing was impossible even for claude to understand. It took a special large workflow session to find most of the mess and even then during the refactor it kept finding new things.

I had to stop all feature work for going on four weeks and burn a ton of tokens to build a refreshing/syncing engine that could track dependencies, priorities, etc and fully test it and just now today I am finally able to get feature work going again.

On another feature an agent came up with a state object containing 55 inter-related fields with all kinds of interlocking dependencies. Something so complex no one could hope to understand it. And I find the agents aren't really much better at understanding such things than humans are. If you leave it like that the agent will just perform worse and worse on that part of the code as time goes on. It will make assumptions that force it into bad design corners, miss edge cases, and flat out miss things no matter how well you prompt. Agents benefit from encapsulation and simplicity just as much as humans.

Your bar for quality must be pretty low if you feel this is better than average?

Theyre usable but leave alot to be desired. SOme other tools like opencode seem sometimes to have less feature (if exact numbers) but at least always work.

Somehow with Claude and some others, random simple thigns dont work. Esp long solved problems like TUI rendering, special chars, breaking changes every release etc.

Surely as always with software this is my experience and might be not yours.

PS: Ive used IntelliJ since... always?. It was quite decent. But these last years it is just so diferent, somehow way less quality, so many random bugs that Im afraid theyre doing AI agentic coding which sucks for such an important tool.

IDEs should be build from real professional crafstman with an exact vision in their heads, not some wild AI.

Im starting to think in a year or two "We dont use AI in developing our products" will be some kind of marketing trick since people will start looking for that.

I'm not sure if this is true. The code is such a small part of the total output. Thinking harder, like what would be needed for architecturing better code, would use more token.

There are also some pretty detailed videos out there on YouTube of Anthropic employees showing how they are using cloud code on several orders of magnitude better than where the bulk of usage is.

What actual bugs do people have with it, and why do we think it is worse than a human coded tool?

as long as something works "good enough" and the code will never be reviewed theres only incentive to blast through tokens generating superfluous code. god forbid they actually ship a vibe coded product then they can basically ransom you for tokens

im probably being overly cynical but it sort of just seems like standard capitalism to me

All software is broken, but LLMs seem to make the wrong compromises consistently when working in large codebases.

This is a fallacy. Computers are very deterministic, a well designed program will not have any bugs or unforeseen failures at all. You're not planting a tree and going "oh god I hope it survives the winter", you're programming a human-made computer, made of hardware that undergoes such incredible scrutiny before it's ever powered on that you can trust that it executes the same code, the same way, every single time, for decades.

No idea why people who clearly don't understand the difference between poppy farms and computers come in here and claim the world isn't perfect and so we should all accept sloppy shit code that barely works. The world isn't perfect, but software CAN be quite close.

Every single instance of jank on computers is a bug that someone wrote, or an LLM wrote, that can be found, understood, and fixed. And only once you understand this, can you talk about software quality to other engineers. You need to understand that the baseline is that software is not fallible the way the rest of the world is.

See sqlite3 if you want to know what nearly bug-free software looks like. I can't point you to a potato farm or an artist who is perfect, but I can point you to that and say "this is where we go when humans do a good job".

That's a thought-terminating cliche. When someone asks how can they can avoid generating a pile of slop (which will compound over time and get increasingly harder to deal with), they're not seeking "perfection", and framing it in those terms is dishonest.

Furthermore, can we step back for a second and remember that user and developer experience matters too?

Working with code like that sucks. Spending much of your day on polishing a turd that grows more unwieldy with every iteration is going to get old, fast. And I also think that's going to take a significant mental health toll on people eventually.

The business won't care about this but we should. AI was supposed to make things better, better quality, better reviews, better QA, better product, better UX - remember?

> janky UX that can probably be fixed by prompting the next generation model to clean it up

I'll counter by pointing out that "Next one will fix everything" has been a meme for at least 2 years now and the slop just keeps getting sloppier.

Monkey's paw curls

Certainly, it would be super super difficult to generate training data for it, so it's unlikely that it will improve.

I e., a responsible developer who cares about quality will have to get their hands a little dirty with some maintenance now and then.

By "Real" in this context I mean companies that aren't Anthropic .i.e. don't sell any kinda AI product and existed at least 10 years before the AI boom. Esp. in regulated or at least sensitive fields like finance, banking, medical, logistics etc.

> I rarely write code anymore. The code that I get from the LLM is just better.

Coding chatbots excel at leaping low bars.

Same here. There is an introspective comment below by khazhoux asking the question from the opposite experience. Why do developers end up on different sides of this coin?

LLM capability is obviously important variable. But those with bad experiences report using top tier models, so that isn't it. Likewise, level of experience can be ruled out. Each side of the coin have experienced developers reporting.

A lot of the other variables are not reported but I can go from my own experience.

Greenfield vs brownfield? The first is indeed usually easier but I get great results updating large code bases with decades of development. And I suspect developing greenfield with LLM is easier as the code is better written from the start.

Rarity of the subject matter? In principle, yet another XYZ app or web page is well represented in the training data so the LLM should have an easy go at making similar. In the past with low-end LLMs, this was noticeable. Working in relatively obscure programming languages produced just garbage. But, that was prior to the inflection point. And today I get good results working on relatively arcane scientific/mathematical algorithm as I do when I ask the LLM to barf out some web app.

Different levels of testing and validation and expectation? Even best LLMs make mistakes. The better LLMs make fewer and expose fewer still to the human as they create internal tests. Maybe people have different expectations and those with bad experience expect perfection from a single prompt? Perhaps, but any experienced developer knows bugs are a part of software development.

What else?

Whatever the answer, it's not a simple one and it may be a confluence of many smaller things. Maybe different developers have a multi-variant function in their brain that pops out a different quality-of-software score and also a different threshold that divides good from bad and all we see in their reports is that binary conclusion.

on mobile it works (where I would expect the hamburger menu), and on usual desktop I have the usual menu bar, but when I change the window size on desktop I get the hamburger menu (and then the UX jankiness is evident, but for me easy to work around, as moving the mouse down closes the "research" block and then it's quite simple to move it up to be able to click "policy")

at this point I think Opus does something better by default

As expected. That woukd require domain understanding, and that's way beyond the scope of stochatic parrotry.

It's always total hallucinations. It could only see local minor issues.

It happily starts to introduce fake abstractions and other junior level "refactoring" making it even worse.

The difference between intent and implementation seems like a very common source of bugs?

If intent and implementation was the same thing programmers as a profession would have been left behind 20 years ago.

I regularly run "experiments" on Azure to figure out what it actually does.

While I think their models are great, and they deserve a lot of props for caring about safety (their interpretability work is great), their public tone just leaves so much to be desired.

Apparently they also don't understand the Streissand effect, given their recent blog posts about GLM 5.3.

Typical anthropic post.

https://en.wikipedia.org/wiki/On_Bullshit

It's easy for them to one-shot solutions because the problems are very well defined, and the agents can easily reason about how the software will be used. The closer you get to the "real world," and the more complex the business logic gets, the worse the models get at making the right architectural or design decisions. If you're not watching closely to give input and steer the agent, it gets out of control pretty quick.

I find it ironic that these same individuals often loudly and publicly celebrate each new model release (as if they're early investors instead of early adopters), and tend to be very optimistic about agentic coding -- even though their jobs are the most at risk of being automated due to the simplicity of their work.

The closer you are to actual business outcomes and real-world software projects, the more you tend to understand that agentic coding patterns struggle to navigate the messiness of the real world. If you're working as a software engineer in an actual major industry (healthcare, insurance, defense, infrastructure, etc), you're probably going to be more skeptical when a gung-ho SDET makes bold claims about how LLMs are going to take everyone's job within the next 3-4 years.

> “I don’t think you’re lying, but I also don’t believe you.”

They're not lying. They're just a bit naive.

If you're Anthropic, you probably don't want a 100Gb of haystack lying around in which a damning needle might be found.