Golf courses don’t have backup generators running 24/7, with humming you can hear from a meaningful distance away. They also don’t pollute the air.
This is a poor comparison, but I do get what you’re attempting here. It’s also absurd that we are leveling land everywhere around me to build warehouses. No one is really complaining about that, either.
Yes, same, between the two of them I feel like results are just better because they have different priorities.
At the same time, I’ve invested in tooling that prints and lints architecture I want, so which model is less of an interesting decision, because the results tend to be very close.
> in some areas, especially customer-facing sales, we expect to keep adding to our teams to support future growth
Can someone help me understand why sales is immune to this strategy and still is employing the “more bodies” approach. I thought we were working smarter in 2026?
> the code it produces is slop, but that’s more the fault of the model than the harness not being a good judge on if a step in the workflow resulted in a net improvement or completion.
I don’t know. I’ve invested heavily in building internal tools that scaffold code and lint the filled in architecture/code design. That with a ratchet pattern, to allow for new rules that have errors across the existing code base, but to asymptotically fix them, is working pretty well.
Example - all modules have tightly scoped design primitives (I’m using hexagonal architecture for the backend, for example). And all code has BDD tests, which is what I spend much of my time reviewing, since cases written in human sentences is easier than looking at so many files of code.
There is a relentless upkeep to draft rules that respond to the workarounds the agents come up with to adhere to the design I want, but it’s slowly approaching perfect. What has helped here tremendously is I use hooks to llm as a judge the decisions the llms make, and then have them review/raise the questionable ones after a first pass is completed. In general, this is snuffing out the slop effectively.
All to say, someone asked me recently what model I prefer. In this approach, the model doesn’t really matter to me because the code is consistently what I want. I’ll choose a model because it has better mcp speed (codex), or a more thorough scope (Claude code).
Where this IS true is when we’re building a net new pattern. The agents are not great at it. BUT most code can fit into the few patterns I’ve created, and what can’t you lock down a new pattern to enforce over a couple iterations of it. Almost everything, at least in SaaS, follows a template.
Is anyone else troublingly addicted to your code agents? I’m constantly thinking about work because work is “just wrapping up” always now. I go to see one thing is done, outside of work hours, then find myself kicking the next thing off.
Who is this good for? My company, Anthropic/Openai, but not me? Maybe if I was investing in a side project I’d feel differently.
At any rate, the thought of bringing the agent out of my work machine and into my pocket or bed with me is terrifying. I hope it doesn’t come to that.
I guess what I’m saying is that there is no “primary” goal, but rather a mix of things to consider, where it working at all as expected is just table stakes.
> I don’t like senior developers who like trying new technology. I like ones that avoid more complexity.
I guess the author has never worked on a dog shit system with no tests at all and constant downtime.
I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done.
I just don’t believe that using new tools is at odds with avoiding complexity.
Sometimes you have to take it to the chin, and get to use the new shiny thing along the way to move much faster.
Good architecture is not about the patterns you pick. It’s about having a team dev cohesively on any pattern(s)
- programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated
- if you # ignore anything, leave a comment explaining why
- use bdd so your cases are human readable and must update with the code (unlike a stale comment)
- follow the same pattern in all your services (I love hexagonal design for backend). If you break from the design have a good reason for it
- COMPOSE your code. It’s almost always the case that two endpoints or jobs or whatever happen to have a few things in common, but differ wildly. Don’t get DRY, just import those things in each spot and don’t entangle them with each other, it’s too confusing
- scope your interfaces tightly. No optional params unless the domain is actually optional. Make separate jobs or endpoints for different configs. I can’t figure out wtf all your configs were from 4 years ago and neither can you
- code is default testable with DI/DIP
- always run tests running real infra like testcontainers
- cement ci/cd as your guardian. Employ every linter you can.
- hammer workarounds with comments in the code
- break all systems into small problems and nothing is challenging technically (though the domain might be!)
- work with less people on your code. It’s easier to stay aligned and follow the same patterns
- don’t expect anyone to figure it out. You need to champion your changes. Do code reviews, hold their hand, show them the way
- clear out mundane items like installfests, local auth, server reloads. Slow dev pisses people off
- finally, and most important, employ an org policy for review. Don’t let shit fall through the cracks unknowingly. It compounds. You have skills now as a quick and dirty to eval and enforce. Use them!
> The ultimate goal of software is to solve the immediate problem at hand. The secondary goal of software is to solve likely future problems with as little work as possible.
Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have full access to, because they needed to get a modal component out the door, but were blocked because they “couldn’t upload the image to s3.” (They could just use the public/ or assets/ directory and have the cdn pick it up, too.)
People do the most insane things when they are tight on time and don’t have the intuition to do a bit of research up front. If you ask them, they’re solving the immediate problem at hand. If you ask anyone else who interacts with their work, they’re disrupting our days/weeks/months/years when we have to step through systems that don’t know any better.
If you have the muscle to plan ahead, even a little bit, which is usually just following the same pattern over and over again, then you are fine.
In this world you are still optimizing for the now problem but you have also solved, to some and ideally a better degree, some future problems for free
Says who? One of the most enriching things about coding with agents is I have them provide new information, tools, patterns, whatever as a follow up to every feature I work on. I’m learning a ton and it’s helping me build better with agents, too.
Build CLIs your agents call, that scaffold what you want, and lint so it actually does achieves your intended design.
Markdown files are a good reference but they are a weak enforcement tool and go stale easily.
Avoid burying yourself in more skills docs you’re not even writing yourself and probably never even read. Focus that toward deterministic tooling. (Not that skills or prompts are bad, I agree a meta skill that tells an agent what subagents and what order to run is useful)
There’s too much in this article to comment on it all, but if we zoom into the first claim:
> An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.
My question is why isn’t there an effort from the author to mitigate the insane things that LLMs do? For example, I set up a hexagonal design pattern for our backend. Claude Code printed out directionally ok but actually nonsensical code when I asked it to riff off the canonical example.
Then, I built linters specific to the conventions I want. For example, all hexagonal features share the same directory structure, and the port.py file has a Protocol class suffixed with “Port”.
That was better but there was a bunch of wheel spinning so then I built a scaffolder as part of the linter to print out templated code depending on what I want to do.
Then I was worried it was hallucinating the data, so I wrote a fixture generator that reads from our db and creates accurate fixtures for our adapters.
Since good code has never been “explained for itself 100%, without comments”, I employ BDD so the LLM can print out in a human readable way what the expected logical flow is. And for example, any disable of a custom rule I wrote requires and explanation of why as a comment.
Meanwhile, I’m collecting feedback from the agents along the way where they get tripped up, and what can improve in the architecture so we can promote more trust to the output. Like, I only have a fixture printer because it called out that real data (redacted yes) would be a better truth than any mocks I made.
Finally, code review is now less focused on the boilerplate and much more control flow in the use_case.
The stakes to have shitty code in these in-house tools is almost zero since new rules and rule version bumps are enforced w a ratchet pattern. Let the world fail on first pass.
Anyway, it seems to me like with investment you can slap rails on your code and stay sharp along the way. I have a strong vision for what works, am able to prove it deterministically with my homespun linters, and am being challenged by the LLMs daily with new ideas to bolt on.
So I don’t know, seems like the issue comes down to choosing to mistrust instead of slap on rails.
Edit: I wanted to ask if anyone is taking this approach or something similar, or have thought about things like writing linters for popular packages that would encourage a canonical implementation (I have seen some crazy crazy modeling with ORMs just from folks not reading the docs). HMU would love to chat youngii.jc@gmail
I watched the demo video on the git butler home page and agree with the premises that:
1. git is not going away
2. git UX is not great
So i appreciate their effort to manage development better as agents make it possible to churn out multiple features and refactors at once.
BUT, I reject this premise:
3. Humans will review the code
As agents make it possible to do so much more code (even tens of files sucks to review, even if it’s broken into tiny PRs), I don’t want to be the gatekeeper at the code review level.
I’d rather some sort of policy or governance tooling that bullies code to follow patterns I’ve approved, and force QA to a higher abstraction or downstream moment (tests?)
> Tests created a similar false comfort. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant contributor to my lack of trust and the decision to scrap everything and start from scratch.
This is my experience. Tests are perhaps the most challenging part of working with AI.
What’s especially awful is any refactor of existing shit code that does not have tests to begin with, and the feature is confusing or inappropriately and unknowingly used multiple places elsewhere.
AI will write test cases that the logic works at all (fine), but the behavior esp what’s covered in an integration test is just not covered at all.
I don’t have a great answer to this yet, especially because this has been most painful to me in a React app, where I don’t know testing best practices. But I’ve been eyeing up behavior driven development paired with spec driven development (AI) as a potential answer here.
Curious if anyone has an approach or framework for generating good tests
This. I have effectively used multiple agents to do large refactors. I have not used them for greenfield development. How are folks leveraging the agentic swarm, and how are you managing code quality and governance? Does anyone know of a site that highlights code, features, or products produced by this type of development?
This is a poor comparison, but I do get what you’re attempting here. It’s also absurd that we are leveling land everywhere around me to build warehouses. No one is really complaining about that, either.