# 8th Light Insights Posts on software craftsmanship and consulting from 8th Light's designers and crafters. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From AI Code to Trusted Software: Harness Engineering in Practice DevFeed: [From AI Code to Trusted Software: Harness Engineering in Practice]() Original publisher: [Read original article]() Author: Travis Frisinger Published: 2026-09-04T21:55:00Z Content type: opinion Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [AI-assisted coding](), [Software](), [trust](), [observability](), [Authorization]() Tags: [agent](), [ai](), [ai-and-emerging-tech](), [code](), [engineering](), [engineering-and-devops](), [observability](), [permissions](), [trust](), [verification]() ### AI overview The article presents harness engineering as a repository-centered discipline for making AI-generated software more trustworthy. It argues that prompts and written standards are insufficient, and that permissions, quality gates, evidence, and observability should enforce organizational standards and support verification. ### Source excerpt If the same reasoning path writes the system change and defines the proof of success, you may be setting yourself up for an avoidable failure in the future. Harness engineering is meant to act as an extension of your own organizational guardrails, which were always meant to reduce risk and improve quality. Travis Frisinger, Head of Agentic AI Your team is shipping more AI-written code every quarter. How do you know it is any good? Good means it meets your standards, and you have probably already tried handing your agents the standards: a context file, a style guide, the wiki pasted into the prompt. The agent reads them, agrees, and still breaks them, because instructions to a model are suggestions. What the repository permits is what actually happens. Your people absorb standards through review comments and hallway corrections, and the lessons stick. An agent apologizes and forgets by the next session. The only place its lessons can accumulate is the repository itself. That gap used to be an annoyance. With AI doing real engineering work, the quality gap is the whole game. Harness engineering is the discipline that closes it. It is the process of imbuing a repository with your standards so that the repository itself enforces them: permissions and boundaries that say what any actor may touch, quality gates that fail closed, evidence attached to every change, and observability that spans runs rather than moments. Models supply software delivery capacity. The harness supplies observable accountability: every change carries what was done, which rule allowed it, and what happened as a result, no matter which model, agent, or person did the work. Why now The industry started using the term harness engineering back in February, 2026. Since then, Thoughtworks, LangChain, and others have built serious thought leadership around the same shape. When several firms independently converge on the same word, it usually means they are trying to name the same problem. The real proble ## Waggy, Claude, and Code: Celebrating Drake Fish, Our Newest Beacon DevFeed: [Waggy, Claude, and Code: Celebrating Drake Fish, Our Newest Beacon]() Original publisher: [Read original article]() Author: Juan Santana Published: 2026-08-10T05:00:00Z Content type: opinion Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Artificial Intelligence](), [Claude](), [anthropic](), [Robotics](), [Code](), [Slack]() Tags: [ai](), [anthropic](), [claude](), [culture-and-news](), [robotics](), [slack](), [work]() ### AI overview An 8th Light profile celebrates Drake Fish as a Beacon Award recipient, highlighting his open sharing of the Waggy autonomous robot project, experimentation with Claude and real-world hardware, and work helping colleagues and clients adopt AI systems. ### Source excerpt Working at 8th Light, we have the daily privilege of collaborating with truly brilliant minds--people who bridge the gap between deep engineering and meaningful human connection. We are also incredibly fortunate to work alongside folks who, no matter how tough the problem or early the hour, are overflowing with honesty, curiosity, and of course, the jokes. That's why it brings us immense joy to announce our latest Beacon Award recipient at 8th Light, Drake Fish! The Beacon Award is a peer-nominated honor celebrating the individuals who bring 8th Light's values to life and elevate everyone around them. Drake was nominated by multiple colleagues last quarter, which tells you everything you need to know about his impact. As a Lead Engineer, Drake has built a reputation at 8th Light that reaches far beyond client teams. The secret sauce? He learns in the open, bringing everyone along for the ride. Waggy is an autonomous robot pooper scooper that Drake started building in his spare time. He stepped into the project without much background in electronics or robotics. Instead of tinkering quietly in private until everything worked, Drake shared the entire journey in Slack (mistakes, wiring mishaps, and all) so the rest of the company could learn, and giggle, alongside him. Along the way, Drake used Waggy to give us a front-row seat to what agentic tools like Claude can actually accomplish when paired with real-world hardware and a little bit of experimentation. As if building an autonomous pooper scooper wasn't enough, Drake took his AI experimentation even further. He became the first of many 8th Light team members to earn the Claude Certified Architect credential, one of Anthropic's benchmarks for engineers building production-grade AI systems. Right after passing the exam, he presented to the company to share tips, break down the material, and demystify the process. If you drop into our internal AI Slack channels or our "AI in the Open" sessions, odds are high you will f ## Teaching the Agent Our Craft: Structured Agentic Development on a Real Codebase DevFeed: [Teaching the Agent Our Craft: Structured Agentic Development on a Real Codebase]() Original publisher: [Read original article]() Author: Alex Haldeman Published: 2026-07-06T16:00:00Z Content type: article Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Agentic development](), [Claude Code](), [Development](), [AI-assisted coding](), [Test-driven development]() Tags: [agentic](), [agentic-development](), [ai-and-emerging-tech](), [claude-code](), [clean-architecture](), [structured](), [test]() ### AI overview 8th Light describes a structured agentic development workflow built around Claude Code. The approach adapts Research-Plan-Implement by separating research, planning, and implementation, adding review cycles and involving product managers and designers at each transition. It also applies test-driven development, clean architecture, and explicit project conventions to address common agent failure modes. ### Source excerpt The Mission We recently partnered with a startup that had developed a clinically proven approach to alleviating neuroplastic chronic pain. Their program worked: a coach-led model that helped patients ease chronic pain at a lower cost than conventional treatment. The problem was reach. The in-person model could not scale to the demand they were seeing, and there were not enough coaches to close the gap. We were brought in to build a digital platform that could deliver the program to every patient who needed it. Our Development Philosophy and Inspiration At 8th Light, we approach agentic development the same way we approach any software engagement: with discipline around test-driven development, clean architecture, and code that is built to embrace change. But agentic development comes with its own failure modes. An agent produces code that covers the happy path and misses critical behaviors. A context window fills with stale reasoning from earlier attempts, and the agent starts working against itself. Without explicit conventions, the output works but looks like nobody on the team wrote it. Tyler Burleigh's Research-Plan-Implement gave us a useful frame for thinking about this. His core observation: the bottleneck is not code generation, it is ensuring the model understands what to build before it starts building. RPI addresses that by separating research, planning, and implementation into distinct phases, each with a review cycle before the next begins. We adapted that structure into our Claude Code workflow, with the additional goal of keeping product managers and designers genuinely in the loop at each transition, not just developers. What follows is a description of the harness we built from a Claude Code-specific perspective. The HarnessStructure Before walking through the pieces, it helps to see how they fit together. Everything that teaches the agent our craft lives in a handful of files at the project root and inside a single .claude/ directory. None of it is ## Celebrating our Beacon: Kevin Buchanan DevFeed: [Celebrating our Beacon: Kevin Buchanan]() Original publisher: [Read original article]() Author: Juan Santana Published: 2026-06-23T05:00:00Z Content type: article Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Artificial Intelligence](), [Claude]() Tags: [ai](), [claude](), [culture-and-news](), [productivity](), [work]() ### AI overview 8th Light recognizes Principal Engineer Kevin Buchanan with its Beacon Award. The article highlights his role in helping a client adopt Claude and develop an AI-supported Research-Plan-Implement workflow that improved productivity while reducing costs and time. ### Source excerpt Congratulations to Kevin Buchanan, our latest Beacon Award recipient, a peer-nominated honor that celebrates the people who bring our values to life and light the way for others to follow. Kevin, Principal Engineer, has been an 8th Light for over 12 years. A long-time favorite of our clients and his peers, he has a reputation for raising the bar on whatever he touches, and those who work alongside him come away sharper and stronger for the experience. Kevin's nomination came out of a year-long re-platforming effort for a long-time client. As AI reshaped what software teams could do, the client was questioning what was truly possible given their limited resources. Collaborating with past Beacon honorees Kelsey Roy and Eric Olson, Kevin introduced AI-forward solutions in a practical, grounded way. He helped the client adopt Claude, build patterns for using it well, and shape a Research-Plan-Implement (RPI) workflow they've kept refining. The result was real productivity for the team, but more importantly, cost and time savings for our client. Kevin showed what it looks like to stand on years of craft and still adapt quickly, bringing others along as he goes. Our CEO, Jenny Farver, put it well: "I'm really excited to see somebody like Kevin, who can stand on all that experience he's been building for years at 8th Light, and also rapidly change, adapt, grow, and bring along others with him." Join us in congratulating Kevin Buchanan, our newest Beacon! ## Production is the New Prototype: Notes from LangChain Interrupt 2026 DevFeed: [Production is the New Prototype: Notes from LangChain Interrupt 2026]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-05-17T14:45:00Z Content type: opinion Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Artificial Intelligence](), [observability](), [Tooling](), [Demo]() Tags: [2026](), [agentic](), [ai](), [ai-and-emerging-tech](), [conference](), [enterprise](), [observability](), [production](), [technical]() ### AI overview An opinion article from 8th Light about discussions at LangChain Interrupt 2026, arguing that agent systems are moving from demonstrations toward production operations. It emphasizes reliability, governance, enterprise constraints, and observability as essential to operating these systems. ### Source excerpt 8th Light's Head of Agentic AI, Travis Frisinger, and I spent two days in San Francisco at LangChain Interrupt 2026 watching what happens when agent demos meet production traffic. The room was full of companies that have crossed that line, and a few that wish they hadn't tried. The conversation a year ago was "can agents work?" The conversation in May was "how do we operate reliable, observable, governable agent systems at scale?" In the discussions we had at the conference, we validated that the shift was real and not just product marketing. What follows is what stood out across the two days, with Travis's read on the technical patterns and what I'm hearing from clients who are trying to ship. Demos are Easy. Operating is the Job. Travis's summary of the two days: agents are moving from demos to real operational systems, with companies like Lyft, Cisco, Toyota, and LATAM already running large-scale production deployments. The keynote framed agents as different from traditional software because of an infinite input space and non-deterministic models. The successful teams ship early and iterate. The unsuccessful ones, according to MongoDB's CJ Desai in conversation with Harrison Chase, built proof-of-concepts for two years and called it strategy. He called it agent washing. 2025 was supposed to be the year of agents at scale. It didn't materialize. He thinks 2026 will, but only for teams who treat the operational work as the actual work. That matches what I hear in client conversations. The question is rarely "can we build an agent?" It is "how do we run one inside an enterprise that has compliance, vendor reviews, change management, and a board that wants to see ROI?" Observability is Not Optional. It's the Foundation. Nearly every speaker named LangSmith or an equivalent as mandatory infrastructure rather than nice-to-have tooling. LATAM Airlines made the point with the most authority. Nico Venegas and Claudio Urbina described a concierge agent on their B2C site se ## Accelerating Delivery: How AI Agents Can Own the Initial Code Draft DevFeed: [Accelerating Delivery: How AI Agents Can Own the Initial Code Draft]() Original publisher: [Read original article]() Author: Stephen Walker Published: 2026-05-05T21:58:00Z Content type: article Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Artificial Intelligence](), [Loop Engineering](), [Pull Request](), [human review](), [jira](), [coding](), [hooks](), [Script]() Tags: [agents](), [ai](), [ai-agents](), [ai-and-emerging-tech](), [code](), [hooks](), [human-review](), [jira](), [pull-request](), [review](), [sandbox]() ### AI overview The article describes a pragmatic workflow in which coordinated AI agents turn a Jira ticket into a code draft and pull request for human review. It emphasizes safety through branch permissions, scoped access, scripts and hooks, plus deterministic structures around probabilistic language models. The supplied text is truncated before the full reliability hierarchy and later conclusions. ### Source excerpt Why This Matters in the Era of Agentic Everything The gap between a Jira ticket and the first pull request (PR) is often a graveyard of productivity. Context switching, boilerplate setup, and requirement analysis can eat up hours of a senior engineer's day before they write a single line of business logic. Recently, industry leaders have showcased "Harness Engineering" [1][2] -- the practice of building autonomous agent workflows that handle end-to-end coding tasks. While their results are inspiring, the barrier to entry can feel insurmountable. The challenge for most teams is finding a starting point that balances long-term vision with immediate ROI. We recently helped a large-scale, high-traffic consumer services platform bridge this gap. Instead of an all-or-nothing architectural overhaul, we took a pragmatic first step: automating the journey from Jira ticket to PR. The Vision: "Let's work on FEAT-123" Our goal was simple. We wanted to enable a developer to provide a single prompt -- "Let's work on FEAT-123" -- and have a coordinated team of AI agents handle the planning, coding, and verification. This culminates in a PR ready for human review. To make this a reality, we focused on three strategic pillars: safety, determinism, and quality. Safety Through Pragmatic Guardrails One of the primary concerns for any engineering leader is "agent drift" -- an AI making unauthorized or hallucinated changes. While an isolated digital sandbox is an ideal long-term goal, we proved that teams can achieve significant safety and progress using existing infrastructure: Branch Permissions: Restrict agent access to specific feature branches. Scoped Access: Use scripts and hooks to define exactly what an agent can and cannot touch. Human-in-the-Loop: Ensure that while the agent proposes the change, a human must always review, approve, and merge the code. By defining the agent's scope as a specialized contributor rather than a system administrator, we mitigated risk while maximizing ou ## Automated Accessibility Tools Support Audits but Cannot Replace Human Evaluation DevFeed: [Automated Accessibility Tools Support Audits but Cannot Replace Human Evaluation]() Original publisher: [Read original article]() Author: Celeste Aronow Published: 2026-04-15T13:44:00Z Content type: opinion Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Accessibility](), [Tooling](), [Large Language Model](), [axe-core]() Tags: [accessibility](), [ai-and-emerging-tech](), [axe-core](), [llms](), [tooling]() ### AI overview The article argues that automated accessibility scanners and LLM-assisted auditing can identify many concrete issues and expand teams' coverage, but they cannot fully assess what people with disabilities experience when using a screen reader. It also warns that scan output can include false violations and requires human judgment and accessibility expertise. ### Source excerpt The Gap is Real If your accessibility process ends with a passing scan, your users with disabilities are likely encountering barriers you do not know about. Automated tools are useful. LLM-assisted auditing has raised the ceiling. Neither closes the gap between what a tool can verify and what a person actually experiences when navigating with a screen reader. The gap is real, it is measurable, and it has organizational consequences. I have spent years running every category of automated accessibility tool the industry has produced: rule-based scanners like axe-core and WAVE, visual analyzers like Lighthouse, browser extensions with built-in screen reader simulations. When LLMs entered the picture, the promise was compelling. Tools that could finally understand context, interpret user flows, and reason about accessibility the way a human specialist does. I wanted that to be true. It isn't. What Automation Does Well Let me be fair to the tools. Automated accessibility scanners like axe-core, Lighthouse, and WAVE are genuinely good at what they do. They catch heading hierarchy violations quickly and reliably. They flag color contrast failures with precision. They identify missing alt attributes on images in many cases. These are real wins. If you have run these tools on your product, you have addressed real issues, and the engineers who did that work should feel good about it. Automated tooling is a force multiplier. It speeds up the work and amplifies how much ground a team can cover. The problem is not what these tools do. It is what they cannot do, and what organizations assume they have done. What Automation Invents The same tools I praised above (SilkTide, axe-core, Lighthouse, and WAVE) are genuinely valuable parts of a real accessibility workflow. They speed up discovery, give teams a shared vocabulary, and help non-specialists see problems that would otherwise be invisible. They also generate a lot of output. A single scan on a moderately complex page can retur ## Reframing Healthcare Technology in the AI Era DevFeed: [Reframing Healthcare Technology in the AI Era]() Original publisher: [Read original article]() Author: Jon Wettersten Published: 2026-03-06T22:14:00Z Content type: opinion Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Artificial Intelligence](), [Generative AI](), [Automation](), [decision-making](), [trust](), [digital]() Tags: [ai](), [automation](), [decision-making](), [generative-ai](), [governance](), [healthcare](), [healthtech](), [human-centered-design](), [safety](), [technology](), [transparency](), [trust]() ### AI overview This article argues that healthcare organizations should approach AI adoption through human-centered design, stronger governance, transparency, and alignment with clinical standards. It emphasizes that clinicians need technology to reduce administrative burden and support patient care without compromising safety, trust, or practical and ethical readiness. ### Source excerpt At 8th Light, we help healthcare organizations design and build AI-enabled systems that put people first, combining product strategy, human-centered design, and technology leadership to create innovative solutions that work for clinicians as well as patients. Why This Matters Although AI continues to dominate healthtech headlines, many frontline clinicians are still battling clunky systems, fragmented workflows, and administrative overload. The reality? Healthcare practitioners are not asking for more technology, they're asking for more time with patients. The tension between innovation and adoption continues to shape healthcare's digital transformation. As AI tools quickly evolve and adapt to revolutionize diagnosis, documentation, and decision-making, many healthcare providers remain cautious. Their questions are not about the potential of technology, but about its practical and ethical readiness for real-world care. For instance: How do we vet these tools? Can we trust the outcomes? Will this actually improve care or just add more work? Will this solution deliver measurable ROI without compromising patient safety? These are not questions of resistance, they're questions of responsibility. As healthcare systems race to deploy generative AI, predictive analytics, and automation, clinicians and administrators are demanding stronger governance, transparency, and alignment with clinical standards. Their goal isn't to slow innovation, but to ensure technology protects both patients and the licensed physicians who care for them. Behind these questions lies a workforce already under significant strain, and technology that fails to ease that burden risks making it worse. The Urgent Need for Human-Centered Healthtech The U.S. is already experiencing workforce strain across many health professions, driven by geographic maldistribution, burnout, and demographic pressures. Federal workforce projections show ongoing gaps across multiple professions, with non-metro communities ## A Primer: MCP Servers and the Model Context Protocol DevFeed: [A Primer: MCP Servers and the Model Context Protocol]() Original publisher: [Read original article]() Author: Priya Patil Published: 2026-02-25T06:00:00Z Content type: tutorial Language: en Sources: [8th Light](), [8th Light Insights]() Topics: [Model Context Protocol](), [Server](), [Security](), [client](), [Authentication]() Tags: [ai](), [ai-and-emerging-tech](), [ai-assistant](), [audit](), [authentication](), [mcp](), [model-context-protocol](), [protocol](), [sandboxing](), [security](), [servers]() ### AI overview This primer explains MCP (Model Context Protocol), an open protocol that gives AI models a standard interface for connecting to external tools and data sources. It also outlines current gaps in authentication, discovery, security, sandboxing, secret management, and audit trails. ### Source excerpt Navigating Change The way we interact with software is shifting. Instead of clicking through web interfaces and learning different UIs for each system, some people are moving toward natural language as the interface - telling an AI what they want done, and it handles the task completion for them. This shift is happening now, but there's been a missing piece: how does the AI actually connect to and control those systems? MCP Defined MCP (Model Context Protocol) is an open protocol that gives AI models a standardised interface to external tools and data sources. Think of it as a USB-C for AI - before USB-C, every device needed its own connector. MCP does the same for AI-system integration. Instead of building custom integrations for every combination of AI model and external service, you implement MCP once and your AI can talk to everything it needs to. Instead of context-switching between Slack, JIRA, GitHub, and dashboards for example, we'll be able to describe what we need and have an AI assistant handle the interactions. Or as Anthropic defines it: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems." Current State: A Nascent Protocol Yes, MCP has gaps. Here are a few: It's relatively new (launched November 2024) and the ecosystem is still figuring things out. Authentication and authorisation have a standard but implementation is patchy. Discovery is a work in progress, with a real need for global registry mechanics. Security is largely left to implementers - no built-in sandboxing, no secret management standard, no consistent audit trails. The community is actively working on all of these, and thing are moving very fast. But these are solvable problems and a lot of the changes are happening on the client side so building out servers feels a little more stable. These gaps shouldn't prevent you from getting value today - they just mean you'll need to handle some plumbing yourself and take an abundance of cauti ## Why Walk-Out Checkout Technology Works Better in Stadiums and Small Stores DevFeed: [Why Walk-Out Checkout Technology Works Better in Stadiums and Small Stores]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-02-16T19:30:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [Computer vision](), [Artificial Intelligence](), [Cloud]() Tags: [ai-and-emerging-tech](), [computer-vision](), [edge](), [edge-ai](), [on-device](), [real-time](), [technology](), [video]() ### AI overview The article argues that walk-out checkout technology struggled in grocery stores because of complex inventories, unpredictable customer behavior, and extensive human review. It says the approach is performing better in stadiums and small-format stores, where controlled conditions, limited products, edge AI, and 3D computer vision support rapid transactions. ### Source excerpt This technology platform, called 'Just Walk Out', required over 1,000 workers in India manually reviewing video footage to verify transactions. By 2022, 700 out of every 1,000 sales needed human review. Amazon pulled the technology from their Fresh grocery stores in 2024. They paved the way. But it wasn't sustainable. The problem wasn't the concept. It was the complexity. Grocery stores carry thousands of SKUs, items without barcodes, and unpredictable customer behavior at scale. In fact, this same technology is succeeding in stadiums and small-format stores. Mashgin kiosks are deployed across 150+ sports venues and a number of airports. Guests drop items on a tray, the system scans and prices them using computer vision, and checkout finishes in under 15 seconds. No barcode scanning. No cashier. No human review loop. Over 1.4 million items sold at NFL stadiums in 2024 alone. Median transaction time sits below 15 seconds, even during halftime surges when traditional concessions collapse under volume. Walk out technology works when the context is controlled. Why Stadiums Succeed Where Grocery Failed Stadiums solve the problems that broke Amazon's model: Limited SKUs. Concessions carry hundreds of items, not tens of thousands. High margins. Premium pricing justifies the tech investment. Controlled environment. Fixed locations, predictable lighting, standardized packaging. Edge AI processing. No cloud dependency. No human review. Decisions happen on-device in real time. Mashgin removes the constraint. Throughput scales without adding headcount. The kiosk processes items as fast as fans can place them on the tray. Speed only holds if the system stays up. Any downtime, and the kiosk becomes a bottleneck worse than the line it replaced. How Mashgin Handles Volume Mashgin uses 3D computer vision and edge AI to identify items in real time: Multiple cameras capture items from different angles as they land on the tray On-device neural networks classify products without cloud d ## Making Sense of Digital Transformation Initiatives: Seeing Past the Fuzziness DevFeed: [Making Sense of Digital Transformation Initiatives: Seeing Past the Fuzziness]() Original publisher: [Read original article]() Author: Josh Korr Published: 2026-02-13T23:41:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [digital](), [product mindset](), [Optimization]() Tags: [digital-transformation](), [optimization](), [organizations](), [product](), [product-strategy-innovation](), [project](), [strategy](), [structured](), [transformation]() ### AI overview This article explains why digital transformation initiatives often become unclear in practice and argues that short, structured strategy and shaping phases can create shared clarity. It discusses how these initiatives may involve business-model shifts, cultural change, product thinking, and process optimization, illustrated by client examples. ### Source excerpt Digital transformation always sounds clear in an RFP or slide deck, but in practice things can get fuzzy fast. What exactly are we transforming? Is this about customers, or about ourselves? Are we reshaping workflows, or the entire business model? Without answers to these questions, projects stall, swirl, or never quite get started in the first place. As a Certified Sense-MakerTM and fuzziness connoisseur, I love helping clients make sense of their digital transformation initiatives.* This includes helping them understand the bigger picture, what their plans will mean for business operations, and what tools or solutions can help. By implementing short, structured strategy and shaping phases, organizations can gain shared clarity and overcome transformational fuzziness. * Just kidding: there isn't a Sense-Maker(tm) certification. (Sigh.) Fuzziness Factor #1: The Big Picture Digital transformation initiatives are typically triggered by something bigger: business model shifts or expansions, operational maturation, rebrands or relaunches. And these initiatives go far beyond technology upgrades. There is a very real shift in culture, a move towards a product mindset, and an optimization of processes that meet the demands of the market. When done well, these initiatives have a lasting impact on the organization and the benefits show up on the bottom line. But teams that are at the "ground level" of this transformative work often have a fuzzy understanding of the macro-strategy and how the immediate near-term effort fits in. Take a Fortune 500 media company I worked with. They had debated for a year whether to introduce self-serve sales alongside their high-touch direct sales model. Nothing with the project had moved because no one had named the real issue: This wasn't just a sales project -- it was a business model transformation. Misalignment across stakeholders was causing them to delay decisions. Once reframed as a fundamental cultural and business model shift, two thin ## The Design Process and Agile Development: Part 1 -- Design Is Collaborative DevFeed: [The Design Process and Agile Development: Part 1 -- Design Is Collaborative]() Original publisher: [Read original article]() Author: Daisy Mølving Published: 2026-02-05T06:00:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [Agile](), [User experience (UX)](), [Development](), [Self-organizing Team]() Tags: [agile](), [delivery-and-practice](), [design-thinking](), [development](), [development-process](), [experiential-design](), [product-strategy-innovation](), [research](), [teams](), [user-experience](), [ux-design]() ### AI overview Part 1 of a series examines how design thinking and UX research can work alongside Agile development. It argues that iterative design and Agile delivery are compatible, while noting the tension between research needs, rapid timelines, client goals, and incremental development. ### Source excerpt This is Part 1 in our blog series on how the design process works alongside Agile methodology to produce results within an integrated team. Updated 2/5/2026. Originally published 2/2/2024 When it comes to developing new software, not every designer approaches the task the same way. While some use a design thinking approach, looking at the tasks from a user perspective, others use Agile methods, approaching it from an iterative project management standpoint. However, the two approaches are not mutually exclusive. The most successful designers approach their tasks using design thinking which helps inform prioritization within the Agile methodology. High performing teams delivering outcomes through the agile methodology do so with confidence when they know solutions are informed by the voice of the user. Working with Design Thinking and Agile Timelines Designers who've worked alongside Agile methodologies have likely felt the pressure of Agile timelines conflicting with the need for comprehensive design. While the approaches may feel conflicting at first, it's important to remember that both design and Agile methodologies emphasize the importance of working in small iterations to develop products that constantly evolve-- focusing on the smallest modifications that lead to making valuable products and building upon them. However, with its need for preliminary research, I've observed that user experience (UX) design can give Agile practitioners the impression of a waterfall process. Agile teams want to deliver quickly and continue iterating on the project after receiving feedback. As a UX designer, it is my responsibility to establish and fulfil the human need by talking to some users and conducting competitor research before we dive blindly into development. Working as a UX designer in this environment can feel like you're stuck between a rock and a hard place. You have a client who cares about the bottom line and wants to get to market quickly and a development team of ## Hand, Meet Prime Time: How Biometrics Drive Fan Experiences DevFeed: [Hand, Meet Prime Time: How Biometrics Drive Fan Experiences]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-01-30T23:05:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [Authorization](), [Latency](), [Back end](), [Amazon Web Services](), [Database]() Tags: [amazon](), [authorization](), [aws](), [backend](), [database](), [latency](), [platform-innovation]() ### AI overview The article examines Amazon One palm biometrics at Seattle's Lumen Field, where the system supports payments, age verification, and access across stadium operations. It argues that the broader system's success depends on authorization speed, network reliability, fallback paths, privacy practices, and infrastructure that can absorb demand. ### Source excerpt At Lumen Field, Amazon One runs across concessions, merch, and age-restricted gates. With over 69,000 fans per game, every second at checkout compounds. Fans hover their palm. Move through. No card. No PIN. No wallet. The Seattle Seahawks adopted it for a simple reason. Every moment spent waiting is a moment not watching, not buying, not coming back. Palm recognition solves the payment bottleneck. Amazon One has processed over 3 million transactions across all venues. But the real test is whether the surrounding infrastructure can handle what comes next. Why This Ripples Beyond Stadiums Airports. Hospitals. Corporate campuses. Every sector faces the same challenge: verifying identity and processing payments at speed and scale. Palm biometrics offer a new way through. The question now is how fast organizations can align their infrastructure to meet that standard. The System Behind the Scan Palm recognition uses near-infrared imaging to map vein patterns beneath the skin. More secure than fingerprints. Harder to spoof. At Lumen Field, the system handles: Real-time biometric matching against encrypted user profiles stored in AWS Payment authorization routed through existing POS rails without custom hardware overhauls Age verification for alcohol sales, replacing manual ID checks Multi-venue enrollment, so a palm registered at one location works across the network The palm scan takes under a second. But backend latency, network jitter, or database contention can stall the entire chain. Speed at the sensor means nothing if authorization takes three seconds. Where Speed Meets Engineering Sub-second recognition is only half the picture. The system must handle: Enrollment at first use. Fans link their palm to payment and identity before value kicks in. Network dependency. Any latency between kiosk and authorization server creates visible lag. Fallback paths. When biometric readers can't match, the system needs equal speed through alternate routes. Privacy perception. Clear ## From VHS to Interactive Streams: Customization at Scale with the NFL Sunday Ticket on YouTube DevFeed: [From VHS to Interactive Streams: Customization at Scale with the NFL Sunday Ticket on YouTube]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-01-23T23:05:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [Streaming](), [personalization](), [Sports](), [real-time](), [Playback](), [ui](), [parallel](), [Mobile]() Tags: [customization](), [interactive](), [mobile](), [parallel](), [personalization](), [platform-innovation](), [playback](), [real-time](), [scale](), [sports](), [streams](), [ui]() ### AI overview This article examines how NFL Sunday Ticket on YouTube moved live sports viewing from a fixed broadcast toward personalized, interactive streams. It describes custom Multiview layouts, fantasy integrations, spoiler controls, playback options, and interfaces that work across TVs, mobile devices, and tablets. ### Source excerpt It's the mid-90s, it's Sunday morning, and you're about to set your VCRs to record on your NFL game of choice You'd capture everything, commercials, dead time, halftime filler, and hope the tape didn't cut out in overtime. It was static. One-size-fits-all. Then TiVo arrived. That pause button changed the game. Suddenly, fans could freeze a field goal, run to grab game day food, and unpause just in time for the kick. Control entered the living room. Fast forward to NFL Sunday Ticket on YouTube. Fans are now building their own broadcast in real time. The cultural shift is clear: live sports have moved from passive consumption to personalized control over the gameday experience. Raising the Stakes For nearly three decades, NFL Sunday Ticket lived only on DirecTV. It was a premium cable-era product; expensive, exclusive, and tied to satellite hardware. Fans outside their home market had little choice but to buy into the bundle if they wanted every game. That era is over. When YouTube secured the Sunday Ticket package, it leapt from the satellite dish into the streaming stack. And with that leap came a redefinition of expectations: reliability is still required, but now the baseline includes interactivity and personalization at a massive scale. Inside Sunday Ticket's interactive layer: Custom Multiview Fans can build their own layout with two, three, or four games running in parallel. Local broadcasts integrate seamlessly for YouTube TV base subscribers. Multiview works across TVs, mobile, and tablets, keeping the experience consistent. Fantasy View Integration Users can link NFL Fantasy and Yahoo Fantasy accounts. This allows fantasy stats and team updates surface directly in the stream. Spoiler Mode & Playback Features Hide scores until you're ready to see them. Advanced playback controls such as broadcast delay toggle All the features create more ways to personalize the live feed. Improved UI & Side-by-Side Experience Dual-column layouts show live action next to stats ## The Design Process and Agile Development: Part 2 -- Collaborative Activities DevFeed: [The Design Process and Agile Development: Part 2 -- Collaborative Activities]() Original publisher: [Read original article]() Author: Daisy Mølving Published: 2026-01-16T06:00:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [Agile](), [User experience (UX)](), [Development](), [Software Engineering](), [Testing]() Tags: [agile](), [continuous-integration](), [design](), [development](), [experiential-design](), [teams](), [testing](), [user-experience]() ### AI overview This article explains how UX designers, product owners, and software developers can collaborate during an agile design process. It focuses on continuous discovery through stakeholder interviews, competitive and analogous research, user interviews, testing, and collaboration with developers on codebase, infrastructure, feasibility, and timelines. ### Source excerpt Updated 1/16/2026. Originally published 12/10/2024 As we talked about in Part 1 of this blog series, The Design Process and Agile Development: Part 1 -- Design Is Collaborative, the design process provides teams with the opportunity to join forces, paving the way for an integrated team of user experience (UX) designers, product owners, and agile software development to create a successful product. So where do you begin? You have a new project and an integrated team. You know that success can be achieved in close collaboration between your team members, each representing deep expertise in desirability, viability, and feasibility. But you need to determine which activities are most profitable for the team to put their heads together on and what their responsibilities should be. Find Out Together Finding Out is where it all starts, but it most certainly doesn't only happen at the start! We 'find out' in continuous cycles throughout the project, not just from our users, but also from our stakeholders and product and development teammates. After all, though the end product is ultimately for our end users, design is also influenced by viability, or the business, and feasibility, or the developers. So it makes sense to 'find out' collaboratively. You can do this through stakeholder interviews, competitive analysis and analogous research, user interviews and testing, and continuous integration (CI) tools. Stakeholder Interviews Stakeholder interviews are an early, integral step for determining what your stakeholders care about -- their hopes and fears, past project experiences that might drive their decision-making, key metrics they need to hit, and any assumptions they may have. Not only will you build rapport, you'll also learn how to engage your stakeholders through the design process. I've experienced that not all stakeholders have immediate faith in design, so understanding how they measure success and engaging with their success criteria throughout your work can be cruc ## How Netflix Built a Resilient Platform for WWE Raw's Weekly Live Broadcasts DevFeed: [How Netflix Built a Resilient Platform for WWE Raw's Weekly Live Broadcasts]() Original publisher: [Read original article]() Author: Shawn DeVries Published: 2026-01-06T23:05:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [Netflix](), [Streaming](), [Resilience](), [Amazon Web Services](), [observability](), [data]() Tags: [aws](), [live-streaming](), [netflix](), [observability](), [platform-innovation](), [real-time](), [resilience](), [servers](), [streaming]() ### AI overview This article examines how Netflix engineered a dedicated platform for WWE Raw's weekly live broadcasts. It describes redundant AWS ingest, low-latency CMAF/HLS segments, synchronized manifests, adaptive AVC and HEVC playback, Open Connect CDN delivery, and observability tooling, while noting remaining risks such as startup surges, origin contention, device diversity, and regional edits. ### Source excerpt What a difference a year makes. When Netflix secured WWE Raw, a three-hour weekly live broadcast with more than three decades of history, it marked a turning point. Raw is chaos in motion: fan-fueled, unpredictable, impossible to rehearse. And now Netflix has to make it flawless. More than a licensing play. It's an engineering gauntlet. Pulling it off means delivering a resilient platform that can handle global, live-grade performance every single week. Raising the Stakes Live streaming has, of course, been around for years. But the expectation that a global service can execute hours of live content flawlessly, at scale, every week, that's new. Raw sets the new bar for resilience. And from here on, every live product will be judged against that standard, whether it's financial trading, real-time auctions, or healthcare collaboration. How Netflix Built for Weekly Live To go beyond its on-demand stack, Netflix built a dedicated live media and data pipeline, piece by piece: Dual ingest with AWS MediaConnect and MediaLive for redundancy at the source. Two-second CMAF/HLS segments tuned for speed without overwhelming origin. Wall-clock aligned manifests to sync across devices and regions, even with edits. Adaptive ladders in AVC and HEVC balancing SD to 4K playback, mindful of constrained devices. Open Connect CDN with 18,000 servers in 6,000 locations, embedded in ISPs to slash startup time. Full-stack observability with Atlas, Mantis, and Lumen, surfacing drift and sync issues before users ever notice. For this approach, Netflix couldn't build on top of an old stack. They're deliberate adaptive platform choices that now set the standard for how live systems must be built. They had to replatform in a way that provided the most elasticity in the future. Fragile Points That Remain Even with this purpose-built pipeline, the weak spots look familiar to anyone running live systems: Start-time surges hammer manifest and session services in the opening seconds. Origin contenti ## Celebrating Our Beacons: Hugh Sato and Pierce Edmiston DevFeed: [Celebrating Our Beacons: Hugh Sato and Pierce Edmiston]() Original publisher: [Read original article]() Author: Juan Santana Published: 2025-11-21T20:31:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [systems](), [Tooling](), [User interface design](), [Usability](), [trust]() Tags: [build](), [culture-and-news](), [delivery-and-practice](), [product](), [time](), [trust](), [usability](), [workflow]() ### AI overview 8th Light celebrates Hugh Sato and Pierce Edmiston as Beacon Award recipients, highlighting their complementary contributions in design, engineering, and product leadership. The article describes their work improving a fragmented experimentation platform by unifying its design, workflow, and technical foundations, reducing deployment time from three weeks to the same day and pursuing a fifteen-minute SLA. ### Source excerpt Congratulations to Pierce Edmiston and Hugh Sato, our latest recipients of 8th Light's Beacon Award! Our Beacon Award recognizes team members who exemplify 8th Light's values and inspire us all. Pierce and Hugh represent two different strengths within 8th Light that come together to create meaningful, high-impact work for our clients. Pierce, Sr. Principal Engineer blends scientific rigor with technical and product leadership to turn complex research and modeling into stable, production-ready systems. While Hugh, Principal Designer, elevates that work through a human-centered design lens that makes intricate workflows clear, usable, and trustworthy. He brings coherence where systems feel chaotic and reduces cognitive load, helping teams and customers move with confidence. Both leaders build products from the system out to the experience, ensuring the core is solid and the experience makes the system clear, adoptable, and effective. They design for adherence, flow, safety and change. They prioritize what matters for the business and what will sustain value over time. They translate complexity into outcomes. They build systems people can use, learn from, and rely on. This partnership became a turning point for one of the world's most valuable enterprises, where Hugh and Pierce were brought in to strengthen a critical experimentation platform at the heart of the client's product decisions. When the work began, that platform was fragmented and difficult to operate. Experiment owners with great ideas had to rely on scattered tooling and manual engineering support just to get started. Pierce and Hugh anchored a full turnaround. They joined forces to unify the platform's design, workflow, and technical foundations, ultimately transforming a cumbersome three-week deployment process into a same-day experimentation engine and charting a path toward a groundbreaking fifteen-minute SLA. This shift did more than speed up launches, it elevated experimentation into a strategic, tr ## AI-assisted Coding is Not Doing My Dishes and Laundry DevFeed: [AI-assisted Coding is Not Doing My Dishes and Laundry]() Original publisher: [Read original article]() Author: Justyna Jurkowska Published: 2025-09-10T18:45:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [AI-assisted coding](), [coding](), [Large Language Model](), [Tooling](), [ChatGPT](), [cursor]() Tags: [ai](), [ai-and-emerging-tech](), [ai-assisted-coding](), [chatgpt](), [coding](), [cursor](), [development](), [llm](), [tooling]() ### AI overview This opinion article examines the author's experience with AI-assisted coding and argues that AI has fallen short at handling mundane software-development tasks. It focuses on project setup and manual data handling, including problems encountered when using Cursor and ChatGPT to generate project setups. ### Source excerpt "I want AI to do my laundry and dishes so that I can do art and writing, not for AI to do my art and writing so that I can do my laundry and dishes." Joanna Maciejewska I'm sure you've seen this quote from Joanna Maciejewska all over social media; I'd bet some money that there are shops already selling t-shirts and mugs with it. Despite seeing it dozens of times, I never thought about it in the context of my day-to-day as a programmer! I, like the quote's author, was more focused on AI hijacking the "classical" creative work such as painting and writing, instead of helping us humans with the most boring tasks. But it's been almost a year since I've started learning more about AI and LLM, applying them to projects, and using assisted coding. And I've gained a new perspective on this quote, this time within the tech world. And it isn't all sunshine and rainbows. I had hoped AI would take over my tech "dishes and laundry" -- the most frustrating and mundane tasks -- freeing me up to focus on the more exciting parts of my job. But ironically, it has consistently fallen short in exactly those areas. In this post, I'll reflect on how AI struggles with two chores: the frustrating complexity of project setup and the dull grind of manual data handling. The Struggle of Setup Someone once asked me, "If there was one thing in software you could magically skip, what would it be?" My answer was immediate: "setup." It's rarely fun, always takes longer than expected, and involves wrangling together tooling that shifts from project to project. We're constantly tempted to try out the new, shiny thing, only to discover a new set of issues when trying to make everything run on multiple environments or deploy. Thankfully, the software community built great instruments to ease this pain, such as Phoenix, Ruby on Rails, Docker, create-react-app, or even version checker for React Native. These tools are lifesavers. I'd probably have gone mad without them. Sincere thanks to their contributors ## The Evolution of Craft - Embracing AI in Software Development DevFeed: [The Evolution of Craft - Embracing AI in Software Development]() Original publisher: [Read original article]() Author: Zuko Mgwili Published: 2025-08-21T16:21:00Z Content type: opinion Language: en Sources: [8th Light Insights]() Topics: [AI Development](), [software-development](), [Software Engineering](), [Code]() Tags: [ai](), [ai-and-emerging-tech](), [code](), [development](), [productivity](), [software-development]() ### AI overview An engineer describes moving from skepticism to using AI code assistants in everyday software development. The article discusses reported productivity claims, the author's concerns about the loss of software craftsmanship, and the use of hobby projects to explore how AI can reduce routine development work. ### Source excerpt The Evolution of Craft: How I Embraced AI in Software Development One Sunday morning after a church service I was enjoying a cup of tea, cake and warm conversations with fellow parishioners. One of the conversations with a particular individual shifted to work and I learned that he works in the energy sector. More specifically, he is an engineering manager for an organization specializing in renewables where he oversees a number of solar arrays and other supporting infrastructure crucial for operational efficiency. He told me he was actively recruiting to in-source the development of their software systems in an effort to reduce costs. I recommended that he seek individuals who have experience with AI code assistants or at least are open to working with them, citing my own significant productivity gains with such tools. I know some may find it paradoxical that someone who has earned a living writing code for years would now advocate for tools widely predicted to render such a profession obsolete in the near future. And, to be fair, I was initially quite skeptical of the tools myself. But after some time, I've grown to embrace them, and have found great value in using them in my everyday work life. My Initial Skepticism My initial skepticism stemmed from having witnessed so many technology hype cycles that delivered little to nothing, so I was easily dismissive of the resurgence of AI. There were early claims of productivity gains of up to 50%. However, reports have since challenged that claim and some tests have revealed a more realistic picture of 10-15%. I also had a deeper concern, one that went far beyond being made redundant by AI. It was a concern and, quite frankly, a fear about the potential loss of a cherished craft that I and many others have devoted their time to perfecting, only to have it suddenly taken over by a machine. Becoming Curious To work through my emotions, I began exploring hobby projects. Many software engineers engage in such endeavors for ## Using SLOs and OpenTelemetry to reduce alert fatigue DevFeed: [Using SLOs and OpenTelemetry to reduce alert fatigue]() Original publisher: [Read original article]() Author: Andy Smith Published: 2025-08-18T19:03:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [observability](), [site-reliability-engineering](), [Prometheus](), [OpenTelemetry](), [incident]() Tags: [alert-fatigue](), [delivery-and-practice](), [monitoring](), [observability](), [prometheus]() ### AI overview The article describes how frequent, non-customer-impacting alerts can cause alert fatigue and delay detection of production incidents. It presents Service Level Objectives and increased observability with OpenTelemetry as changes intended to focus engineers on user-impacting failures. ### Source excerpt How to make your customers happy and your engineers even happier It's common for monitoring and alerting solutions on production services to be quite chatty, sometimes producing hundreds of notifications per day. There's a scene in the classic film The Matrix where one of the characters (Cypher) is looking at a screen with green unintelligible code. He's asked: "Do you always look at it encoded?" He responds by telling Neo he doesn't see code, just what it represents. After some time in The Matrix like Cypher, in the sea of notifications you understand what they mean and know what is important. Unfortunately, for your new team members they have to learn what they mean and may have no idea what customer impact these alerts have. If too many of these notifications are not customer impacting and just informational what follows is "alert fatigue", you begin to tune out from them because of the volume. This becomes "dangerous" when you miss something in the noise that IS important. You can bet that the notification you missed will lead to a 3AM support call from an irate customer which is SLO not fun! Scenario I joined an eight person team for a large enterprise client that had a few production incidents. There were two in July which were high stress problems, the team worked impeccably to resolve them. However, users of the website noticed them first, called Customer Support, then it was "all hands on deck" to try and resolve. This is known internally as a "Major Incident"*. The team fixed the issues and everyone was happy but of course the damage was already done, reputation was harmed. We were in reactive fire fighting mode. It doesn't have to be like this. It was not the case that there was no monitoring, there were SLO many Prometheus alerts firing, and that's the problem. Due to the frequency of these alerts, a lot of them were ignored. They didn't tell the engineers specifically that a key feature of the site was not working. Just because a pod has crashed with "o ## Using Viability and Feasibility to Guide Ambiguous Design Projects DevFeed: [Using Viability and Feasibility to Guide Ambiguous Design Projects]() Original publisher: [Read original article]() Author: Agustin Sanchez Published: 2025-07-25T05:00:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [iteration](), [Testing](), [Users]() Tags: [experiential-design](), [experiment](), [human-centered-design](), [iteration](), [onboarding](), [value]() ### AI overview This article presents human-centered design as a way to navigate ambiguous projects. It explains how defining business objectives and measurable outcomes establishes viability, while testing ideas early and iterating helps assess feasibility and reduce risk. ### Source excerpt Updated 7/25/2025. Originally published 12/10/2024 Ambiguity in design isn't a roadblock -- it's an opportunity. Design ingenuity thrives in the gray area where rules haven't been written, and solutions are waiting to be discovered. So how do you turn "I have no idea where to start" into breakthrough ideas that actually work? At 8th Light, our approach is anchored in the three pillars of human-centered design: viability, feasibility, and desirability. These are the tools that transform chaos into clarity and make ambiguity your ally, not your enemy. Viability: Define Your Destination Before Picking the Route The truth is, you don't need to know the "how" right away. However, you absolutely need to know the "why." Viability ensures your team stays aligned with business objectives, reducing costly detours and keeping your efforts focused on delivering measurable value. Picture this: You're tasked with fixing an outdated customer onboarding process. The details are vague, but the goal is crystal clear -- reduce the time it takes for new users to find value. Once you've mastered the "why," the rest becomes an experiment. Early setbacks are simply data points, guiding you toward smarter decisions. Viability keeps you aligned with business objectives, ensuring that every test and rapid iteration thereafter, serves a purpose. Pro tip: Start every ambiguous project with these two questions: What are we trying to achieve? Why does this matter? -> Takeaway: Before starting a project, define clear business objectives and measurable outcomes. Use these as your north star to guide every decision. Feasibility: Stop Guessing, Start Testing With your goals in place, it's time to embrace the unknown and start experimenting. Feasibility minimizes risk by validating ideas early, reducing the chance of expensive missteps, and accelerating your path to market-ready solutions, encouraging you to iterate effectively to reach the solution. It answers the question: Can we actually build this? ## Unlocking Safer, Faster Experimentation for a Global Tech Leader DevFeed: [Unlocking Safer, Faster Experimentation for a Global Tech Leader]() Original publisher: [Read original article]() Author: Kristin Kaeding Published: 2025-07-18T22:18:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [Development](), [systems](), [Deployment](), [iteration]() Tags: [architecture](), [cross-functional-teams](), [delivery-and-practice](), [development](), [engineering](), [operational-risk](), [platform-innovation](), [workflows]() ### AI overview A case study describes 8th Light's seven-week assessment for a Fortune 100 consumer technology company whose growing experimentation pipeline was slowed by manual approvals, fragmented workflows, and unclear ownership. The work combined human-centered design, technical architecture, organizational strategy, and the Double-Diamond process to define a more scalable, self-service experimentation platform. ### Source excerpt Why It Matters At 8th Light, we help enterprise teams remove friction, foster alignment, and build tools that scale with confidence. This project exemplifies what happens when human-driven design meets technical rigor: major time and cost savings. By focusing on systems thinking, user needs, and resilient architecture, the organization created a path forward that supports both immediate impact and long-term innovation. This story is one of many showing how that approach delivers lasting results. The Challenge: A Strong System Slowed by Scale A Fortune 100 consumer technology company built a powerful experimentation pipeline -- one that fueled product innovation across its digital ecosystem. As the platform grew, so did its complexity; manual approvals, fragmented workflows, and inconsistent tools created friction that slowed development cycles and added risk. Rather than patch over the pain points, the company sought a bold transformation to reduce this risk: to turn a solid foundation into a modern, scalable, and self-service experimentation platform. The Goals Accelerate the end-to-end experimentation pipeline Reduce manual bottlenecks and operational risk Align cross-functional teams around shared metrics and ownership Unlock safe, scalable innovation at speed Our Approach: Human-Centered Meets Technically Grounded 8th Light was brought in to lead a seven-week high-level assessment, blending human-centered design with technical architecture and organizational strategy. We followed the Double-Diamond Process to move from discovery to delivery: Problem Discovery Problem Synthesis Solution Discovery Solution Synthesis The TimelineWeeks 1-2: Solving the Friction We kicked off with deep interviews across engineering and product leadership. These conversations uncovered systemic blockers -- ranging from delays in approvals to lack of experiment ownership. Weekly playback sessions helped align stakeholders and refine the focus on the end-to-end experimentation lifecycle. ## 8th Light Honors Rani Zilpelwar with Quarterly Beacon Award DevFeed: [8th Light Honors Rani Zilpelwar with Quarterly Beacon Award]() Original publisher: [Read original article]() Author: Juan Santana Published: 2025-07-11T17:27:00Z Content type: article Language: en Sources: [8th Light Insights]() Topics: [Development](), [Software Engineering]() Tags: [beacon](), [culture-and-news](), [delivery-and-practice](), [growth](), [leadership](), [mentorship](), [software-delivery](), [team](), [trust]() ### AI overview 8th Light highlights Rani Zilpelwar as the recipient of its Quarterly Beacon Award. The article recognizes her leadership as a Software Delivery Lead, including managing contractors for a client and mentoring others. ### Source excerpt Congratulations to Rani Zilpelwar, the recipient of 8th Light's Quarterly Beacon Award, a peer-nominated honor that celebrates team members who shine light on our core values. Rani is a Software Delivery Lead with over a decade of experience building high-quality software and high-trust teams. This quarter, Rani's leadership and influence grew significantly beyond her original role with one of the world's largest entertainment providers. Her ability to build credibility with key client leaders resulted in her being entrusted with new leadership responsibilities, including managing a team of contractors on the client's behalf. Beyond the client work Rani leads, she is also deeply committed to the mentorship and growth of those in her circle of influence. Recently, Rani published an insight on "Integrating Agile in the Era of AI", amplifying the voice of her practice and helping to shape the conversation around modern software development. Through her commitment and trusted leadership, Rani is a powerful Beacon to the values we hold true at 8th Light. Her actions illustrate how 'Honestly Builds Trust' and how a commitment to continuous education and growth can fuel limitless opportunity. Our CEO, Jenny Farver, sums it perfectly: Rani doesn't just lead. She blazes the trail. She delivers with purpose, speaks with honesty, and helps make our organization better. If Rani is your manager, you're lucky. If she's not, you're still lucky because her leadership lifts all of us. ## TDD: The Missing Protocol for Effective AI Assisted Software Development DevFeed: [TDD: The Missing Protocol for Effective AI Assisted Software Development]() Original publisher: [Read original article]() Author: John Riccardi Published: 2025-05-28T18:14:00Z Content type: tutorial Language: en Sources: [8th Light Insights]() Topics: [Test-driven development](), [Large Language Model](), [AI Development](), [Software Engineering](), [Prompt Engineering]() Tags: [ai](), [coding](), [core](), [engineering-and-devops](), [llm](), [prompting](), [quality](), [software-development](), [tdd]() ### AI overview This article argues that test-driven development provides a structured communication protocol for collaborating with AI coding tools. It explains that large language models often struggle with broad, ambiguous software tasks because developers provide insufficient context, constraints, and edge cases, and recommends writing tests first before using AI to implement solutions. ### Source excerpt Bottom Line Up Front The goal isn't to replace human developers but to offload repetitive tasks so we can focus on creativity and architecture--where human expertise is irreplaceable. Start your next feature by writing tests first, then let AI help implement the solution. You'll deliver higher quality code faster, with greater confidence. Large Language Models Aren't as Simple as They Seem Large language models (LLMs) have a fundamental flaw: they appear deceptively easy to use. That blinking cursor invites you to interact with an LLM as if it were another human being--one that understands your intent, the context of your questions, and the logic behind your requests. You type a prompt, hit send, and then disappointment sets in. While it's exciting to watch it generate multiple files of code for your new project, the moment you try to run that code, it often fails to work as intended or doesn't run at all. As you continue prompting it to iterate on previous outputs, the LLM may go in circles, change direction entirely, or simply stall. The core issue is that we ask LLMs to do too much while providing too little direction and context--effectively setting them up for failure. It's like the classic PB&J experiment, where a father follows his children's sandwich-making instructions literally. We believe we're being clear, but we drastically underestimate how much implicit context AI lacks about the problems we're trying to solve. What we need is a better communication protocol--one that structures our requests in a way AI tools can reliably understand and execute. Why AI Struggles With Large, Ambiguous Problems Despite their impressive capabilities, current LLMs consistently struggle with large, vague problems. The issue is not primarily token limitations or technical constraints; it's a deeper problem in how we frame our requests. When developers ask AI to "build a complete authentication system" or "create an e-commerce checkout flow," they inadvertently set the AI up to