I'm two weeks behind on the newsletter, so I was trying to be responsible by resisting the urge to document the success I've had with my current coding agent setup. My self-restraint has paid off, as Peter Steinberger essentially wrote the exact post I was planning to write.

There's lots of good nuggets in here, and it's uncanny how many I agree with:

1. I also use Codex CLI (well, this fork) on a $200 ChatGPT Pro plan. Claude Code was an epiphany, but their models are overrated for the task, whereas GPT 5's variants are more adherent and diligent across the board. OpenAI's usage limits are virtually infinite by comparison, too
2. I run 3-6 agents in parallel (usually up to 3 per project and up to 2 projects at a time). Unlike Peter, it's rare I let two agents edit the same codebase simultaneously. GPT 5's "medium" reasoning setting is so fast that the time-consuming activities are brainstorming, researching, unearthing technical debt, and planning refactors
3. While git worktrees are a very cool feature, they dramatically slow down code integration with merge conflicts. Additionally, I've found it's hard to avoid API and port conflicts when running numerous development instances simultaneously. And when an environment stops working, agents will silently start coding based on speculation and conjecture. Fast feedback through observable execution of code is the single most important thing, so the risk isn't worth the (marginal) reward
4. Hooks, custom commands, and fancy hacks like coder's undocumented auto-drive mode are nice, but they're no replacement for thinking really hard about what you want

But really, the reason I've had so much success with Codex in comparison to Claude is that if you get off your ass and do the hard thinking necessary to arrive at an extremely crisp and well-informed articulation of what you want, why you want it, and what obstacles it will face, today's agents will generally do a really good job.

Oh, and fuck prompt engineering, just communicate better. As Peter says:

Don't waste your time on stuff like RAG, subagents, Agents 2.0 or other things that are mostly just charade. Just talk to it. Play with it. Develop intuition. The more you work with agents, the better your results will be.

I've started a dozen posts about working with coding agents that I deleted before publishing, because I eventually realized whatever insight I had could just as easily apply to dealing with human colleagues as with LLM agents. Seriously, just talk to it like a human.

Common communication failure modes:

• Telling the agent how to do the work instead of answering why, what, and where, and then getting upset when the ultimate solution manages to complete all the hyper-specific tasks I defined while failing to solve the broader problem
• Giving the agent instructions that contradicted the facts on the ground, only for the agent to spin its wheels endlessly and make a huge mess trying to do the impossible
• Lazily hand-waving away important requirements, only for the agent to miss edge cases it lacked awareness of
• Telling it what I want before I'd really thought things through, then hating whatever it gave me
• Failing to first deal with underlying technical debt, then getting mad when the agent shoehorns in a necessarily-messy solution on top
• Getting frustrated, being condescending, or treating the agent like it's my underling, and then peeking at its reasoning log and seeing 80% of its thoughts are about managing my emotional state and 20% about the problem at hand

I'm more convinced than ever that when people are having a bad time with using AI to write code, it's not only due to ignorance and incompetence surrounding the tools themselves—just as often, it's a failure of imagination and lack of communication skills. Two things that even the best programmers frequently lack. If you're a programmer who's bad at communicating with humans, I hope you've got some other plan for making money in the next decade.

Anyway, that's where things stand in October. June feels like three years ago, so we'll see where we are in February, I guess.

[TL;DR, Ruby Central has alleged that after he was notified that the board had voted to remove his production access to RubyGems.org, André Arko accessed the Ruby Central AWS account without authorization and proceeded to change the root password. 👇]

For context, last week I wrote a post bringing to light a number of things André Arko had said and done in the past as a way to provide some context. Context that might explain why any of the principal actors involved in the RubyGems maintainer crisis (summarized well up to that point by Emanuel Maiberg) would take such otherwise inexplicable actions and then fail to even attempt to explain them.

Today, Jean shed some light on Shopify's significant investments in Ruby and Rails open-source, and it actually paints a picture of corporate investment in open source done right. (Disclosure: I know and am friends with several people who work at Shopify on these teams, and unless they're all lying to me, they sure seem to prioritize their work based on what Ruby and Rails need, as opposed to what Shopify wants.) Jean went a step further by contrasting Shopify's approach with the perverse incentives at play when individuals or groups receive sponsorships to do open source. He also drew a pretty clear line of those incentives playing out based on how RubyGems and Bundler maintainers reacted to Shopify's feature submissions. Read the post, it's good.

But now, not an hour after reading Jean's post, Ruby Central has published a jaw-dropping tick tock of the events that precipitated their decision to revoke maintainer access. Even more bizarrely, the only reason we're learning this information at all seems to be a self-own: that by publicly dunking on Ruby Central's failure to remove André's systems access—as opposed to properly disclosing the security breach—Joel Drapper and André inadvertently compelled Ruby Central to issue a post-mortem that lays out the facts we've all been clamoring for.

Seriously, just go read it yourself.

The Bad Part

On August 3, Ruby Central leadership became concerned there was a risk André might access and sell logs containing personally identifiable information from RubyGems.org servers. This concern was raised by André himself, who proposed it in an email:

Following these budget adjustments, Mr. Arko's consultancy, which had been receiving approximately $50,000 per year for providing the secondary on-call service, submitted a proposal offering to provide secondary on-call services at no cost in exchange for access to production HTTP access logs, containing IP addresses and other personally identifiable information (PII). The offer would have given Mr. Arko's consultancy access to that data, so that they could monetize it by analyzing access patterns and potentially sharing it with unrelated third-parties.

(The screenshot of André's email to Marty is in the post.)

So, according to Ruby Central, André was making $50k a year to fulfill a "rarely activated" role as secondary on-call, and when that budget was cut, he proposed harvesting PII and reselling it for his own profit. No mention that this might be unethical, much less in violation of RubyGems.org's privacy policy.

This led Ruby Central to go to work shoring up proper Operator Agreements and Contributor Agreements that could sufficiently defend against this kind of action. They decided to take the further step of temporarily revoking various accesses from multiple (most? all?) contributors until such protections were in place, which—as has been widely discussed—they didn't do a great job of explaining and did not even attempt to justify. Of course, now that we've seen this email and understanding that Ruby Central probably didn't want to catch a defamation suit by naming and shaming André as the reason, it certainly casts the subsequent community outrage in a different light.

Suddenly, that Shopify's leadership undertook a bizarre corporate conspiracy to withhold sponsorship dollars if Ruby Central didn't mass revoke maintainer access isn't the simplest explanation for why things might have gone down the way they did.

The Somehow Even Worse Part

But wait, there's more. Joel's post identifying that André still had systems access not only represented a security incident, it connected the dots Ruby Central would need to affirmatively identify an unauthorized actor who had accessed and changed credentials on their AWS account.

On September 18th, Ruby Central notifies they're revoking André's access:

Ruby Central notifies Mr. Arko, via email, of the board's decision to remove his RubyGems.org production access, and the termination of his on-call services. During that transition, our teams remove the AWS security credentials belonging to Mr. Arko for accessing the production systems, but we fail to rotate the AWS root account password in tandem.

Not eight hours later, a mysterious stranger in San Francisco (who Ruby Central asserts is André) logs in as the root user of Ruby Central's AWS account and changes the password. Ten days later, another mysterious stranger in Tokyo (who is apparently also André) logs in as root again.

I'm no lawyer, but that timeline could implicate the Computer Fraud and Abuse Act. That'd be incredible enough on its own, were it not for the fact he may have done it again in Tokyo—meaning he might have exposed himself to Japan's own statutes governing unauthorized computer access.

I'm not here to gloat, I'm here to plead with People On The Internet who rushed to judgment against Ruby Central or in defense of André to learn from this situation. The next time a story hits that rhymes with the basic outline of your prior convictions or political beliefs, pause and weigh the evidence before grabbing the nearest pitchfork and joining the mob. Sometimes that means—and I realize this is hard for some of us—not posting anything at all.

That said, I am formally accepting apologies from anyone who dismissed my previous post as "hearsay" or a "hit job" on Reddit, Hacker News, Bluesky, and Mastodon. (The X folks were mostly into it, a fact which brings me no joy.)