Technical Debt
My observation is that “AI” makes easy things easier and hard things impossible. You’ll get your niche app out of it, you’ll be thrilled, then you’ll need it to do more. Then you will struggle to do more, because the AI created a pile of technical debt.
Programmers dream of getting a green field project. They want to “start it the right way this time” instead of being stuck unwinding technical debt on legacy projects. AI creates new legacy projects instantly.
This reminds me very similarly of GPT-3’s research paper in which they describe a pattern of “Few-Shot Learners”. However, I’ve seen overtime the trend that even with extremely large context models there is still an innate need to make “One Shot Execution” prompts for task delegation. Think of how subagents are needed to do a specific task. If you’re currently making some type of app or process, I still think that one shotting is the most efficient when it comes to utilizing it for yourself because the barrier for diagnostic is the lowest. I still think the methodology from Gas Towns will still be applicable in the future as it correlates somewhat to present work delegation models. However, the tradeoff between ‘time spent fixing issues’ vs. ‘getting a minimal viable product’ will all depend of the subject expertise of what you’re trying to make.
For example - Generate some type of video with Remotion Code Animation - One Shot Applicable Automate a complex workflow with poor documentation - Less One Shot Applicable
I find it very interesting that with the rise of skills that the documentation for “how” to do a certain activity has increased. For example, a popular repository called ui-ux-pro-max-skill sets standards to define what makes a website a certain design style and where you can find examples of it.