Machinists > Tailors

Machinists > Tailors

Software engineers are turning into AI Engineers? No, we are turning into software machinists. Replacing handmade software with (increasingly) cheap, plentiful, machine-made software. Unlike tailors who handcraft each item, machinists build tooling and inspect samples and then produce in large numbers.

Mid 2025 tab completion was a toy. I didn't really use it and was no slower than colleagues who did. I shipped around 60 PRs a month in 2025 and barely used AI. Around September 2025 I confidently told a table of other engineers that there was no chance I would stop writing code. I simply loved it too much.

Then Opus 4.5 happened and by chance I changed laptops. I realised at the end of January 2026 that I had not written a line of code by hand. I hadn't even installed an IDE on the machine I was using. I merged 62 PRs in the PostHog monorepo in Jan 2026, roughly the same as any month in 2025, but all without typing a single line. And I loved it. It made me wonder if I was that wrong in September, then how wrong was I now?

Observing the changes in how I work, and how my colleagues work, I see a number of common changes:

• we are tech leads for a team of junior engineers now
• the code is not for us
• paying attention to context (pun intended) is even more important

And have some predictions:

• continuous integration and review will change next
• we make tools for our workshop

Ok, some folks are still working on systems with critical safety requirements or high performance systems where it is easier to cause an incident and things have changed less for them. But the majority of us now have a different job. It is no longer sufficient to pore over every line of code, following the practices of bespoke tailored software engineers. Now we are software machinists.

Observations

We are all tech leads now. Leads of a team of robo-juniors

Tech leads set direction and curate team habits so that the group becomes more effective over time. Our robo-engineers are not curious, so with a robo-team it is up to us to set direction. In the past this was necessary because it helps us do better work. Now it is necessary because the robots won't do it. It's one part where the human is value-add. To quote Kent Beck after he first tried using ChatGPT: "The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate".

The tech lead was always responsible, not for reading and reviewing all the code, but for setting direction. For being the casting vote when there is disagreement. They follow the work of each team member in enough detail that they can share context without getting into the weeds of each piece of work.

Now we do that for our robots. At first it was by choosing when to hit tab, then the prompt, the context, the harness… increasingly at PostHog I see even that work delegated. Several people will ask our Slack agent to create github issues when they see a thread they want to act on. Those issues are picked up by our self-driving tooling and they will be tagged on the pull request when it is generated.

A lead is responsible for paying attention to overall quality of the systems they own. Importantly, that's not quality per PR. Your team should be able to review each other's PRs without you. Your responsibility is the quality over time. Unintended consequences accrue over time as well-intentioned decisions in each change combine in a way you didn't expect and wouldn't have chosen.

To cover this I have been using Scouts (agents that run on a timer). I have a suite of "complexity hunters". They check for cyclomatic complexity because even with agent-written code, we see exceptions cluster in complex code. And then they open PRs to split this up. Using skills to guide how we like to see code split, not just chasing a complexity score.

The hunters check for share of comments in a diff, we've seen that grow from 2% to over 9% before getting things back under control. And they check for known shapes of bugs we've seen more than once. Like forgetting to use a different serialiser in an API for listing things, or using a Django TestCase that sets up the database only to run tests that don't make any queries.

The complexity hunters have merged 47 PRs in the last 30 days. These PRs are mostly reviewed by other agents. The job of the software machinist is to make it safe not to review the PRs. This one set of scouts are shipping almost as many PRs in a month as I was each month through 2025.

Leading from a place of trust means coming to understand what different models are capable of. To delegate to my robo-team members appropriately. Giving them the right instructions and guard rails so that they can do good work. It means not always reading every line of code because we trust the system built around the work of the robots. Knowing when a task needs closer attention and when it needs none at all. Setting up the practices that team members can follow so that lessons learned are baked into our habits.

I have a review skill that is "trained" on the history of my PR reviews at PostHog over the three years before AI really took off. Another that is trained on the wisdom of the conversations on c2wiki.com. Where the folks that went on to write the agile manifesto and in other ways shape modern software engineering would discuss how they thought about engineering. These and other skills run on a variety of models and their reviews automatically become prompts that ship fixes to my PRs. I only get involved when that all has settled.

In the same way that I don't check the work of prettier when it reorganises my files. I don't check the individual steps of the work of these reviewers. I only look at their final output. The job has always been about delivering the most value for the least effort. How I express that is different now. I can fight it or I can shut up and ship some value. 2025 Paul would never have handed over review to automation. 2026 Paul can't afford not to.

The code is not for us

The better the robots become, the less that the code is for the humans.

To quote my colleague, Tue Haulund:

I'm sure when the first FORTRAN compiler was released, for a time, engineers still read the machine code output that it produced to make sure it was up to scratch. Who does that still? Compiler developers and nobody else. It will be like that for generative LLMs producing code also. Imagine someone making the argument that if you don't read, understand and verify all the assembly that GCC outputs then they're not a real engineer or they're somehow not doing their job.

Sure, compilers are deterministic, so this doesn't map one-to-one onto agent driven work. But it shows that as technology changes our behaviours around it will need to change.

This can be seen not just at the technology level. As soon as a company is large enough you don't read all the code. Another team ships an API. You may write some integration tests but you use the API without reading its code. You install a dependency and you don't read the code, you write some tests to verify it works and you move on.

Now that it is cheaper to generate code I have to treat the work of the agents in the same way. I don't read it. I verify it works. We take the behaviours that protect us and double down. Having strong habits and automation around validation has always been a multiplier for how fast you can safely mutate your system. As we speed up the ability to create and change our software this becomes more important. Reading the code was only ever a part of that validation so that the human could understand the interaction between the desired impact and what needed to be validated.

Paying attention to context (pun intended) is even more important

An old colleague, Andy Longshaw, used to say "A problem has a solution in a context". Even within one organisation there is more than one context for the work of doing engineering. In test driven development people talk about "driving in gears". The idea that just like you have to drive in the right gear for the terrain and conditions the way you write code and tests changes as the context of the code changes.

Folks who are working on high performance or critical systems will be less likely to allow robots to self-drive their systems with minimal human interaction. I made a mistake once in a change to PostHog's ingestion pipeline that increased CPU usage. The runaway impact led to an hours-long incident call as we fought to stabilise the pipeline enough to recover from the backlog that was caused.

In that type of system accepting a change is more complicated. Deployments are split into stages and the new code taking effect is separated from the deployment of the code so that it can be safely rolled out. Robo-juniors still need much more shepherding to achieve this kind of work.

Even here they can help. For example, in our JS SDK repo we have a list of code areas that were involved in significant bugs. We automatically flag when a change touches one of those areas and have a skill that teaches an agent how to go deeper in a follow-up if the validation flags a change. Encoding organisational knowledge in an active way to help improve safety.

Or we surface checks from CI back to the agent. When a PR might change an API and the desktop app at the same time, we warn the agent that it needs to deploy the work to change the API first or make the change backwards compatible. And that problem doesn't need to bubble out to humans unless the solution isn't clear.

Predictions

Continuous integration and review will change next

Theory of constraints suggests that continuous integration and review will change next. This theory tells us that every system has one step that is slower than all the other steps. That slow step sets the speed of the whole system. We call it the constraint (or the "bottleneck"). You can learn more in The Goal from Dr. Eliyahu Goldratt. I’m lazy, so I recommend the graphic novel of the book.

Now that robots can speed up PR creation, PostHog has seen around a 5x increase in PRs against a 1.5x increase in headcount, that creation is likely no longer your system's slowest step. The next steps in the chain are to review, build, test, and then deploy your system. One of those becomes the new bottleneck in your delivery.

We are forced to focus even more on "the work not done". For example to reduce unnecessary CI steps. PostHog ran 46 years of CI time in August 2026 (kudos to depot.dev for absorbing the growth). Allowing this to grow unbounded is unsustainable even just economically. In September we had this down to 36 years of CI time. There’s the value of the work not done, we merged 26% more PRs but CI time fell 22%.

We expect to see software services and tooling flourish here. This new bottleneck will need new solutions to help us deal with this growth in code creation. I’m thinking about how we present changes so that we can care about each agent-driven PR roughly as much as we used to care about each commit in the PRs.

The next discovery for us is what tooling and behaviour has to change to make this safe. Of course, it is possible that it cannot be made safe. And then we also need to recognise that and put back pressure in place to avoid overwhelming the system with fresh PRs when there is already too much work in progress. One consequence of the theory of constraints in a production line is to teach us to control work entering the system, as well as to increase it at the slowest point.

I have never recommended that people try to read every PR. Instead we set up the guard rails that help the members of the team make decisions and then step back and let them work. We have an agent called StampHog that has a set of rules of how to decide if a PR is safe to approve without needing further review. It can approve a PR without other human interaction. About 30% of our PRs are approved by StampHog. For around $910 a month in token costs. Fantastic value for money to speed up other work.

StampHog is open source so you can see how it works. But how can I be sure it’s not a slop cannon? At PostHog we are quick to revert a PR if there is even a hint of a problem. In January 2026 1.5% of our PRs were reverts, in August 2026 just 0.25% of PRs were reverts. I’m confident from how we measure the system and from user feedback that we’re not shipping fast just for the sake of it.

And for the PRs that aren't an easy stamp, we have ReviewHog. This goes deep on reviews and you can apply your own skills to extend the reviews on your PRs. Humans at PostHog tend to take half a day to get around to reviewing a PR. It takes ReviewHog 30 minutes to do a deep and thorough review.

We run evaluations against our AGENTS.md making a change with and without it present to check that it is actually guiding our agents and scoring various models to keep track of how they behave. And have various models recreate human-only pull requests from the before times to score how well they mimic accepted changes from the past.

We make tools for our workshop

Machinists, of course, do one-off work to make tools for the workshop. They make them cheaply and often throw them away, because they’re just as cheap to make again. And so we should expect to see some systems be completely ephemeral, while others will be critical. When the cost of making code is low, people will make very quick apps to solve their problems. The opportunity for organisations to identify when something is useful and to promote it from “ephemeral” to “critical” will be powerful.

We are already seeing this at PostHog as people generate new apps to manage PR reviews, present diffs in new ways, manage CI and review shepherding across tens of PRs at a time, and even ship wasm to the browser so they can embed doom in our main product. And they are doing this alongside their primary work not instead of it.

My colleague Tom Owers has made Talyn. He uses it to manage the hundreds of PRs he generates expanding the range of sources our context warehouse can handle. Talyn started as one person’s vibe-coded app and now multiple people are using it and contributing to it. Alongside it, he made totally custom software to manage tracking requested sources and replying to people automatically when they’re shipped. Several others have made applications to visualise and review changes through multiple lenses. Our devex team has made an application to group and prioritise github notifications so you can focus your attention when unblocking others.

Here is a real impact of the switch to machine-made systems over bespoke systems. The ability to very quickly retool and deliver products is enhanced. This is a new expression of agility and craft. Something that wasn't available to as many organisations as before. These applications might continue to be worked on, they might be thrown away and serve as inspiration to the replacement. When the cost of making is low, the cost of discovery is lowered.

Generating SQL queries and UI over your data is available to more people on a timescale that wasn't available before. When I worked at Co-op Digital we had a large team that spent many months making a repeatable web platform on top of a design system in order to industrialise the production of content driven websites. I would expect that to be days or weeks not weeks or months now.

But I would also expect the bottleneck there to still be the design system. At co-op one problem was that with so many teams and departments systems that were built looked, behaved, and felt different. And so their design system was critical. That work is still hard and still essential.

Since the barrier to entry for SQL queries has fallen, the barrier to generating a bad query or analysis has fallen too. At PostHog we've had to build a "semantic layer" so that we can have one place where the robots can look-up meaning to guide their decisions. Otherwise nuanced questions like "What is the revenue of product X" can have varying answers. We don't want to restrict who can ask which question, we just want tooling that enables good answers.

So, some of the systems we use now will be almost entirely ephemeral. Entirely validated by their behaviour, generated on-demand, cheap to create, and so cheap to throw away. Others will be all the more critical. Being built and validated more carefully under the increased rate of change. As the cost of creating these things falls. The shared layer, things like your design system or security controls, becomes even more important, contributing to your ability to maintain a high pace safely.

The conclusion

There isn't one kind of engineering job. This is true at PostHog where we have teams that cover a range of responsibilities: growth, products, ingestion, ClickHouse, billing, and more. And so it is easy to make statements that will work for one group and not at all for others. But that won’t stop me. Most engineers need to stop trying to read the code and start trying to make it safe not to read the code. Even if agents don't improve their capabilities from now, the job of a software engineer has changed. If they keep improving it will be fully transformed.

This might feel uncomfortable but we mustn't complain about "slop" any more than a sailor should complain about the weather. Instead we must act to make our systems better. Taking advantage of the tools available to us. Like a machinist we build tools to do the work and the checks that test it.

Don't stop the slop

I've long avoiding saying "legacy". I think it's lazy to use it. It's always seemed to be a term to group together "a bunch of stuff i don't like".

Same with technical debt. Which I wrote about at length a few years ago.

They're words that mean "i don't like that" or "i wouldn't do that"

Worse. If you say them to ten people at least eleven different definitions were heard. It's just not good communication.

And now everyone says "slop"

How I use LLMs? - six

Let's growth hack blog visitor numbers and keep on recording how I use agents/LLMs today as a little reflection on where I think they work and where they don't. Something I can revisit as the tech (and my skill with it) improves

This is update number five, or entry number six, depending on how you want to count it.

• part 1 - structured tone of fascination + scepticism
• part 2 - learning how to manage and control them
• part 3 - reluctant acceptance but also thankfulness (?) of what they do for you when you let go of control
• part 4 - realising even though it's no longer "braincode" + no longer for humans, it still comes from human brains
• part 5 - oh no, am i AI pilled

someone at work named the episodes for me, i love it

so now… part 6 - i think maybe everything changed

in today's edition of AI hot takes

• saying "slop" considered harmful
• ship value, not craft
• don't read code
• manage loops and context - fuck prompts
• if you make me copy & paste a prompt you've lost me

How I use LLMs? - five

I have lost roughly 60% of my cynicism about the current high-water mark for LLMs and augmented coding… I am certain this last 9 months has been a significant generational change in how we can approach work.

Oh no, I'm AI pilled

Let's growth hack blog visitor numbers record how I use them today as a little reflection on where I think they work and where they don't. Something I can revisit as the tech (and my skill with it) improves

This is update number four, or entry number five, depending on how you want to count it.

• part 1 - structured tone of fascination + scepticism
• part 2 - learning how to manage and control them
• part 3 - reluctant acceptance but also thankfulness (?) of what they do for you when you let go of control
• part 4 - realising even though it's no longer "braincode" + no longer for humans, it still comes from human brains

someone at work named the episodes for me, i love it

so now… part 5 - yee haw, paul is AI pilled

in today's edition of AI hot takes

• the agent is my to-do list
• no longer focused on the code, 5% focus down from 95%
• i don't use these tools, i hire them into my team
• genuine frustration when they lack autonomy
• stop making me tell you when to run
• skills skills skill skills

Where have I been?

At a recent company offsite a bunch of people asked me how many of the off-sites I'd been on. I didn't remember so I made this list since if I don't remember now I have no chance of remembering in 5 or 10 years.

Let's plan that

My favourite quote is "The plans are useless, the planning is essential"

Since the plans are useless, why do we run planning sessions at all?

It's planning season at work. We are high trust, high agency, and minimise collaboration. It is pretty common for folk to change their plans and they do so without needing to seek approval.

Without shared context and an understanding of the broader picture, people would change plans but be pulling in different directions. Having the big picture means you can rely more on instinct and curiosity rather than rigid plans.

How I use LLMs? - four

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

Let's growth hack blog visitor numbers record how I use them today as a little reflection on where I think they work and where they don't. Something I can revisit as the tech (and my skill with it) improves

This is update number three, or entry number four, depending on how you want to count it.

• the first entry is here
• the second entry is here
• the third entry is here

in today's edition of AI hot takes

• basically never braincode
• it's still about your brain
• hot take

I shipped 1000 PRs in a year, AMA

I shipped 1000 PRs in the last 12 months at PostHog. And someone asked me how I do it… let's see if i know.

preamble

• yes, yes, I know you don't think I should count PRs
• when a measure becomes a target it stops being a useful measure
• embrace yourself

advice

• it is running not cycling
• small steps ftw
• practice like a jazz musician
• love making things
• one more iteration

How I do user interviews

I've been lucky to watch some excellent engineers, product managers, and user researchers carry out user interviews.

And had the opportunity at PostHog to practice that skill. I've explained all this a couple of times to different people, so thought I'd write it down.

• set expectations
• write down quotes
• show > tell
• compound interest
• sometimes stop
• be a Labrador
• this is the redesign that will kill the the Facebook

How I use LLMs? - three

I remain very cynical about the current high-water mark for LLMs and augmented coding… but at the same time I use them every day and I don't think they're finished improving.

Let's growth hack blog visitor numbers record how I use them today as a little reflection on where I think they work and where they don't. Something I can revisit as the tech (and my skill with it) improves

This is update number two, or entry number three, depending on how you want to count it.

the first entry is here the second entry is here

• XP pedant agent
• primarily using LLMs
• throw away way more work
• be very strict with what i do type
• i approach understanding code differently