agenteo

I wrote this after seeing the same pattern a few times: AI makes it easy to generate tickets that are better formatted, but not better justified.

I call them “Zombie Barbies” — tickets that look finished on the surface, but don’t clearly connect to a goal, metric, or decision.

The post is mostly practical. It covers 5 ticket templates I use for different kinds of work: feature, non-user feature, bug, spike, and chore. The argument is that a lot of ticket quality problems come from forcing very different kinds of work into the same story format.

I also included the prompt I use with MCP/LLMs to generate tickets from conversation context.

A PM actually used that very flow at my client :D

Input: I just hacked claude code soutions for 4 hours withoutany local testing and pushed a PR and the CI build broke. Now I need actual devs helping figuring out what's wrong.

Output: I’m thrilled to share that I’ve spent the last 4 hours deep-diving into Claude code solutions! In the spirit of moving fast and embracing a "bias for action," I pushed a PR directly without local testing. While the CI build is currently providing some "growth opportunities," I’m now looking to collaborate with my incredible network of developers to troubleshoot and iterate.

Who else loves the thrill of real-time problem solving? Let’s connect and figure this out!

#BuildingInPublic #AgileDevelopment #ContinuousLearning #TechCommunity #ProblemSolving

An LLM without MCP is a brain thinking with its eyes closed.

LLMs are trained on static data, then frozen. Ask one to query your production database or pull yesterday's error logs, and it can't. It's like Mr. Anderson living in the Matrix. It'll make something up that sounds plausible.

The jump from "chatting with AI" to "AI doing work" runs through this. Let your LLM take the red pill.

Product can't tell if prompts improved. Engineering optimizes prompts without clear performance thresholds. The CEO discovers runaway costs too late.

A practical checklist for integrating LLMs into your application: test datasets, evals, cost controls, traces, and version control.

I've been connecting AI agents to production databases via MCP (Model Context Protocol) for product analytics. The problem: when you ask "how many records are running?" the agent sees status values 0, 1, 2, 3 — and guesses which means what. It picked "failed" records instead of "running" and confidently gave the wrong number. The fix was obvious in hindsight: give the agent access to the app source code too. It finds the enum (pending: 0, running: 1, failed: 2, completed: 3) and stops guessing. Blog post walks through real Claude Code conversations showing the before/after, plus setup with DBHub MCP and Repomix for packaging your codebase.