Kafka App? There's a Skill for That
Isobel Scott ยท rss ยท 2026-07-30 source โ Reader ๐ฅ๏ธ
Well-built Agent Skills that wrap error-prone Kafka streaming-pipeline work in deterministic, guardrailed automation are worthless until the coding agent reliably recognizes when to invoke them โ so discoverability (matching the developer's actual vocabulary, workflow entry points, and file-touch context) must be engineered as deliberately as the automation itself.
practical ยท mixed โ A first-person engineering case study (narrative: build, fail to get adoption, diagnose, fix) that also argues for a specific architecture (deterministic scaffolding behind a conversational Skill interface) and cites external security research to justify it โ narrative in structure, argumentative in payload.
Structure
| Part | Role |
|---|---|
| Context: Etsy's ML models need fresh Kafka-streamed features/embeddings, and hand-building each streaming app required expertise (schema choice, base-class identification, validation, edge cases, local testing) that static templates couldn't streamline. | context |
| Solution: 'Kafka Skills' โ Agent Skills invoked by natural language or slash command โ let the agent generate code, validate configs, run apps locally, and open PRs, using scaffolding scripts and tools the team built. | evidence (thesis component 1: automation) |
| Observability: a hook-based telemetry system tracks Skill invocations and whether they reach a completed pull request, feeding a BigQuery table. | evidence (measurement infrastructure) |
| 'Build It and They Won't Come': despite a successful demo, adoption was near zero because the coding agent never offered the Skills โ developers' copy-paste habits and team-specific vocabulary didn't match the Skills' natural-language triggers. | complication / turn (thesis component 2: discovery is a distinct problem) |
| Fix: enumerate entry points across vocabularies, lifecycle stages, and copy-paste-shaped requests, plus repository-level routing so touching related files itself triggers the Skill. | resolution |
| Guardrails: keep the agent handling ambiguity while versioned scaffolding scripts execute structured, schema-constrained actions; justified by external research (2023 Stanford study, BaxBench) showing AI-assisted code is less secure while developers feel more confident in it; paired with tightened least-privilege ACLs and deployment controls. | supporting argument for the architecture choice |
| What's Next: seven Kafka workflows covered so far; adoption (not automation) is the stated near-term focus, to be judged by the observability data. | conclusion / open work |
Key terms
- Agent Skills Agent Skills
Reusable playbooks that teach a language model how to execute a specific, bounded task; invoked conversationally or via slash command, and paired with deterministic tools/scripts the team built rather than left to free-form code generation. - entry point
A specific phrasing, vocabulary, lifecycle stage, or file-touch context that should cause the coding agent to recognize and invoke a given Skill โ treated as something that must be deliberately enumerated, not assumed from a single description. - guardrails Guardrails
The architecture of routing the agent's ambiguous, natural-language understanding into structured tool calls that deterministic, versioned, application-owned scripts execute โ as distinct from a security control layered on top afterward.
Propositions
- explicitHand-building a Kafka streaming application required expertise in choosing the right schema, identifying the correct base class, validating input, anticipating edge cases, and running local tests โ a genuinely iterative process that static code templates could not streamline.conf: high
- explicitAgent Skills, invoked via natural language or a slash command, let developers and an LLM collaborate conversationally to generate code, validate configs, run applications locally, and create pull requests for streaming pipelines.conf: high
- explicitRouting the agent's output through versioned scaffolding scripts and validation tools โ rather than free-form code generation โ lets the agent handle ambiguous understanding (the request, the schemas, which validations apply) while deterministic, application-owned code executes the actual work, following the pattern where a structured tool call is returned and executed by code the team controls.conf: highsupportsAccelerating Delivery: How AI Agents Can Own the Initial Code Draft ยท p3 โ Independent real-world case confirming the same architecture: constrain LLM non-determinism by putting hard-coded scripts/tools first and letting the agent handle only the ambiguous orchestration layer.
- explicitA well-built, well-demoed, well-tested set of Agent Skills can still see near-zero real-world adoption โ the failure mode was that the coding agent never offered the Skills to developers during ordinary sessions, not that the Skills themselves were bad.conf: high
- explicitDevelopers' pre-existing habit โ find the closest existing feature, copy its code, modify the fields, engaging the agent mid-task ("copy this class and change it to count cart moves") rather than starting from "I'd like to create a new streaming feature" โ doesn't match a Skill's natural-language trigger phrasing, so the Skill never activates even where it is the better path.conf: high
- explicitRequests for a new feature arrive in whatever internal vocabulary the developer's own team uses (a specific feature-store entry, an internal event name, a parent Java class, an output data type) rather than in the vocabulary encoded into the Skill's description.conf: high
- explicitSkill discoverability can be improved by enumerating multiple entry points across vocabularies, lifecycle stages, and copy-paste-shaped requests, and by adding repository-level routing so that touching related files is itself a trigger, independent of how the request is phrased in natural language.conf: highextendsLessons from building Claude Code: How we use skills ยท p8 โ Real-world evidence that description-based trigger matching (p8's mechanism) under-covers actual request phrasing; Etsy extends it with enumerated multi-vocabulary entry points and repository-level file-touch routing as an additional trigger layer.
- explicitLightweight telemetry โ a hook that fires a 'started' event when a Skill is invoked, and a wrapper that fires a completion event when the agent opens a pull request, both flowing through an existing company event pipeline into a BigQuery table โ lets a platform team measure which Skills are used, how often they reach a PR, and where developers still need support.conf: highextendsLessons from building Claude Code: How we use skills ยท p15 โ Both use a hook that fires on skill invocation to measure usage; Etsy's version adds a second signal (whether invocation reached a completed PR) and routes it through an existing company-wide event pipeline (Kafka + BigQuery) rather than a bespoke log.
- explicitAI-assisted coding measurably degrades code security while increasing developers' confidence in that code's security โ a 2023 Stanford study found this pattern, and BaxBench found that across 392 backend tasks and 11 models, the best model was functionally correct 62% of the time but no model was correct-and-secure on more than 37% of tasks, with roughly half of functionally correct programs exploitable.conf: high
- explicitBecause agents can now run commands and commit code, the surrounding production system needs tightened least-privilege access (Kafka ACLs, repository permissions, deployment controls) so that neither the human nor the agent can delete an important topic, write to an unexpected one, change an unrelated pipeline, or bypass the normal production review path.conf: high
- implicitAutomation quality and discoverability are separable engineering problems: solving the first (building a Skill that works well when invoked) does not solve the second (getting the coding agent to actually invoke it), and a team should budget dedicated design effort for entry points and routing after the Skill itself already works, not assume it follows automatically from quality.conf: high
- implicitHow a system announces its own capabilities to a coding agent (its trigger surface โ description text, slash-command names, file-touch context) is a distinct design problem from the correctness of the capability itself, and is undervalued relative to the effort spent on the capability's internal logic.conf: medium
Arguments
Deterministic, schema-constrained tool execution โ not free-form LLM code generation โ is the right architecture for agent-authored production data pipelines. strength: medium
Explicit premises:
- AI-assisted code is measurably less secure while developers feel more confident in it (Stanford study, BaxBench).
- Kafka Skills route the ambiguous parts of a request (understanding it, identifying schemas/fields, choosing validations) to the LLM, and route the deterministic parts to versioned scaffolding scripts and validation tools.
Implicit premises:
- Determinism and reviewability are more valuable for production streaming infrastructure than the speed gained from letting the agent generate code freely.
- Anthropic's general tool-use pattern (structured tool call executed by application code; strict tool use constraining inputs to a schema) generalizes safely to this specific Kafka-pipeline domain without further validation.
Inferences:
- The same division of labor โ LLM disambiguates, deterministic code executes โ likely generalizes to other coding-agent workflows with well-defined but variable-input pipelines, not just Kafka apps.
Skill discoverability engineering (entry points, vocabulary coverage, repository-level file-touch routing) is a necessary investment separate from building the Skill's internal automation. strength: high
Explicit premises:
- Adoption was near zero after a successful build, demo, and test, because the coding agent never offered the Skills.
- The root cause was that developers' actual request phrasing (mid-workflow, copy-paste-shaped, team-specific vocabulary) didn't match the Skills' natural-language triggers.
- Adding enumerated entry points and repository-level routing was the fix pursued.
Implicit premises:
- Developers will not proactively seek out or learn the name of a new Skill; discovery has to happen through the agent, not through developer initiative.
- Description-based, prompt-text trigger matching alone is insufficient coverage for how requests are phrased in a real engineering org.
Inferences:
- Any team shipping a coding-agent Skill should treat 'how will the agent recognize when to reach for this' as its own explicit design pass, informed by how developers already ask for the underlying task โ not as something that follows from the Skill working correctly once invoked.
Narratives
- "Build It and They Won't Come": the team tested and demoed Kafka Skills and was pleased with the results, then found adoption was near zero; asking developers why revealed they simply didn't know the Skills existed, because the coding agent never surfaced them given how the developers actually phrased their requests.
โ Shows, rather than states, that automation quality and discoverability are distinct problems โ carrying the implicit premise (proposition 11) more persuasively than a bare claim would, since it depicts the team's own surprise at a gap they hadn't anticipated. - The concrete copy-paste example: an engineer, instead of opening with "I'd like to create a new streaming feature," says "copy this class and change it to count cart moves" or asks to "edit this file" using a path lifted from a prior pull request.
โ Illustrates concretely why natural-language and slash-command triggers alone under-match the real vocabulary and workflow shape of requests, motivating the file-touch routing fix.
Questions addressed
- โ
How can Kafka streaming-pipeline development be made faster and less error-prone for engineers without deep Kafka/ML-platform expertise?
Built Agent Skills that scaffold code, validate configs, orchestrate local test runs, and open PRs, covering seven Kafka workflows so far. - โญ How do you get developers to actually use a new internal developer tool built on top of a coding agent?
Diagnosed the cause (agent never offers the Skill given real request phrasing) and applied fixes (enumerated entry points, repository-level routing), but the article explicitly defers the verdict on whether these fixes worked to future observability data. - โญ Does routing agent output through deterministic scaffolding scripts actually make the resulting Kafka applications more secure than the old hand-written process, or does it only reduce a different risk (hallucinated/incorrect code) while leaving the scaffolding scripts and the surrounding review process as an unaudited attack surface?
Gaps
- incompleteThe article never reports whether the discoverability fixes (enumerated entry points, repository-level routing) actually improved adoption โ it explicitly defers this to future observability data ('we'll continue to iterate as we learn'), so the piece's central practical claim (discoverability engineering fixes low adoption) is asserted as a hypothesis, not yet confirmed by the team's own measurement.
Read next: A follow-up Etsy Code as Craft post reporting the observability-table results after the entry-point and routing fixes shipped. - incompleteNo before/after comparison is given between the old hand-written Kafka apps and Skill-generated ones on error rates, review time, or production incidents โ the productivity and security claims rest on general reasoning and cited external research (Stanford study, BaxBench) rather than on Etsy's own data about the pipelines this specific system produces.
Read next: Any Etsy engineering post (or industry study) that measures defect/incident rates for agent-scaffolded infrastructure code against a pre-agent baseline. - incompleteThe guardrails section frames deterministic scaffolding scripts and least-privilege ACLs as what prevents an agent from deleting an important topic or touching an unrelated pipeline, but never addresses whether the scaffolding scripts and validation tools themselves go through the same review and security process as human-written production code โ a bug or compromise in a shared scaffolding script would be inherited by every Skill invocation that depends on it, a single point of failure the deterministic-execution architecture creates but doesn't discuss.
Read next: Material on supply-chain security for the tooling/scaffolding layer that agent-facing tools themselves depend on, as distinct from the agent's own output.
Closes gaps elsewhere
- Lessons from building Claude Code: How we use skills ยท g4 โ That gap complains the 'measuring skills' pattern (a PreToolUse usage-count hook) tracks only how often a skill fires, never whether its output was good. Etsy's telemetry pairs the invocation hook with a second, outcome-oriented signal โ whether the invocation actually reached a completed pull request โ moving one concrete step beyond raw usage-count toward outcome measurement, though it still stops short of defect-rate or rework tracking.
Related documents
- Agent Skills: Google-Backed AI Coding Agent Workflow
- GitHub Copilot CLI Gets Tabs and No-Config-File Tool Setup in Redesigned Terminal UI
- 11) AI-spesial med Vilde Opsal og Anders Sveen
- When Guardrails Go Wrong
- Agent Skills
- Have your agent record video demos of its work with shot-scraper video
- Agentic AI and Code Reviews
- Agentic Engine Optimization (AEO)
- Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules
- Your AI agent just blamed the network team. Now what?