The Jenny Wen point is the one that keeps rattling around in my head. We built entire professional disciplines around the assumption that implementation is expensive. Design reviews, sprint planning, specification documents, architecture committees. All of them exist because building the wrong thing used to cost months.
If building costs hours instead of months, a lot of that upstream apparatus becomes overhead rather than insurance. The bottleneck moves from "can we build it" to "should we build it" and those are very different organisational muscles.
The evaluation point is equally interesting. Simon's instinct that usage matters more than code quality as a trust signal is basically the shift from inspection goods to experience goods. You cannot tell from looking at the code whether it is good. You can tell from running it for two weeks. That changes how software earns trust, and it probably changes how open source reputation works too. Stars and commit counts meant something when they implied human attention per commit.
I have been designing and coding for 20 years and this new world has made it a lot more possible for me to work through and try my ideas more quickly and see what sticks.
I'm about to release my first Mac app and have had a very similar feeling, "If this code is going to run on someone else's machine, I have to make sure it's right." I know how it works throughout all the 'agentic engineering' I did, but I don't know every line. I'm currently going through a process of reviewing every line of code (I have a spreadsheet!) and making sure I understand what's going on. I make edits along the way, nothing substantial but adjustments, improvements, *legibility* type changes so the code is *good* (read legible).
As much as I am becoming more and more trusting of these tools, I have a very heavy feeling that I cannot release this until I know every inch of it myself.
last week I let Claude do a whole feature via agentic setup, watched it spiral into this overengineered mess with 4 abstraction layers for a one-off script. the vibe was strong, the correctness was not
isn't "vibe coding" just the thing we used to call prototyping before the agents got good enough to fool us into thinking it was something new? the rebranding speed is impressive
Even for my own projects, I can't tell. You nailed it. I lived the extreme version. 18 hours, zero visibility, zero memory. Had to use AI to reconstruct everything I built. Turns out it shipped clean.
I feel like agentic engineering doesn’t necessarily involve reading code at all, but rather verifying it works. Would be interested in your thoughts, Simon, as you coined the term!
The Jenny Wen point is the one that keeps rattling around in my head. We built entire professional disciplines around the assumption that implementation is expensive. Design reviews, sprint planning, specification documents, architecture committees. All of them exist because building the wrong thing used to cost months.
If building costs hours instead of months, a lot of that upstream apparatus becomes overhead rather than insurance. The bottleneck moves from "can we build it" to "should we build it" and those are very different organisational muscles.
The evaluation point is equally interesting. Simon's instinct that usage matters more than code quality as a trust signal is basically the shift from inspection goods to experience goods. You cannot tell from looking at the code whether it is good. You can tell from running it for two weeks. That changes how software earns trust, and it probably changes how open source reputation works too. Stars and commit counts meant something when they implied human attention per commit.
I have been designing and coding for 20 years and this new world has made it a lot more possible for me to work through and try my ideas more quickly and see what sticks.
I'm about to release my first Mac app and have had a very similar feeling, "If this code is going to run on someone else's machine, I have to make sure it's right." I know how it works throughout all the 'agentic engineering' I did, but I don't know every line. I'm currently going through a process of reviewing every line of code (I have a spreadsheet!) and making sure I understand what's going on. I make edits along the way, nothing substantial but adjustments, improvements, *legibility* type changes so the code is *good* (read legible).
As much as I am becoming more and more trusting of these tools, I have a very heavy feeling that I cannot release this until I know every inch of it myself.
My experiences, and thoughts on the process, are very much aligned with yours.
You had me at REGEX. However TRE is chasing the tail of some older COTS. Nuance comes to mind as one.
last week I let Claude do a whole feature via agentic setup, watched it spiral into this overengineered mess with 4 abstraction layers for a one-off script. the vibe was strong, the correctness was not
isn't "vibe coding" just the thing we used to call prototyping before the agents got good enough to fool us into thinking it was something new? the rebranding speed is impressive
Even for my own projects, I can't tell. You nailed it. I lived the extreme version. 18 hours, zero visibility, zero memory. Had to use AI to reconstruct everything I built. Turns out it shipped clean.
Full forensic log:
https://tylerbliss.substack.com/p/drunk-vibe-coded-chrome-extension
I feel like agentic engineering doesn’t necessarily involve reading code at all, but rather verifying it works. Would be interested in your thoughts, Simon, as you coined the term!
Discussed this with Wes yesterday: https://substack.com/@hugobowne/note/c-256022207?r=1239uj&utm_medium=ios&utm_source=notes-share-action