You have probably heard that story about a software developer buidling a replacement for Adobe’s software over a weekend by now.
My personal reaction to seeing those announcments was somewhere in between “Holy crap what a feat!” and “Wait a second, has it been exaggerated, perhaps, even if a little?”
Don’t get me wrong, coding agents powered by those frontier LLM-s can do a lot. At this point I would not be questionning the fact that a coding agent can write greate code, I’d be questionning the economics/feasibility of creating Adobe’s replacement over a weekend for a regular person.
That would be, mostly, for a few reasons:
– Employing a coding agent, or a swarm of agents, can be quite expensive. I mean, sure, you can prove the point that way, you can come up with something cool, but it’ll cost you. Simply put, you can’t even test such a product over the weekend. As of today (Oct 16), the project puts itself at about 50% in terms of parity with Adobe (https://github.com/storytold/pdfcraft) . And even that can be optimistic in my opinion. However, that means it’s not a replacement, yet. The project now has to close the gap to get to the parity.
– It is Oct 16, it was released almost two weeks ago, and its still in the early alpha stage. Does it count as an over the weekend Adobe replacement? Not really
– If the dev team continues to use Opus 5.5 or another frontier model to keep development going, this is now going to start costing them money AND time. That’ll not be a free ride (as in, there is no way one can simply ask Opus 5.5 to fix all the bugs and get to the parity with Adobe. It does not work that way)
So, then… When I hear such news, I take them with a grain of salt. It is impressive what AI can do, it is also terrifying sometimes, and there is no doubt this is something we could hardly imagine a few years ago, but it is not as if everyone could just start writing their own software. If you have money to buy enourmous amount of API calls, if you have time to work with the agents, and if you have time to test the outcomes… maybe you’ll get something really useful out of it. Otherwise, you will arguably end up with an unfinised project, and you’ll be constantly quetionning yourself if it would have been eaiser to just pay for a licence or to download an existing open-source alternative.
That said, though, it’s the method that matters (and that terrifies a software developer in me): one dev, a fleet of agents, and sufficient funding to cover those agents can produce a working clone of 30-year-old professional software in days. Even if the clone itself is still a long way from Photoshop.
PS. If you want to see a somewhat more systematic review, have a look below, I asked GPT Sol 6.1. It did not completely dismiss most of the claims, but it did provide a useful perspective.
The code is real, and rapidly building these alpha applications with Opus is plausible. The claim that someone “recreated Adobe’s software over a weekend,” understood as usable, feature-complete replacements, does not hold up.
The stories concern Brandon Thomas’s ArtCraft suite: PhotoCraft, VectorCraft, FilmCraft, LightCraft, EffectCraft, DesignCraft, and PdfCraft.
There are two important distinctions:
- Launched over a weekend ≠ developed entirely over that weekend. The earliest public commits date to September 30–October 1, ahead of the October 3–4 weekend. Private preparation is unknown.
- A large implementation ≠ a finished replacement. The developer’s own launch-period roadmaps acknowledge substantial unfinished work, despite his public statement that he “one-shotted Photoshop. The whole thing.”
I inspected public repository snapshots and counted their Rust files. I did not build and functionally test all seven applications, and I have no access to the developer’s actual API bills or agent transcripts.
1. How big is the codebase?
I counted physical lines in .rs files, including blank lines, comments, tests, and generated tables. These are not counts of independently verified, functional code.
| Application | Adobe counterpart | Launch-period Rust lines¹ | Current Rust lines² |
|---|---|---|---|
| PhotoCraft | Photoshop | 187,000 | 569,000 |
| VectorCraft | Illustrator | 141,000 | 488,000 |
| FilmCraft | Premiere | 270,000 | 401,000 |
| LightCraft | Lightroom | 91,000 | 304,000 |
| EffectCraft | After Effects | 282,000 | 382,000 |
| DesignCraft | InDesign | 83,000 | 239,000 |
| PdfCraft | Acrobat | 161,000 | 423,000 |
| Total | 1.22 million | 2.81 million |
¹ Latest available commits before October 5, 2026, UTC.
² Repository default-branch snapshots retrieved October 16.
After excluding identifiable vendor/third_party Rust files, the totals are approximately:
- Launch period: 1.14 million lines
- Current: 2.63 million lines
That exclusion is only a first pass—not a provenance or duplication audit. Tests embedded inside source files remain included, and ordinary dependencies downloaded by Cargo are not counted.
What these numbers mean
This is much more than a few screenshots or a tiny interface mock-up. There are substantial implementations of document models, rendering, editing commands, file formats, automation, and UI.
But line count cannot establish:
- correct PSD round-tripping;
- reliable video decoding and export;
- accurate color management;
- brush responsiveness;
- compatibility with complex existing projects;
- professional-quality typography;
- functional equivalence of hundreds of effects.
It also cannot tell us how much was generated from scratch, reused between sibling applications, or rewritten repeatedly.
2. What would it cost Opus 5.5 to generate that code?
Anthropic’s official pricing currently lists:
| Token category | Price per million tokens |
|---|---|
| Ordinary input | $4 |
| Output | $20 |
| Five-minute cache creation | $5 |
| One-hour cache creation | $8 |
| Cache reads | $0.20 |
These are standard API rates, not the developer’s necessarily actual spending. Fast mode doubles the base input/output rates; subscription-based usage has different economics.
First: the unrealistically cheap “type the final code once” calculation
The launch-period Rust files contain approximately 52 MB of text, including vendored code.
Using a deliberately broad assumption of 2.5–4 bytes per token, that represents roughly 13–21 million tokens. An exact count would require the model’s tokenizer.
At $20 per million output tokens:
Emitting the launch-period Rust files exactly once would cost roughly $260–$420 in output charges.
For the current non-vendored code, the comparable output-only estimate is roughly $600–$1,000.
Those are not development budgets. They omit reasoning, plans, tool calls, searches, code reads, tests, failed attempts, revisions, and integration. Reusing or copying existing code could reduce model output; repeated rewrites could increase it enormously.
More realistic development scenarios
Here are explicit illustrations for the launch-sized seven-app suite, not claims about the actual bill. “Output” includes generated code, revisions, explanations, tool-call text, and billable reasoning.
| Scenario | Ordinary input | Cache writes³ | Cache reads | Output | Approximate API cost |
|---|---|---|---|---|---|
| Efficient alpha build | 30M | 20M | 300M | 30M | $880 |
| Substantial iteration | 150M | 100M | 2,000M | 100M | $3,500 |
| Heavy rework/integration | 500M | 300M | 8,000M | 300M | $11,100 |
³ Assumes five-minute cache creation.
My planning range would be roughly $1,000–$10,000+ in API-equivalent spending for an alpha of this scale. Lower is possible with reuse and very little validation; higher is possible with extensive retries, long-context churn, or fast mode.
The key observation is that token cost does not make the story implausible. A million lines of code sounds financially enormous, but generating text is cheap relative to traditional engineering labor. Getting that text to behave correctly is the expensive part.
3. Could Opus actually do this in a weekend?
The project provides one useful throughput data point
PdfCraft’s October 3 roadmap reports:
About 72,000 lines of kept, tested Rust in roughly 65–75 agent-hours—about 1,000 lines per agent-hour.
That is the project’s own report, not an independently audited measurement. Nevertheless, it gives us something better than guessing from typing speed.
If that rate applied across the launch-period non-vendored suite:
- 1.14 million lines ÷ 1,000 lines/hour
- ≈ 1,140 aggregate agent-hours
Which produces this rough schedule:
| Concurrent agents | Ideal elapsed time |
|---|---|
| 1 | 47 days, running continuously |
| 7 | 6.8 days |
| 24 | 47 hours |
| 40 | 28 hours |
These are idealized divisions, not achievable schedule guarantees. Agents run into shared interfaces, merge conflicts, build failures, rate limits, and tasks that depend on earlier decisions.
Still, seven separate applications offer substantial parallelism. Around 24 agents means roughly three or four per application—not an absurd configuration.
A second check: output speed
Take 16 million tokens as a midpoint estimate for the retained launch code. At an assumed 50–100 output tokens/second, emitting it once takes 44–89 aggregate generation-hours.
That is only a text-production floor. Actual development also needs reasoning, revision, compilation, tests, and integration. I am not claiming that speed range is a measured Opus 5.5 benchmark.
These checks suggest:
- One agent, one weekend, the entire seven-app suite: not credible under a realistic iterative workflow.
- Many agents, several days, substantial alpha code: plausible.
- A Photoshop-like alpha alone, in a weekend: plausible with parallel agents and limited acceptance criteria.
- Seven production-quality Adobe replacements in a weekend: unsupported.
Most importantly, the coverage I found says the suite debuted over the weekend; it does not establish that all development started that weekend. Public commits show work already underway September 30.
4. What would maintenance cost?
You are right about the full suite exceeding context capacity. Opus 5.5 has a 1-million-token context window, but the current non-vendored Rust text alone is likely tens of millions of tokens.
However, maintenance does not normally require summarizing or rereading the whole repository for each change.
A competent coding-agent workflow uses:
- a small architecture and module guide;
- filename and symbol searches;
- selected function bodies and references;
- relevant tests and compiler errors;
- targeted changes and regression testing.
The important variable is how much relevant code must be understood for a particular task, not the repository’s total size.
Illustrative per-task costs
At the verified standard rates:
| Task | Ordinary input | Cache writes | Cache reads | Output | API cost |
|---|---|---|---|---|---|
| Localized bug fix | 100k | 100k | 1M | 30k | $1.70 |
| Medium feature or investigation | 500k | 500k | 5M | 200k | $9.50 |
| Difficult cross-module repair | 5M | 3M | 30M | 2M | $81 |
These are workload examples, not empirical averages. A stubborn compatibility or rendering bug could require many such investigations and cost hundreds or thousands of dollars.
For all seven applications combined, a reasonable illustrative budget is:
| Activity level | Monthly Opus API budget |
|---|---|
| Light upkeep of a reasonably stable suite | $100–$1,000 |
| Active fixes and incremental improvements | $1,000–$10,000 |
| Intensive alpha stabilization / compatibility work | $5,000–$30,000+ |
The last row better describes this project’s current challenge. Completing an alpha is development, not ordinary maintenance.
These figures exclude human engineering and QA, CI machines, test corpora, platform hardware, signing, support, and infrastructure. For professional creative software, those can dominate the token bill.
Your context-cost concern is real—but architecture matters more
Poorly structured code can force agents to read large files, chase hidden dependencies, and repeat investigations. Good module boundaries and regression tests can keep many changes cheap.
In other words:
A large, modular, well-tested repository can be cheaper to maintain than a much smaller tangled repository—even with AI.
Caching also makes repeated context cheaper, but it is not permanent repository memory: new sessions, changed prefixes, and cache expiry cause fresh charges.
5. What evidence undermines the strongest claim?
The strongest evidence comes from the project itself.
PdfCraft acknowledged only about one-third of the effort was complete
Its October 3 roadmap reported:
- 49.6% of tracked features “shipped”
- 53.3% weighted feature-count parity
- approximately 35% effort-weighted parity
It explicitly warned that feature counts overstate progress because remaining work includes hard problems such as text editing and reflow, OCR, font/rendering infrastructure, preflight, and Office export.
It estimated another 600–1,100 hours for one agent, or 2–4 months with human review, integration, and pauses.
Those forecasts may themselves be optimistic. But they clearly do not describe a completed Acrobat replacement.
VectorCraft likewise acknowledged substantial remaining work
Its launch-period roadmap reported approximately:
- 68% feature-surface coverage
- 50% parity including interaction fidelity and hardening
- 425–650 further single-agent hours to its definition of full parity
These are self-assessments, not independently validated percentages.
Reports from users are mixed—and depend on the workflow
The Hacker News discussion includes both:
- users reporting successful basic operations and rapid improvement;
- users describing broken smart objects, masks, text editing, slow brushes, and problems with existing projects.
These are anecdotal reports, not controlled benchmarks. They nevertheless support “a real, evolving alpha”, rather than “the entire Adobe suite has been replaced.”
The developer himself wrote there: “It’s not anywhere close to ready” and described the apps as “super early alpha.”
My verdict
| Claim | Assessment |
|---|---|
| There is substantial public code | Verified |
| AI could have generated much of it rapidly | Plausible; actual process not audited |
| The API cost would be prohibitively large | No—low thousands to low tens of thousands is plausible |
| All seven apps were developed entirely in one weekend | Not established; public work predates the weekend |
| They are complete Adobe replacements | Contradicted by the project’s own launch documentation |
| This demonstrates rapid alpha development | Yes |
| This demonstrates professional software can now be replaced in a weekend | No |
I would call this a real project with heavily overstated claims, not a fabricated project. The impressive achievement is generating and assembling a substantial suite of early applications quickly. The unsupported leap is treating code volume, familiar interfaces, and nominal feature coverage as equivalent to Adobe-level correctness and usability.
To verify the weekend claim conclusively, we would need agent logs, model IDs, token usage, concurrency records, starting materials, and independent acceptance tests against a pinned launch commit. Public repositories alone cannot establish those facts.