Recently, Sourcegraph’s AI programming tool, Ampcode, has garnered attention as a new dark horse after Cursor, Devin, and Claude Code. The article delves into Ampcode’s technical features, product philosophy, and industry impact, pointing out that it redefines programming workflows through innovations such as deep model understanding, feedback loops, and sub-agent functions, driving the transformation of AI programming tools from synchronous to asynchronous, leading future programming trends.
In the latest podcast of Every, they have made a rating classification of all current AI coding products, and Claude code is ranked in the S grade with Claude code is Ampcode just launched by Sourcegraph recently, and the popular Cursor is only ranked in the second grade of A.
This actually represents a future trend from synchronous coding tools to asynchronous Agentic Coding, which is also perfectly in line with the concept of LLM OS and Software 3.0 mentioned by Andrej Karpathy in his speech at YC Startup Camp a few days ago. Here is another video of the speech by the person in charge of Claude code, detailing the evolution of Agentic coding.
As a veteran player in code search and intelligent tools, Sourcegraph has been deeply involved in the enterprise developer tools market for many years. Founded in 2013, this company is known for its robust code search platform, helping numerous large enterprises manage and understand complex codebases. However, when the wave of AI programming tools came, Sourcegraph did not stop at existing successes and chose a more radical path. Their CEO Quinn and engineer Torsten embarked on an unprecedented experiment: could they build a completely different AI programming tool in just a few weeks? The result of this experiment is Amp, which is now shocking the entire industry.
Interestingly, they open-sourced the entire process of making products in the form of a podcast series “Raising an Agent”, in which I heard the complete process of an AI programming tool from idea to formation, and more importantly, I saw how a group of engineers created a unique product through deep thinking and bold experimentation.
This is not your typical product launch story. No flashy PPTs, no well-planned marketing campaigns, or even formal product planning. Quinn and Torsten built a prototype that shocked them themselves in two or three weeks, almost “learning by doing”. But it’s this seemingly haphazard development process that brings a deep understanding of the nature of AI programming tools.
B-end product manager’s ability model and learning improvement
The first challenge faced by B-end product managers is how to correctly analyze and diagnose business problems. This is also the most difficult part, product design knowledge is basically not helpful for this part of the work, if you want to do a good job in business analysis and diagnosis, you must have a solid …
View details >
From their hours of podcast conversations, I extracted several key dimensions of thought that not only shape Amp’s product but may also indicate the direction of the entire AI programming tool industry. What interests me even more is that these insights are summarized from actual combat, not theoretical deductions on paper, but real experience accumulation that is used every day, discovered every day, and adjusted every day.
I see an important trait of the Amp team: their willingness to try ideas that seem unlikely to succeed. This spirit of experimentation allows them to discover possibilities that others miss. What’s more, they are not bound by traditional product development processes, but let the possibilities of technology guide the direction of the product. This “technology first” approach, while it may seem risky, may be the most effective way to explore in the rapidly evolving field of AI. Quinn summed it up well: “That’s why we’re here, because there are moments like this every day. ”
I especially noticed one point they repeatedly emphasized: there are exciting discoveries every day. This is not accidental, but because they have chosen the right way to work. Instead of trying to predict all the possibilities of the AI model, they discover the true capabilities of the model through continuous experimentation and observation. This approach allows them to “dance with the model” rather than forcing it to work the way it is preset. As they have mentioned many times in their podcasts, many times the best answer is to “let the model do it” rather than trying to control it through complex logic.
So I have this article, I hope to give you some thinking and inspiration. I am very interested in AI coding and have done a lot of research, so if you want to start a business in this area, please contact me to chat.
Disruptive product philosophy: less is more
In the current AI tool market, most products are looking for a breadth of features: model selectors, complex configuration options, hundreds of tool integrations. But the Amp team chose the exact opposite direction. Their product philosophy can be summed up in one sentence: do subtraction instead of addition. This philosophy permeates all their design decisions, from interface design to feature selection, from pricing strategies to user experience.
The most obvious manifestation of this philosophy is their refusal to provide a model selector. Quinn emphasizes this several times on the podcast: “We have literal text areas, so many other AI agents have those rich text areas, like lexical or prose mirror and stuff like that, we’ve done it and know that adds 1000 times more complexity. “Their goal is to provide users with the best experience, not the most options. They think, if you know which model is the best, why ask users to choose a worse model?
This logic sounds simple, but behind it is a deep understanding of product value. Torsten explains: “How do a lot of outdated things look now? selectors and different modes, as well as one more button to configure everything. I don’t know if it’s just me thinking so, but it’s just that I’m getting used to Amp now, but that seems to be why you would make users switch to a significantly worse model, like why put Mini or Haiku there? ”
Even more radical is their attitude towards token usage. While other tools were looking for ways to save on token costs, the Amp team chose not to limit token usage at all. Their environment variables even contain a variable name with swear words to the effect “I’m a low-ambition idiot who cares more about cost than building something awesome, so tell me the price”. Behind this almost extreme attitude is their clear understanding of what really matters.
Quinn has a deep analysis of this: “I think the magic of this tokenless limit is because if you optimize for requests or low requests or low token counts, you end up with a completely different product. If you say let it run wild, you remove all restrictions, you give the tool to the model, and then you put it in a loop, and that’s where all the magic comes from. Magic is not …… A lot of the magic is in the tool, a lot of the magic is in how it integrates, and a big part is that there are no limits. ”
From their discussion, I understood the deep logic of this philosophy. When you try to meet everyone’s needs at the same time, you may end up with no one being satisfied. Instead, if you focus on providing the best experience for a specific user group, you may create a truly valuable product. This “opinionated” product design, while losing some users, will win the loyalty of those who really need a high-quality tool.
This philosophy is also reflected in their approach to tool integration. While there are hundreds of MCP tools out there to integrate, they choose to offer only a handful of well-tuned tools. Torsten’s point is clear: “I don’t think ‘more is better’ here…… I don’t think you’ll have a good experience if you have a thousand tools available. “Their reasoning is simple: giving AI too many choices can lead to choice paralysis, just as giving people too many choices can make decisions difficult.
They even have a strategy of selective response to user feedback. “We’ve got a lot of user feedback, and it’s really funny, where users say ‘Hey, I don’t want to see all the things it does’ and we’ve been very cautious…… We like people to say this, but we’ve always been cautious because we don’t want to set the wrong expectations, it’s magic. This “stubborn” attitude, while potentially dissatisfied with some users, ensures that the product maintains a clear direction.
Deep Model Understanding: Dance with the model, not against it
While listening to the discussions of the Amp team, I noticed an interesting phenomenon: their understanding of different AI models has reached an almost personified level. They will say “Claude likes delegating tasks”, “Gemini prefers to generate a complete scenario in one go”, “This model is trained to be more aggressive”. Behind this anthropomorphic description is a deep understanding of model behavior patterns, which has been accumulated through extensive practical use and meticulous observation.
This understanding does not come from reading technical documentation, but from thousands of hours of practical use and observation. Torsten mentioned an interesting finding: “Once we had access to Claude Sonnet 4, we quickly put the sub-agent back into Amp to see if this new model was different, and indeed, things were different. It turns out that Sonnet 4 really likes to delegate work to sub-agents, calling them whenever it can find a well-defined task. ”
This observation allows them to quickly adapt to the characteristics of the new model and adjust their product strategy accordingly. More importantly, they recognized that these characteristics of the model were not accidental, but intentional results during training. “The first widely recognized agent framework was AutoGPT, which actually emerged back in early 2023, shortly after the release of ChatGPT…… The models were all trained a long time ago, I don’t know the exact time frame, the model company won’t announce it, but let’s say six or nine months ago…… At that time, they surveyed the environment, they looked at what people were doing internally and around the world, they said how people would do tool calls in six to nine months, and they trained the model to do a good job of that. ”
What I am particularly interested in is their thinking about “model training data”. They recognized that different models have seen different tools and usage patterns when trained, which directly affects the model’s tool usage preferences. “Models are largely trained, and what we’re seeing is that they have a high affinity for the tools we think they’ve been trained on, like editing files…… Even we see that Gemini seems more reluctant to run shell commands. ”
This realization makes them understand that instead of forcibly changing the model’s behavior, it is better to design tools that align with the model’s preferences. This “dancing with the model” philosophy, I think, is one of the key factors in Amp’s success. Many other tools try to “tame” the model with complex prompt engineering, but the Amp team chose to understand and adapt the model.
From their discussions, I also saw a deep insight into the evolution trend of the model. They noticed that different model vendors have different directions in terms of agent capabilities. Torsten has a wonderful analysis: “To me, it seems that these companies have different philosophies about what an agent should be…… Anthropic seems to be by far the closest thing to the path of this practical coding agent that can figure things out, not just build applications. He further explained that Anthropic’s model is more focused on environmental interaction and feedback loops, with the ability to experiment with different solutions based on the errors encountered, while other models may focus more on generating a complete solution in one go.
This difference is not a contingent result of technological implementation, but rather different companies’ different understandings of the future of AI agents. Understanding these differences allows the Amp team to make more informed technology choices. As Quinn says, “If you have a model selector and arbitrary tools, you won’t get the same results as if you were using a tool optimized for a model that’s what it’s trained on, but big labs have an incentive to make their models work with many different tool implementations and make them as versatile as possible.” ”
The Art of Feedback Loops: Let AI Learn Like a Human
Of all the technical discussions, I find the most valuable insight to think about feedback loops. The Amp team found that AI agents and human programmers actually have many similarities and need to improve the quality of their work through feedback. This seemingly simple observation has subverted many people’s expectations of AI tools.
Quinn uses a very telling analogy in the podcast: “If you ask a human to output 300 lines of a file at once on a very good day, they can write 300 lines for you, but it won’t be right…… But what we often need is compiler feedback, interpreter feedback, tests, linter, squiggly, all of which guide us and help us understand if the code I’m writing works. It turns out that if you give the model the same feedback, it gets better at writing code. ”
This insight led them to rethink tool design. Instead of trying to get the agent to do everything at once, they created a rich feedback loop for it. Includes compiler diagnostics, test runs, static analysis, and even browser automation for visual feedback. Torsten shared an impressive example: “We have some tools to edit files, we have tools to view files, we have a tool to run terminal commands…… It tried twice and you can see it going in real time like let me try to edit this file and then maybe that’s the sound of it I want me to try to edit this file and it fails and we send back an error message that we say this is not a valid parameter and then it tries again the parameter changes and it still fails and then it decides and writes let me try this another way, what it does is create a new file and put the contents of the other files it wants completely into the new file, Then run the terminal command to move the new file over the old one. ”
This adaptive problem-solving capability is achieved through a good feedback loop. Even more exciting is their application in front-end development. They integrate browser automation tools that allow agents to see how the web page is performing. What impressed me the most was the example of the Space Invaders game they mentioned: the agent not only writes the game code, but also automatically opens the browser, presses the spacebar to start the game, and shoots aliens to verify that the game is working correctly.
But building a good feedback loop isn’t easy. Torsten points out an important problem: “Ideally, it always knows the best way to verify its work, but this is often difficult and you don’t even know as a human being…… What I find effective is that when I know it’s going to run into problems, I tell it beforehand, I say make sure you run this command after every little thing, and then it’s a type checker or any linter or whatever. ”
This feedback loop design philosophy, I think, is a key advantage that sets Amp apart from other tools. Many tools treat AI as a black box, enter prompts, output code, and call. But Amp treats AI as an “engineer” that needs to be continuously learned and improved, providing rich environmental feedback. This approach not only improves code quality but also frees up agents to handle more complex tasks.
Quinn has a deep observation about this: “The most important thing I would say is that I want more designers to go down the entrepreneurial path…… For those of you who are already founders, I also hope that you will develop ‘design thinking’ because this will be one of the most critical competencies in building the next great company. This view of feedback loops as a “design problem” is very enlightening to me.
From a technical implementation perspective, building a good feedback loop requires a lot of engineering input. You need to make sure that the build system can quickly give clear error messages, tests can run at a granular level, the development environment is configured correctly, and so on. Torsten mentioned an interesting observation: “It turns out that this is not good for agents, and not good for humans, like if you have some build tools that output a lot of warnings, you know super detailed results, which is not good for agents, if I hire a new junior engineer and say build this web application and it shows eight warnings, then I have to go over and say you can ignore those eight warnings, they are harmless, but they won’t know, agent Same issue as well. ”
Sub-agent revolution: from individual combat to teamwork
In Amp’s technological evolution, the introduction of sub-agent functionality is perhaps the most revolutionary change. This is not just a new feature, but a fundamental rethinking of the way AI agents work. From their discussion, I saw how this feature evolved from a technical experiment to a product core, and the deep technical insights behind it.
The concept of a sub-agent is simple: a master agent can create other agents to handle specific tasks. But behind this simple concept lies a deep understanding of the boundaries of AI capabilities. Traditional agent systems are limited to a single context window and can easily “run out” of tokens when dealing with complex tasks. Torsten explains the problem: “One of the problems everyone faces is that you only have a limited window of context, right? We now have 168k input tokens because we have 32k output tokens for claude, at some point you hit that limit, especially after the agent goes off track and does something bad, which is not good, you know like when it fails to edit the file 18 times or when it creates a new test file and costs a bunch of tokens and so on. ”
Sub-agent systems break through this limitation through task decomposition and parallel processing. More importantly, it also brings a sense of fault tolerance: “What’s interesting with these proxies and what Claude 4 prefers to call proxies is that each sub-agent has its own context window, right?” So if you say hey agent, take these eight blog posts and remove YAML stuff, they get their own K-token, right? If it fails to edit the file, of course it may fill up that context window, but after that task is completed, your master agent is still only using about 20% of the token or something like that, it’s not a lot. ”
What I am particularly interested in is their observation of behavioral changes in Claude Sonnet 4. Previous model versions rarely actively used the sub-agent feature, preferring to handle all tasks themselves. But Sonnet 4 is clearly trained to be better at delegating tasks. Torsten describes the change: “It turns out that Sonnet 4 really likes to delegate work to sub-agents, calling them whenever it can find a well-defined task. ”
This change is not accidental, but rather a reflection of Anthropic’s understanding of the agent’s working pattern. Quinn provides a deeper explanation: “These models are well trained ahead of time…… When new models come out, a lot of other companies say ‘oh, now our benchmarks do this’…… But this unadjusted evaluation, because we just said, like claude has a certain way of using certain tools, Gemini has a certain way of using other tools, and in order to get the most out of each model, you have to be honest about your prompts and tools for that particular model. ”
From the use cases they shared, I saw the qualitative change brought about by sub-agents. The example of dealing with a blog post is telling: “I tested it and I said take all the blog posts here and remove the comments from the YAML preamble to the real stuff because I don’t have comments anymore, what it does is it does a rip, I think rip grab or glob, so it knows there are 36 blog posts, and then it divides them into four groups, spawns four different agents, and tells each agent that you go and remove the comment from the blog post and they’re gone. ”
This change in work patterns, I think, could potentially redefine the way we interact with AI tools. Previously, we needed to carefully manage the complexity of conversations and avoid overly complex tasks for agents. Now we can be bolder in proposing complex requirements and let agents decide how to break down and assign tasks.
What’s more interesting is that the sub-agents also support parallel processing. Torsten mentioned: “No, no, no, it just produces four different because it can be called using parallel tools, right?” This is another thing, clot 4 seems to be more eager to use parallel tool calls, seemingly faster than 37. “This parallel processing capability greatly improves the efficiency of task execution.
Geoff Huntley’s review sums up the significance of sub-agents very well: “One of the things that stops me from doing this is contextual window management because it requires advanced skills. But thanks to sub-agents, this skill level is now commoditized and makes it easy for anyone to do, which means there may now be various initial categories. ”
From a technical architecture perspective, the sub-agent system also presents new challenges. How do I manage coordination between multiple agents? How can conflicts between sub-agents be avoided? How do you ensure consistency in overall tasks? Solutions to these problems may become key differentiators in the future of AI tool competition. Torsten is continuously optimizing the system: “Now I’m working on tasks or sub-agents again to make it look better in the UI, giving it more tools to simplify the whole thing. ”
Redefinition of cost and value
Throughout the podcast series, discussions on cost topics have allowed me to see the Amp team’s unique understanding of value creation. Their attitude is clear: instead of limiting functionality to save costs, focus on creating value. This shift in values, I believe, could potentially redefine the competitive landscape of the entire AI tool market.
One data they mentioned is telling: users who use Amp heavily can incur hundreds of dollars in AI costs per month. Torsten shared his experience: “Yesterday I showed someone a little demo and I think we burned $15, I don’t know, like $10, $10, I think…… We haven’t shown the price yet, but…… It’s just that your time and the time they spend looking at it outweigh that value. “But if you take into account the salary level of software engineers, this cost becomes reasonable.
Deeper thinking is about changes in pricing models. Quinn has a deep analysis of this: “I think this whole $10/month, $20 per month subscription flat rate model looks a little outdated now when we have these tools, and I think we’re going to see a lot of usage-based pricing or other forms of pricing in the future. The main reason for this is …… Someone asked why claud code felt so different from other tools…… This is because it is not optimized for cost savings, token savings. ”
There is a deep logic behind this strategy of “not optimizing costs”. Quinn explains, “If you optimize requests or say low requests or low token counts, you end up with a completely different product, if you say let it run wild, you remove all restrictions, you give the tool to the model, and then you put it in a loop, and that’s where all the magic comes from.” ”
From their experience, users are more receptive to the cost of AI tools than expected. Torsten observes: “I am very angry at how many people, and I would even say haters who don’t like AI online, when people say ‘I spent $50 on this over the weekend, I just let it rip or something.'” And then it did this, even those who said ‘Oh, this is the first time I’m using a proxy, I just put in a token that I think someone put in $70 and it fixes this old codebase. Instead of saying, ‘Wow, $70, that’s a lot of money.’ ’…… They’ll say ‘Well, it’s not crazy compared to my salary, compared to the salary of a junior developer.’ ‘”
Behind this change in cost concept, there is also an important business logic. Quinn mentioned an interesting analogy: “It’s like if you were Apple, you would also want to own a $19 Huawei phone. He noted that it would be very difficult if you were trying to satisfy both the people who built emoji games on weekends and the most efficient professional software developers in the world.
I think this change in cost perception may drive a productivity revolution in the entire software industry. When cost is no longer a major limiting factor, we are able to explore the possibilities of AI more boldly. This could lead to significant improvements in software development efficiency and a change in the talent demand structure of the entire industry.
More interestingly, they found that cost acceptance was higher in the team usage model. Quinn referred to a customer’s question: “There’s a question a customer asking today, do you know if they have 20,000 or 40,000 engineers or whatever, they’re going to get a full agent that can run the tool, or is there going to be some limitation or security from a cost perspective?” His answer was clear: “For me, this is a tool used by programmers…… It’s something that makes them more efficient if it gives them more leverage, so I’d say yes, like giving every programmer access to this tool, like why block it? ”
This shift in enterprise-level thinking could be a significant driver of the adoption of AI tools. When businesses start to see the cost of AI tools as a necessary infrastructure investment, the overall market may grow much faster.
Balance user education with product evolution
From the discussion with the Amp team, I saw an interesting challenge: how to educate users to use the tools to their full potential while maintaining product simplicity. This is not a simple product design question, but a deep thought on how to guide user behavior change. This challenge is particularly prominent in the realm of AI tools, where users often approach AI tools with expectations of traditional tools.
They found that many users use AI programming tools for the first time with false expectations. Some expect AI to “read” their intent perfectly, while others use AI as a traditional code generator. Torsten mentioned a typical misconception: “I think before the tool call or before the proxy, the code editing agent, I had different expectations, and I think a lot of people still have those expectations, which is that you talk to the model, you ask it to generate some code, you know it’s coming, you write a line or two of the prompt, it comes back with 300 lines of code, and then you’re like thumbs down it doesn’t do what I want, and then you adjust the prompt and do it again, and now my mindset is, Now why would I expect this to work well. ”
This misalignment of expectations can lead to a poor user experience. Quinn analyzed why: “I think a lot of people don’t realize how to use these things, or they don’t use these things, but when I say they don’t know how to use these things, it’s difficult because it feels like blaming the user, I understand it’s hard, these are nuanced, but it’s just that there are people who try something else if it doesn’t work, they have evolved that intuition and know how to get it right, they actually think it’s funny, While others don’t think it’s funny. ”
To solve this problem, the Amp team took a clever approach: using thread sharing to let users learn best practices. Users can see how others interact with the agent, learn how to express their needs more effectively, and understand what tasks are appropriate for the agent to handle. Quinn explains the value of this feature: “I think thread sharing has an unexpected value: it helps team members learn how to better collaborate with agents. Many people don’t know how to effectively express their needs or what tasks are suitable for the agent when using AI agents for the first time. By observing the operating patterns of colleagues who are good at using agents, newcomers can quickly grasp best practices. ”
This “peer learning” approach is more effective than traditional documentation because it shows real-world usage scenarios. Torsten mentioned the evolution of some best practices: “I would say there are different meta-phases, right, the first step people take is they start writing something, and then they look at the agent to figure things out, and then they realize that I didn’t get it, so the next obvious step is everything I know about this that I’m going to put in this, you know all the files I mentioned I’m going to put it in this or… That’s the first step, and then I would say the second step is people optimizing the feedback loop. ”
I especially appreciate the way they handle user feedback. Instead of simply responding to all user needs, they selectively respond to feedback that aligns with the product philosophy. This “stubborn” attitude, while potentially dissatisfied with some users, ensures that the product maintains a clear direction. Quinn makes it clear: “We really want to build for people who want to use AI as a powerful tool…… What I don’t want to build or I’m not even interested in is this one-line prompt tool, like building a wedding website for me…… And then it just does things, and I don’t want that. ”
They also observed differences in usage patterns across different user groups. Torsten mentioned an interesting phenomenon: “I wondered yesterday if it was …… That famous curve that we keep seeing, oh, junior engineers love AI tools, super advanced…… Senior engineers like it, but the people in the middle, they are not so enthusiastic about it. His analysis is that this may be related to how well engineers at different levels of experience understand architecture and local changes.
In the long run, this user education strategy may create a more mature user base. These users will not only be able to use Amp better, but they will also be able to become evangelists for AI programming tools, driving the industry forward. This formation of user groups may become an important competitive advantage for Amp.
This balancing act is also reflected in their approach to product iteration. Instead of reactively adapting products based on user feedback, they actively explore technological possibilities and then guide users to adapt to new capabilities. This “technology-led” approach to product development, while riskier, is also easier to create real innovation. Quinn summed it up well: “So we wanted to build what we used, focus on what we wanted to use, and then expand it from there, but really nailed like the core proposition and how well it worked for us. ”
Background Agent: Redefining the spatiotemporal boundaries of programming
In addition to sub-agents, the Amp team is exploring another interesting direction: background agents. At its core, this concept is about enabling agents to perform tasks without your direct involvement. To use the example they often mention, it is “start a programming task on your phone while your child is playing a soccer game and come back to see the results after the game”. Although this example has been repeated countless times by them, the technical thinking behind it is profound.
I think this idea reflects a rethinking of the boundaries of agent capabilities. Traditional programming tools require the participation of programmers throughout the process, from analyzing problems to writing code to testing and debugging, every link requires direct human intervention. But if the agents are reliable enough, we can delegate some relatively independent tasks entirely to them. Quinn describes the pervasiveness of this need: “Everyone who starts using proxy editing has this problem, do I want to watch this now, like do I watch it do these things, and then everybody is like I have attention issues now like the agent is running, it’s the command label, I go, and then the dinging comes, I go back, it’s oh, did you do the right thing.” ”
However, the implementation of background agents faces a critical technical choice: whether to build a complete cloud development environment or leverage existing CI/CD systems as feedback mechanisms. The technical philosophy behind this choice is very interesting. Most existing background proxy products, such as OpenAI’s Codex and Google’s Jules, have chosen the first option: building a complete build environment.
But the Amp team leans towards the latter, and their reasoning is compelling. Quinn has a profound criticism of cloud development environments: “Cloud IDEs are such a good idea, who doesn’t want to be able to generate something in their web browser, have the same build environment as they do on their native desktop editor, make changes, not even touch their native state, it’s so beautiful and clean, yet basically there are probably two companies in the world that really do this, and that’s Meta and Google, They have invested an incredible amount of money to make a cloud IDE that works perfectly. ”
He further explained the problem with the cloud IDE: “For everyone else, cloud ID adoption is so non-existent, I mean, even if you have VS Code, which literally uses web technology and can run in a browser, it’s the same experience, it’s all these little long-tail stuff, just doesn’t work very well, no extension really works in that scenario, no language server works, you know all your gadgets, they don’t work. ”
In contrast, using a CI/CD system as a feedback mechanism is more feasible with limited functionality. Most companies already have a CI/CD process in place, where agents can get feedback by committing code, triggering builds, and getting test results. Quinn’s point is: “The assumption is that if you want background agents, then they should use CI for feedback to see if the tests pass, if linter works, if you know all these things are correct, instead of having a build environment, it’s not bad to build an environment now, but it’s an optimization, build it first to use CI, build it for the whole problem category where CI is good enough.” ”
This way, while higher latency than local feedback loops, is perfectly acceptable for tasks that do not require frequent iterations. And, there’s an implicit benefit to this: it forces teams to optimize their CI/CD processes, which is also beneficial for human developers.
Torsten added an important point: “For background proxy use cases I want, like I don’t want it to do things that I know it needs a lot of compiler feedback because I know you’re kind of removing through this layer and you can’t really touch it, it’s the same as cloud ID, I’d rather let it do something that I know it can just be a single shot…… Something crazy, it doesn’t need to build environments. ”
Behind this choice of technical route is the persistence of pragmatism. Instead of pursuing technical perfection, it is better to choose a solution that can actually be implemented and bring value. This mindset, I think, is an important reason why the Amp team is able to iterate and innovate quickly.
The Future of Programming Workflows: From Tools to Partners
After listening to the entire podcast series, I have a clearer idea of how programming workflows will change in the future. The Amp team’s exploration is not just building a tool, but also exploring new models of human-AI collaboration. This change in pattern may redefine the connotation of the profession of programmers. Judging from the experience they shared, this shift is already quietly happening.
Judging from their experience, AI agents are no longer simple code generators, but more like a capable junior programmer. It can understand complex requirements, develop execution plans, handle various anomalies, and even proactively suggest improvements. Quinn describes his experience: “I went from having AI write about 40% of my code but I’m still involved, to AI being the first drafter and writing probably 85% or so of my code, I haven’t dealt with forever change, a hobby I’ve had since I was a child. ”
This improvement in capabilities makes collaboration between humans and AI more natural and efficient. I particularly noticed one change they mentioned: the shift in programmers’ focus from “writing code” to “guiding AI to write code.” This is not only a change in the way we work, but also a change in the way we think. Torsten has a vivid analogy: “The mental model I think of is…… You know number painting and that phrase has been thrown around a lot, but you know the way I know digital painting is that you have a blank or no color picture with small areas and each area has a color, and my take on the agent is that as a person who knows what I’m doing, it’s my job to draw those lines and then instruct the agent to fill in that number, but I need to determine what the line is. ”
This metaphor illustrates the new collaborative model: programmers are responsible for architectural design and boundary definition, and AI is responsible for specific implementation details. This division of labor not only improves development efficiency but also allows programmers to focus on more creative work.
From the perspective of technological development trends, the exploration of background proxy functions is particularly noteworthy. While still in its early stages, this model of “asynchronous collaboration” could become an important part of future programming workflows. Some users have already started experimenting with this way of working, such as someone who “prepared a separate task list for agents before a weekend trip so that they come back with all the differences ready to wait for them”.
The practice of heavy users such as Jeff Huntley pushes the boundaries of this collaboration model. They run multiple agents that work 24/7 and even have agents in the background to handle tasks while sleeping. This usage pattern, while seemingly extreme, could signal a mainstream trend in the future.
I believe the Amp team’s exploration heralds an important shift in programming workflows: from “people using tools” to “human-AI collaboration.” In this new collaborative model, programmers are more like project architects and quality controllers, while AI is responsible for specific implementation details. Torsten has a deep reflection on this: “I think this shift could be beneficial for the software industry as a whole. If agents can handle most of the repetitive programming tasks, programmers can devote more time to innovative problem-solving and user experience optimization. ”
Of course, this shift also brings new challenges. How can I ensure the quality of AI-generated code? How do you maintain consistency in complex systems? How to deal with AI’s errors and limitations? Quinn is candid about this: “I just want a really good logger and time-lapse debugger with 100 milliseconds of full CI time in all my code…… All of these things, it’s a criminal situation, only software engineering and not foundation model research stand between where we are today and that world. ”
From the experience of the Amp team, these challenges are not insurmountable, and the key is to have the right approach and enough patience. Their experience shows that AI programming tools can truly improve development efficiency and code quality through good tool design, reasonable feedback loops, and continuous user education. More importantly, they proved that rapid technological development does not necessarily require complex products, and sometimes simple and focused design can unlock greater potential.
As Quinn said at the end of the podcast, “We’re going live…… If you want to find out where it all goes – come with us. “This is not only an invitation to users, but also a call to the entire industry: in this era of rapid change, the best way to predict the future is to participate in creating it.
My thoughts: the underlying logic behind the dark horse
After listening to a few hours of podcast conversations with the Amp team, I have a deep feeling: true product innovation often comes not from a sophisticated business plan, but from a deep understanding of the nature of technology and a keen insight into the real needs of users. Amp’s success is not accidental, and there are several underlying logics behind it that deserve to be pondered by all product creators.
The first logic is that “technology-driven is better than demand-driven”. In most product development, we are taught to investigate user needs and then design solutions. But in the rapidly changing world of AI, this traditional approach can leave you missing out on the most important window of opportunity. The Amp team did the opposite: they first understood the boundaries of technical capabilities and then let the technical possibilities guide the direction of the product. This “technology first” approach, while seemingly riskier, may be a more effective strategy in an era of rapid technological evolution. The key is that you must be technologically sensitive enough to identify which technological breakthroughs are truly transformative.
The second logic is that “depth is better than breadth”. In a market environment where feature competition is prevalent, Amp chose to do subtraction rather than addition. They reject model pickers, limit the number of tools, and don’t cater to all users. This seemingly “stubborn” product strategy actually reflects a deep understanding of the essence of value creation: instead of trying to meet all the needs of everyone, it is better to create the ultimate value experience for specific user groups. This reminds me of a quote by Steve Jobs: “Innovation is to say no to a thousand things.” “In the emerging field of AI tools, this ability to focus and make trade-offs may outweigh the richness of features.
The third logic is that “dancing with the trend is better than fighting the trend”. The Amp team’s deep understanding of the behavioral characteristics of different AI models allows them to “conform to the model’s preferences” rather than forcibly changing the model’s behavior. This philosophy applies not only to the technical level, but also to the business level. They observed changes in user acceptance of AI costs and adjusted their pricing strategies promptly; They discovered the value of sub-agents and immediately invested resources in in-depth development. This ability to adapt agilely, I believe, is key to maintaining a competitive edge in a rapidly changing environment.
The fourth logic is that “pragmatism is better than perfectionism”. Whether it’s the technical route selection of background agents or the design of feedback loops, the Amp team shows a strong pragmatism tendency. They do not pursue technical perfection, but choose solutions that can actually be implemented and bring value. This pragmatic attitude allows them to iterate and innovate quickly with limited resources, avoiding the “over-engineering” trap common to many startups.
The last logic, and I think is the most important, is that “long-termism is better than short-term opportunism”. Many of the Amp team’s decisions seem “irrational” in the short term: declining feature requests will lose users, not limiting costs will reduce profit margins, and stubborn product ideas will cause controversy. But in the long run, these decisions build a unique competitive advantage and user loyalty for them. They are not chasing the current hot spots, but are laying out the technology trends for the next five or ten years.
Behind this underlying logic, I see a new product development paradigm: in the era of rapid technological evolution, the most successful products may not be those with the most features, but those that understand the essence of technology most deeply and focus on core value creation. Amp’s story teaches us that sometimes “doing less but doing deep” is more valuable than “doing more but doing shallowly”. This is not only a product strategy question, but also a cognitive question about how to make the right judgment in the face of uncertainty.
Returning to the AI programming tools track, I believe we are witnessing the beginning of a new era. The traditional software development model is being redefined, and the content of programmers’ work is fundamentally changing. In this process of change, products that can deeply understand the nature of change and have the courage to make difficult choices will become the leaders of the new era. Amp may be just the beginning of this story, but it has already shown us a possible path: to create lasting value in a rapidly changing world through deep technical understanding, focused product strategy, and pragmatic execution
