I don't think your sprinkled AI hints help your pitch if they immediately show injected into the diff.
Also, I think the guided review presents the opportunity to skim the code versus read the full diff - as semantic overview of multiple files/diffs, as well as file change description, give you the opportunity to green light anything you don't really need to read into, or give you enough context that you should dive in. i.e. https://x.com/thdxr/status/2073238046296924466?s=20
As crazy as it may sound, my workflow today does not look too different from a year ago - where I was already heavy into claude code.
Im not certain things will look too different a year from now either. We still have serious bottlenecks in terms of focus/attention you have for both delegating agent work and being able to review it. Even if we solve the "trust what ai does" problem, these cognitive deficit issues still exist - for teams coordinating work, even users adopting new shit, etc.
As an industry we are leaning heavy into accepting "slop" as the status quo - we care more about efficiency of output right now. Slop will get better & we can become more adaptive to living with the paradox of amazing yet delicate systems generated by AI. But I feel big shifts coming in this regard and if/when it does we may find ourselves in the dystopia of broader unemployment with worse net outcomes.
I do think the teams that ship quality with AI will do so by learning to slow down
I mean, I didn't mean specifically every agent, and I also did not mean as a experiment. I see real at scale uses for this. Agents operating on their own networks, cross-team agents, my own agents on my own laptop, etc. Sharing context only gets more important the better these things get.
I do think Cloudflare probably institutes a similar manual review process as well. I have a handful of fairly vocal and supportive engineers I stay in contact with around https://plannotator.ai (there is an integrated code review surface that creates a feedback loop with your local agent).
> agents do a good job of looping over PR comments
This is the easy part. Most harnesses enable some sort of integration now, so you can actually create a smooth local experience around this as well - better code before it ships to more costly review or bloats PR threads.
> guided, educational code review tool
This is a bit tougher, and I find the main harness chat tends to work best. I learn better when I'm more engaged and aware of what I'm asking. It's easy to stick a code tour type of thing on a screen. It's hard to really nail the right attention and learning mechanism around it.
we're going to end up speaking past each other - but generally I do agree with you and am not denouncing the importance of formal verification methods. I do think abstractions are going to dominate the human ux above them
Shame us all for moving away from something so perfect, precise, and that "doesn't have edge cases."
Hey - if you invent a programming language that can be used in such a way and create guaranteed deterministic behavior based on expressed desires as simple as natural language - ill pay a $200/m subscription for it.
> If I had to roll out such a development process today, I’d make a standardized Markdown specification the new unit of knowledge for the software project. Product owners and engineers could initially collaborate on this spec and on test cases to enforce business rules. Those should be checked into the project repositories along with the implementing code. There would need to be automated pull-request checks verifying not only that tests pass but that code conforms to the spec. This specification, and not the code that materializes it, is what the team would need to understand, review, and be held accountable for.
The constant urge I have today is for some sort of spec or simpler facts to be continuously verified at any point in the development process; Something agents would need to be aware of. I agree with the blog and think it's going to become a team sport to manage these requirements. I'm going to try this out by evolving my open source tool [1] (used to review specs and code) into a bit more of a collaborative & integrated plane for product specs/facts - https://plannotator.ai/workspaces/
I was about to comment: "HTML creates too much friction after doing all sorts of visual explainers" ... thanks for articulating it well.
As a layer of abstraction, it also creates more requirements: need a browser, likely need includes/cdn libs to avoid bloat, all sorts of other things. Markdown is consumable, diffable, shareable in raw form - and you can add enrichment layers on top without much effort.