← All topics

ai productivity

2 captures, most recent first.

Tim Duffy @timfduffy

reposted by Sichu Lu; quoting @EpochAIResearch (Epoch AI)

[repost icon] Sichu Lu reposted @timfduffy (Tim Duffy) — 50m If you use the middle of each provided range as the mean for that bucket, total contributed hours are ~1.5x as high as they were a year ago. As the thread notes this method is imperfect and my estimate adds more uncertainty, so take this with a grain of salt. This is more likely to be an overestimate than an underestimate in my view, since with LLMs it's worthwhile to add things that wouldn't be worth adding without assistance. So the time to create estimates probably rise more than value created. [Table] effort_level | estimated_hours | q2_2025_share | q2_2026_share | estimated_hours_middle[column label truncated at right edge] Low | <6 | 66.3 | 50.9 | 3[possibly truncated] Medium | 6-12 | 18.8 | 24 | 9[possibly truncated] High | 12-24 | 12.9 | 16.9 | 18[possibly truncated] Very high | 24-48 | 2 | 7.2 | 36[possibly truncated] Extremely high | >=48 | 0 | 1 | 72[possibly truncated] | | Total Hours | | | | | 672.3 | 1004.1 | | | | Speedup Factor | | | | | 1.49 | | | > QUOTED: @EpochAIResearch (Epoch AI) — 1h > How much does AI speed up the engineers building it? We analyzed contributions to OpenAI's public Codex repository to gather evidence. ... [truncated by platform] > [Image: bar chart thumbnail, not legible at this resolution]
Note from Claude Sonnet 5

A tweet analyzing Epoch AI's research on AI-driven engineer productivity using OpenAI's public Codex repository; Tim Duffy recomputes a "speedup factor" of ~1.49x from Epoch's effort-level bucket data comparing Q2 2025 to Q2 2026 contribution shares, with a caveat that this likely overestimates real productivity gains due to LLM-enabled scope creep.

ai productivitytwitterepoch aiai forecastingsoftware engineeringdata analysis

Thariq @trq212

Thariq @trq212 · Jan 21 This was a legacy migration, we had to port our entire rendering engine while making sure nothing user-facing broke. Doing this without Claude Code could have taken on the order of 1-2 years for a single engineer, something we would have never been able to prioritize. [17 replies, 13 reposts, 212 likes, 160K views] Thariq @trq212 · Jan 21 Wanted to clarify this 1-2 years thing. Of course this was just a back of the envelope estimate, it's entirely possible it's wrong. And Claude Code itself is like a year old, so how could this take longer? As a team and company grows, your codebase moves under you more often, coordination cost is higher and you have more users in more diverse scenarios so it is easier to break things. By default large tech companies ship things slowly as a result, especially legacy migrations. Claude Code is the first time I've seen a team within a large company ship this fast. This is what I'm comparing the baseline to- a single engineer at a large tech company working on a product with many users in many different places. If you are a solo developer or startup, you have much less coordination cost to deal with and certainly the technical work alone would not take this long. For a long time it has been impossible for large teams to ship fast, we believe this is changing. That's the point I wanted to make, apologies if it was garbled.
Note from Claude Sonnet 5

A software engineer's Twitter thread claiming Claude Code enabled a legacy rendering-engine migration that would otherwise have taken 1-2 years, with a follow-up clarifying the estimate and discussing organizational coordination costs at large companies. Relevant to Nathan's tracking of empirical AI-uplift/productivity claims (parallels the METR/Anthropic productivity data already in his notes).

claude codeai productivitysoftware engineeringai uplifttwitter