Loading…
Browse by type
Explainer reads
Explainer posts on Yomu, summarised newest first.
- 1,318 posts
- 20 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Explainer posts
What are MCP Servers?
This explainer clarifies what Model Context Protocol (MCP) servers do and where they differ from conventional APIs, serverless functions, and standalone appliances. It frames MCP servers as Alexa Skills that connect capabilities to an LLM, then as JSON-based APIs with multiplexing, server push, and built-in introspection for discovering tools, arguments, and usage descriptions. The post cautions that blindly generating an MCP server from an OpenAPI schema may expose low-level calls rather than agent-oriented workflows, and notes that MCP servers have a long-lived initialization, operation, and shutdown lifecycle rather than a serverless one. It also argues that MCP is not inherently secure or private, recommending remotely hosted servers protected by revocable bearer tokens, and envisions customized MCP-based agents becoming family-like assistants rather than mere appliances.
My AI Skeptic Friends Are All Nuts
The essay argues that skepticism about LLMs for software development often reflects outdated experience with chat-based code generation rather than current agent workflows. Modern coding agents inspect repositories, edit files, invoke Unix tools and MCP calls, use Git, and run linters, compilers, tests, and model checkers, turning feedback into iterative repairs. The author says these systems can automate tedious typing, lookup, bookkeeping, test refactoring, and edit-compile-test-debug cycles while developers retain responsibility for curation, judgment, direction, and reviewing merged code. Hallucinations are presented as substantially mitigated by tool-based validation, although the author notes that agents remain unsuitable for some trusted operations and that effectiveness depends on language, tooling, prompts, indices, and guardrails. The conclusion is that AI-assisted programming is already materially changing developer productivity, despite its noise and unresolved limitations.
Odysseus to AI: Matt Greenwood on the Dev Interrupted Podcast
Matt Greenwood, Chief Innovation Officer at Two Sigma, outlines strategies for managing technological change, integrating artificial intelligence into systematic investment, and building supportive engineering organizations. Greenwood describes sustained innovation through the S-curve using an epsilon and omega approach, combining small iterative steps with a broad long-term vision. To direct resources amid rapid advances in machine learning and large language models, he presents a functional framework categorizing AI roles into advisory insights, oracle outcome validation, operational task automation, and agentic coordination. This categorization aims to automate routine workflows while keeping human creativity, control, and higher-level thinking at the center of the investment process. Additionally, the organization fosters employee engagement through initiatives such as an internal hacker lab where cross-disciplinary teams build projects ranging from robots to racing simulators.
Why the future of work depends on AI
The post examines why organizations struggle to make AI useful in daily work despite strong demand. Tool fragmentation forces teams to search across disconnected systems, manually prepare data, and switch context, while resource limits and concerns about hallucinations complicate adoption. A survey of 1,000 productivity-software decision-makers found that integrating AI into existing systems was the leading challenge, while productivity motivated 57% and AI specifically motivated 44% of platform evaluations. The post presents embedded AI and connected workflows as the response, citing Notion AI’s AI Meeting Notes and Enterprise Search as examples. It reports that 86% of users would be disappointed without it, over 70% report improved work quality and faster information processing, and 50% save more than an hour weekly.
Evolution of Product Classification at Shopify: From Categories to Comprehensive Product Understanding
Shopify’s product classification system evolved from a 2018 logistic-regression model using TF-IDF into a product-understanding platform designed to capture categories, attributes, characteristics, metadata, and content-safety signals. A 2020 multimodal image-and-text approach improved classification, but growing product complexity led Shopify to combine Vision Language Models with its Standard Product Taxonomy, spanning more than 10,000 categories and over 1,000 attributes across more than 26 business verticals. The production pipeline uses two-stage category and attribute prediction, with category context shaping the second call, and runs on Kubernetes with NVIDIA GPUs; FP8 quantization, Nvidia Dynamo in-flight batching, and KV caching improve inference efficiency. A multi-LLM annotation system independently evaluates products and uses arbitration when models disagree, helping build training data for consistent predictions. The resulting system processes over 30 million predictions daily, delivers an 85% predicted-category acceptance rate, and doubles hierarchical precision and recall versus the earlier neural network approach.
How to turn your company's knowledge into action
Companies can lose speed when knowledge remains in silos, making work harder to complete quickly. A Harvard Business Review survey cited in the text found that 44% of respondents think their company manages knowledge well, while 3% use AI to help. Conversations with Rohit from OpenAI, Jennifer from Slack, and Kristen from Hinge point to organizing information around actual work, establishing clear locations for knowledge, and designing systems people will use. The examples include Hinge’s weekly “Documentation Fridays” and Slack’s inclusion of documentation in performance expectations. Recommended actions are to define a source of truth, map where information lives, use templates, build sharing into routines, and recognize contributors; the stated payoff is faster movement, more innovation, and learning from experience.
30 Minutes With MCP and flyctl
Kurt Mackey describes building a minimal MCP server for flyctl in 30 minutes, motivated by testing how an LLM could inspect deployed applications. MCP connects an LLM client to server-exported tools through JSON exchanges; this implementation uses stdio mode, a Go MCP library, and exposes only fly logs and fly status, producing roughly 90 lines of code. Existing JSON modes in flyctl commands made the tools easier to drive from automation. When pointed at unpkg through Claude, the server surfaced a globally distributed deployment, identified two critical machines, and connected repeated restarts and oom_killed events to Bun using about 3.7 GB of a machine’s 4 GB allocation. The post calls the result surprisingly useful while warning that local MCP servers give cloud-hosted Claude access to native programs and would be safer in isolation.
Our Best Customers Are Now Robots
Fly.io reports that users driving the platform’s most recent growth are robots rather than people, prompting a reconsideration of developer experience (DX) as the primary product lens. The post describes how vibe-coding workflows use Fly Machines—Docker containers running as hardware-isolated virtual machines—to create, modify, stop, and rapidly restart environments without paying during stopped periods. These workflows favor incremental filesystem state, object storage, and controllable routing for MCP connections, including potentially long-lived SSE connections that should reach the same stateful instance. Fly.io also proposes exposing its API through MCP and using sealed, tokenized secrets so isolated machines can substitute real OAuth credentials only when needed. It concludes that a useful robot experience (RX) will require more than an MCP interface, while managed Postgres remains the company’s most important engineering priority and the platform is still primarily designed for humans.
Using an AWS microservice architecture for subscription management
Enterprise subscription management must handle mid-cycle plan changes, usage-based billing adjustments, synchronized service updates, atomicity, failed operations, data consistency, and auditability beyond basic recurring billing. This sample architecture uses an event-driven AWS design in which subscription changes are published to EventBridge and routed to Step Functions workflows. EventBridge provides at-least-once delivery, content-based filtering, dead-letter queue support, and integration with Step Functions, while Lambda functions validate changes, calculate Stripe proration, update external subscriptions, and trigger service-specific actions. Step Functions supplies retries with exponential backoff for StripeTemporaryError, DynamoDB stores current and historical subscription data using transactional updates, and Stripe calls use an event identifier as an idempotency key. The pattern is presented as a flexible foundation for reliability, maintainability, compensation for partial changes, and auditability in systems handling financial transactions and service provisioning.
Growth Intern to Procurement New Grad
A 2023 summer internship on Ramp’s growth engineering team changed the author’s view of software engineering and led to a return as a new graduate engineer. The team accelerated outbound sales through fast experiments, metric ownership, and decisions about whether promising tactics deserved scalable systems, rather than following the thorough specification process typical of regular projects. His work included reducing third-party data-enrichment costs, building AI-driven outbound-sales tools, adding observability and service monitors, and conducting competitive intelligence projects. He returned to join the new procurement product line, where he helped match card transactions to purchase orders and led additional projects. The post also recommends rapidly building system context through code review and on-call shadowing, while full-time engineers should weigh velocity against maintainability and take initiative on less-defined problems.
A Fall Internship at Ramp: Improving Reimbursements
During a fall internship at Ramp, a backend software engineering intern worked on the reimbursements team and describes projects that improved reimbursement flows while providing full-stack experience. One early change clarified multi-currency mileage reimbursements by showing both the expense currency and the payout currency, while later work overhauled mileage support with live navigation storage, frequent-trip recommendations, commute deductions, and automatic e-receipts. The post also discusses using LLMs to predict merchant categories from receipt text, enhancing merchant matching, and adding monitoring and alerts for OCR categorization errors. The reflection emphasizes measuring feature usage and outcomes, writing and revising specifications before implementation, leaving reusable code, and using Ramp’s transparent documentation and collaborative support. The internship concluded with a return to the University of Waterloo planned for 2025.
Behind the Scenes - A Glimpse into Tax Calculations
As jurisdictions increasingly require marketplaces to collect and remit tax, Etsy describes the infrastructure it uses to calculate, record, and report taxes on transactions. When a buyer adds an item to a cart, Etsy sends a Quotation Request API call to Vertex, using buyer and seller locations, product category, tax rules, and mappings to determine the amount shown. At checkout and throughout fulfillment, DistributeTaxRequest SOAP calls carry order, cancellation, and refund details to Vertex, whose records support reporting and audit workflows imported into Etsy’s bigdata. The integration also required mapping Etsy taxonomy categories to Vertex rule drivers and separating quotation, distribution, and reporting workloads across multiple instances for horizontal scaling and load balancing. Shadow requests, ramped gradually without applying calculated taxes to carts, let the team simulate added Vertex load and monitor checkout performance before releasing traffic-increasing features.
Operationalizing Macaroons
Operationalizing Macaroons at Fly.io requires treating them as online-stateful bearer tokens whose nonces must be checked against database state, while keeping root secrets away from the primary API cluster. The team built tkdb, a roughly 5,000-line Go service backed by encrypted SQLite managed with LiteFS and Litestream, deployed on isolated hardware across the US, Europe, and Australia. Its HTTP/Noise interface supports verification and restricted signing, while FlyCast routing, retries, and client-side caching reduce the impact of unreliable global connectivity; verification caching exceeds 98%. Revocation uses blacklist state, and third-party caveats let services such as flyd obtain narrowly scoped secret-reading authority through tkdb rather than holding broad credentials. OpenTelemetry, standard metrics, and a retained OpenSearch audit trail provide visibility, while the post concludes that Macaroons’ internal infrastructure benefits outweigh limited user adoption.
Building Ramp's MCP server
Ramp built an open-source MCP server that exposes its developer API to LLMs through tools and a SQL interface, enabling natural-language access to business spend data. Using FastMCP in Python and Claude Desktop, the prototype could run analyses, generate visualizations, and issue cards on demand, but pagination struggled beyond a few hundred transactions because of miscalculations, context limits, input sizes, and token use. The team replaced bulk responses with an in-memory ETL that flattens API JSON into SQLite, then exposes load, transformation, and query tools; an OLAP-powered API was added for reporting workloads that caused timeouts. This let Claude analyze tens of thousands of spend events with aggregate and window functions while reducing token usage, although API latency, occasional reliability problems, tool-selection errors, and security risks remain; audit logs, OAuth scopes, and constrained tools provide mitigations, while write actions await a safety framework.
Simplifying JVM App Development with Heroku’s Buildpack Magic
Heroku’s Java buildpacks simplify JVM application deployment by detecting project languages and frameworks, fetching build tools, and configuring runtime settings automatically. They support Spring Boot, Quarkus, and Micronaut by inspecting Maven or Gradle build definitions, packaging applications, selecting framework-specific runner commands, and mapping service variables such as SPRING_DATASOURCE_URL, SPRING_REDIS_URL, DATABASE_URL, and JDBC_DATABASE_URL. In many cases, a Procfile is unnecessary because the buildpack can identify the executable JAR and provide a default web process, while Quarkus and Micronaut receive their respective runner JAR and port settings. Heroku also automatically attaches a lightweight JVM agent for runtime metrics, including memory usage and garbage collection, and offers similar buildpack support for Scala and Clojure through sbt and Leiningen.
Scaling Nextdoor’s Datastores: Part 1
Nextdoor relies on a Django backend connected to monolithic PostgreSQL databases and Redis look-aside caches. Migrating to distributed SQL datastores proved impractical because legacy business logic depends heavily on multi-table joins that could not be rewritten. Intermediate mitigations, including read replicas and data partitioning by severing foreign keys, extended infrastructure runways but left primary databases vulnerable to load bottlenecks. Furthermore, look-aside caching and replica usage introduced data staleness risks, atomicity losses across partitioned databases, and inconsistent cache-population behaviors. To address these limitations, Nextdoor initiated an architecture redesign focused on dynamic query routing to replicas, replica-driven cache hydration, time-bounded eventual consistency, and schema-resilient cache serialization.
Grab AI Gateway: Connecting Grabbers to multiple GenAI providers
Grab AI Gateway is a central access layer connecting Grabbers’ applications to multiple GenAI providers, including OpenAI, Azure, AWS Bedrock, and Google VertexAI. Built as a set of reverse proxies, it centralizes provider authentication, authorization, rate limiting, auditing, and capacity management while presenting a unified OpenAI-style API; users can switch models by changing the model parameter. Exploration keys support short-lived staging experiments, while reviewed use cases can use longer-term service keys, and the gateway exposes embedding, image, audio, fine-tuning, search, and in-house open source models. Shared capacity, dynamic routing, monitoring, cost attribution, and usage records support governance and efficiency, although batch traffic can interfere with latency-sensitive services and provider-specific SDK edge cases require integration testing. More than 3,000 Grabbers have requested exploration keys, and the gateway powers applications including ride-safety audio analysis, content moderation, SQL generation, incident automation, and Slack support.
Tracking customer spend in an omnichannel or multiprocessor environment
Merchants operating across websites, mobile apps, physical stores, and multiple payment processors struggle to connect spending because customers use physical cards, digital wallets, and tokenized methods. Payment Account Reference (PAR), a 29-character alphanumeric identifier introduced by EMVCo, provides a non-financial, non-reversible reference that maps one PAN to multiple tokens without exposing sensitive payment data. Because the PAR is independent of payment method and processor, merchants can link transactions across channels and preserve continuity when a card is replaced with a new PAN. The post presents an omnichannel retail example and describes potential benefits including unified customer profiles, personalization, cross-channel reconciliation, reduced PAN-related PCI burden, and processor flexibility.
Did Semgrep Just Get A Lot More Interesting?
Thomas Ptacek considers whether LLM-driven coding agents could make Semgrep more useful by closing the loop between code generation, execution, and automated repair. He describes Semgrep as a semantics-aware code-search tool whose symbolic variable placeholders and ordinary code can express vulnerability patterns, while noting that teams rarely have time to build extensive rule libraries. Drawing on Cursor’s rules feature, including rules that help organize or generate other rules, he proposes having an agent observe runtime errors, generalize fixes into unit tests, and generate Semgrep rules for the underlying bug. The proposed workflow would test each rule with positive and negative controls, save it, scan the codebase, and fix newly found instances. The post concludes that this adaptive process may be more compelling than predicting every failure in advance.
VSCode’s SSH Agent Is Bananas
VSCode’s remote-editing flow over SSH is examined as a concern for running LLM-driven agent workflows on remote machines. The motivation is to keep iterative code generation and execution away from a development laptop, ideally on a clean-slate Linux instance that starts instantly and cannot damage the host. Unlike Emacs Tramp, which operates through commands on the remote connection, VSCode uses a Bash snippet stager to download an agent, including a binary Node installation. That agent communicates over port-forwarded SSH through a WebSockets connection to the VSCode front end and can browse the filesystem, edit arbitrary files, launch shell PTYs, and persist itself. The author says this raises concerns for development servers and especially production incident work, while noting a custom Fly Machine connection avoids needing this mechanism.
Top topics
- Architecture830
- Performance812
- LLMs648
- Machine Learning617
- Open Source561
- AI Agents542
- AI454
- Developer Experience446
Weekly digest
The best engineering reads, once a week.