GitHub's 2024 internal research on Copilot Chat found developers accept LLM-generated fixes in roughly 31% of debugging sessions — but only 11% of those fixes actually closed the underlying bug. The other 20% patched a symptom, introduced a regression, or confidently pointed at the wrong subsystem. An ACM 2024 study from Shi et al. on LLM-assisted debugging across 2,500 sessions reported a similar pattern: speed-up happens on shallow bugs; deep bugs often get worse when the developer outsources hypothesis generation.

The takeaway is not "don't use LLMs to debug." It's: use them where they're measurably better, skip them where they systematically lie, and build a workflow around the difference. This post walks five workflows that actually save time, drawn from instrumenting our own team and five PanDev Metrics customer teams.

A distributed team with 5 hours of timezone spread has a median lead time of 6.8 days per change. A colocated team in the same codebase — same language, same size, same PR size — has a median lead time of 3.2 days. That's not a rounding error. That's the timezone tax, and it roughly doubles at every additional 3-4 hours of spread. GitLab's 2023 remote-work report estimated "3-5 hours of overlap" as the sweet spot for async-friendly teams, and our IDE-heartbeat data across 100+ B2B companies says the same — but with the extra detail of where exactly the time goes.

This isn't an article about whether remote work is good (it is, for many teams). It's about the specific ways that timezone spread slows delivery, and what measurements tell you whether your distributed team is paying a 2× lead-time penalty or learning to live with it.

A fintech product team we work with shipped a single 400-line feature four times. The Figma file updated Tuesday. Dev started Wednesday. Design reopened the file Thursday morning to "refine spacing" and again Friday afternoon for "one more micro-interaction." The feature shipped on Monday. The engineer then spent two days fixing visual regressions caught by the PM post-ship. Total time: 7 engineering days. Total net-new code: 400 lines. The handoff killed more than the work.

The "Figma-to-code" conversation is usually about tools — Zeplin, Figma Dev Mode, Locofy, Visual Copilot. None of those fix the actual problem, which is that the design-to-code handoff is a measurement gap hiding in a process gap. We'll define the metrics that actually predict a good handoff, how to measure them without adding overhead, and where the tool choice matters (sometimes) vs doesn't (usually).

A platform team at a 600-engineer company spent $340,000 over 9 months fine-tuning a 13B-parameter model on their internal documentation. Launch day: the model answered roughly 72% of common questions correctly but was already 3 weeks stale on the day they shipped. They then built a RAG pipeline over the same corpus in 2.5 weeks for $18,000. It answered 88% of common questions correctly and was always current. The fine-tuned model got quietly retired after six months of parallel running.

This is the dominant pattern in 2025-2026: for internal developer documentation, RAG has won on economics and freshness. Fine-tuning still wins for specific cases — domain vocabulary, style alignment, tight latency budgets. But "fine-tune an LLM on our wiki" is now the wrong default. OpenAI's DevDay 2024 benchmarks showed RAG outperforming fine-tuning in 14 of 16 documentation-QA scenarios when measured by answer accuracy and recency, with costs 8-40× lower. Let's look at when each actually makes sense.

Notion passes a hidden failure threshold around 300 pages per engineering workspace. Up to that point, the tool is loved. Past it, search breaks down, duplicate pages accumulate, and the team splits into two camps: one that keeps writing, one that stops reading. Stack Overflow's 2024 Developer Survey put Notion in the top 3 non-IDE tools engineers use daily — but also flagged it as the #1 tool engineers abandoned within 18 months, mostly from exactly this collapse.

The collapse isn't Notion's fault. It's a structure problem. This is a playbook for a 7-database engineering workspace that stays navigable from 5 to 50 engineers, and the specific rules that prevent the 300-page collapse.

A payments engineering director told me the sentence that captures the whole vertical: "We have two stopwatches running. One measures how fast we ship. The other measures how many years we'll be paying for the mistake we ship fast." Everything else in payments engineering is a tradeoff on that pair.

The Bank for International Settlements' 2024 Annual Economic Report documents that global cross-border payments cleared $190 trillion in 2023, with payment technology handling roughly 1.4 billion daily transactions. Nilson Report, the card-industry reference, tracks industry fraud losses at around $33 billion globally per year — that's roughly 6 basis points on card volume, paid for by the engineering quality of the platforms in the middle. An engineering team shipping a regression into the authorization path doesn't get fired for shipping slowly; they get fired for the 40-basis-point spike on the next week's reconciliation report.

A 45-engineer platform team I worked with in Q4 2025 had 214 Slack channels, 82 of them active in the last 7 days. The average engineer belonged to 31 channels, got mentioned in 14 per week, and — based on our IDE heartbeat data — lost 5 hours 42 minutes of coding time per week to Slack-triggered context switches. That's over 10% of the working week vaporized before anyone gets to meeting calendars or code reviews.

Slack isn't the villain; channel sprawl plus broken norms is. UC Irvine's Gloria Mark's multi-decade research puts the recovery cost of a single interruption at 23 minutes to return to full focus. Stack for 14 Slack mentions a week and the math is unforgiving. The good news: the fix doesn't require switching tools or adopting Zen-mode software. It's a set of explicit norms any 10-500-engineer org can apply in a quarter.

Linear ships a new feature almost every week and has become the default "we're a modern startup" issue tracker. Jira has 20 years of institutional muscle memory, 3,000+ Marketplace apps, and a reputation for being slow and configurable in equal measure. Between them sit 200,000+ engineering teams making the wrong choice for six-figure sums per year.

This comparison goes past the feature-matrix surface. It looks at what breaks when a team switches, what the real cost of migration is, and where each tool's design choices quietly exclude it from certain team shapes.

The team adopted Terraform 18 months ago. Deploys are slower than the old click-ops setup, reviews take longer, and three of your best engineers now spend a full day per week on Terraform plan output. Senior leadership asks whether the migration was worth it, and nobody has a clean answer. The honest one is: you never defined what "worth it" looks like in metrics. HashiCorp's 2024 State of Cloud Strategy reported that 76% of enterprises adopted IaC, but only 31% measured its outcomes against pre-adoption baselines. The CNCF's 2023 Annual Survey found a similar gap for infrastructure-as-code tooling generally.

This article is a measurement framework for infrastructure teams already using Terraform, OpenTofu, or Pulumi. It doesn't debate whether IaC is worthwhile — that ship sailed. It defines six metrics that show whether your adoption is healthy or decaying, plus the benchmark ranges from 37 companies in our dataset that run Terraform in production.

A Series-B board presentation went sideways in 2023 when a director — former GitHub VPE — asked the CTO three questions in a row she hadn't prepared for. She knew deployment frequency and team size. She didn't know median lead time, hiring velocity against plan, or the engineering payroll as a share of operating burn. The board didn't defund engineering, but they added a quarterly engineering review with a different CTO on the call. The meeting became a test the team passed but the CTO didn't.

Boards are harder to prepare for than investors because they have more context and less patience. This is a question list — what a working board actually asks, what the CTO should bring without being asked, and the red flags an experienced director spots in 15 minutes. We collected it from conversations with CTOs who have presented successfully, CTOs who haven't, and two board directors who sit on engineering-heavy portfolios.