Applying AI across different industries and disciplines—such as programming—is extremely challenging. We know that the goal of AI companies has never been merely to help programmers code better; rather, the aim is to enable ordinary people to program as well.
Google’s approach is relatively traditional. Looking at their latest open-source models reveals their internal product philosophy: treating app and program generation much like image generation—creating a pathway that allows the average person to program.
However, this approach is clearly flawed. Unlike images, every individual has unique needs and ideas; AI-generated content based on a single prompt cannot satisfy the vast array of diverse ideas people have. This raises a few key issues:
(1) If you start a task incorrectly, the errors tend to compound; often, the best solution is to start over from scratch. (2) The limitation isn’t necessarily a lack of raw AI power; rather, AI struggles to deeply infer an individual’s specific thoughts and nuanced needs from fragmentary information—especially since humans themselves often cannot predict what needs they might have the very next moment. (3) Many users lack technical expertise—myself included; I know absolutely nothing about programming.
This often leads to getting stuck in a loop when using AI for work. Therefore, I believe the next generation of AI shouldn’t be defined merely by its raw capabilities or its ability to create polished products from a single prompt.
Instead, it should employ a “teaching-plus-questioning” format to collaborate with the user in refining ideas—drawing inspiration from the planning mode in Claude Code, though that implementation remains imperfect.
For instance, suppose I want to build an instant messaging (IM) app. The AI should first provide some background and propose potential plans, then guide me through simple lessons and step-by-step plan refinement.
If I say, “GPT, I want to build an IM app,” it should ask: “What is the intended use case for your IM app?” (offering options A, B, and C with brief explanations). It might then add, “Common IM scenarios require the following features; which ones do you need?” (A, B, C) Do you want messages stored locally on the user’s device, or copies kept on both the client and the server? Please organize this into a comprehensive document for me—step-by-step—and then break it down into separate files (such as DESIGN.md). Next, please distribute these tasks among different MOE teams based on departments (refer to my previous post: essentially, breaking a project down into workgroups based on departments, where each group maintains a specific document, assists other Agent teams with feature development, and generates high-quality documentation). This approach yields clean, tidy code and files that are easy to maintain long-term, drastically lowers the barrier to entry for non-experts crossing into new industries or disciplines, and creates a powerful data flywheel.
P.S. I’ve been a bit busy lately, which has scattered my focus and left me with little energy to articulate my thoughts clearly. When I have some downtime, I’ll return to share more in-depth ideas.
This topic was automatically closed after 24 hours. New replies are no longer allowed.