Principal Software Architect at Tint (@heytint)
San Francisco, CA
Joined July 2008
- Tweets16K
- Following567
- Followers1K
- Likes1.5K
Jonathan P. retweeted
volume does matter
look, i get it. if you were an engineer before agents came along, you're rightfully skeptical about lines of code and number of PRs being used as a metric for any kind of productivity. and i agree! or at least, i used to. for ease of explanation i will talk about this from the perspective as being an engineer on a large team of at least 50.
volume didn't matter before because we focused on impact. you could have high impact even with a few PRs: for example you could make a one line config change and save the company millions of dollars.
but before agents, the times where i saw volume come into the conversation were for the outliers. on the negative end you might have someone who is struggling to perform, on the other end you might have someone who was a "coding machine" archetype. a coding machine was someone who could just lock themselves in a room and emerge with a stack of PRs that solve a huge number of problems. so volume did matter, but only at the tail ends of the distribution, and combined with impact.
if you've ever worked at a large tech company before, you'll get what i mean. the thing about agents is that big tech co problems are now small-medium co problems as well.
how do agents change this calculus? well, everyone now has the ability to become a coding machine. you have incredibly capable frontier models that can write code better than any of us, at a rate much faster than we can. in this world, if you're still producing the same number of PRs as before, why wouldn't you pause to wonder why you're not being more productive? alien intelligence is here, and yet you can't outship a human coding machine?
this brings me back to why i keep talking about trust (xitter.cf/poteto/status/21020504…). if you haven't put in the work to trust your agent's output, it is very difficult to scale up your productivity.
and yes, this approach does require more tokens, but i think about this in terms of cost per intelligence. before agents, this cost was very high - you needed to hire many software engineers with high 6 figure salaries to do the work. tokens are still expensive today, but are likely to get cheaper over time (xitter.cf/theo/status/2107924138…) factoring in the cost of intelligence. what looks exorbitant today will likely be affordable in 6 moths to a year. a single engineer with agents can do the work of tens if not hundreds of engineers, at a fraction of the cost.
the reality that i don't think has hit yet is that job of the software engineer has truly changed. our job is not merely to produce software any longer (well tbh it was never only about the code, but bear with me for the sake of the explanation), but the machine that writes the software. this idea of a software factory, or a Michelin kitchen as i like to call it, is still a topic of research. and it's the type of stuff i like to share, not to flex, but to show you what's possible when you put a lot of rigor into using agents at scale
Inspiring post by @linear: how they sped up their #CI, one of the new bottleneck at the #AI era: linear.app/now/ci-bottleneck…
A very inspiring video to start with #Pi, by @IndyDevDan. I'm going to experiment with it in the coming days/weeks. My main motivation: having a model-agnostic #harness and playing with open-source models!
youtube.com/watch?v=f8cfH5XX…
Jonathan P. retweeted
New blog post: Self-hosting LLM models for software development
It's surprisingly easy to self host a medium-sized model.
Cheaper than I expected!
Performances are good enough for me to reduce my Claude personal subscription.
kmaschta.me/blog/2026/09/22/…
Being wrong is the best way to learn! Iterate fast, be wrong often, and gain experience from the failures!
Boris Cherny talking about how he's often wrong about stuff, and how he uses that to improve things.
borischerny.com/management,/…
Great introduction on how to train a fine-tuned model. Very interesting, especially as I didn't really know where to start from.
Jonathan P. retweeted
OK. It's time to rethink this.
I've spend the last several weeks working on a harness that tightly constrains the agents to work the way that I want them to work. I set up all kinds of gates, and tests, and tools, and protocols, and ...
And while I was heads-down getting that to work, the agents got a LOT better. So much so that when I came up for air, the need for my harness was obviated. Indeed, the need for _any_ but the most liberal of harnesses may be obviated.
Just how good these things have gotten blows me away. I have had long debates with grok and codex about the structure of systems -- as if they were senior engineers. They often disagree with me and have their own perspectives. I have, more than once, found myself agreeing with their views.
I have not given up on constraints and tooling. Unit testing is still important. So is CRAP and Mutation testing. These tools still find bugs and offer useful constraints, though they can leave scars.
However, the agents have gotten so good that I can now give one a very significant task with a few guidelines and it will faithfully implement it. I can walk away for 40 minutes and when I return it will be done. CRAP will be satisfied, Coverage will be high, and Mutation testing complete. The architecture will be clean, and the code will be very good.
The end result may not behave perfectly, but it's so close that a couple of tweaks usually puts it into place.
What does this mean going forward? I'm not sure. But I'm beginning to think that harnesses should not treat agents as components within a software design.
Jonathan P. retweeted
One pattern I find useful for working with LLMs is a nice long ramble session. Sometimes the LLM needs more bits to understand what you're trying to achieve, but you're too lazy to type them. In these cases I like to lean back, switch to /voice and just ramble for like 10 minutes, total mess, anything goes, full stream of consciousness. Sometimes I declare it up top, something like "switching to speech recognition sorry for any typos...". Sometimes I turn it into a small interview of a few turns. But I find that the LLMs are somehow very good at reconstructing long incoherent rambles and often their echo of your own tangle of thoughts comes out quite a bit cleaner than what you started with. The result is that you improve the mind meld and have to correct things less from that point on.
This is the core of software engineering during the #AI era in my opinion. Product could ship features developed with #LLMs today. The value brought by Engineers relies in the harnesses ensuring a high quality, security, and reliability.
Thanks @rophilogene and the whole @Qovery_ team ! You were super fast to iterate on top of our solution, and the RDEs have been filling our need really well so far!
Just discovered #Stryker, a mutation #testing framework. It looks like an interesting alternative to test coverage. It changes your code, and validate that your tests are failing. If not, you may not have tested all the paths.
stryker-mutator.io/
I switched our code review skill (launching 6 agents in parallel) to the new #Opus workflow feature.
The gains are impressive: execution time cut in half, token usage reduced by 80%, and a higher reliability thanks to the JS execution.
Big shoutout to the @ClaudeDevs! 🙌
I am now able to launch #Claude within an isolated and secured @Hetzner_Online #VPS. It now runs in YOLO mode, without worrying about data exfiltration. As a bonus: I can now launch my own environment from my phone too! 🚀
jonathan-petitcolas.com/2026…
That's also my view on it! Better for those who comply with their ToS.
Jonathan P. retweeted
¿Como estar actualizado en AI?
Para mi, la comunidad tech acá es de lo mejor para esto
Si quieren estar dos semanas adelante que linkedin, recomiendo a:
@trq212 @bcherny - Claude code
@thsottiaux - OpenAI
@LLMJunky - Crack total en Codex
@karpathy - No necesita intro
Ustedes, a quien recomiendan?
Jonathan P. retweeted
At any other company, the person who just leaked 512,000 lines of source code, internal model codenames, and an entire product roadmap is clearing their desk by lunchtime.
Boris built Claude Code from a side project into $2.5B+ in annual revenue and 4% of all GitHub commits. His public response to the leak: the system failed, not the person. A manual deploy step should have been automated. One missing exclusion rule in a package config let a .map file slip into a routine npm publish.
The companies that fire the engineer who made the mistake get exactly one outcome: every other engineer learns to hide their mistakes. Near-misses go unreported. The next config error gets buried instead of flagged. You trade one public incident for dozens of silent ones.
Google codified this into SRE doctrine fifteen years ago. Every major outage postmortem at Google, Amazon, and Microsoft runs blameless by default because the math on incident frequency proves it works. The teams that punish errors have higher error rates. The teams that instrument errors have lower ones.
Anthropic just exposed their entire product roadmap to every competitor in the space. The response from the head of the product: here's what broke in the process, here's what we're automating, here's what ships next to prevent it.
That's how you keep the engineers who build billion-dollar products from leaving for the company that won't fire them over a config file.
Mistakes happen. As a team, the important thing is to recognize it’s never an individuals’s fault — it’s the process, the culture, or the infra.
In this case, there was a manual deploy step that should have been better automated. Our team has made a few improvements to the automation for next time, a couple more on the way.
I forked this public official repository from @AnthropicAI: github.com/anthropics/claude…. I wanted to see if I could help with some @claudeai issues, as it seemed open-source.
Today, I'm receiving a #DMCA notice? It looks super aggressive for an open-source repo, isn't it?
