Intro
The theme of this week is dev tools are agent tools too. So good practices are still just that. AI will change some things but it will mainly just reinforce the good practices of before. If you don’t have those set up, throwing money at AI isn’t going to change things for you a whole lot either.
Highlights of the Week
The Factory Model: How Coding Agents Changed Software Engineering
https://addyosmani.com/blog/factory-model/
The barrier to creating software has genuinely dropped. That is not hype. What it means for professional engineers is not that their skills are less valuable, but that the skills that matter have shifted up the stack, as they have in every previous transition.
The engineers who will have the most impact in this era will not be distinguished by how fast they type or how well they remember syntax. They will be distinguished by a different set of capabilities. Systems thinking. The ability to hold a complex architecture in mind, understand how components interact, and anticipate how a change in one place affects behavior elsewhere. This is harder to develop than typing speed and far more valuable when you are managing a fleet of agents whose outputs you have to integrate. Problem decomposition. Knowing how to break a large, ambiguous goal into well-scoped subtasks that an agent can execute reliably. Tasks that are too large tend to go off-track. Tasks that are poorly scoped get interpreted incorrectly. The skill of decomposing problems well, and then verifying that the decomposition was right, is a genuine craft. Architectural judgment. Understanding why a system is designed the way it is, what properties it is optimizing for, and what tradeoffs were made. Agents can implement. They cannot judge whether what they are implementing is the right design. Specification clarity. The ability to write requirements that are unambiguous, complete with respect to the important edge cases, and structured in a way that makes evaluation straightforward. Vague specs produce vague results. Precise specs multiply into precise implementations. Output evaluation. The taste to recognize when something looks correct but is not, when an implementation solves the stated problem but creates a new one, when the architecture of the solution does not fit the architecture of the rest of the system. This judgment is not automatable. Orchestration skill. The practical ability to manage multiple parallel workstreams, give effective feedback on agent outputs, recognize when an agent needs to be redirected versus retasked, and maintain coherence across a fleet of autonomous workers.
I do think the core skills of software engineers are mostly the same, only now there’s less emphasis on nitty gritty technical details and more on higher level concepts. Those were always present and required, only now they are even more so than ever.
I Sold Out for $20 a Month and All I Got Was This Perfectly Generated Terraform
This is a really good take from a cynic of AI tech to having their view on it changed. The job is no longer what it once was and things are changing now. Especially so for people who don’t care about so called code quality and instead have a problem that needs to be solved.
His approach to development is 80% refining requirements and getting feedback. He doesn’t care at all about DRY, he uses Node because then he can focus on just JavaScript, he doesn’t invest a second into optimization until the application hits a hard wall that absolutely requires it. His biggest source of clients? Creating fast full stacks because internal teams are missing deadlines. And he is booked up for at least 12 months out all the time because he hits deadlines. When he started freelancing I thought he was crazy. Who was going to hire this band of Eastern European programmers who chain smoke during calls and whose motto is basically “we never miss a deadline”. As it turns out, a lot of people.
He doesn’t see LLM-generated code as a problem because he’s not building software with a vision that it will still be used in 10 years. Most of the stuff typically associated with quality he, more or less, throws in the trash. He built a pretty large stack for a automotive company and my jaw must have hit the table when he revealed they’re deploying m6g.4xlarge for a NodeJS full-stack application. “That seems large to me for that type of application” was my response. He was like “yeah but all I care about are whether the user metrics show high success rate and high performance for the clients”. It’s $7000 a year for the servers, with two behind a load balancer. That’s absolutely nothing when compared with the costs of what having a team of engineers tune it would cost and it means he can run laps around the internal teams who are, basically, his greatest competition.
The Software Development Lifecycle Is Dead
https://boristane.com/blog/the-software-development-lifecycle-is-dead/
The future of observability isn’t dashboards, it’s closed-loop systems where telemetry data becomes context for the agent that shipped the code, so it can detect the regression and fix it. The observability layer becomes the feedback mechanism that drives the entire loop. Not a stage at the end. The connective tissue of the whole system.
Some things are now more important than ever and observability is one of them. It was always important just nobody really cared. I guess like proper documentation. Now though that the negative effects of it show up in agents performing poorly it is more evident than ever why it is important.
One List to Rule Them All - By James Stanier
https://theengineeringmanager.substack.com/p/one-list-to-rule-them-all
A single prioritised list is a forcing function, and it’s equally powerful at the individual, team, department, and organisational level. In fact, it gets more important the broader the impact. It forces the hard conversations to happen, because you cannot place two items in the same position, and someone has to decide which one comes first.
At PayPal, Peter Thiel insisted that every single person could only do exactly one thing. According to Keith Rabois, Thiel would refuse to discuss virtually anything else with you except what was currently assigned as your number one initiative. Annual reviews reinforced this: employees could only identify their single most valuable contribution to the company. Thiel understood that most people will solve problems that they understand how to solve, which means, in his words, that they will solve B+ problems instead of A+ problems. A+ problems are high impact, but they’re difficult, and you cannot immediately derive a solution, so you tend to procrastinate. The discipline of only being allowed to do one thing led to significant breakthroughs.
Focus on just one thing and do that well. Don’t look around for other things, just get the main thing done.
Minions: Stripe’s One-Shot, End-to-End Coding Agents
https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents-part-2
A minion run starts in an isolated developer environment—or “devbox”—which are the same type of machine that Stripe engineers write code on. Devboxes are pre-warmed so one can be spun up in 10 seconds, with Stripe code and services pre-loaded. They’re isolated from production resources and the internet, so we can run minions on devboxes without human permission checks. This also gives parallelization without the overhead of something like git worktrees, which wouldn’t scale at Stripe.
For maximum effectiveness, unattended agent coding at scale requires a cloud developer environment that’s parallelizable, predictable, and isolated. Humans should be able to give many agents logically separate work. Agents should have clean environments and working directories: it unnecessarily wastes tokens on resolution if agents are interfering with one another’s changes. Full autonomy also requires the agent to be systematically isolated from acting destructively over privileged or sensitive machines, especially with a human’s personal credentials.
This is, I think, the core takeaway from this. Build proper developer environments and agents can use them too. Good practices are good practices. There’s no need to have to figure out what script to run or repo to pull or keys to get, you just have your dev box and you can test out and be confident of the changes.