I'd wager this methodology is going to become very prevalent in enterprises going forward. Encoding all of the context necessary to recreate your entire application in "plans" or "rules" allows for much more rapid refactoring to address new business needs.
It also makes for much more fungible developers. Instead of having a few key engineers that know the system inside and out, that knowledge is encoded in markdown throughout the project, allowing new devs to ramp up by asking questions against the codebase and tracing the history of reasonings that led to the shape/implementation that exists today. It's like having near exhaustive design docs & documentation with change tracking included.
While it seems likely that developers will become more fungible (replaceable) going forward, I think being able to operate at this layer of abstraction & still having the capacity to drop down to the nitty gritty implementation details will make strong devs more valuable, rather than less.
whattheheckheck 22 days ago [-]
It's the latest iteration of the Mechanistic Myth described in the book Software and the Mind, http://www.softwareandmind.com/
xg15 22 days ago [-]
Is there a summary for what exactly he means with the "myth" in the context of software? The whole detour into the history of western science and philosophy is interesting but also quite expansive.
nonrandomstring 23 days ago [-]
I like the arts metaphor and enjoy the writing style. Understanding
"AI" as a component in an ecosystem of materials, tools, techniques,
plans, abandoned attempts and final products is helpful.
spariev 23 days ago [-]
The approach described resonates well with my (limited) experience using tools like Cursor/Cline and Aider, thanks for writing this up.
It feels more like the waterfall-style method and it takes time to get used to it after years of test-driven/agile development.
falcor84 10 days ago [-]
The nice thing is that you can easily go both ways - e.g. do full "vibe coding" to build a throw-away prototype, then ask the AI for help creating documentation and end-to-end tests for it, then collaborate with it to redesign the architecture, create a new implementation plan, and start coding from scratch.
It also makes for much more fungible developers. Instead of having a few key engineers that know the system inside and out, that knowledge is encoded in markdown throughout the project, allowing new devs to ramp up by asking questions against the codebase and tracing the history of reasonings that led to the shape/implementation that exists today. It's like having near exhaustive design docs & documentation with change tracking included.
While it seems likely that developers will become more fungible (replaceable) going forward, I think being able to operate at this layer of abstraction & still having the capacity to drop down to the nitty gritty implementation details will make strong devs more valuable, rather than less.