My view on all the LLM-powered code review processes I've seen: 90% of it is just creating text slop absolutely nobody reads. Doing it yourself, before you push to GH, is fine. But making your co-workers interpret this noisy slop is wasting their time.

Puma utilization is not busy_threads/max_threads when you're using MRI. "1 thread busy out of 5" isn't 20% utilization b/c those other 4 threads may be unusable due to GVL contention.

Normally Datadog is an absolute moneypit, but their Database Monitoring product is an incredible value at $70/mo. It's a supercharged AWS Performance Insights dashboard, but far more useful and integrated with the rest of DD. Price doesn't change if you've got a 192 core DB.

If you're Ruby Central, where do you go from here?

Observing test runtimes and then trying to binpack examples into N number of jobs doesn't work. Test time is highly variable, and this approach assumes no variance in test exec time. No matter what you do, you end up w/50-100% variation in job time. Use queues (i.e. Knapsack)

Just to be clear, Ruby Central has not taken money from DHH/Basecamp.

Everything can be high availability on a long enough timeline. We've only been down for 1 day this decade - that's 5 nines of uptime!

Most teams are doing "performance theater", where any micro performance improvement is celebrated w/o context. The problem is that the product side eventually gets frustrated because you keep stacking micro-wins with no measurable/noticeable difference to customers.

Clip: 'They've been given this rocket ship and they've got no fucking clue where to fly it'

Despite all the improvements that have been landed on this stuff over the years, logging the source code line for every SQL query remains pretty expensive. It's better to use your APM for this, which will only add it to ~1% of your transactions, rather than 100%.

Most of what I'm seeing in the wild re: dev agents is trying to go against the bitter lesson. We keep trying to build in more 'knowledge bases', 'memory banks', human knowledge and ways of working. The only thing that matters in the long run is the leveraging of computation

If you're not sure if you're running jemalloc with Ruby correctly - set MALLOC_CONF="stats_print:true", and when you exit Ruby you should see a bunch of debug output.

I've been using this combination of prompt+tool to get Claude to setup arbitrary Rails apps dev envs for me. It's got a pretty good success rate, I would say about 80%.

99% of developer environment setup scripts in Rails apps would be improved if: 1. They didn't try to install a ruby/ruby version manager if the correct version is already working. 2. They used direnv. 3. They used mise. 4. They were shell and editor agnostic.

There's an emerging consensus around LLM coding agents that 5 to 15 minutes is the "ideal" amount of time they should spend w/o human impact. Longer -> context rot, ~5% probability of success if run longer Shorter -> Too much human intervention/review, main thread blocked

At first I was a bit skeptical of Shopify's "LLM spend" leaderboard, but now I see from firsthand experience that most devs are still underindexing how useful LLMs are and are still sweating the costs far too closely. Unlimited budget was the right call.

From the Speedshop skunkworks laboratory: effects of RUBY_THREAD_TIMESLICE. In this example, we hammer a 10 thread Puma server with a high IO workload. Note how drastically the amount of time spent waiting for the GVL shifts around and how long the spans are.

LLMs have me thinking about this chart almost daily. We are in the age of self-ware. Small throwaway utility software for an audience of one.

I wish everyone had this tool that my clients Pronto built: temporarily set up a production db copy. They take a snapshot of prod every day. This page allows a dev to start a new db instance, same size, same data. Fire up psql and test all the indexes you want w/o fear.

In some ways LLMs are the perfect tool for me. It's often really hard for me to write the first ~500+ lines of a feature or refactor. But now the LLM does it, and I think "jesus christ this is awful, dumb-ass Claude here's what we should do..."

Are you an Obsidian user? If yes, sell me on it? Are you a former Obsidian user that gave up on the dream? Why?

Claude wrote two commits in Go for me, a language that I do not understand the first thing about, and those commits were accepted in the OSS project Thruster:

With LLMs making leetcode and other whiteboard problems trivial, software hiring IMO should shift towards establishing taste, which LLMs absolutely do not have. "What do you hate about ActiveRecord? What would you change about Rails if you could?" Review this PR, etc.

You can't learn by editing. Editing without knowing about the underlying "thing" is trying to grade a test without the answer key. There's no feedback loop to create learning. Thus, a junior developer is poorly served by trying to learn through reviewing LLM-generated code.

A lot of people in our CGRP Slack community are having issues with Router 2.0 on Heroku. I initially thought this was more Puma/keepalive problems but actually we're seeing it with Falcon, Anycable, and Puma with keepalives disabled too!

My heuristic for "is an LLM/agent useful for this?" is: would hiring 6 juniors to do this be useful? Not useful: contributing to Linux kernel, writing a new concurrency library Useful: shipping 40 tickets for my Rails app, 1000+ line refactor from pattern X to Y

Noisy tools with low signal get ignored. If you don't constantly improve the feedback that a code review agent (e.g. Claude GH action) is giving you (by updating a memory bank/ruleset), your developers are eventually going to ignore these review bots.

I'm sold. Agentic coding is the future of web application development. There is no going back. Close the editor. Open Claude. Your job is now to manage, review, corral and improve a relentless junior dev who is working on 6+ PRs in parallel.

non-native English speakers: a lot of you are running too much of your online writing through chatGPT. The "stink" of LLM on your writing is unmistakeable. personally, it makes me completely uninterested in w/e you have to say because it just looks/sounds like LLM slop.

Native structured logging PR proposal for Rails, extracted from Shopify. I'm not a huge fan of the gems available for this currently, so first class support in the framework itself (fiber-aware, phew!) would be a huge plus

Don’t let the LLM think. LLMs are bad thinkers, and are choosing between options probabilistically. If you let the LLM think you create a negative feedback loop, because the decision will be slop. Slop in context begets worse slop. LLMs autocomplete, they don’t think.

Predictions of a rugpull on LLM pricing are going to be wrong. This isn't Uber, which had operational costs in the real world that didn't change with scale. Maybe the only "too good to continue" deal I see out there is Claude Max.

In the age of LLM-augmented dev, your job is to: 1. Put the AI in the right latent space (prompt) 2. Provide correct context 3. Refine the output with automated loops and deterministic tooling. 4. Review output and improve step 1-3 so that you dont provide the same review 2x.

I keep coming back to this, from Birgitta via Martin Fowler's recent post on LLMs - we are entering the age of non-deterministic development.

Agentic coding is putting massive pressure on CI and testing: 1. Overall build times are exploding as LLMs add far more tests than humans typically do, along with overall velocity increasing 2. LLMs need good tests to be successful, test quality more important than ever

Parallel agent enjoyers: What tactics are you using to make sure agents don't interfere with each other? I've already got git worktrees with claude-swarm and each agent having its own db via changing the DATABASE_URL (in Rails). Other sneaky sources of collision?

@searls.bsky.social I'm noticing that standardrb doesn't work well with LLMs. Standardrb actually implicitly assumes a base level of competence and taste that LLMs don't have. Find myself wanting things like ABC score, outlaw require_relative, things you would never do for a human.

claude-swarm, worktrees and vibe mode

If you haven't done enough LLM-assisted coding that you needed the Claude Max plan, you haven't tried this stuff fully enough yet. I am fully convinced every developer can get more than $200/mo of value out of a Max sub.

thanks to everyone who recommended Aerospace as an i3-like MacOS window manager - I've made the switch and won't be going back. The performance is great, the mouse support is really good, and I like the ability to create arbitrary layouts

Anyone use yabai on macOS and can comment on a) stability and b) responsiveness? I've been a long-time Amethyst user but having to constantly restart it and the slightly-slow layouting isn't great

This was a great listen but what's truly impressive is Rosa's incredible rolled r. I could listen to her read the phone book (but only starting from the R section).

When setting cooldowns for scaling up or down horizontally: It is important you EVENTUALLY scale down, but it's not important that you scale down QUICKLY. The exact opposite is true for scaling up.

Which web app server is more performant: 1. 1 container with 8 forked child processes 2. 8 containers with 1 process each, round robin/random load balancer in front It's #1 and it's not even close! This extremely relevant if you have to have to use random/RR load balancers.

From the CGRP Slack. Don't be stingy with Redis connection pool sizes. Redis is pretty efficient w/idle connections so I will just set size to either 100 (if using mike's connection_pool gem) or equal to the concurrency of the puma/sidekiq threadpool.

As a consultant, you can be 99% certain what I tell you is correct, and you can make fast, big bets and decisions based on that. If an LLM tells you something, you can't just immediately go sign up for $300k worth of yearly AWS spend without significant addt'l research.

Retainer full for the summer!

NEVER MISSES. Jemalloc STRIKES AGAIN, this time for a retainer client. 47% less memory with two lines changed in the Dockerfile. $2000/year saved on Fargate costs.

Kinda crazy that 9 months ago I felt the need to excuse this, now I just sort of assume everything is ai-generated-garbage

The more I use it, the more I'm "all-in" on Datadog. I love every new addition they make to the product, and the stuff they're modifying in old parts too. 1. Love the new Scorecards feature. 2. The new Notebook 2.0 UI is amazing. 3. CMD-K to nav thru the massive feature set