I’d also point out that LLM inference revenue already totals more than 100B annually based on publicly reported numbers. Almost none of that is replacing knowledge workers. Almost all is increasing their productivity. So empirically what you describe is already happening to a nontrivial degree.
Cool, good to hear. I think it’s often the case even within an individual file or change that it’s 90% routine and 10% critical to review. That’s a big part of the problem in my mind.
Interested to try this! Have you thought about separating the parts of a PR that are routine/uninteresting from the parts that are load-bearing and need more careful review?
I mean it’s quite literally a command line interface to their tool… what else should it be called that differentiates it from a pure browser flow?
What you are describing sounds more like “TUI” than “CLI” imo. A CLI is an interface—it’s about the input step. It makes no promise about what happens after that.
You can’t get every detail right up front, but you can build a robust foundation from the beginning.
The argument seems to be that AI is causing managers to demand faster results, and so everything has to be a one-shotted mess of slop that just barely works. My point is that it doesn’t take much longer to build something solid instead. Implementation time and quality/robustness are not tightly coupled in the way they used to be.
You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.
Line by line is no longer what I need to think about. I think about types/schemas, architectural division, contracts between services and components, how to test thoroughly, scaling properties, security properties, and these kinds of things.
That sounds pretty much the same as it’s always been? It used to be: “Does the happy path work? Then ship it! There’s no time to make it robust or clean up tech debt.”
Now there actually is time to make things robust if you learn how to do it.
> thinking, abstracting, deciding how to apply your knowledge and experience, searching for information
None of this requires coding by hand. I can do those things better and faster with agents helping me. That incudes unfamiliar areas where I am effectively a junior.
That’s also true without AI. Engineers want more time to polish and businesses want to ship the 80/20 solution that’s good enough to sell. There's always going to be a tension there regardless of tools.
This is a great point. We’re very much in a transitional phase on this, but I personally do see signs in my own work with agents that we are heading toward the main deliverable being a readme/docs.
The code is still important, but I could see it becoming something that humans rarely engage with.
If a junior builds something with agents that turns into a mess they can’t debug, that will teach them something. If they care about getting better, they will learn to understand why that happened and how to avoid it next time.
It’s not all that different than writing code directly and having it turn into a mess they can’t debug—something we all did when we were learning to program.
It is in many ways far easier to write robust, modular, and secure software with agents than by hand, because it’s now so easy to refactor and write extensive tests. There is nothing magical about coding by hand that makes it the only way to learn the principles of software design. You can learn through working with agents too.
It seems like that could change the math quite a bit, since you’d presumably be losing a lot of capacity to failures. I’d assume you would have a much higher failure rate in space, and component failure is already pretty common on earth.
tmux makes it easy for terminal based agents to talk to each other, while also letting you see output and jump into the conversation on either side. It’s a natural fit.
Anyone can google it /shrug