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?
yes! we've found that reading changes this way make it very easy to separate the important stuff from the unimportant stuff, and we're thinking of ways to make that more visible in the UI
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.
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.
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.
> that will teach them something. If they care about getting better,
This pre-supposes the idea that the business is _willing_ to let that happen, which is increasingly unlikely. The current, widespread attitude amongst stakeholders is “who cares, get the model to fix it and move on”.
At least, when we wrote code by hand, needing to fix things by hand was a forcing function: one that now, from the business perspective, no longer exists.
This is what I have been thinking. Business will always try to do more with less because their only true goal is figuring out how to make more money. They will sacrifice giving those juniors time to learn from their mistakes for the sake of making more widgets (code). From the wider generational view, they will rob today's juniors from the chance to learn and thereby keep the talent pipeline full so they can profit today, the future (and the developers who will arrive there) be damned. The economic game is flawed because it only ever comes down to a single output that is optimized for: money. One solution? I think software people might consider forming unions. I know that's antithetical to the lone coder ethos, but if what this comment reflects is true, the industry needs a check and balance to prevent it from destroying its foundation from the inside.
Why would a business train anyone when they can lean on the govt to provide unbankruptable loans to the student to go to university to learn themselves
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.
Don't you see the problem? Now engineers literally do not have any leverage. Did the model make it work? Yes? Then ship it, what are we waiting around for?
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.
> Now there actually is time to make things robust if you learn how to do it.
What makes you think you are going to be given time to polish it? You would be pushed to another project. You have more responsibilities with none of the growth.
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.
One cannot build something robust just by thinking about it _a priori_, and while this was somewhat at the periphery of the author's argument, it is important.
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.
Coding by hand is not mere typing symbols into editor that LLMs are now replacing, it’s thinking, abstracting, deciding how to apply your knowledge and experience, searching for information.
And of course in the current workplace where there’s often a push from managers to use LLMs as much as possible and to put as much work as possible on yourself, in this churn junior will not get to learn anything besides prompting and simple tooling.
> 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.
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.
Simply put, you don’t. Your DC is launched into its graveyard. If a chip burns out it burns out—maybe rack design is a bit more redundant to keep failures as independent as possible.
Maybe at some point repair is a valid optimization. But it’s not necessary for an MVP, namely, one that is competitive against 3 to 5-year terrestrial delays and sub-10% costs of capital for such projects. That’s what has surprised me.
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.
And people weeded out by this kind of questions are probably rightfully so. I for one could not ever work with someone that says "my answer is correct, period.". Part of the answer and the discussions made by mature individuals must ask for feedback, incorporate it in your design, be open to compromises sometimes but also to die on a hill when it makes sense. And in an interview context, you ought to show the hiring manager all these faces.
Then, there are hiring managers that suck and you might be discarded because you didn't follow the script. Sure, but that's a bullet you dodged.
I have a similar process and have thought about committing all the planning files, but I've found that they tend to end up in an outdated state by the time the implementation is done.
Better imo is to produce a README or dev-facing doc at the end that distills all the planning and implementation into a final authoritative overview. This is easier for both humans and agents to digest than bunch of meandering planning files.
reply