Trust and quality notes
- Last updated
- September 18, 2026
Building on top of fast-improving AI creates an unusual planning problem. A feature that seems essential today may become unnecessary when the underlying model improves. At the same time, an idea that looks distinctive may be easy for another team to reproduce because access to strong models and APIs is widely available.
Chris Pedregal’s original statement is aimed at startup builders, but its lesson is broader: automation changes which problems are worth solving.[1] His advice is blunt. Do not invest deeply in a problem that the next generation of the underlying technology is likely to remove.
That does not make planning impossible. It makes assumptions about future capability part of the work.
The ground moves under the product
Pedregal compares building a generative AI startup to playing a difficult video game at twice the speed. His reason is dependency. When a product relies on models supplied by companies such as OpenAI or Anthropic, the product is built on technology improving at an unpredictable pace.[1]
The risk is not merely technical failure. It is successful work that becomes redundant. A team can spend weeks building around a current model limitation, then see a new release handle that limitation directly. According to Pedregal, recent model progress has already moved across image processing, complex mathematics, and sophisticated code generation.
His source presents this as a break from familiar startup intuition. Rules developed in a slower software environment may no longer guide good decisions. Even the common advice to solve the biggest pain point first can mislead if that pain point is temporary.
My interpretation is that teams need to separate customer problems from model problems. A customer problem may persist even as the technical method changes. A model problem exists because today’s system cannot perform a task reliably. Building a durable product around the first may make sense. Building heavily around the second requires a clear view of how long the limitation will last.
Some hard problems are temporary
Pedregal’s central instruction is, “Don’t solve problems that won’t be problems soon.”[1] It sounds obvious, but he emphasizes that following it feels wrong. Teams are trained to respond to visible friction. Leaving a current problem unsolved can look careless, especially when users experience it now.
The source does not claim that every limitation will disappear on schedule. In fact, Pedregal calls the pace unpredictable. His argument is that builders must still make a forecast because refusing to forecast is itself a decision. If a roadmap assumes today’s model capabilities will remain fixed, it contains an implicit prediction that may be less defensible than an explicit one.
A useful consequence follows. Before committing to a feature, a team can ask whether the feature creates lasting value or merely patches a likely short-lived weakness. That question comes from Pedregal’s thesis. The next step is my interpretation: write the capability assumption beside the feature. State what the current model cannot do, what improvement would make the feature redundant, and how the product would remain useful if that improvement arrived.
This does not require pretending to know the future. It requires making uncertainty visible enough to guide the size and timing of an investment.
Prediction becomes part of the job
Pedregal says that predicting the future is now part of the job for people building at the application layer. They have to form a view of what the next model generation will be capable of, then use that view to shape product strategy and the roadmap.[1]
That forecast should not be confused with a grand prediction about society. My interpretation is that it can be narrow and operational. Which forms of input will models handle? Which reasoning or production tasks may become routine? Which current failures seem tied to a fundamental constraint, and which look like the kind of limitation a model update could reduce?
The source does not provide a forecasting method. One interpretation is to treat forecasts as revisable product assumptions rather than fixed convictions. A team can record them, watch model releases, and update its plans when evidence changes. The value lies less in always being right than in knowing which bets depend on being right.
This approach also discourages oversized commitments. If a problem may disappear, a small bridge may be more sensible than a large permanent system. The goal is not to ignore present users. It is to serve them without turning every temporary constraint into a long-term product foundation.
Easy construction raises the bar for value
Pedregal notes a second pressure: strong APIs and frontier language models are available to many builders, so an impressive idea can often be copied. Automation lowers the effort required to build, but that lower effort applies to competitors too.[1]
The source does not say exactly where durable differentiation will come from. It does imply that the mere ability to assemble a feature is less protective when many teams can access similar underlying capabilities.
My interpretation is that the test for a roadmap item should include more than “Can we build it?” Teams should ask why the result will continue to matter when implementation becomes easier and the model improves. A feature that exists only because construction used to be difficult may lose significance. A product connected to a persistent need may continue to matter even if its internal implementation changes.
This is a sober reason to avoid treating technical novelty as the whole product. Novelty can attract attention, but Pedregal’s argument focuses on what will remain a problem.
Plan around what stays difficult
For people new to AI, Pedregal’s thesis offers a clear way to review an automation idea. First, identify which part of the proposed work solves a human or business need. Second, identify which part compensates for a current model limitation. Third, decide how much effort is justified if that limitation shrinks.
This review does not guarantee the right prediction. Nothing in the source promises certainty. It does improve the quality of the bet by forcing the team to acknowledge that the technical baseline is moving.
The deeper point is that faster automation changes the cost of being attached to an old problem. A team can work hard, ship successfully, and still discover that it optimized for a world that has already changed. Product judgment therefore includes choosing not only what is painful today, but what is likely to remain worth solving tomorrow.
If you need to test an automation opportunity without overbuilding around today’s limitations, review one workflow with Agentic Workers.