There is a psychological pull to keep agents moving, I feel like that is the path of slop. Delegate what makes sense to delegate when it’s ready to delegate, don’t treat subsidized token burn as a reason to generate code.
I honestly don’t think we know enough about the future to act right now. So far I have seen a lot of big swings and big bets on the future, and have yet to see a home run.
I think the big brain move right now is to pay attention and be ready to move, but move based on evidence not speculation.
Also, when people talk about “builders” it strikes me as sf bullshit language, it immediately raised my skepticism shield.
If you do not spend more time thinking and learning and improving as a software engineer while using AI, you are doing it wrong.
This should be a form of specialization. Trading technician skills for deeper engineering skills.
I understand the concern of skills atrophying when using agents. But so far I am not seeing it. Instead I have learned all sorts of dark secrets of linux networking I somehow didn’t learn before agents building a networking product.
The scourge of "Claude said..." is rampant.
If you use "Claude said", it had better be in a sentence that is structured something like:
"When I did some digging, Claude said <thing>, so I looked into that and it looks like it might work based on <x, y, z>."
not
"Well, Claude said <thing> so you're wrong."
Claude says many things. Claude is very often wrong. Even when it's right, you should know why it's right.
Own your work. Don't delegate all thinking to AI.
AI is the most transformational technology of my lifetime, and I lived through the internet getting big and smartphones being a thing.
How is it possible that I believe that 👆, and also think that AI is overhyped?
I don't understand why people use terminal multiplexers (tmux / zellij)
TTYs are a shitstorm of legacy standards.. All good terminals have solid split / tab implementations that do not inject complexity into the rendering pipeline. Why not just use your term?
No one could have known that telling programmers "spend as much money as possible on this new agent technology; whoever spends the most money wins!" would result in companies spending too much money on this new technology.
Giant caveat: we don't have a lot of data on this.
Given that, I think most folks legitimately are not aware that pretty much all the data we have points to agent efficiency being better in dynamic langs.
Anecdotally, that is also my experience.
https://t.co/vtU9kCS97b
Agents don't need types. They're perfectly capable of pulling off incredible refactorings without. Give them a linter and a test suite, and you have all you need. Token efficiency is where it's at.
I think part of the bad rap that OOP has came from the unfortunate practice of using private fields to avoid threading params through a lot of tiny methods.
That is not OOP, that is DSL fetishism, and it exists in other forms in other paradigms.
I'm glad @dhh is starting to market rails this way. The reality is your experience using agents with rails will be close to an order of magnitude better then nextjs / gin / react. Its a crime the platform has fallen so far out of favour.
https://t.co/vtU9kCS97b
Agents don't need types. They're perfectly capable of pulling off incredible refactorings without. Give them a linter and a test suite, and you have all you need. Token efficiency is where it's at.
I think solo dev + ai on code not dealing with PII/Money you can responsibly operate at 5-10x output.
solo dev dealing with PII/Money? maybe 3x?
2 devs? Maybe 1.5-2x
limit is not workflows, techniques, or the models. It is human communication/comprehension.
I feel like there is a hard cap on how much code you can responsibly merge in a day, and that number goes down as the number of folks you are working with goes up.
Its not worth chasing reliable code gen past that.
My current gut feel is that juniors will start at small companies as the first or second developer hire, for developing in-house software.
They’ll build low stakes apps for those companies, like estimating, automations, websites, task management.
It’ll teach them the strategic layer (since they own the whole stack) in a lower pressure environment. They’ll need to think about all of it, but the projects are small and the user bases tiny.
This is as opposed to being a junior on a larger tech team, where you’re given small tactical slices to work on under close supervision. That route is drying up, I’m sad to say.
These juniors will be affordable to a small business and AI will give them instant productivity that the business can leverage for operational efficiencies.
My son @cedricholmgren is currently doing exactly this route; working at a local fence and deck company as their in-house programmer. He owns probably a dozen apps in 5 different languages and frameworks. It’s amazing. He’s been doing it for a couple years and at some point someone’s going to discover that he’s a lot smarter and more disciplined than his old man and snap him up.
After using @mattpocockuk grill-me-with-docs, I think there is a lot of value in sparse docs.
Domain Language should deepen, not thrash, ADRs are a snapshot record of a thought in time, and don't pretend to be living/comprehensive.
Document high value things that rarely change.
@garybernhardt - deterministic constraints > all, if you can express it through a lint tool
- split plan / build / review into 3 sessions
- plan and review force load specific docs/rules, have them available for the builder if it wants it, dont force load