Imagine a personal software repository whose GitHub issue and pull-request sequence number is approaching four digits.
The immediate reaction is tempting:
“Wait, did one person really do almost a thousand development jobs?”
Close, but not quite. GitHub treats every pull request as an issue for numbering purposes, and issue and pull-request numbers do not overlap inside a repository. A sequence number near 1,000 therefore does not mean that 1,000 pull requests were completed.[1]
The more interesting question survives the correction:
If a human had to perform this scale of modification, checking, repair, publication, and operations mostly by hand and without AI, what would it cost—and would the economics make sense?
That question gets to the heart of AI-assisted solo development.
1. A GitHub number is not a gym rep counter
A repository number is not a workload meter.
One developer may put 2,000 changed lines into one pull request. Another may open a pull request for a one-line CSS fix. Issues are mixed in as well: bugs, design notes, feature requests, investigation tasks, and operational follow-ups can all consume the same numbering space.
So:
Almost 1,000 in the sequence does not mean 1,000 people worth of labor.
Nor does it mean:
Almost 1,000 completed features.
The number is closer to a turnstile counter than a scale.
Still, if many small changes were accumulated in a short period, the history reveals something meaningful: the design → implementation → verification → repair loop ran again and again.
For human cost, the important variable is not the number itself. It is the average time consumed by each substantive loop.
2. Human cost is easiest to underestimate when every task looks tiny
A September 2026 report based on listings on a Japanese freelance-engineer marketplace put the August 2026 average monthly project rate at ¥789,000.[2]
That is not every developer’s salary and not the hourly wage of any particular person. It is a marketplace average.
But it is useful as one replacement-cost benchmark: roughly, what might comparable professional engineering capacity cost if purchased externally?
At 160 hours per month, ¥789,000 is about ¥4,930 per hour.
Now consider a hypothetical 1,000 substantive change units. This is deliberately not the same thing as a GitHub sequence number.
| Average time per change | Total time | Person-months at 160 h/month | Cost at ¥789,000/month |
|---|---|---|---|
| 15 min | 250 h | 1.56 | about ¥1.23M |
| 30 min | 500 h | 3.13 | about ¥2.47M |
| 45 min | 750 h | 4.69 | about ¥3.70M |
| 1 h | 1,000 h | 6.25 | about ¥4.93M |
| 2 h | 2,000 h | 12.5 | about ¥9.86M |
| 3 h | 3,000 h | 18.75 | about ¥14.79M |
| 4 h | 4,000 h | 25 | about ¥19.73M |
Even 1,000 tiny 15-minute changes become 250 hours.
“One task is small” does not imply “the total is small.”
Small tasks also carry fixed coordination costs: investigation, branching, review, testing, merging, deployment checks, and rollback thinking.
Do all of that manually and the business card eventually becomes a fold-out brochure: writer, translator, frontend developer, backend developer, QA, infrastructure operator, and editor-in-chief.
3. “I did it myself, so labor cost is zero” can be true in cash accounting and false in economic comparison
A personal site may spend ¥1,000 a month on hosting and earn ¥5,000 from ads.
In cash terms, that is a ¥4,000 surplus.
But suppose the owner spends 50 hours per month creating and maintaining it.
If the goal is to compare the site as a business, separate two views:
Cash profit = revenue − cash expenses
Labor-adjusted profit = revenue − cash expenses − owner hours × chosen replacement hourly value
For a hobby, valuing your own time at zero can be completely reasonable. Nobody normally says that playing a game for 50 hours created a labor loss.
The problem starts only when hobby accounting is presented as proof of commercial profitability.
Learning, enjoyment, reputation, and the satisfaction of building something are real returns. They simply are not identical to business profit.
When comparing businesses, time does not disappear because the invoice was never sent.
4. Advertising economics can require a surprisingly large denominator
A simplified advertising equation is:
Ad revenue = pageviews ÷ 1,000 × effective RPM
Effective RPM varies sharply with country, device, format, season, topic, audience, and ad stack.
So instead of pretending there is one universal market RPM, use hypothetical values simply to see the scale.
If a site needed to recover ¥789,000 per month from advertising alone:
| Illustrative effective RPM | Pageviews needed for ¥789,000/month |
|---|---|
| ¥100 | about 7.89M PV |
| ¥300 | about 2.63M PV |
| ¥500 | about 1.58M PV |
| ¥800 | about 0.99M PV |
This is not a forecast of anyone’s ad revenue.
It shows why valuing manual labor at professional replacement cost can make an ad-only business look demanding.
Many manually operated sites therefore work because the return is not ads alone: affiliate revenue, product sales, client acquisition, memberships, donations, brand value, or simple hobby value may matter more.
5. AI changes more than writing speed
Reducing AI to “it writes an article in 30 seconds” misses most of the economics.
Running a web publication involves surrounding work:
- finding topics,
- researching,
- drafting,
- fact-checking,
- changing code,
- testing,
- localization,
- publishing,
- production verification,
- incident repair,
- social and newsletter distribution,
- performance review and improvement.
With manual operations, each additional process usually increases variable labor.
With AI plus automation, the initial system-design cost can be larger, but the marginal cost of the second, tenth, and hundredth item may fall.
That is a different economic structure.
It is less “a writer became faster” and more:
one person can own the operating system of a small editorial and engineering team.
The human does not disappear. The role moves toward inputs, decisions, specifications, quality standards, exceptions, and governance.
The job shifts from typing every artifact to designing the factory and editing its output.
6. AI is not a magic bottle of nitrous oxide that always makes development faster
Research is interesting precisely because the results do not point in one direction.
A controlled study published in 2023 found that participants with GitHub Copilot completed a specified JavaScript HTTP-server task 55.8% faster than the control group.[3]
A 2025 randomized controlled trial by METR found something very different. Sixteen experienced open-source developers working on mature repositories they had known for years took 19% longer, on average, when early-2025 AI tools were allowed.[4]
In February 2026, METR explained that a later experiment had become difficult to interpret. More developers were reluctant to participate if they had to work without AI, and measuring time became harder for people running multiple agents in parallel. METR said later tools may well be producing more speedup than the early-2025 tools, but the new data could not support a strong numerical estimate because of selection and measurement problems.[5]
So the lesson is not:
AI always makes coding 55% faster.
Nor is it:
AI makes experts 19% slower.
Effects depend on the task, codebase familiarity, agent workflow, review burden, parallelization, and test environment.
AI can create correct work at high speed. A bad system can also manufacture bugs at high speed.
The relevant productivity number is the one measured in your actual workflow.
7. A manual site does not automatically lose
A heavily automated AI system is not guaranteed to outperform a handcrafted site economically.
Manual production can be rational when:
- only a few pieces are published each month,
- the expert’s personal writing is itself the product,
- one article sells a high-value service or product,
- localization and large-scale distribution are unnecessary,
- updates are rare,
- the owner enjoys the work as a hobby,
- or the cost of building automation would exceed the labor saved.
Automation becomes more attractive when:
- the same process repeats constantly,
- many locales are supported,
- the article inventory grows,
- QA, publication, and production verification occur every time,
- distribution channels multiply,
- and humans repeatedly perform identical checks.
This is fundamentally a fixed-cost versus variable-cost problem.
The AI factory can be expensive to build. The manual workshop can be expensive per unit.
And one warning matters: a spectacular fully automated factory with no readers is not the media future. It is an extremely sophisticated warehouse.
8. To understand the economics of an AI-free manual site, ask for these numbers
There is no need to judge the person. To compare systems, a few operating numbers are enough:
- Owner hours per month
- Monthly pageviews or unique users
- Monthly revenue and cash expenses
- Number of articles and new articles per month
- Number of supported languages
- Years in operation and approximate initial build hours
From these, useful measures follow:
Cash profit = revenue − cash expenses
Owner cash return per hour = cash profit ÷ owner hours
Labor-adjusted profit = cash profit − owner hours × comparison hourly value
Marginal cost per article = incremental writing + translation + QA + publication + distribution labor and expenses
The last measure is especially important.
The fact that 1,000 hours were spent in the past is less predictive than how many hours the next article requires now.
9. The strongest AI advantage is not volume; it is repeatability
Generating a huge pile of files overnight is not especially difficult anymore.
The hard part is creating a system in which:
- the same quality rules apply next time,
- only the failed scope needs to be retried,
- duplicate publication is prevented,
- the current revision is identifiable,
- the real production output is verified,
- one blocked channel does not freeze unrelated work,
- authentication that truly requires a human is handed back to a human,
- and the history remains auditable.
That is not merely generation volume.
It is an operating asset.
A manual site can build the same kind of asset through procedures, templates, CMS automation, backups, and checklists.
The AI-era difference is that one person can now build these operating layers unusually deeply.
10. Conclusion: the interesting question is not “Did the counter reach 1,000?” but “What does the next unit cost?”
A four-digit issue/pull-request sequence number looks dramatic.
It should not be used as a productivity score.
The more useful numbers are:
human hours, cost per change, marginal cost per article, rework before publication, output per owner hour, and labor-adjusted profit relative to revenue.
A manual site can absolutely be profitable.
An AI-assisted site can absolutely be unprofitable.
But the cost curves differ sharply between a model where humans repeatedly perform writing, translation, coding, QA, publication, monitoring, and distribution by hand, and a model that spends upfront effort to systematize those steps and lower marginal cost.
The approaching 1,000th sequence number is interesting not because it is a trophy.
The interesting part is this:
Of all those rounds of trial and repair, how many became mechanisms that no longer require a human to repeat the same work next time?
That is where the unit economics of AI-assisted solo development becomes genuinely different.
References (5)
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
