Simon Willison on PR (anti-) patterns in the world of agentic AI

There are some behaviors that are anti-patterns in our weird new world of agentic engineering.

It’s so easy to create AI PR slop in this new world, even on private teams.

If you open a PR with hundreds (or thousands) of lines of code that an agent produced for you, and you haven’t done the work to ensure that code is functional yourself, you are delegating the actual work to other people.

These are good rules for event human-created PRs and these stood out:

The change is small enough to be reviewed efficiently without inflicting too much additional cognitive load on the reviewer. Several small PRs beats one big one […]

The PR includes additional context to help explain the change. What’s the higher level goal that the change serves? […]

Agents write convincing looking pull request descriptions. You need to review these too! It’s rude to expect someone else to read text that you haven’t read and validated yourself.

**Key points** * SSDs wear out differently from hard disks. * Expect modern Mac internal SSDs to wear out after at least 3,000 erase-write cycles. * To monitor wear, measure the total data written to the SSD. * Expect an internal SSD to wear out when that total reaches 3,000 times the total capacity of the SSD. * For a given amount of data written to an SSD, the larger the total capacity of the SSD, the slower it will wear out. * Keep at least 10% of the SSD free at all times, with 15-25% even better. * Ensure your Mac has sufficient memory to never use VM swap space.

hoakley in How long will my Mac’s SSD last?

How to find out where I am in that cycle?

Version 1: use iostat and some math.

$ iostat -Id disk0
              disk0
    KB/t xfrs   MB
   19.02 36987892 686874.89

The MB column is “total number of megabytes transferred” (since the disk was installed).

So 686.87 GB, in my case. My disc is 1TB and that means I’m not even fully through one of those 3k cycles.
This seems low and hurts my developer pride, so let’s try another approach.

Version 2: using smartmontools

smartmontools is an open source project and can be installed using brew install smartmontools.

It installs multiple utilities and the one that’s of interest is smartctl:

$ smartctl -a disk0
...
Available Spare:                    100%
Available Spare Threshold:          99%
Percentage Used:                    1%
Data Units Read:                    217,642,465 [111 TB]
Data Units Written:                 70,672,272 [36.1 TB]
...

Much more “respectable” numbers. The 36.1 TB is about 1% of those 3000 x 1 TB, and it’s also conveniently displayed in the “Percentage Used” column.

“Available Spare” is the percentage of the remaining spare capacity available for use. As the SSD wears down this could see a decrease, although the Disk Utility might continue to report the same size for the disk.

(Thanks MacWorld for the instructions and descriptions.)

LLM Pricing Calculator allows you to compare models and there it includes nice explanations like “1.33x input vs Gemini 2.0 Flash Lite, 1.33x output”.

Can also calculate operation pricing if the number of input and output (and cached) tokens are known.

The post has a really strong opener:

[…] the first week isn’t about reading the code. It’s about reading the signals.

The client already has opinions about what’s wrong. They’re usually partially right and almost always wrong about why. Your job in week one is to separate what looks bad from what’s actually dangerous.

Summary

This guide outlines a practical, week-one playbook for auditing legacy Ruby on Rails applications. Rather than starting in the code, begin by reading the signals: run stakeholder interviews to surface risky areas (deploy frequency, fear zones, blocked features), then form a working thesis by skimming three files—Gemfile, db/schema.rb, and config/routes.rb—to spot dependency duplication, god tables, missing indexes, integer primary-key risks, and architectural routing issues.

After the initial read, prioritize security and dependency scans (bundle audit, Brakeman, bundle outdated) before other tooling. Use SimpleCov zero-coverage files as a “fear map,” measure SLOC and complexity (cloc, RubyCritic), inspect model structure manually and run active_record_doctor and Bullet for DB and N+1 problems, and time the test suite to gauge developer feedback loops. Deliver a concise, single-page triage with prioritized risks and next steps rather than an exhaustive report; AI tools can accelerate repetitive parts of the audit but should complement, not replace, human judgment.

I think the lessons here are well structured and easy to “port” to other frameworks and languages, with appropriate file and tool modifications.

Source: How to Audit a Rails Codebase: Legacy App Playbook

A good security approach when working with Azure-hosted databases is to connect through a VPN tunnel.

This typically involves installing the Azure VPN Client and importing a profile file, and then starting that VPN tunnel before connecting to the database.

On macOS the above creates a system-wide VPN profile, which means it can be started from the command line with:

scutil --nc start "vpn profile name"

Which in turn means that we can have DataGrip automatically start it before opening a connection to the database.

Steps are as following:

1. Locate the name of the VPN profile in macOS System Settings -> VPN.
   Mine is prod-shared-vnet.
2. After selecting the desired data source, open the Options panel.
3. Find the Before connection section, click + to Add New Configuration and select Run External Tool.
4. Create a new tool with an explicit name like “vpn connect”, then enter:
   1. Program: scutil
   2. Arguments: --nc start prod-shared-vnet, or whatever is your VPN connection name.
5. Make sure the “vpn connect” external tool has been selected before returning to the Before connection section.

Note:

• executing the first query fast enough, before giving the tunnel a chance to fully connect, might fail with a “Cannot find server” or something similar; retrying works pretty reliably.
• for other connections to the same server, just select the existing tool.
• scutil --nc stop prod-shared-vnet disconnects the VPN tunnel. It seems to also drop when the computer goes to sleep.

Screenshots below.