21 posts tagged with "research"

The AI coding tool market fragmented into four serious contenders by early 2026: GitHub Copilot, Cursor, Claude Code (Anthropic CLI), and ChatGPT with Code Interpreter. Marketing decks from all four claim "40% productivity boost" — the number is identical, and it's meaningless without measurement. We pulled IDE heartbeat and session data from 112 engineers across 14 B2B teams in Q1 2026 to see what actually saves time.

The punchline: Claude Code users ship 54 minutes of saved time per day; Copilot users ship 28. But the distribution is not what marketing implies — the best tool depends on the kind of work, not the team's "AI maturity".

AI code review sits at the crest of the hype cycle. GitHub Copilot, CodeRabbit, Qodo, Graphite, and half a dozen startups are pitching a future where LLMs catch bugs faster than humans. Microsoft Research and Bacchelli's seminal 2013 study on code review established the baseline we've been measuring against for a decade: human review catches ~14% of functional defects but 68% of maintainability issues. The question now is: does layering an LLM on top actually move either number?

We pulled review data from 100 B2B teams between Q1 2025 and Q1 2026: a mix of teams using AI review, teams not, and teams running hybrid. The pattern isn't what the vendors claim.

Two developers on one task. Double the labor cost, half the bugs, and nobody agrees on whether it pays back. The most-cited study on this question — Cockburn & Williams, The Costs and Benefits of Pair Programming (2000) — reported a 15% time overhead for paired work and a 15% drop in defects. That looks neutral on paper. It isn't. The math of defects-caught-early flips the ROI by roughly 2× once you include rework avoided and shipped-bug incidents prevented.

This article crosses Cockburn and Williams' academic data with our own IDE heartbeat dataset across 100+ B2B companies — including teams that pair daily and teams that never do — to answer the question practically. Not "is pair programming good?" but "when does it pay back and when is it theatre?".

Every engineering leader asks the same question: how much time do developers actually spend writing code?

Microsoft Research found that developers spend only 30-40% of their time writing code. A 2019 study by Haystack Analytics suggested closer to 2 hours. Our own IDE heartbeat data across B2B engineering teams confirms a median of 78 minutes per day.

Here's what the data actually shows and why it matters.

AI/ML teams are unlike any other engineering organization. Half the team is exploring novel approaches where most experiments fail — and that's expected. The other half is building production systems where reliability and speed matter. Many team members do both, switching between Jupyter notebooks and production codebases within the same day. The MLOps maturity model defines this spectrum — from ad hoc experimentation (Level 0) to fully automated ML pipelines (Level 2) — and most organizations sit somewhere in the middle.

Traditional engineering metrics don't capture this duality. Measuring an ML researcher by deployment frequency is like measuring a chef by how fast they wash dishes. But having no metrics at all means you can't tell whether your research investment is producing results or if your production systems are reliable. Papers with Code trend data shows that the gap between state-of-the-art research and production-ready ML is widening — making the research-to-production bridge more critical than ever.

Here's how to build a metrics framework that respects the difference between research and engineering while giving leadership the visibility they need.

Every "top programming languages" list you've seen is based on GitHub stars, Stack Overflow surveys, or job postings. None of them measure what developers actually spend their time writing.

We do. Here's the ranking based on thousands of hours of real IDE coding time across 200+ programming languages, tracked from active B2B developers at 100+ B2B companies.

Some developers swear by 6 AM starts with coffee and silence. Others don't open their IDE until 10 PM. Managers debate whether to enforce "core hours" or let people work whenever they want.

We looked at extensive activity data from developers across 100+ B2B companies to find out when developers actually code — and whether timing matters.

Every engineering manager has a gut feeling about their team's weekly rhythm. Monday feels slow. Friday feels like a wind-down. But what does the data actually show?

We analyzed thousands of coding hours from developers across 100+ B2B companies to map developer productivity across the work week — and the results challenge some common assumptions.

The IDE debate is eternal. VS Code fans say it's fast and extensible. JetBrains loyalists swear by deep language support. And now Cursor is the new challenger, riding the AI wave. The Stack Overflow Developer Survey consistently ranks VS Code as the most popular editor, while the JetBrains Developer Ecosystem Survey shows strong loyalty among its users. But surveys measure sentiment, not reality.

What do developers actually use when they sit down to work? Not what they tweet about. Not what they starred on GitHub. What they code in, hour after hour, day after day.

We have the data. thousands of hours of tracked coding time across 100+ B2B companies, broken down by IDE.

"Adding manpower to a late software project makes it later." Fred Brooks wrote that in 1975. Fifty years later, engineering leaders still debate whether it's true.

We looked at real coding data from 100+ B2B companies on PanDev Metrics to understand how team size relates to individual developer productivity. The answer is more nuanced than Brooks suggested — but his core insight still holds.