Jujutsu is a new version control system that is backward-compatible with Git. All the cool kids are raving about it. In this article I will try to help you decide whether it’s worth investigating.

If you use git rebase, the answer to this article’s question is probably yes. You will mostly likely love Jujutsu. Proceed to Part Two. Do not pass Go. Do not collect two hundred dollars.

If you don’t use git rebase, you might still enjoy Jujutsu, but you might wonder, why would I care about all this fancy stuff? All I do with Git is commit and occasionally sync with main… what more could I possibly want?

Folks are starting to figure out what kind of environment AI agents need to be productive. The gist is:

• Agents need clear guidelines in a markdown file at the root of the repository explaining how to contribute to the project.
• Agents need a clean, isolated, reproducible environment in which they can run tests and go wild without breaking stuff and getting stuck.
• If the environments are sufficiently isolated, you can run them in parallel and allow multiple agents to work concurrently.
• Agents need fast tools so they can get feedback quickly. Tests should run fast. Speed of the iteration loop is everything.
• Documentation and code comments help agents figure out what’s going on.
• Agents work best with small contained tasks which can be reviewed and deployed continuously, rather than in huge risky chunks.

What’s maddening is, if you replace the word “agents” with “humans”, all these sentences are equally true, if not more so.

When I started at StrongDM five years ago (woah), we had zero automated tests. Last year we had 50,000 tests. Today, around 70% of our code is covered by over 100,000 tests, most of which run on every pull request.

What follows is my personal opinion about what constitutes a “good” automated test based on my observation of this colossal increase in test coverage. The goal is not to convince you I’m right, but to draw some contrasts and provoke you to question assumptions and form your own opinions.

It’s a famous joke that naming things is one of the hardest problems in computer science. I think this alludes to a fundamental truth behind so many of the problems I encounter every day as a software engineer. Let me ruin the joke and reword it a bit.

The hardest problem in computer science is deciding whether two things are the same thing, or different. I don’t know if there’s already a name for this concept, but I’ll just call it the “identity problem”.

In 2019 we had roughly zero automated tests at StrongDM. We did manual quality assurance testing on every release. Today we have 56,343 tests.

Anecdotally, the rate of bugs and failures has not decreased by a commensurate amount. Instead I think it correlates with focused efforts we’ve made at various times to either ship big new features (resulting in many unforeseen bugs), or stabilize existing features (resulting in fewer bugs).

In March 2018, I had been a full-time indie game developer for four years. My heroes were Jonathan Blow, Lucas Pope, and Robyn and Rand Miller. I had 2,500 Twitter followers, an ambitious title under my belt with thousands of sales, and a free office in a hip coworking space near downtown Columbus, generously provided by some friends at a local game studio. I distinctly remember wondering why anyone would want to be something other than an indie game developer. I joked that I had a “disease” that compelled me to make games (my dad once told me that what people joke about speaks volumes). One month later, I was living in Los Angeles, working as a software engineer, and realizing I had just burned out of the game industry.

This post originally appeared on the strongDM engineering blog.

Once upon a time, strongDM had no dedicated frontend engineers. We backend engineers dipped our toes in the React frontend as infrequently as possible. It relied on dusty, bespoke, private REST endpoints that returned schema-less JSON blobs. We let these languish while we built a shiny new public API with code-generated SDKs in five languages. Occasionally I was forced to write a new private endpoint for the frontend. I did so with shame, dreaming of a future when the whole frontend would only talk to the public API. Then one day, we hired a frontend engineer, and everything changed.