The threshold for writing a browser extension, a CLI (command-line interface) tool or a small web app with AI (artificial intelligence) has dropped noticeably. In my own experience, and in the experiences developers share on LinkedIn and X, I see development work that could take weeks shrink to days, or even hours, depending on its scope. This is a real gain, especially for people who have an idea but not the skills to write the code. On the other hand, this ease has a side effect: many projects that solve the same problem, resemble one another and are maintained by a single person, along with the extra cognitive load and bottleneck these projects create for makers and developers. Yet the solution needed may already have been written by someone else, and a feature added to that project may live longer than a brand-new repo, deliver more value and keep the workload to a minimum.
This post looks at building products with AI along three axes: where the constraint moves once production gets cheaper, how discoverable a newly written product or tool is, and how its maintenance cost and revenue can be handled. Every figure cited comes from external sources; the source of each is in the footnotes.
Production Got Cheaper, the Constraint Moved
The theory of constraints (TOC) holds that a system’s output is set by its weakest link.1
According to Lean Production’s summary, optimizing steps that are not the constraint does not provide a meaningful benefit, and once a constraint is resolved, the next one should be addressed right away.1 In product development, one of the constraints is, broadly, the time and skill needed to turn an idea into a working product. The core parameters are the same in physical and digital product development, but the scope of the required skills differs. In digital product development, one of the constraints for a long time was coding skill.
With the approach known as vibe coding and with AI coding agents, the coding step in digital product development got cheaper. Seen through TOC, the expected outcome is that the constraint moves somewhere else. Two telemetry reports from Faros AI show the other metrics that changed along with the number of PRs (pull requests) merged per developer.2
| Metric (per developer) | 2025 report, 10,000+ developers | 2026 report, 22,000 developers |
|---|---|---|
| Tasks completed | +21% | +33.7% |
| PRs merged | +98% | +16.2% |
| PR size | +154% | +51.3% |
| Time spent in PR review | +91% | +441% (median) |
| Bugs | +9% | +54% |
These figures come from Faros’s own telemetry and appear in the company’s post summarizing the DORA 2025 report.2
Yes, code generation got faster. But reading, understanding and verifying the generated code could not keep up with that pace. In the 2026 data, the rise in review time being far larger than the rise in merged PRs points to the constraint moving to review. Of course, this is not proof of causation. The telemetry shows the relationship between AI usage and review time, not the cause of the change.
The same report also measures metrics that point to cognitive load in teams moving from low to high AI usage. The number of PRs a developer touches in a day rose 67.4%, and the number of tasks they switch between rose 17.7%. Work moving back to in-progress from another stage rose 13.8%, and work that has seen no PR or activity for 7 days or more rose 26%.2
“The picture is of a development environment where it is easy to begin and hard to finish.”2
The Gap Between Perception and Measurement
DORA’s 2025 report and Faros’s 2026 report diverge at this point. Based on a survey of nearly 5,000 technology professionals, DORA describes AI as an amplifier that magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. According to the report, AI adoption now improves delivery throughput, but still increases delivery instability.3 Faros, in turn, says its own telemetry does not support DORA’s conclusion that strong engineering foundations protect against AI’s negative effects, and that high-performing organizations go through the same degradation in review and production. It attributes the difference to method: a survey measures how developers feel, while the effect that builds up in review queues and in production reaches that feeling only months later.2 The two reports point the same way on rising throughput and declining stability; where they diverge is whether strong teams are protected from it. I could not find independent data that answers this question; DORA’s evidence rests on a survey, Faros’s on telemetry from teams on its own platform.
In a randomized controlled trial METR ran in early 2025, 16 experienced open source developers worked on 246 real issues in projects they had contributed to for years, averaging more than 22,000 stars and over 1 million lines of code. Tasks where AI tools were allowed took 19% longer. The developers had expected a 24% speedup beforehand, and after the study they still believed they had been 20% faster.4
It is hardly possible to say this result also holds for current AI tools. Indeed, in February 2026 METR described the data from its new experiment as an “unreliable signal” of the current effect:
“we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools.”5
Between 30% and 50% of developers reported not submitting some tasks because they did not want to do them without AI, and METR notes that this selection likely pulls the speedup estimate down.5
The lesson to take from the study is not a speedup rate but the gap between developers’ perception of their own speed and the measurement. My reading is that in a large, mature codebase, the cost of building context and verifying output can outweigh the cost of writing the code.
When Everyone Writes, Who Finds It?
The second place the constraint moves to is distribution. In Amit Prakash Sharma’s preprint published in January 2026, a total of 2,240 queries were sent to ChatGPT (gpt-4o-mini) and Perplexity (sonar) for 112 startups selected from the top 500 of the 2025 Product Hunt rankings.6 The results:
- Asked about products by name, both LLMs (large language models) recognized them almost every time: ChatGPT 99.4%, Perplexity 94.3%.
- In open-ended discovery questions such as “What are the best AI tools launched this year?”, the rate dropped to 3.32% on ChatGPT and 8.29% on Perplexity.
- No correlation was found between GEO (generative engine optimization) scores and discovery rates.
- On Perplexity, the number of referring domains and the Product Hunt ranking correlated with visibility; once false matches in the Reddit data were cleaned up, community presence became significant as well.
This is a study based on a single preprint, two models and observational data. It does not show that external references directly lead to LLM recommendations.
If even a product in Product Hunt’s top 500 rarely comes up in a general discovery question, I think things are harder for a newly opened repo with no community. I have not verified it, but if I had to guess, a feature added to an active project inherits that project’s references, documentation and user community. In that sense, contributing is also a distribution decision.
Contributing can also be seen as a matter of prestige. On LinkedIn and X, I now and then see developers celebrating when their contributions to large projects are accepted. Of course, I can understand a developer’s wish to stand out in their own name too, but the question is: what will it cost?
The Bottleneck Is the Maintainer
Cheaper production shifts the load in open source from the contributor to the maintainer. In its April 2026 post, the Dagster team sums up the situation: changes are becoming easier to produce than to review thoroughly, but reviewing a PR still takes context, judgment, and coordination.7 The friction points listed in the post:
- A passing CI (continuous integration) run does not show that a change meets the codebase’s conventions and quality bar.
- Even functionally correct PRs can need several review rounds to fit the repo’s conventions.
- Broad AI prompts produce large diffs with thin context.
- Core framework changes need more design context and coordination.
Data on which patterns AI-generated code carries also shows where review load comes from. OX Security’s “Army of Juniors” report, as covered by InfoQ, lists recurring anti-patterns in AI-generated code by how often they appear.8
| Anti-pattern | Frequency given in the report |
|---|---|
| Comments Everywhere | 90-100% |
| Avoidance of Refactors | 80-90% |
| By-the-Book Fixation | 80-90% |
| Over-Specification | 80-90% |
| Bugs Déjà-Vu | 80-90% |
When the contributor does not weed out these patterns before submitting, each one turns into work the maintainer has to catch in review. I often come across X posts from developers about this.
A Contribution That Protects the Maintainer’s Time
Dagster’s suggestions on PR shape:7
- One PR, one clear problem.
- Few files; a change that does not spread across several teams’ areas.
- Picking the right area: documentation, examples and community integrations are the fastest path to a merge, while core framework changes take longer.
Beyond these, my modest suggestions, based on my own experience, for those working with AI and thinking about contributing to a project would be:
- Reading the diff line by line before submitting. A line the sender cannot explain turns into a question from the maintainer in review.
- Opening an issue or discussion before a large change to agree on direction with the maintainer. On GitHub, I can say this is rarely a fast process, and sometimes an issue gets no response at all.
- Giving the AI tool the project’s contributing guide and, if there is one, its agent instructions file as context.
Before Writing: Is This Problem Already Solved?
MyWorks is one example of a tool that grew out of a real, recurring friction. According to the Acquire.com post, its founder Peter Leonard ran an agency that built WooCommerce sites. As the business grew, reconciling the accounting and sales systems took more and more hours and turned into a full-time job.9
“We started building the software for ourselves, but after months of listening to customers, we realized this would be a huge time-saver for them, too. We began to plan our roadmap around their needs and not our own.”9
They first built the software for their own team, and after months of listening to customers they realized those customers had the same problem.9 The same post draws another distinction: Leonard says competitors seemed to build their apps for developers, while they built theirs for the people living with the problem. For those who want to hear Leonard’s story in his own words, there are two interviews: the saas.unbound episode (April 2023) on the sale process, and the Sounds Good episode (September 2026) on life after the sale.
Two points in Leonard’s account give two legitimate reasons for writing a new tool: the need is real, and existing solutions serve a different user. Without either, the case for opening a new repo weakens. While his team was building the product, Leonard also looked through ecommerce app stores to see whether a similar product already existed.9 Places to look before starting:
- Searching package and extension directories (npm, PyPI, Chrome Web Store) and GitHub by the job the tool does, not by its name.
- Relevant awesome lists and the ecosystem’s own directories.
- The same feature request in candidate projects’ issue trackers. If there is an open request, the place for the contribution is already there.
- The date of the last commit and release, and the response time on open PRs.
- The license: how far it allows contributions, forks and commercial use.
Some services automate part of these checks:
- Open Source Insights (deps.dev): A service developed by Google; it shows the dependency graph, licenses, known vulnerabilities and release history for Cargo, Go, Maven, npm, NuGet, PyPI and RubyGems packages.10
- OpenSSF Scorecard: Scores a repo from 0 to 10 through a set of checks on maintenance, licensing and security practices. The Maintained check looks at weekly commits over the last 90 days and at maintainers’ issue activity; projects younger than 90 days cannot pass it. Results for regularly scanned projects can be viewed without any setup.11
- ecosyste.ms: Offers metadata for more than 15 million packages and 349 million repos from 110 sources as an open dataset.12
Scorecard’s documentation also carries a caveat: a lack of active maintenance is not always a problem; small utility libraries in particular may normally need no maintenance.11 I recently ran into this with the d3-sankey repo, which I was considering for the Inspect Signals extension. So the date of the last commit is not a filter on its own, but a sign to look more closely.
These services measure the health of a candidate project, but they do not find the candidate. Finding the project that solves the need still means searching directories and issue trackers by the job. Asking an AI tool is another route, but in the Discovery Gap study products were rarely recommended in open-ended questions. I assume the same limit applies to small open source projects; I could not find data that measures it.
What Can Make a Project Findable?
The question can also be asked the other way around: if a new tool has been written, or an existing project is waiting for contributions, what can be done so that the developer who would contribute, and the user searching with a search engine or an AI tool, find it? The Discovery Gap study partly answers this. Some of the signals whose relationship with Perplexity visibility was measured:6
| Signal | Correlation with Perplexity visibility (r) |
|---|---|
| Number of distinct subreddits (cleaned) | +0.405 |
| Reddit mentions (cleaned) | +0.395 |
| Number of referring domains | +0.319 |
| Dofollow link ratio | +0.238 |
| GEO score | No significant relationship |
| GitHub stars and Hacker News | No significant relationship |
The Reddit rows were computed on the 60 products left after removing 52 products whose generic names produced false matches. On ChatGPT, none of these signals turned out significant; according to the author, discovery on ChatGPT appears “essentially random”. The author reads GEO’s lack of effect as a multiplier that does not work without an existing visibility base, and recommends building the SEO (search engine optimization) foundation first rather than optimizing directly for AI discovery.6
Two limits are worth keeping in mind when reading these findings. The study measures Product Hunt products, not open source repos. GitHub stars not being significant may not hold for a repo. There is no separate measurement for AEO (answer engine optimization) either. A landing page or documentation site gives an address that other sites can link to and that can be found by searching for the job the project does; but I could not find data that measures its effect on discovery, so this is an interpretation.
The answer to the vicious-circle question is in the same study. The author says training data overrepresents established players, and that this creates an “authority concentration” effect in which the rich get richer in AI visibility.6 My reading: a new project without references and community does not get recommended, and because it is not recommended, it struggles to gain references and community. The correlations show that this loop is possible, but they do not prove that it exists. Contributing to an existing project means starting outside this loop.
On the side of the developer who would contribute finding the project, the maintainer’s options are clearer:
- Topics: GitHub presents adding topics to a repo as a way to help others find and contribute to the project.13
- The
good first issuelabel: Lets people searching by the label find these issues; according to GitHub, the label also increases the likelihood that issues are surfaced on the platform.14 - Contribution guides and tools: Dagster keeps separate contribution guides for code and documentation, adds automated review tools such as Greptile that give PR suggestions based on the repo’s existing patterns, and recommends a skill called Dignified Python to contributors working with AI, so they produce more consistent and reviewable changes.7
- An up-to-date README, ADRs and specs: This item comes from my interpretation, not from a source. An up-to-date README that explains what was done and why, ADRs (Architecture Decision Records) and specs make it easier for someone coming from outside the project, and for the AI tool they use, to build context. I covered one way to structure this documentation for AI agents in the Living Architecture post, and decision records in the ADR vs Spec-Driven Development post.
Decision Table
| Situation | Path | Rationale |
|---|---|---|
| An active project covers most of the need; one feature is missing | Contribute | The feature reaches the project’s users and distribution; maintenance is shared |
| The project is active, but the desired change does not fit its direction | A plugin or a separate small tool | Avoids creating PR load for work outside the maintainer’s scope |
| The project is abandoned and the license allows a fork | Fork | Maintenance now sits with whoever takes the fork; that load should be accepted up front |
| Existing solutions serve a different user | New tool | The distinction in the MyWorks example: a tool written for developers vs one written for the people living with the problem |
| The need is specific to a single workflow | An unpublished local script | Every published tool is a maintenance and support commitment |
Revenue and Sustainability
In my view, the cost of a new tool takes shape over time and settles at a baseline. AI lowered the cost of writing (a subscription costing about as much as a month of coffee), but answering issues, keeping dependencies up to date, patching vulnerabilities and supporting users still take time and create cognitive load. Ten small projects mean ten separate maintenance commitments, and for a solo developer all of them pile up on the same person. On top of that come the stress of earning revenue and fixed costs.
A common pattern shows up in the examples where open source generates revenue:
- Langfuse: According to ClickHouse’s January 2026 acquisition announcement, the core features are MIT-licensed, and this license allows self-hosting at production scale. The project has more than 20,000 GitHub stars and Langfuse Cloud customers.15 Orrick, which advised Langfuse on the acquisition, states that the company had more than 2,000 paying customers.16
- Dagster: Brought the open source project and the commercial Dagster+ product together under a single monorepo and a single development model.7
In both examples the core is open. Hosting, the managed service and enterprise use are paid. This pattern requires a team, a company structure and enterprise customers. I assume that a browser extension or CLI tool maintained by one person building this structure is the exception; I could not find data that measures it.
For the contributing developer, the return is not direct revenue. In the Discovery Gap study, the signals that correlated with visibility were referring domains and community presence. Appearing in the commit history of a well-known project may be a more visible reference than a new repo nobody discovers. This is also an interpretation. A source showing that contributing brings in work or clients is not among the data this post rests on.
Users have a share too. If there is a way to help an open source tool they use survive, it is using its paid plan, reporting bugs or supporting the project directly; not rewriting it.
Decision Order
- Defining the need by the job it does, not by the name of a tool.
- Searching package and extension directories, GitHub and candidate projects’ issue trackers.
- If there is an active project, opening an issue, agreeing on direction with the maintainer and sending a small PR.
- If the project is abandoned, calculating the maintenance load of a fork up front.
- Starting a new tool only if the need belongs to a different user or a different problem, and planning distribution together with the code.
AI opening up code writing to everyone also made the work around software visible: review, distribution, maintenance and revenue. Now that the constraint sits in these areas, the first question for the next tool idea might not be “how do I write this” but “does this already exist, and how can I contribute to it”.
Related Posts
- Decision Gate: The Missing Piece of Vibe Coding
- Context Engineering for AI Coding Agents: From Static Documents to a Living Ecosystem
- AI-Powered Codebase Audit: A Production-Grade Approach for Solo Entrepreneurs
Footnotes
- Theory of Constraints (Lean Production). “spending time optimizing non-constraints will not provide significant benefits” and “once a constraint is resolved the next constraint should immediately be addressed.” ↩ ↩2
- Key Takeaways from the DORA Report 2025 (Faros AI). The 2025 figures come from Faros’s “The AI Productivity Paradox” telemetry analysis covering more than 10,000 developers, and the 2026 figures from the AI Engineering Report 2026: The Acceleration Whiplash (Faros AI) report covering 22,000 developers; the cognitive load figures and the quote are on pages 8-9 of the report. The section where it diverges from DORA is on page 5: “Our telemetry data, drawn from engineering systems across thousands of teams, does not support that as a protective factor.” “Median time in PR review is up 441%, compared to 91% in our 2025 dataset.” On the DORA report: “arrived with survey data from nearly 5,000 developers worldwide to complement the picture.” ↩ ↩2 ↩3 ↩4 ↩5
- 2025 DORA State of AI-assisted Software Development (Google Cloud). The quotes are on pages 3-4 of the report. “AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.” and “AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability.” ↩
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR). 10 July 2025. ↩
- We are Changing our Developer Productivity Experiment Design (METR). 24 February 2026. “we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools.” ↩ ↩2
- The Discovery Gap: How Product Hunt Startups Vanish in LLM Organic Discovery Queries (arXiv:2601.00912). Amit Prakash Sharma, 1 January 2026, preprint. ↩ ↩2 ↩3 ↩4
- Making Dagster Easier to Contribute to in an AI-Driven World (Dagster). 1 April 2026. “reviewing a PR still takes context, judgment, and coordination.” ↩ ↩2 ↩3 ↩4
- AI-Generated Code Creates New Wave of Technical Debt, Report Finds (InfoQ). Patrick Farry, 18 November 2025. The article covers OX Security’s “Army of Juniors: The AI Code Security Crisis” report. ↩
- How I Got Acquire’d: Listen to Customers Inside and Outside of Your Business, Says Founder of MyWorks (Acquire.com). “Our competitors seemed to build their apps for developers, not the people suffering the problem.” and “Meanwhile, he researched ecommerce app stores to see if anything like it existed in the market.” ↩ ↩2 ↩3 ↩4
- Frequently Asked Questions (Open Source Insights). “Open Source Insights is a service developed and hosted by Google to help developers better understand the structure, security, and construction of open source software packages.” ↩
- OpenSSF Scorecard (GitHub) and, for the check definitions, Scorecard Checks. “However, a lack of active maintenance is not necessarily always a problem.” ↩ ↩2
- ecosyste.ms. “Tools and datasets to support, sustain, and secure critical digital infrastructure.” ↩
- Classifying your repository with topics (GitHub Docs). “To help other people find and contribute to your project, you can add topics to your repository” ↩
-
Encouraging helpful contributions to your project with labels (GitHub Docs). “Adding the
good first issuelabel can increase the likelihood that your issues are surfaced.” ↩ - ClickHouse welcomes Langfuse (ClickHouse). 16 January 2026. “Langfuse remains 100% open-source under its existing MIT license for core features.” ↩
- Open source LLM Observability Langfuse Acquired by ClickHouse Inc (Orrick). 26 January 2026. “more than 2,000 paying customers.” ↩
- 01 According to the theory of constraints, speeding up a step that is not the constraint does not increase a system's output; as code generation with AI speeds up, the constraint shifts to review, verification and maintenance.
- 02 In Faros AI's telemetry reports, PR size and review time rose along with the number of PRs merged per developer; in the 2026 data, median review time rose 441%.
- 03 In a study of 112 products from Product Hunt's top 500, ChatGPT recommended these products in only 3.32% of open-ended discovery queries; on Perplexity, community presence and referring domains correlated with visibility, while GEO scores did not.
- 04 Contributing is less about opening a PR than about protecting the maintainer's review time: one problem, few files, adherence to the repo's conventions.
- 05 In the Langfuse and Dagster examples, where open source generates revenue, the core stays open while hosting and enterprise use are paid.
+ Is it more sensible to write my own tool with AI or to contribute to an existing project?
If an active project covers most of the need and only one feature is missing, contributing is usually less costly; the feature reaches the project's users and distribution, and maintenance is shared. If existing solutions serve a different user, or the project is abandoned, a new tool or a fork may fit better. The decision table in the post separates these cases.
+ Is it a problem to send an AI-generated PR to an open source project?
Not in itself. The problem is review cost: as Dagster puts it, changes are becoming easier to produce than to review thoroughly. A PR that solves a single problem, touches few files, follows the repo's conventions and has been read line by line by its sender does not noticeably increase the maintainer's load.
+ Why is nobody finding the tool I just wrote?
In the Discovery Gap study, even products in Product Hunt's top 500 were recommended by ChatGPT in only 3.32% of open-ended discovery queries. On Perplexity, the signals that correlated with visibility were referring domains and community presence, while GEO scores did not correlate. A new repo starts these signals from zero; a feature added to an existing project inherits that project's references and community.
+ Is it possible to earn revenue from an open source tool?
It is, but the examples share a pattern. Langfuse kept its core features open under the MIT license while serving paying customers through Langfuse Cloud, and according to Orrick it had more than 2,000 paying customers. Dagster runs the open source project and the commercial Dagster+ product under the same development model. This pattern needs a team and enterprise customers; building the same structure around a small one-person extension is hard.
+ How can I tell whether an open source project is still maintained?
OpenSSF Scorecard's Maintained check looks at weekly commits over the last 90 days and at maintainers' issue activity; Google's Open Source Insights (deps.dev) service shows packages' licenses, known vulnerabilities and release history. The Scorecard documentation also notes that a lack of active maintenance is not always a problem; small utility libraries may not need maintenance.
+ What can I do so that developers who would contribute find my project?
GitHub presents adding topics to a repository and using the good first issue label as ways to make a project easier to find. Dagster keeps separate contribution guides for code and documentation and recommends a skill to contributors working with AI so their changes follow the patterns in the repo.