alexei_led

I’ve been thinking about a problem that seems to be getting worse and more visible as we use coding agents more seriously.

An agents can write good quality code today and can make a perfectly reasonable local changes and write tons of new tests. So that everything compiles, the all tests are green, and even the PR looks reasonable and well-written.

But the change may still bypass a module’s contract, reach into another module’s internals, introduce a wrong dependency and break your architecture intention and design. And do this by hundreds of small changes, creating an architecture erosion and converting your code to big ball of mud.

Of course, this isn’t unique to LLM models. People have been doing the same thing for years, especially under delivery pressure. The big difference is speed and about of new code and tests models generate relentlessly. People cannot scale - not in speed and not in code review.

You can try to use well-written prompts, ADR documents, `AGENTS.md`, and code review, and you should, but I’m not sure helpful is this. All these "rules" depend on agent remembering the right thing and following the rule at the right time.

I was looking for a more deterministic approach to keep architecture intent and prevent architecture/design erosion. Unfortunately I did not find the right tool (but I would a lot of helper tools) and I used AI to create meta linter for architecture [archfit](https://github.com/alexei-led/archfit)

The basic idea is to describe the intended module boundaries, compare them with the dependencies that actually exist in the code, and report findings and violations as part of CI or other automation trigger. The checks must be deterministic and not random LLM-based.

I don’t think this as a replacement for a thoughtful architecture review. It’s more like a structural linter that catches some kinds of erosion early.

I’m still trying to figure out where the useful boundaries are:

- Which architecture rules should block CI, and which should only be warnings? - How much configuration is reasonable before the tool becomes a burden? And who is responsible to write this configuration and maintain it over time (imho, this is human role, but ...) - If coupling scores are useful, or not that much? - Can structured reply actually help agents to follow the architecture guidance and respect it?

I wrote a blog with more detailed explanation on Medium:

[https://itnext.io/the-tests-are-green-the-architecture-is-no...](https://itnext.io/the-tests-are-green-the-architecture-is-no...)

And open source the `archfit` project is here:

[https://github.com/alexei-led/archfit](https://github.com/alexei-led/archfit)

I would appreciate any feedback on this approach, any ideas and contribution too.

Hi HN,

I built CCBot (Command & Control Bot) — a Telegram bot that gives you remote control over AI coding agents (Claude Code, OpenAI Codex CLI, Gemini CLI) running in tmux on your machine.

The problem: AI coding agents run in your terminal. When you step away — commuting, on the couch, at dinner — the session keeps working, but you lose visibility and control. Permission prompts pile up. You miss when the agent finishes or gets stuck.

=The approach: CCBot doesn't wrap agent SDKs or create isolated API sessions. It sits on top of tmux. Your agent process stays exactly where it is, in a terminal window. CCBot reads its output (from session transcripts, terminal scraping, and hook events) and sends keystrokes to it. You can tmux attach at any time and pick up where you left off — nothing is abstracted away.

How it works: Each Telegram Forum topic maps to one tmux window running one agent. Messages you type go in as keystrokes; the agent's responses come back as Telegram messages with MarkdownV2 formatting. Interactive prompts (permissions, plan mode, ask-user questions) are rendered as inline keyboard buttons you can tap.

Key features:

- Multi-provider — Claude Code, Codex, and Gemini in the same session. Each topic can run a different agent. Auto-detects provider from running processes. - Interactive UI from your phone — Permission prompts, AskUserQuestion, ExitPlanMode rendered as tap-to-respond inline keyboards. No more returning to your desk just to hit "y". - Real-time monitoring — Live status line, assistant responses, thinking content, tool use/result pairs streamed to Telegram. - Hook-based event system — 5 Claude Code hook event types (SessionStart, Notification, Stop, SubagentStart, SubagentStop) for instant detection — no polling delay for interactive prompts. - Session lifecycle — Directory browser to create sessions, auto-sync for manually created tmux windows, Fresh/Continue/Resume recovery when sessions die, paginated message history. - Terminal screenshots — Capture the current pane as a PNG image, right from Telegram. - Sessions dashboard — Overview of all running sessions with status and kill buttons. - Agent command passthrough — Send /clear, /compact, /cost, or any slash command directly to the agent. - Multi-instance — Run separate bots per Telegram group on the same machine.

Install: `uv tool install ccbot` or `brew install alexei-led/tap/ccbot`

Credits: CCBot started as a fork of https://github.com/six-ddc/ccbot, who created the original Telegram-to-Claude-Code bridge — a clever idea that I immediately wanted to build on. The project has since been rewritten with multi-provider support, topic-based architecture, interactive UI, hook event system, and a 1250+ test suite. Thanks to six-ddc for the original idea and implementation that got this started.

Tech: Python, python-telegram-bot, tmux, pyte (VT100 emulation), structlog. MIT licensed.

Would love feedback — especially from anyone running AI agents on remote machines or headless setups.

I've updated the AWS MCP server to v1.5.6. This project bridges the MCP with the AWS CLI, allowing LLMs to securely interact with AWS services. The intent is to enable secure AI agent operations in AWS environments.

The focus since v1.3.0 has been entirely on host security: 1. Native Sandboxing: Added seatbelt profiles for macOS and constraints for Linux execution. 2. Container Hardening: The Docker image now enforces non-root execution and read-only filesystems. 3. Model: Shifted to a strict IAM + Sandbox + Container architecture.

The goal is to enable "Agentic" workflows with AWS without exposing the local host to arbitrary code execution risks.

Query AWS Spot pricing from your terminal, automate instance selection, and connect to AI assistants - all with one static binary.

*Problem*: No programmatic access to AWS spot instance advisor data without web scraping.

*Solution*: - Single Go binary with embedded AWS data - Works offline - important for CI/CD - Implements MCP for AI assistant integration - No runtime dependencies

*Usage*: ```bash spotinfo --type="c5." --region=us-west-2 --sort=interruption ```

*Design choices*: - Data embedded via `go:embed` for offline use - Regex support for flexible instance matching - Human and machine readable outputs - Same binary serves CLI and MCP modes

*MCP integration*: ```json {"mcpServers": {"spotinfo": {"command": "spotinfo", "args": ["--mcp"]}}} ```

Enables natural language queries while maintaining data accuracy.

Code: https://github.com/alexei-led/spotinfo

What spot instance selection challenges haven't I considered? How could this better fit your automation workflows?

Kubernetes 1.33 introduced in-place Pod resource resizing as a beta feature, enabled by default. You can now adjust CPU and memory allocations for running Pods without restarting them. This eliminates the longstanding requirement to recreate Pods when changing resource requests/limits - a major pain point for stateful workloads and high-availability services. I've published a detailed walkthrough with a copy-paste demo showing the feature in action.

Vertical Pod Autoscaler (VPA) is one of Kubernetes’ most promising tools for optimizing resource usage, but its adoption remains surprisingly low—less than 1%! Why? Because while it’s great on paper, in practice, it comes with a host of limitations: disruptive pod restarts, conflicts with HPA, and a lack of control over when updates are applied.

In my latest blog post, I explore: - Why VPA struggles to gain traction. - The critical limitations holding it back (like pod eviction chaos and OOM roulette). - Emerging solutions like in-place resizing and tools like Goldilocks. - A roadmap for improving VPA, including better update control, advanced scheduling, and applying recommendations beyond pods to higher-level objects like Deployments and StatefulSets.

Whether you’re a Kubernetes enthusiast or someone who’s tangled with autoscaling nightmares, this post dives into the tech, the challenges, and some exciting ideas to make VPA shine.

Check it out here

I've just released Kubernetes MCP Server v1.1.2, an open-source project that connects AI assistants like Claude Desktop to Kubernetes CLI tools (kubectl, helm, istioctl, and argocd).

It enables natural language interaction for managing clusters, troubleshooting issues, and deploying applications—all through validated commands in a secure containerized environment.

Key features: - Execute Kubernetes CLI commands securely - Retrieve detailed documentation for supported tools - Support for Linux command piping for advanced workflows - Secure Docker deployment with multi-architecture support (AMD64/ARM64) - Configurable context and security management

Demo video available on the GitHub repo showcasing how an AI assistant deploys a Helm chart and manages Kubernetes resources seamlessly using natural language commands.

GitHub: https://github.com/alexei-led/k8s-mcp-server

Would love to hear your thoughts or answer any questions!

I've released AWS MCP Server (v1.0.4), an open-source project that lets AI assistants like Claude, Cursor, Windsurf (and other MCP Clients) execute AWS CLI commands through natural language.

Key features: - Execute AWS CLI commands via AI assistants - Support for Linux commands and pipes - Execute commands in isolated Docker container (with AMD64/ARM64 support)