The Agent Ledger #11: Dogfooding, MCP servers, and air-gapped agents

JetBrains makes a point that AI-tool builders should internalize: the team uses IntelliJ, YouTrack, and Rider to build IntelliJ, YouTrack, and Rider. That feedback loop is now more valuable, not less, in an era where most developer tooling ships with an LLM somewhere in the pipeline. Synthetic benchmarks and curated eval sets can hide the failure modes that only surface when an engineer is three hours into a refactor and the autocomplete starts hallucinating a deprecated API.

For teams shipping AI features, the practical takeaway is to treat internal usage as the first evaluation tier and weight it accordingly. A model regression that breaks the daily workflow of ten staff engineers will surface in Slack within an hour. The same regression buried in an offline benchmark may take a release cycle to notice.

The harder question is what to do when your product is not something your engineers naturally use. In that case, dogfooding becomes a deliberate ritual rather than a happy accident, and it needs calendar time, not just good intentions.

Karrot, a Korean second-hand marketplace, used Gemini through Firebase AI Logic to ship an in-app translation feature in under two weeks and saw measurable lift in cross-language transactions. The interesting detail is not the model choice but the integration path: Firebase AI Logic let the mobile team call Gemini without standing up a separate inference backend, auth layer, or rate-limiting service.

This pattern, where a managed SDK collapses what used to be a multi-team project into a single mobile pull request, is becoming the default shape of applied AI work. The risk is that teams skip the parts that used to be forced on them by infrastructure friction: prompt versioning, output logging, cost ceilings, and a fallback when the model is down.

Engineers evaluating these SDKs should ask vendors specifically how they expose request logs, how they handle PII redaction before it reaches the model, and what the migration path looks like if pricing or latency shifts. The two-week build is real. The two-year maintenance bill is the part nobody quotes.

A new PyPI release, recruitment-ai-mcp, bundles three recruiting tasks (job description generation, CV scoring, interview question generation) as Model Context Protocol tools. On its own it is a small package. As a signal, it is more interesting: domain-specific automations are increasingly shipped as MCP servers rather than as SaaS APIs or SDK wrappers.

The shift matters because MCP collapses the integration surface. Instead of writing bespoke glue between an agent and each vendor, an engineer points Claude or another MCP-compatible client at the server and the tools appear. For internal platform teams, this means the unit of reuse for AI capabilities is moving down a level, from application to tool definition.

The near-term watch item is governance. When any team can publish an MCP server and any agent can pick it up, the question of which tools an agent is allowed to call, with what credentials, becomes the new IAM problem. Expect MCP gateways and policy layers to become a category in the next year.

The airgap-devkit package, now at 1.3.4, exists to install and manage developer tools in network-restricted environments. It is unglamorous infrastructure, but it points to a real shift: regulated industries, defense contractors, and increasingly large enterprises want AI-assisted development workflows that do not phone home.

The technical challenge is not just running a model locally. It is reproducing the full developer experience, including package mirrors, model weights, vector indexes, and tool registries, inside a network with no outbound connectivity. Tools like airgap-devkit handle the boring parts of that pipeline, which is exactly why they tend to get ignored until a procurement deadline forces the issue.

For engineers building commercial AI dev tools, the strategic question is whether to support an air-gapped deployment story at all. The answer increasingly is yes, because the customers who will pay enterprise prices are the ones who cannot use a hosted-only product.

A guide aimed at marketers walks non-developers through installing Claude Code and building their first automation. The audience is notable. Claude Code began as a terminal-native tool for engineers, and it is now being pitched as a general-purpose automation builder for anyone willing to open a shell.

This has two implications for software teams. First, the population of people writing scripts that touch production data is about to expand, and the usual guardrails (code review, secret management, repo permissions) were not designed for a marketing manager running an agent that reads from a CRM. Platform teams will need to think about sandboxes, scoped tokens, and audit logs as a product surface, not an internal concern.

Second, the line between a developer tool and a horizontal productivity tool is dissolving. The tools engineers pick this year will likely be the tools their colleagues are using by next year, which raises the bar on defaults. Sensible permissions, clear cost reporting, and reversible actions stop being nice-to-haves once the user base is no longer technical.

Framework M Studio, a visual DocType builder and developer tools package, is a small reminder that low-code is not dead. It is being quietly reshaped by LLMs that can generate, inspect, and modify the underlying schemas. Visual builders fell out of favor when they hit the wall of expressing complex logic. That wall is lower when a model can translate between a diagram and the code it represents.

The interesting design question is which artifact is the source of truth. If the visual representation is canonical, the generated code is disposable. If the code is canonical, the diagram is a view. Most teams today muddle this and pay for it later when the two drift apart.

Engineers evaluating visual or schema-driven tools should pin down that question before adoption. The tools that survive will be the ones with a clear answer and a clean round-trip between representations.

Sartorius is hiring a Senior Machine Learning Scientist to work across modern ML, computer vision, and robotics for lab automation. The specific role matters less than the combination it represents. Companies outside the obvious AI hubs are now staffing teams that expect a single scientist to span perception, control, and applied automation.

For engineers planning their next move, this is a useful tell about where applied AI roles are growing. The work is less about training foundation models and more about wiring them into physical or semi-physical workflows where reliability, calibration, and integration with existing equipment dominate the day-to-day.

The skills that travel well into these roles are not the ones most heavily marketed. Solid software engineering, comfort with sensor data, and patience for the unglamorous integration work tend to matter more than another fine-tuning project on a public benchmark.

Apple is reportedly adding a Create a Pass feature to Wallet that turns arbitrary QR codes into digital passes for tickets, gift cards, and similar artifacts. On the consumer side this is a convenience feature. For developers, it is a new endpoint where structured data flows from the physical world into a managed container on hundreds of millions of devices.

The automation angle is straightforward. Once a pass exists, it can be updated, geofenced, and tied to push notifications. Combine that with an agent that watches a user's email or calendar, and the pipeline from booking confirmation to live, location-aware pass becomes something a small team can build without negotiating with Apple directly.

The constraint, as always with Apple platforms, is the policy layer rather than the technical one. Engineers building on top of this should assume the rules will tighten as soon as the feature gets popular, and design for graceful degradation when a pass type stops being permitted.