{"slug": "your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail", "title": "Your Coding Agent Can Read the Code—but Can It See the App Fail?", "summary": "TailFlow, an open-source runtime-verification layer for coding agents, captures local application output and exposes it via an MCP server, enabling agents to observe runtime failures without sending logs to a hosted platform. The tool, developed by ThinkGrid Labs, provides commands for initialization, a daemon, an MCP bridge, and a shell client, allowing agents to query logs, group errors, and verify fixes in a continuous loop.", "body_md": "TailFlow gives coding agents compact, queryable evidence from the applications\n\nthey are changing—without sending local logs to a hosted platform.\n\nCoding agents are increasingly capable of navigating repositories, editing\n\nmultiple files, running tests, and explaining unfamiliar systems.\n\nBut there is still a gap in the typical agent workflow:\n\n**The agent can read the code, but it often cannot see what happens after the\napplication starts.**\n\nA build may pass while the development server fails during startup. A frontend\n\nmay compile but crash during hot reload. A background worker may begin retrying\n\nindefinitely. A Docker container may restart with a configuration error.\n\nIf the agent cannot observe that output, the workflow usually becomes:\n\n```\nagent edits code\n→ checks pass\n→ application fails at runtime\n→ developer notices the terminal error\n→ developer copies the error back to the agent\n→ agent tries again\n```\n\nThat manual handoff is the problem\n\n[TailFlow](https://github.com/thinkgrid-labs/tailflow) is designed to solve.\n\nTailFlow is an open-source, local runtime-verification layer for coding agents.\n\nIt collects output from:\n\nTailFlow then exposes the same bounded runtime view through:\n\nThe goal is not simply to display logs. The goal is to let an agent answer\n\nconcrete questions:\n\nThe resulting loop looks like this:\n\n```\ncapture the stack\n→ establish a baseline\n→ make the change\n→ wait for the runtime outcome\n→ inspect failures\n→ verify the fix\n```\n\nTests remain essential, but they prove only what they exercise.\n\nA passing test suite does not necessarily prove that:\n\nRuntime output contains evidence that static analysis and isolated tests cannot\n\nprovide. TailFlow makes that evidence accessible to the agent without requiring\n\nthe developer to continually watch several terminal tabs.\n\nInstall TailFlow through npm:\n\n```\nnpm install -g tailflow\n```\n\nThis installs four commands:\n\n| Command | Purpose |\n|---|---|\n`tailflow` |\nInteractive TUI and project initializer |\n`tailflow-daemon` |\nRuntime collector and local API |\n`tailflow-mcp` |\nMCP bridge for coding agents |\n`tailflow-logs` |\nShell client for queries and automation |\n\nFrom the root of a project, run:\n\n```\ntailflow init\n```\n\nTailFlow detects common runtime sources, including:\n\n`dev`\n\n, `serve`\n\n, and `start`\n\nscripts in `package.json`\n\nIt then proposes a configuration:\n\n```\nTailFlow v0.3.2\n\nTailFlow found:\n\n  1. process web: pnpm run dev [recommended]\n  2. Docker containers (compose.yml) [recommended]\n  3. file worker: logs/worker.log [recommended]\n\nSelect sources:\n```\n\nAfter selection, TailFlow writes a `tailflow.toml`\n\nfile. Existing configurations\n\nare never replaced unless `--force`\n\nis explicitly provided.\n\nFor noninteractive environments:\n\n```\ntailflow init --yes\n```\n\nYou can also specify sources directly:\n\n```\ntailflow init \\\n  --docker \\\n  --process 'api=go run ./cmd/api' \\\n  --file logs/worker.log\n```\n\nStart the collector:\n\n```\ntailflow-daemon\n```\n\nThe local dashboard becomes available at\n\n[ http://127.0.0.1:7878](http://127.0.0.1:7878).\n\nVerify the connection from another terminal:\n\n```\ntailflow-logs status\ntailflow-logs sources\n```\n\nFor Claude Code:\n\n```\nclaude mcp add tailflow -- tailflow-mcp\n```\n\nFor another MCP-compatible client:\n\n```\n{\n  \"mcpServers\": {\n    \"tailflow\": {\n      \"command\": \"tailflow-mcp\"\n    }\n  }\n}\n```\n\nThe MCP server gives the agent four focused tools.\n\n`list_log_sources`\n\nShows which sources are running, exited, failed, or merely observed.\n\nThis distinction matters. An empty error list does not prove that a service is\n\nhealthy—it may never have started.\n\n`get_recent_errors`\n\nReturns distinct recent failures with occurrence counts and related stack\n\ncontext.\n\nInstead of filling the agent's context window with the same crash 400 times,\n\nTailFlow can condense it into one failure group:\n\n```\nx400 connection refused: postgres:5432\n     at Pool.connect (...)\n```\n\n`search_logs`\n\nReturns exact records with source, severity, time, regular-expression, and\n\ncursor filters. This is useful when exact values or event ordering matter more\n\nthan deduplication.\n\n`wait_for_logs`\n\nWaits inside the daemon until a runtime event appears. An agent can wait for:\n\n```\ncompiled successfully\nserver listening\nmigration complete\nrequest finished\nerror|failed|panic\n```\n\nThis replaces arbitrary sleep-and-poll loops with event-driven verification.\n\nOne of TailFlow's most important features is its cursor model.\n\nEvery captured record receives a monotonically increasing sequence number. The\n\nagent can save the current cursor before making a change and request only\n\nrecords that appeared afterward.\n\n```\nbaseline cursor: 241\n        │\n        ├── edit application code\n        ├── hot reload begins\n        └── wait after cursor 241\n              ├── compilation succeeded\n              └── server ready\n```\n\nThis changes the question from:\n\nAre there errors in the logs?\n\nto:\n\nWhat happened after this specific edit?\n\nTailFlow also reports when the requested cursor has fallen outside its bounded\n\nbuffer. That prevents an agent from presenting incomplete evidence as proof\n\nthat nothing failed.\n\nTailFlow deliberately gives humans and agents access to the same underlying\n\ndata.\n\nDevelopers can use the terminal UI:\n\n```\ntailflow\n```\n\nOr inspect Docker directly:\n\n```\ntailflow --docker\n```\n\nShell-based agents and scripts can query the daemon:\n\n```\ntailflow-logs errors --since 5m\ntailflow-logs search 'timeout' --source api\ntailflow-logs wait --grep 'compiled successfully|Failed to compile'\n```\n\nThe web dashboard provides live following, severity filters, source counts, and\n\nregular-expression search.\n\nThis shared model makes agent behavior easier to audit: the developer can\n\ninspect the same runtime evidence the agent used to reach its conclusion.\n\nTailFlow is not trying to replace production observability platforms.\n\nIt does not provide:\n\nInstead, it focuses on one job:\n\nGive a coding agent timely, compact evidence from the local software it is\n\nchanging.\n\nThe daemon binds to loopback, stores a bounded in-memory buffer, and does not\n\nrequire an account or hosted service.\n\nThat makes it useful during development, but it also creates important\n\nlimitations:\n\nThese boundaries are documented rather than hidden behind a generic “healthy”\n\nresult.\n\nVersion 0.3.2 focuses on reducing setup friction and making the project easier\n\nto understand and operate.\n\nThe release includes:\n\n`tailflow init`\n\nThe broader direction is to make runtime verification a normal step in an agent\n\ncoding loop—not a manual debugging step performed only after the agent declares\n\nsuccess.\n\nPlanned directions include:\n\nTailFlow will remain local-first, bounded for agent context, and explicit about\n\nincomplete evidence.\n\nTailFlow is open source and licensed under MIT.\n\n```\nnpm install -g tailflow\ncd your-project\ntailflow init\ntailflow-daemon\n```\n\nThen connect your coding agent or explore the local dashboard at\n\n[ http://127.0.0.1:7878](http://127.0.0.1:7878).\n\nProject links:\n\nIf your coding agent has ever produced a change that looked correct while the\n\napplication was visibly failing in another terminal, TailFlow is built for that\n\nmissing part of the loop.", "url": "https://wpnews.pro/news/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail", "canonical_source": "https://dev.to/akosidencio/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail-49dc", "published_at": "2026-08-17 14:52:44+00:00", "updated_at": "2026-08-17 15:13:53.002806+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "mlops"], "entities": ["TailFlow", "ThinkGrid Labs", "Claude Code", "MCP"], "alternates": {"html": "https://wpnews.pro/news/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail", "markdown": "https://wpnews.pro/news/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail.md", "text": "https://wpnews.pro/news/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail.txt", "jsonld": "https://wpnews.pro/news/your-coding-agent-can-read-the-code-but-can-it-see-the-app-fail.jsonld"}}