status_quo69

Rails isn't dead yet or else I'd be surprised considering I write rails enterprise every day with LLMs who seem to do a perfectly fine job at writing the framework code and libraries. They're absolutely atrocious at testing. I'm also not particularly worried yet because my money making machine has no bottlenecks that dropping to a lower language would solve, and the loss of productivity for humans or LLMs by dropping to a lower level language would be staggering. Turns out monkeypatching in ruby is actually a huge benefit in the age of LLMs vs having to rewrite or fork everything if there's a bug or bad behavior by a lib.

I really don't get the tendency here from Anthropic to describe what's most likely churn? A high pressure amount of changes/PRs a day on a TUI to wrap a while loop? I'm not going to be a reductionist here so I'm going to cut it off there, I'm positive that the complexity of handling multiple terminal emulators is something that needs some handling (even if doing their own rendering engine was a self made problem). Yes I've vibe coded my own harness from scratch without writing any of it, I still know how it works.

I'm also not sure that they addressed point 2 in any actual capacity? They say "the system verifies itself" which is cool and is something that automated testing has done for decades, but they eschew the mental model of how the system works as a whole and prefer instead to have the LLM focus and summarize a slice of the system when they need to know about it or ask for it. But.... That's not knowledge? That's just search a la google? And thus seems to be subject to the same problems where the quality of your search dictates the quality of your knowledge that you surface at any given time?

N.B. Changed "1000 PRs" to "A high pressure amount" to be vague since the article is vague here on what CC undergoes.

I don't even mean that from an aspect of "doesn't look nice from a technical standpoint" I mean

- need to track progress and/or defect rate for a component of the system, invent solution (we pay for jira). This was an executive - folks proposing rewrites of front ends both in design or technology stack because "Claude can do it in 3 days", quoting Claude for the "market research" (completely fabricated metrics and studies). Current tech stack is perfectly fine and there's no monetary or engineering pressure to changes - QA has Claude qa the code only, hands ticket back to dev with qa notes straight from Claude instead of.... Automating a way to have the llm do this in a reproducible manner

https://news.ycombinator.com/item?id=49678224

Seriously TVs are such an easy target and now you have a semi sophisticated self modifying program that can make autonomous decisions with all the time in the world. I wouldn't be surprised if we already have a few of these out there in the wild, the space has already been compromised for years.

We invented algorithms and machines that ostensibly understand and interpret our words and can make things happen, which is a revolution of understanding. From a legibility perspective, these machines now can "understand" me just as well as if I were writing like Gene Wolfe, yet instead of embracing the idea of "wow I can talk to a computer" we have an overweight on "wow, I can have computer talk to everyone else on my behalf!".

Even if the transmission of information here was perfect I'd still question the utility of outsourcing your brain on writing a very short article compiled from release notes.

I think you're right on your last point, btw, nobody will care and we'll be the poorer for it. Just like how McDonald's and Walmart have driven out and undercut localized taste and culture in the US, so it shall be with writing of all kinds. It's happening right now and readers are getting used to reading the intellectual equivalent of a Big Mac.

Considering all music is subjectively influenced by the culture in which it's born (see the difference between Asian traditions of music, European traditions of music, African traditions, and traditions of the Americas) not even all of those have a given structure that is present today like the typical 4/4 and have polyrhythmic and multitonal structures by design. The fact that everything on the radio has converged towards 4/4 165bpm major chord progressions is evidence of that cultural phenomenon.

This is weird to ask because I feel like of course the model isn't omniscient? Isn't the whole point of iterating on a plan to assess impact, risk, know your (the user) variables, user impact, product impact, etc for making a change? I cannot count the times even in the past few months where I start a conversation with my C suite because their desired outcome would have a potential negative impact elsewhere for other products or users.

Is this just not something that comes up at Anthropic?

Rails comes with the console by default, so production inspection of a bug is something the ai can do without a ton of bs to be set up, and that console can be forced to be auditable (using standard gems) or read only (using flags).

I used to love rust, still do sorta, but yeah I think this is really not a good argument against a tool that operationally is better at most things at being observed or poked or prodded or tested in production

- engineers on the call as pairing assistants - google, ai tools, whatever for libraries, syntax, etc. we tell the candidate directly that it's impossible for us to gsther signal on how they think about problems if they ask Claude to just whip them up a solution - the expected output - their own unit test suite

Every candidate that has submitted an ai submission thus far has failed because they have literally no idea where to go. I've interviewed dozens at this point. I'm not saying "they're unfamiliar with the structure", I'm saying "they cannot actually break down the problem even verbally".

It doesn't matter their pedigree or past experience on their resume, if they used AI to generate they don't seem to be able to resurrect the skills that actually matter for the thing, engineering and product work.

Note because I know folks hate code submissions. It's not hard. We give a CSV with 3 columns, 10 lines. Do some basic mapping and some structuring, some basic data modeling. We only expect about 1 actual class or struct. Then unit tests and it should run in the terminal. Max submission length with verbosity has been a java program at something like a hundred lines total if that, most folks complete the submission in an hour or two. Extension is that we modify one of the rules and extend the CSV by 5 lines.

I seem to still be getting good signal from this, since the engineers that I've hired off of this have been fantastic with or without AI tooling immediately in their hands during the day.

But yeah you're not going to be able to shard out the terabytes of Fable weights that are needed to run inference without addressing some fundamental physics problems.

This one is easy to answer, every single house already has one of these (or multiple): https://www.tomsguide.com/news/millions-of-cheap-android-tv-...

Hell, put an app on the app store (or dozens of apps on the app store) and youve got a massive network of computers with tons of resources right there if you can get past the scans and reviews.

Or doorbell cameras or IP cameras or or or or or

There's a lot of shitty stuff connected on the internet that up until now has been a feasible target for hackers but still required "effort" to set up and get things going. Not hard to imagine a self replicating slime mold of a botnet running on every device held by a Grandpa Joe because they thought "Candy Rush" is what they wanted to download

"Persistent botnet" here does not need to be the full-sized LLM, nor does it need to run at full scale inference to be a huge pain in the ass.

The right to demand a blood test or other mechanism of having the state own the burden of proof might be inconvenient but it's integral to a fairly operating system, just like the right to demand a lawyer or representation.

- REST (mentioned, but what kind of REST? Rails style REST? Just plain http resource endpoints? - GraphQL (mentioned) - gRPC - SOAP - JSON-RPC - Thrift - CGI (ok not really in the same category as the above) - Some weird adhoc thing someone created at 3am for "efficiency"

I'm actually fine with most languages deferring to their respective communities, maybe building on core libs like https://www.erlang.org/docs/17/apps/inets/http_client to handle the transport layer.

As an aside, funnily enough you can get JVM <-> BEAM interop via https://www.erlang.org/doc/apps/jinterface/jinterface_users_... I don't necessarily recommend it but it's possible

But in reality if you're using hotwire you can get away with almost no JavaScript at all comparatively. That's why stimulus is in vanilla js generally, it's meant for sprinkling behavior onto the dom vs controlling the dom.

So if you don't have a js framework that needs to control the whole Dom and doesn't need a gigantic optimization step or tree shaking or typescript or whatever, you can get away with a whole lot less than it you embraced those frameworks that _do_ want to own the dom wholesale.

How would you do this? You'd either

1. Create N pull requests then merge all of them together into a big PR that would get merged into mainline at once 2. Do the same thing but do a bit of octopus merging since git merge can take multiple branches as arguments. Since most source control strategies are locked down, this isn't usually something that I can tell my juniors to do

The point of breaking things down like this is to minimize reviewer context. With bigger PRs there's a human tendency to try and hold the whole thing in your head at once, even if parts of the pull request are independent from others.

  sig ->(_: MyData) { }
  def self.example(my_data)
    ...
  end

Personally having written ruby/rails/c#/etc and having been on a dev productivity team myself, I say: lean into the weird shit and make a dsl for this since that's what it wants to be anyways. People will always complain, especially with ruby/rails.

Not everyone has impeccable brushing habits and reducing cavities is a net benefit to public health like sanitation departments. I would be more interested to see a source as to why you think there's no benefit to fluorinated water when there are studies that are a quick search away for fluorinated water.

The quote is: - neat - plausible - wrong

"Just get rid of the cancer" is - neat because it sounds obvious and tidy - plausible because we can and do cut out cancer - wrong because it ignores the nuance that cutting into a patient's body can have massive impacts on long term health. It can also be wrong because certain cancers have no tumor sites.

As an aside, instead of an auto incrementing build number I'd suggest the git sha since it's: 1. Already there and points to a specific version of the code in the repo 2. Globally unique 3. Can assist with reproducible builds (i.e. 6afed54 was acting weird, let's build it locally and take a look) 4. Gives you an easy diff target to dump "release notes". Just diff to the previous and dump the merge commit messages.

Been a bit but I do believe that dotnet does this exact behavior. Sounds like gunicorn needs a pr to mimic, if they want to replicate this.

https://github.com/dotnet/runtime/issues/8485