Rob Lanphier

This week, Microsoft and The Seattle Times hosted the AI in Local News Summit, an effort born of the partnership between the Lenfest Institute for Journalism, Microsoft, and OpenAI. I was honored to lead a session for this incredible group of technical fellows, which included participants from The Seattle Times, The Philadelphia Inquirer, The Minnesota Star Tribune, Chicago Public Media, Newsday Media Group, Boston Globe Media, ProPublica, NEWSWELL at Arizona State University, Baltimore Banner, and The Dallas Morning News. Here's a teaser of some links of relevant content that could help journalists in the newsroom augment their abilities with AI to move quickly on short deadlines for breaking news. 𝐑𝐞𝐥𝐞𝐯𝐚𝐧𝐭 𝐭𝐞𝐜𝐡 • Azure AI Foundry: https://ai.azure.com/ • Real-time speech API for translation: https://lnkd.in/g7XS3xsD • AI Search: https://lnkd.in/g-QefmbP • Content Understanding: https://lnkd.in/gQV7BdB2 • Evaluation service: https://lnkd.in/gBvkfVyz "𝐀𝐈 𝐢𝐧 𝐉𝐨𝐮𝐫𝐧𝐚𝐥𝐢𝐬𝐦" 𝐏𝐫𝐨𝐭𝐨𝐭𝐲𝐩𝐞𝐬 𝐚𝐧𝐝 𝐔𝐬𝐞𝐟𝐮𝐥 𝐒𝐭𝐚𝐫𝐭𝐞𝐫 𝐂𝐨𝐝𝐞 • RAG implementation to search over text-based news articles using Azure OpenAI and Azure AI Search: https://lnkd.in/gDwv8bws  • Writing assistant to extract key people and locations from article and run search on them, using Azure Cognitive Services Text Analytics for entity extraction and Bing API for search: https://lnkd.in/gZQURmn9  • Multiagent collaboration using AutoGen to conduct online research, edit, and write article: Code repo is at https://lnkd.in/gddznwQS and LinkedIn post with video: https://lnkd.in/gDXZK4cN  𝐍𝐋𝐖𝐞𝐛 NLWeb is especially exciting as it brings the power of LLMs to every website. It can search over your item catalog (and will always return a real piece of content from your collection). This open standard allows you to easily switch out the model, embedding model, and vector database used. There are tools to import structured data. Finally, the MCP integration makes your website agent-compatible and ready for the agentic web.   • Get our sample running locally: https://lnkd.in/geTGx9nB • Explore the demos: https://lnkd.in/gxw6NR3t • How to change your default model, vector DB, etc.: config directory at https://lnkd.in/geTKw4yw • How to load data: https://lnkd.in/gWM7MwGw • How to deploy to Azure: https://lnkd.in/gayfzrr3 • Web scraping tool: https://lnkd.in/gUqeZJWf

105

3 Comments

From Silicon to Software: Week 7 The Hidden Cost of Re-Inventing the Wheel We didn’t kill the old platform - our customers did. At Analog Devices, many product groups built evaluation platforms for their products. They went closed HDL, closed drivers, closed tools, polished UI & locked internals. The thinking was simple: control the experience, reduce support headaches & hold on to competitive advantage by not opening the hood. A different team took the opposite approach: open HDL, open drivers, open tools & clean interfaces to third-party ecosystems like #Python, MathWorks #MATLAB & NI (National Instruments) #LabVIEW. It wasn’t as shiny, but customers could pull it apart, modify it & drop the pieces straight into their own designs. Both platforms let customers measure device performance, but over time, one approach proved easier for customers to carry forward into their own designs. The closed platform was an impressive demo. But when evaluation ended, customers hit a wall. Integration meant starting from scratch. Every bug was unique to their build. Support questions piled up because no one could see the internals. That worked for large customers who had 1:1 support, but it left smaller teams struggling. The open platform told a different story. Customers didn’t stop at evaluation, they kept going: - HDL cores dropped directly into their FPGA designs. - Driver code ported into production firmware. - Toolchains mirrored in their own build systems. That reuse changed everything. Early integration bugs vanished because they’d already been solved in the platform. “How do I…” questions disappeared because the answers were right there in the source. Fixes in the platform helped everyone instantly, not just the last person to open a ticket. The kicker? The open system was aimed at “broad market” customers with minimal direct support. But many large OEMs found the open platform & started using it. Here’s the thing about re-inventing the wheel: you don’t pay for it once. You pay for it every time you touch it. Every closed, one-off platform means you own the upkeep forever. Every duplicated driver or BSP traps bug fixes in silos. Every unique onboarding path slows the next customer. A platform is the opposite. It’s a foundation you build together: fix once, share everywhere & let improvements compound. Your fastest projects will be the ones with the deepest reuse. Why teams still re-invent: - Local optimization bias: “It’s faster if I just write it myself.” - No platform owner: Without stewardship, duplication spreads. - Perceived uniqueness: “Our project is different.” (It usually isn’t.) If you want speed, stability & fewer support calls, stop thinking of reuse as a shortcut. Think of it as engineering infrastructure. Where have you seen the most painful wheel-reinvention? Did it really save time or just move the bill into the future? #EmbeddedSystems #PlatformEngineering #Firmware #FromSiliconToSoftware #EngineeringProductivity

44

2 Comments

Hi everyone! My last post was in Florida; this time I'm across the continent in Huntington Beach, California, for #OptivCon SoCal and the latest tip from my "guide to the AD forest recovery guide". Do you have virtualized DCs? Here's an important point to consider for forest recovery. #ActiveDirectory

66

2 Comments

Context engineering for agents is an interesting concept. My two cents, truly agentic systems w/ reasoning ability don't need verbose context awareness in their prompts - they should be able to handle their context autonomously via basic tool-use and some light scaffolding for state observations. This is for sure contrary to current trends. Many agentic apps have built proprietary value by identifying context engineering methods that significantly enhance features via context-aware prompting (like repo indexing in Cursor). However - in the long run, if LLMs are ever to really be true autonomous agents, such methods should only provide value vis a vis efficiency, and not capability lift. In other words, model + tools should be able to achieve the same results as a context-engineered approach, but over a longer trajectory.

37

3 Comments

Whenever you're writing something at work (whether it's a pull request, a document, a system design, a bug report, a feature request, etc.), make sure to give it a meaningful title and a TL;DR. Make it easy for folks to get a grasp of what it is you're doing.

52

5 Comments