I agree completely, I recently went thru this. Customer API session/journey security is a beast to secure, so many layers, so many moving parts, so many approaches.
> Before you tell the agent to start building anything, you go there and read and understand it first.
The sentence is maybe ambiguous, but it sounds like it's saying to not use the AI at all until you understand what's happening in the area that needs to change.
I don't agree with this as you can spend quite a bit of time digging around to first find the correct place which needs to be updated and then more time reading the code (likely in multiple files or places) to build up a mental model of what's going on.
I typically have more than one AI conversation on the go at any given time, so I'll always start by asking it to make a plan to solve a problem and while it's busy exploring to make a plan I review some other AI conversation's work in the meantime, when the AI's plan is ready I review it.
If at this point there is anything that is unclear to me about its approach to implement the plan, or I don't already have familiarity with the part of the system it's proposing to update, I start questioning the AI on how the system works. I will scrutinize the AI's plan until I'm absolutely sure that it's going to implement something that is sound from a system design perspective and as a senior software developer with architecture level experience I am capable of making such judgments.
I'm not sure what it might be like for comparitively inexperienced developers, but I would expect that AI's capacity for infinite patience allows them to ask as many questions as they need to get a clear mental model of what's happening, so if I were mentoring such a person in this age of AI I would drill into them on how to interact with AIs to ensure they have this clarity before the AI starts implementing anything.
The difference between vibe coding and highly accelerated agentic development is having the expertise and judgment to ensure you're building properly sound software.
> before sending your stuff to other people for review, you need to make the work reviewable.
Yes, but the amount of work needed here is overstated. With good orchestration/prompting in the task[1] (and token budget), the work on this end is significantly reduced.
This is the same approach I use. I don't know if it actually produces good results yet as I've only been doing this for about three months. At the very least it feels like I have some agency in my work which I think is one of the things people complain they lose to AI.
If you're saying AI has _never_ found a more elegant solution than your original idea, you're not using it right or you're only using the cheapo models.
(Before someone asks: "not using it right" could mean a lot of things, but intentionally constraining its search by telling it how to do everything is one example. Or by not giving it a way to hill-climb: no tests, no iteration on a solution, etc.)
If you've given up on understanding your code base, AI will give you a better solution than you could come up with. Not because AI is better, but because you've become a low performer.
AI is reasonable at reviewing code, with only a 50-60% false-positive rate, and its persistence at broadening scope often finds things human reviewers would miss. It's still actually still pretty shitty at writing code, though, again, with enough ground truth and persistence, it'll often generate something that's a functional turd. It will sometimes come up with better suggestions if you prompt for it, but it needs a ton of hand-holding at the moment. And usually the suggestions are still overly complicated messes that you can trim down to 1/10th the size, while keeping the core idea.
A lot of devs are micromanagers who think they’re smarter than everyone else. You’ve probably at least met a couple if you’ve had a long career. They typically leave lots of nits on code that is mostly meaningless noise or personal preference.
These types of people will get the least out of AI as their ego prevents them from letting it outshine themselves.
I have a very simple framework I use for working with John von Neumann ... the idea is very simple, and can be summarized by: whenever you work on something with John von Neumann, you should use:
1. Your brain, and then
2. John von Neumann, and then
3. Your brain
Explaining a bit more… Before you tell John von Neumann to start working on anything, you go there and read and understand it first. And when John von Neumann brings you the solution, you will know if it’s right, or if it’s too much, or if it’s completely solving the wrong problem, etc.
This approach appears valuable for personal growth as an engineer, yet it demands discipline that may not yield returns in corporate settings. Specifically:
> The rule of thumb is: if you can’t explain what’s changing and why, it’s not ready for someone else to take a look
I have observed firsthand that the metric or "understanding" can be irrelevant to management. When delivery dominates, understanding can be deferred to future agents who will gladly consume your codebase and convince you they grasp it, and further, that you do too. If I invest substantial effort in my PRs only for them to be /review'd, does it still matter? Perhaps reviewers should practice brain sandwich as well.
The worst offenders seem to sit at either extreme: fully AI firms that treat understanding as a human weakness and prioritize outcomes alone, or large corporate teams building internal CRUD apps whose middle management merely pretends to value good engineering to satisfy finicky senior engineers.
Not a criticism on the authors work at all, I like the idea (and I don't think they were trying to solve anything to do with work culture), but ultimately if my company doesn't find my practice valuable, I can't easily justify taking it on. Especially if I have to sell to them that I'm going to be spending _more_ time delivering. Fun times!
The sentence is maybe ambiguous, but it sounds like it's saying to not use the AI at all until you understand what's happening in the area that needs to change.
I don't agree with this as you can spend quite a bit of time digging around to first find the correct place which needs to be updated and then more time reading the code (likely in multiple files or places) to build up a mental model of what's going on.
I typically have more than one AI conversation on the go at any given time, so I'll always start by asking it to make a plan to solve a problem and while it's busy exploring to make a plan I review some other AI conversation's work in the meantime, when the AI's plan is ready I review it.
If at this point there is anything that is unclear to me about its approach to implement the plan, or I don't already have familiarity with the part of the system it's proposing to update, I start questioning the AI on how the system works. I will scrutinize the AI's plan until I'm absolutely sure that it's going to implement something that is sound from a system design perspective and as a senior software developer with architecture level experience I am capable of making such judgments.
I'm not sure what it might be like for comparitively inexperienced developers, but I would expect that AI's capacity for infinite patience allows them to ask as many questions as they need to get a clear mental model of what's happening, so if I were mentoring such a person in this age of AI I would drill into them on how to interact with AIs to ensure they have this clarity before the AI starts implementing anything.
The difference between vibe coding and highly accelerated agentic development is having the expertise and judgment to ensure you're building properly sound software.
Yes, but the amount of work needed here is overstated. With good orchestration/prompting in the task[1] (and token budget), the work on this end is significantly reduced.
… and then the brain drain issue returns.
[1] https://claude.dev/blog/solving-code-review-at-anthropic/
(Before someone asks: "not using it right" could mean a lot of things, but intentionally constraining its search by telling it how to do everything is one example. Or by not giving it a way to hill-climb: no tests, no iteration on a solution, etc.)
AI is reasonable at reviewing code, with only a 50-60% false-positive rate, and its persistence at broadening scope often finds things human reviewers would miss. It's still actually still pretty shitty at writing code, though, again, with enough ground truth and persistence, it'll often generate something that's a functional turd. It will sometimes come up with better suggestions if you prompt for it, but it needs a ton of hand-holding at the moment. And usually the suggestions are still overly complicated messes that you can trim down to 1/10th the size, while keeping the core idea.
These types of people will get the least out of AI as their ego prevents them from letting it outshine themselves.
1. Your brain, and then
2. John von Neumann, and then
3. Your brain
Explaining a bit more… Before you tell John von Neumann to start working on anything, you go there and read and understand it first. And when John von Neumann brings you the solution, you will know if it’s right, or if it’s too much, or if it’s completely solving the wrong problem, etc.
https://en.wikipedia.org/wiki/Third-person_effect
> The rule of thumb is: if you can’t explain what’s changing and why, it’s not ready for someone else to take a look
I have observed firsthand that the metric or "understanding" can be irrelevant to management. When delivery dominates, understanding can be deferred to future agents who will gladly consume your codebase and convince you they grasp it, and further, that you do too. If I invest substantial effort in my PRs only for them to be /review'd, does it still matter? Perhaps reviewers should practice brain sandwich as well.
The worst offenders seem to sit at either extreme: fully AI firms that treat understanding as a human weakness and prioritize outcomes alone, or large corporate teams building internal CRUD apps whose middle management merely pretends to value good engineering to satisfy finicky senior engineers.
Not a criticism on the authors work at all, I like the idea (and I don't think they were trying to solve anything to do with work culture), but ultimately if my company doesn't find my practice valuable, I can't easily justify taking it on. Especially if I have to sell to them that I'm going to be spending _more_ time delivering. Fun times!