Faros

AI is making individual developers feel more productive, while making engineering organizations measurably less reliable. The Financial Times cited Faros's Acceleration Whiplash report in a piece challenging how we even measure AI's value in AI engineering. New survey research from METR found that even when carefully designed questions pushed 350 technical knowledge workers to assess value delivered rather than speed, self-reported AI gains still came in at 1.6x — a useful reality check on how inflated individual perception tends to be, even under scrutiny. But surveys have a ceiling. Faros telemetry from 22,000 developers gave the FT a data-grounded counterpoint: more code is being shipped, but incidents have tripled and review and testing cycles are getting longer at every handoff. "The code entering production systems is not meeting the bar that engineers once set for themselves." If you work in AI engineering and want to separate signal from noise on what's actually happening, this one is worth your time. https://lnkd.in/gTDh9Vf8

Microsoft Build 2026 is coming. And this year, we're bringing together the top builders. I'll be at Microsoft Build with an exciting lineup of Microsoft for Startups Pegasus portfolio companies spanning the full AI and developer stack: compute, agents, data, code modernization, reliability, robotics, security, and trust. 🥁 𝗛𝗲𝗿𝗲 𝗮𝗿𝗲 𝘁𝗵𝗲 𝗣𝗲𝗴𝗮𝘀𝘂𝘀 𝘀𝘁𝗮𝗿𝘁𝘂𝗽𝘀 𝗷𝗼𝗶𝗻𝗶𝗻𝗴 𝘂𝘀: - Anyscale: Production-scale AI workloads, powered by Ray. - Arcade.dev: The MCP runtime to secure and level up AI Agents. - CoreStory: Code intelligence for legacy modernization and governance. - Endor Labs: AI-native application security platform - Faros: Engineering intelligence for AI-native software teams. - General Robotics: Physical AI infrastructure for robotics deployment. - LanceDB: Multimodal data lakehouse for all your AI applications. - Moderne: Agent-driven code modernization at enterprise scale. - NeuBird AI: Autonomous Ops AI for engineering teams. - Replit: AI-powered app development from idea to deployment. - Tonic.ai: Privacy-safe synthetic data for software and AI teams. 𝗧𝗵𝗲 𝘁𝗵𝗲𝗺𝗲 𝗜 𝗸𝗲𝗲𝗽 𝗰𝗼𝗺𝗶𝗻𝗴 𝗯𝗮𝗰𝗸 𝘁𝗼: AI adoption is no longer just about better models. It is about the systems, tools, data, workflows, and developer experiences that make AI actually work in production. And these startups are a key part of the operating layer that enables that for enterprises. 👉 𝗜𝗳 𝘆𝗼𝘂'𝗿𝗲 𝗮𝘁𝘁𝗲𝗻𝗱𝗶𝗻𝗴 𝗕𝘂𝗶𝗹𝗱: - Come meet the startups building the next layer of AI infrastructure. More info on each of them: https://lnkd.in/eKygYWAz - Let me know if you'd like to be invited to our exclusive VIP event! 👉 𝗜𝗳 𝘆𝗼𝘂 𝗰𝗮𝗻'𝘁 𝗺𝗮𝗸𝗲 𝗶𝘁 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱: Some of the best sessions are being livestreamed, including Satya's keynote, which I'd totally recommend watching. Register (it's free): https://lnkd.in/eM4bVGQA 👋 See you in SF. #MicrosoftBuild2026 #EnterpriseAI #Startups #AITooling Microsoft Events Microsoft Developer

AI coding tools are creating a new problem most teams aren't measuring yet. 𝗔𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗶𝗼𝗻 𝗪𝗵𝗶𝗽𝗹𝗮𝘀𝗵. Developers are shipping faster. PR volume is rising. More code is entering the system. But the downstream systems were never designed for this pace. → Code review gets overloaded → QA becomes the bottleneck → Debugging takes longer → Incidents increase → Rework quietly eats the productivity gains Read more by Faros > https://fandf.co/4tPmLIE 𝗧𝗵𝗲 𝗽𝗮𝗿𝘁 𝗺𝗮𝗻𝘆 𝗰𝗼𝗺𝗽𝗮𝗻𝗶𝗲𝘀 𝗺𝗶𝘀𝘀 AI doesn't just accelerate developers. It accelerates the entire software delivery system. If your engineering system isn't ready for it, speed turns into instability. 𝗧𝗵𝗲 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻 𝗶𝘀 𝗰𝗵𝗮𝗻𝗴𝗶𝗻𝗴 The old question was: "Are our developers using AI?" The better question is: "Do we know what AI is doing to our engineering system?" Because faster code is not the same as faster delivery. 𝗪𝗵𝗮𝘁 𝘁𝗵𝗲 𝘄𝗶𝗻𝗻𝗶𝗻𝗴 𝘁𝗲𝗮𝗺𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗺𝗲𝗮𝘀𝘂𝗿𝗲 The teams that win with AI won't be the ones generating the most code. They'll be the ones that can clearly measure: → Where AI improves productivity → Where it creates risk → Where review cycles are slowing down → Where quality is degrading → Where engineering capacity is actually being spent 𝗧𝗵𝗲 𝗙𝗮𝗿𝗼𝘀 𝗿𝗲𝗽𝗼𝗿𝘁 Faros’s latest report on Acceleration Whiplash frames this as a system-level engineering challenge — not a developer productivity story. For CTOs, VPs of Engineering, DevEx, and platform leaders, it's worth a careful read. The next phase of AI engineering won't be about "more output." It will be about visibility, quality, reliability, and control. Where in your delivery system are you already seeing AI-driven speed create downstream pressure — and how are you measuring it? — Thanks to Faros for sponsoring this post.

AI engineering in 2026 demands more than better tools. At enterprise scale, it necessitates a connected system spanning strategy, tooling, cost management, adoption, workforce evolution, measurement, governance, and the context layer that makes AI output production-ready. Read more at: https://lnkd.in/gYgtKMHg

Embroker VP of Engineering Ralf Dagher's two-part post on their AI journey is one of the most detailed, clear-eyed accounts we've seen — covering what didn't work (Spec-Driven Development across brownfield repos), what did (background agents triggered from Jira), and how they're using Faros to measure whether instruction files are actually improving agent effectiveness or just generating noise. The part that stands out: their adoption model. Trust earned through exposure, not mandates. Skeptical engineers reviewing agent PRs regularly, building confidence gradually. Read both parts. Worth your time. Part 1: https://lnkd.in/ghXVdzgD Part 2: https://lnkd.in/gva2wQ9D

Why are developers deleting more code than ever before? Under high AI adoption, the relationship between how much code teams add and how much they remove has shifted dramatically. The ratio of deletions to additions is nearly 10 times what it was when the same organizations were at low AI adoption. An 861% increase. That number needs context before it means anything. There are three plausible explanations. 1. The pessimistic one: developers are accepting AI-generated code quickly and returning to replace it when it proves insufficient, rework that represents real waste. 2. The optimistic one: AI is finally giving teams the capacity to tackle large-scale refactoring that was previously too slow or costly to staff — years of legacy code being productively cleared out. 3. The mixed one: engineers are simply moving faster to improve code they were never fully satisfied with at the time of shipping. All three are consistent with the findings of our cross-company observational research. The exact explanation almost certainly varies by organization and repo. The way to find out which one applies to yours: look at when the deleted lines were written. Git-level provenance data can tell you whether they were recent (suggesting rework of AI-generated code) or older (suggesting productive refactoring). Analyzing deletion-to-addition ratios per repo at monthly rather than quarterly intervals sharpens the signal further. Throughput measures what was shipped. Not what survived. Code churn is the asterisk on every output number your organization is tracking right now. #AIEngineering #EngineeringMetrics #EngineeringLeadership

Daily PR contexts per developer are up 67% under high AI adoption. Work restarts, referring to tasks that return to in-progress after moving to another stage, are up nearly 14%. More than a quarter of in-progress tasks show no activity for 7+ days. AI tools excel at acceleration. The workflow data underneath the individual productivity story shows more threads opened, more work stalling mid-flight, and a development environment where starting has become the easy part. For DevEx and platform engineering teams, this is the signal worth watching: not just how fast developers move, but how often they complete what they start. >> Explore more findings of the two-year longitudinal study https://lnkd.in/gSW7jbJD #DeveloperExperience #ContextSwitching #AIEngineering

Tokenmaxxing is the lines-of-code mistake with a new coat of paint. Tokens are an input, not an outcome; so the increased productivity story is really just a volume story with a higher bill attached to it. Full take: https://lnkd.in/gqTZhFE2

31% more pull requests are being merged with no review at all under high AI adoption. The data doesn't suggest teams are making a deliberate choice to skip oversight. The more likely explanation is simpler: reviewers cannot keep pace with the volume arriving in their queues. When you combine that with a tripling of incidents per PR, the shape of the risk becomes clear. Code is reaching production systems with no oversight at a meaningfully higher rate than before high AI adoption, not because the review process was abandoned, but because it was overwhelmed. That's a different problem, and it requires a different response. This is one finding from the AI Engineering Report 2026 - The Acceleration Whiplash, covering telemetry data from 22,000 developers over two years as they transition from low to high AI adoption. Link to main findings in the comments.

A companion piece to DORA's ROI of AI work, with the inputs our telemetry suggests engineering leaders should pressure-test before any CFO conversation. Worth a read.