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.
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.
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.
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.
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.
It's the latest iteration of the Mechanistic Myth described in the book Software and the Mind, http://www.softwareandmind.com/
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.
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.
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.
[flagged]