Releasing features 400x faster than 10 years ago

In 2016, a feature request could take multiple teams about ten weeks to ship. In 2026, with an LLM triage step and a Claude Code loop, it ships in one afternoon.

A user asks for a new feature. What happens next says more about how a company builds software than any architecture diagram.

Below are the two pipelines I have worked in: the 2016 version, with a support team, a product manager, a backlog, two developers and QA; and the 2026 version, which is just me, an LLM triage step and a Claude Code loop.

Releasing features 400x faster than 10 years ago

2016 vs 2026

Person required

2016 multiple teams
1 User sends a message
1–2 days
2 Support classifies, adds to Jira
1+ week
3 Manager approves, moves to backlog
2+ weeks
4 Team estimates and prioritizes
6+ weeks
5 Sprint starts
Frontend team
Backend team
3+ days
6 QA evaluates it
2+ days
7 Final reviews Fails → back to development
1+ day
8 Staging QA Fails → back to the sprint
1+ day
9 Released

≈10 weeks + 2 days

Assuming the feature doesn't become an epic!

2026 One person
1 User sends a message
~1 min
2 An LLM classifies it, opens a GitHub issue
~5 min
3 Claude Code loop drafts a plan
~20 min
4 Solo founder reviews and refines the plan
~30 min
5 + Claude Code implements Copilot reviews
~3 h
6 Solo founder validates
~20 min
7 Released

~4 h 16 min

Same request, same day.

Request to release 72 days → 4 h 16 min marcgarciamartinez.com

2016: ten weeks, multiple teams

The message lands in a shared inbox and waits a day or two. Customer support reads it, decides it is a feature request and files it in Jira, which takes a week. A product manager moves it into the backlog, where it sits for two weeks or more. The team estimates the ticket and prioritizes it, six more weeks.

Then the work finally starts: a frontend developer and a backend developer build it in parallel over three days, QA evaluates it for two days, and it goes to review. A failed review sends the ticket back to development, and the loop repeats. Once it passes, the feature goes to staging for a day, where a problem sends it back into the sprint, and is released the day after.

Only three of those seventy-two days were spent building the feature. 95% of the time was spent waiting, because the next three sprints were already planned.

2026: four hours, one person

The message arrives and is read in about a minute. An LLM classifies it as a reasonable feature request and opens a GitHub issue automatically. A Claude Code loop picks up the issue and drafts a plan, and twenty minutes later I get a notification on my phone. I read the proposal, refine it, and instruct Claude to implement it against a goal.

Claude Code writes the frontend, the backend and the tests in the background, pushes to GitHub and asks Copilot for code review, iterating until everything is green. That is the long part of the day, roughly three hours, and I am not in it. I do the final check, try the feature myself in staging, merge, and CI/CD deploys to production. The customer hears back the same afternoon.

What actually changed

None of the steps disappeared. Classification, planning, implementation, review, testing and deployment all still happen. What disappeared is the waiting between them: five calendars, four queues and a backlog. Two of the seven steps still need me, and my time goes to two decisions: whether this is worth building and whether what came back is correct.

← Back to Home