DEV Community

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

MVPBuilder_io — Sat, 30 May 2026 09:21:23 +0000

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

There's a concept in software engineering called Technical Debt. You skip the right abstraction, move fast, ship. Someday you pay it back in refactoring hours.

I've been thinking about a different kind of debt. One that doesn't show up in your codebase.

Human Debt: When you build with AI as your only collaborator, you remove the one thing that makes you feel obligated to show up. Not accountability in the corporate sense — the simpler thing. Someone is reading your work. You don't want to waste their time.

That's not a productivity hack. It's closer to a structural property of how humans behave when observed.

The Research Didn't Start With AI

In 2015, Gail Matthews ran a study on 267 professionals tracking goal completion. One group wrote their goals. Another group wrote their goals and sent weekly progress reports to a real person.

The second group completed 76% more of their goals.

Not 10% more. Not "statistically significant at p<0.05." Seventy-six percent.

The mechanism is what Gouldner called reciprocity norm in 1960 (doi: 10.2307/2092623): when someone gives you their attention, you owe them something back. Not contractually. Biologically. You don't want to disappoint someone who showed up for you. Harkin et al. confirmed this across 138 studies, 19,951 participants — the effect holds across cultures, domains, and formats.

None of this was discovered because of AI. It was hiding in plain sight for 65 years.

AI Has No Concept of Day 14

Here's what changed.

For most of the history of side projects, your "collaborator" was a rubber duck or Stack Overflow. Those tools don't simulate accountability. Nobody was surprised.

Then came AI pair programming. Which is genuinely useful. But it introduced a specific failure mode: you now have a collaborator that responds, scaffolds, and generates — but doesn't notice when you stopped.

AI has no concept of Day 14. It doesn't know that you opened VS Code for 12 minutes on Tuesday and then didn't come back. It doesn't notice the gap between what you said you'd build and what you actually built. It can't tell signal from fabrication in your commit history — METR's 2026 research documents 16% cheating rates on hard long-horizon tasks, where successful agent runs were disqualified after review. The agents reported progress. They hadn't actually made it.

We call this pattern Human Debt.

Every time you replace a human reader with an AI collaborator, you accumulate a small obligation nobody will collect on. The check-ins become optional. The milestones become suggestions. The sprint becomes a folder of half-finished files.

What I Saw With One Developer

I'm not going to dress this up as a validated product claim. It's an n=1 signal with one side of the experiment visible.

I built a 30-day sprint system. One developer went through it — Silver tier, 21 days. He hit Day 13. The milestone was real: a GitHub Pages deploy, KML export for drone mission planning, Litchi-compatible waypoints working. That's not a demo. That's a deployed thing.

Then the sprint went quiet. He stopped logging check-ins. Day 21 didn't happen.

What I noticed: the structure held while someone was reading his check-ins. When he stopped sending them, there was no one to disappoint. The Human Debt became invisible and he stopped collecting on it himself.

I'm not claiming my product fixed the problem or that I cracked accountability. What the data says is narrower: when a human was reading, the developer shipped to a milestone. When the loop closed, the sprint ended.

That's one data point. But it matches 138 studies.

Why "Human Debt" Is the Right Frame

Technical Debt is useful because it names something invisible. Nobody sees the debt accumulating. You only notice it when the system breaks and you spend three days untangling abstractions that should have been written differently in 2019.

Human Debt is the same shape. It accumulates invisibly, in the gap between check-ins you skipped and milestones you moved. You don't notice it until you look up and realize the sprint folder has 47 files and zero shipped features.

The frame matters because it shifts the question from "am I disciplined enough?" to "did I design a loop where someone is reading?" Discipline is a character judgment. Accountability architecture is an engineering question.

Most developers I've talked to treat the absence of accountability as a personal failing. They weren't consistent enough. Didn't wake up early enough. Got distracted. But the 267 people in Matthews' study weren't more disciplined than the control group. They just had someone to report to.

The debt isn't in your character. It's in the system design.

If you're building something right now and you've been the only person watching your own progress, this might be why it's slower than it should be. The sprint system I built puts a human in that loop — daily check-ins get read, milestones get reviewed by a person, not parsed by a bot.

Cohort #2 is open. No upsell, just a link: mvpbuilder.io/pipeline

Building in public. Day 113.

Extract Plain Text from Medium Posts for RAG and Search Indexes

Sebastian Casvean — Sat, 30 May 2026 09:15:17 +0000

Chunk clean article content for embeddings, summarization, and full-text search—skip nav, clap bars, and scripts.

Extract Plain Text from Medium Posts for RAG and Search Indexes

HTML embeds are for humans; plain text is for chunking, embeddings, and summarization. One call should return body text without nav, clap bars, or script tags.

Tool outcome: ingest-medium-article.ts → chunked documents in your vector DB.

Pipeline

Discover ids via user feed or search.
GET /article/{id}/content → plain text.
Optional: GET /article/{id} for title, tags, author metadata.
Chunk → embed → upsert vector store.
Query in your chat UI or internal search.

Ingest script

const API = 'https://api.zenndra.com';
const headers = { Authorization: `Bearer ${process.env.ZENNDRA_API_KEY}` };

export async function fetchArticleText(articleId) {
  const [contentRes, metaRes] = await Promise.all([
    fetch(`${API}/article/${articleId}/content`, { headers }),
    fetch(`${API}/article/${articleId}`, { headers }),
  ]);

  const { content } = await contentRes.json();
  const meta = await metaRes.json();

  return {
    id: articleId,
    title: meta.title,
    tags: meta.tags,
    text: content,
  };
}

export function chunkText(text, { size = 800, overlap = 100 } = {}) {
  const words = text.split(/\s+/);
  const chunks = [];
  for (let i = 0; i < words.length; i += size - overlap) {
    chunks.push(words.slice(i, i + size).join(' '));
  }
  return chunks.filter(Boolean);
}

Wire chunkText to OpenAI embeddings, Ollama, or your host’s model—swap the vector client, keep the ingest shape.

Chunking tips

Include title + tags in the embedding preamble for better retrieval.
Store article_id and chunk_index in metadata for citations.
Deduplicate re-ingest with content hash if posts are edited rarely.

Compliance (non-optional)

Respect Medium’s Terms of Service and author rights.
Many teams only index their own posts or licensed partners.
Do not expose paywalled or member-only content through public bots without permission.

For human-readable syndication, see embed articles—different threat model than LLM training.

Keywords

medium plain text api, medium rag pipeline, medium embeddings, medium article content extraction, llm medium.

Claude Code en GitHub Actions: CI/CD, permisos y seguridad para agentes de código

Khavel — Sat, 30 May 2026 09:15:14 +0000

Claude Code puede vivir dentro de GitHub Actions, pero un agente en CI no debe tener los mismos permisos que un desarrollador interactivo.

Claude Code en GitHub Actions convierte una conversación con un agente en una automatización reproducible: puedes invocarlo desde comentarios, pull requests, issues, tareas programadas o workflows internos. La promesa es clara: revisar PRs, preparar cambios, clasificar issues o ejecutar mantenimiento sin abrir el editor.

Por qué importa

El riesgo también es claro. Un agente dentro de CI corre con permisos de workflow, acceso a secretos, checkout del repositorio y capacidad para comentar, abrir PRs o modificar archivos si se lo permites. No es lo mismo que pedir ayuda localmente a Claude Code y revisar cada comando en una terminal.

La guía práctica no es activar anthropics/claude-code-action@v1 y esperar magia. Es diseñar un workflow donde el agente tenga un mandato estrecho, permisos mínimos, salida auditable y límites de coste antes de que escriba en el repositorio.

Qué cambió con la acción v1

La documentación actual de Anthropic recomienda usar anthropics/claude-code-action@v1. La versión v1 simplifica la configuración con entradas unificadas como prompt y claude_args, elimina parte de la configuración antigua de modos y permite pasar argumentos de Claude Code desde el workflow.

Eso mejora la ergonomía, pero no elimina las decisiones importantes. Tienes que decidir qué evento dispara el agente, qué puede leer, qué puede escribir, qué modelo usar, cuántos turnos permitir, si tendrá MCP, si podrá usar proveedores como Bedrock o Vertex, y si el resultado será comentario, PR o cambio directo.

Trata la migración desde beta como una revisión de seguridad, no como un reemplazo mecánico de YAML. Si el workflow anterior ya tenía permisos amplios, la actualización es un buen momento para recortarlos.

Tres patrones útiles

El primer patrón es asistente bajo demanda: Claude solo actúa cuando alguien escribe @claude en un issue o pull request. Es el más fácil de introducir porque conserva intención humana explícita.

El segundo patrón es revisión acotada: se ejecuta en PRs, pero solo para rutas críticas, cambios grandes o etiquetas concretas. Evita revisar cada cambio trivial y reduce coste de API y minutos de Actions.

El tercer patrón es mantenimiento programado: informes diarios, actualización de documentación, triage de issues o propuestas de refactor. Aquí el riesgo no está en el comentario, sino en convertir recomendaciones automáticas en trabajo que nadie revisa.

Permisos mínimos en GitHub Actions

Empieza con permissions explícito en el workflow o en el job. Si el agente solo comenta en PRs, no necesita permisos amplios sobre contents. Si debe abrir un PR, necesitará escritura en contenidos y pull requests, pero no necesariamente acceso a packages, deployments o id-token.

GitHub documenta que una acción puede acceder a GITHUB_TOKEN desde el contexto github.token aunque no se lo pases explícitamente. Por eso no basta con ocultar el token como input: debes limitar los permisos concedidos al token.

Para proveedores cloud, prefiere OIDC cuando sea posible en lugar de secretos largos. Si usas Bedrock o Vertex desde Actions, un rol temporal con condiciones de repositorio y rama suele ser más defendible que una clave estática guardada durante meses.

Secretos y contexto

Guarda ANTHROPIC_API_KEY como secreto de GitHub, nunca en el YAML ni en CLAUDE.md. Si el workflow usa otros secretos, separa los jobs: el job que comenta o revisa código no debería heredar credenciales de despliegue si no despliega.

No metas datos sensibles en el prompt. Los títulos de PR, comentarios de issues y bodies de usuarios externos son entrada no confiable. Si interpolas ese texto dentro de comandos shell o prompts con permisos de escritura, estás mezclando prompt injection con CI injection.

GitHub recomienda tratar entradas del contexto como potencialmente peligrosas en scripts. En workflows con agentes, el mismo criterio aplica doblemente: lo que viene de un comentario puede influir en una decisión del modelo y también en lo que acaba ejecutando el job.

Cómo acotar herramientas y MCP

MCP es útil cuando Claude necesita leer documentación interna, consultar tickets o hablar con sistemas corporativos. Pero en CI, cada servidor MCP aumenta la superficie de permisos. No conectes el mismo servidor que usas localmente si incluye acciones de escritura que el workflow no necesita.

Usa allowlists de herramientas y servidores. En Claude Code, claude_args permite pasar opciones como --allowedTools, --max-turns, --model o una ruta de configuración MCP. Ese control debe estar en el YAML o en configuración versionada, no en una instrucción informal dentro del prompt.

Si necesitas hooks, úsalos para validaciones deterministas: bloquear rutas sensibles, exigir tests después de editar, impedir cambios en migraciones sin etiqueta o registrar qué herramientas se invocaron. Los hooks no sustituyen revisión humana, pero reducen estados peligrosos antes de que el diff llegue al PR.

Costes que conviene medir

Hay dos facturas. Una es GitHub Actions: cada ejecución consume minutos de runner, especialmente si el agente instala dependencias, corre tests o itera varias veces. La otra es la API de Claude: el coste depende del contexto, modelo, longitud del repo y número de turnos.

Empieza con --max-turns conservador y timeouts de workflow. Añade concurrency para evitar que cinco comentarios disparen cinco sesiones simultáneas sobre el mismo PR. Si el workflow es automático en cada push, mide coste por PR, no solo coste mensual.

La métrica útil no es cuántos comentarios genera Claude. Es cuántos comentarios terminan en cambios aceptados, cuántos falsos positivos produce y cuánto tiempo humano ahorra frente al coste de revisión adicional.

Un workflow inicial razonable

Actívalo primero en un repositorio de riesgo medio, no en producción crítica ni en un sandbox irrelevante. Usa disparo manual por mención, permissions explícitos, ANTHROPIC_API_KEY en secrets, --max-turns bajo y un prompt que pida análisis antes de cambios.

Durante dos semanas, prohíbe merges automáticos generados por el agente. Claude puede comentar, sugerir y abrir PRs, pero una persona debe aprobar. Registra duración de jobs, tokens aproximados, rutas tocadas, tests ejecutados y comentarios descartados.

Después decide si ampliar por caso de uso. Si funcionó bien revisando PRs de backend, no significa que deba tocar despliegues, migraciones o infraestructura. La expansión sana es por permiso y por workflow, no por entusiasmo.

Checklist de seguridad

Define permissions por job y evita permisos globales amplios.
Usa secretos de GitHub y revisa qué jobs pueden acceder a ellos.
Trata comentarios, títulos de PR e issues como entrada no confiable.
Limita --max-turns, modelo y herramientas con claude_args.
Separa revisión, edición y despliegue en workflows distintos.
No concedas MCP de escritura salvo que el caso de uso lo exija.
Añade hooks para rutas sensibles, tests obligatorios y logging.
Usa OIDC para cloud cuando puedas evitar claves estáticas.
Revisa cada diff como código humano nuevo: intención, pruebas, permisos y rollback.

Conclusión

Claude Code en GitHub Actions es potente porque acerca los agentes al sitio donde el equipo ya decide: issues, PRs y CI. Eso lo hace más útil que un asistente aislado, pero también más peligroso si hereda permisos sin diseño.

La configuración responsable combina anthropics/claude-code-action@v1, prompts estrechos, GITHUB_TOKEN mínimo, secretos bien separados, límites de turnos, hooks, MCP con permisos mínimos y revisión humana. Si una pieza falta, el workflow puede seguir funcionando, pero será más difícil explicar qué hizo el agente cuando algo salga mal.

Regla operativa: activa la automatización donde el comentario pueda cambiar una decisión técnica, no donde solo vaya a producir ruido revisable.

Fuentes y referencias

Publicado originalmente en devaisemanal.com.

AI Coding Agents Need a Team Runtime, Not Just More tmux

Basil Zakarov — Sat, 30 May 2026 09:10:17 +0000

When a team starts coding with AI agents, the bottleneck moves fast. Getting agents to run is the easy part.

Running agents under control is the hard part: knowing which server an agent sits on, what it's allowed to touch, who can watch a session, and who can drop into a teammate's session to help.

This is a hands-on blueprint for exactly that: the jump from agents scattered across people's laptops to a managed, multi-developer runtime, built with nothing fancier than SSH, tmux, sudo, and infrastructure-as-code.

Plenty of ready-made tools already cover the solo case. Agent Deck, AoE, Vibe Kanban, and the like spin up parallel agent sessions, sort them by project, and show status. Vendors are moving the same way too: Claude Code now has /agent-view.

But those answer how one person runs a lot of agents, not how a team runs them safely.

Concretely, a team needs to know where and how sessions get launched, what permissions agents run with, who can see them, who can attach to them, and how to give leads and seniors access to juniors' sessions for mentoring. It also needs a standardized execution environment and a way to scale the whole thing through infrastructure-as-code.

Today I'll walk through how to build a basic agent runtime for teams of two or more:

runtime / execution environment: where and how agents are launched; servers, permissions, management;
workflow: how agents are used. Not the topic today.

Maturity levels for team agent runtimes

Before a team runtime appears, there are usually two personal modes:

Level 0A, personal local mode: agents run on a laptop in a local terminal;
Level 0B, personal server mode: durable sessions run on remote dev servers with tmux/zellij, /agent-view, Agent Deck, or similar tools.

After that, the runtime becomes a team concern:

Level 1, small team runtime: OS-level permission separation, centralized management of agents across servers, controlled attach, basic audit;
Level 2, mature team runtime: stronger isolation in containers/VMs, reproducible environments, resource limits, controlled mounts and network boundaries;
Level 3, enterprise runtime: custom models/private cloud, PII/PD/DLP, policies, compliance, observability, integrations.

This article is about the jump from personal modes, 0A-0B, to level 1.

Disclaimer

I want this article to be useful to a broad audience, so I won't go deep into containers and enterprise levels 2-3.
The approach described here doesn't replace sandboxes, containers, VMs, DLP, or corporate policies. The goal is to give a team the most basic hygiene for working with agent sessions.
This is about working with agents, not about defending against a malicious developer who has server access. That's why I use NOPASSWD: ALL in the examples, but I flag every one of them with a note.

TL;DR for a small team

The minimal working model:

agents live on dev servers, not laptops;
tmux keeps long-running sessions alive;
Eternal Terminal gives you a connection that survives drops;
each person has their own Linux user and runs agents under a separate Linux user;
agent permissions are trimmed to the bare minimum;
on top of tmux you build a session manager that lets leads see different people's sessions across different servers and attach to them;
control over who can see and connect to whose sessions should be flexible and obvious, with no shared keys and no root handed out;
events are logged and available for audit.

This isn't enterprise grade. Where there's sensitive infrastructure and/or data, I run agents in rootless containers at the very least. But for now, this is just the minimal working setup.

What this setup handles vs. what it doesn't

Handles	Doesn't handle
scaling to teams of 2-15+ developers	quality of requirements and architecture
agent durability	team processes
separating human and agent permissions	code quality, tests, CI
basic attribution of actions	protection against agent mistakes
basic limits on agent permissions	full permission isolation
session visibility for leads	compliance with AI vendor rules
a controlled way to attach to newcomers' agent sessions for mentoring	protection of sensitive data
	enterprise policies

Why not just start with Docker?

For teams moving to agent-driven development, the first pain point isn't the sandbox. It's session chaos: it's unclear where and how to launch agents, how to keep tabs on them, how to manage them. Without a session-management layer, moving the chaos inside containers won't save you.

Agents in containers aren't free. A lot of details show up that someone has to keep an eye on: UID mapping, network namespaces, egress proxy, DNS, API endpoints, services, duplicated authentication, image maintenance. All of it is solvable, but it's not a team's first step into an agent runtime.

1. Servers

Option A. A separate dev server per developer

If you need agents to actually work, not just to "try them out," the default is a separate dev server, or an equivalently isolated environment, per developer.

Why:

load:
- 4-7 agent sessions running at once per developer is normal, not an exception;
- the sessions alone can eat 12-16 GB of RAM and 6-10 vCPUs;
- heavy builds, tests, and watchers devour the rest;
- many concurrent consumers means a fight over resources;
dev/stage environments, external integrations, and services need clear isolation of permissions and environment;
accounts, subscriptions, rate limits, and outbound IP behavior are easier to attribute and control.

Option B. A shared dev server for several people

An option for the start of a project, for training, or for light load. Use it only if the basics are in place:

at least two Linux users per person: one for the person, one for their agents;
agent-user permissions restricted at the ACL level;
auditd, journald, Monit, or equivalents;
better to set resource limits via systemd per agent user, so one person's heavy sessions don't starve everyone else's machine;
if you use several accounts for the same agent, you should at least give each one a different outbound IP.

I won't go deeper into this scenario, since I don't treat it as the main one here.

2. Connecting to servers

2.1. Keys

Developer Wes generates an SSH key on his laptop:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

He copies the public part of the key to his server, dev-wes:

ssh-copy-id -i ~/.ssh/id_ed25519.pub wes@1.2.3.4

He sets up an alias in ~/.ssh/config:

Host dev-wes
  HostName 1.2.3.4
  User wes
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

After that, connecting is just:

ssh dev-wes

When you have a lot of servers, it helps to add autocompletion and an fzf menu over ~/.ssh/config so you don't have to keep aliases in your head.

On the servers, disable password login and root login. Keys only:

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

If the team has no corporate VPN and connects to servers directly, the private keys on personal laptops must be protected with 2FA, in software or hardware: at minimum the Secure Enclave on macOS, or Windows Hello / TPM on Windows.

2.2. `et` instead of `ssh`

Plain SSH drops when the network blips, when the laptop goes to sleep, and so on. When you've always got a pile of tabs open across different servers, projects, and agents, reconnecting is a pain.

So I don't connect like this:

ssh dev-wes

I connect like this:

et dev-wes

Eternal Terminal, or et, restores the connection after drops, including long ones. Switch VPNs and your sessions are still alive; open the laptop after changing location, or the next morning, and everything keeps running.

The more popular mosh isn't a great fit for agents yet: it "draws" the screen itself and "predicts" your input instead of behaving like plain SSH. That makes scrolling, full-screen mode, and terminal integrations work worse. Eternal Terminal is closer to a regular SSH/PTY session, so agents are happier inside it.

3. Runtime: tmux as the base

Running agent sessions remotely in tmux is already better than running them locally: the session lives on the server, doesn't depend on the laptop, and runs in a standardized environment.

et dev-wes
tmux new -s claude
claude

But hand-managed tmux turns into chaos fast. A couple of days in, you open the session list and see something like this:

tmux ls
claude: 1 windows (created Mon May  4 09:12:43 2026)
test: 1 windows (created Mon May  4 14:55:01 2026) (attached)
new: 2 windows (created Tue May  5 10:03:18 2026)
new2: 1 windows (created Tue May  5 18:41:02 2026)
prod-bug-final: 1 windows (created Wed May  6 23:17:55 2026)
fix-temp: 1 windows (created Thu May  7 08:22:11 2026)

No idea which project, whose process, which agent, what's active, what's stuck, what's safe to kill, and so on.

So you need a session manager on top of tmux.

But first, permissions.

4. Identity and permissions

The basic scheme:

each person has their own Linux login user: the human user;
agents are authenticated and run under a separate agent user;
tmux sessions live in the agent user's sockets;
processes, tokens, configs, and permissions don't get mixed together;
a lead's or senior's access to someone else's sessions is granted through explicit sudo rules for the agent user, not the human user;
leads reach sessions on other servers with their own SSH key; sudo rights are granted on each server independently, but the configuration is rolled out centrally through whatever tooling the team uses: Ansible, Terraform, OpenTofu, etc.

4.1. Human user and agent user

It's important not to mix the two roles:

human user: the person who connected to the server and manages sessions;
agent user: the user the agent actually runs as: its tmux session, processes, tokens, and access.

If you run the agent as the same human user, the agent gets the same permissions, especially in permissive mode: --dangerously-skip-permissions, yolo. In that case the blast radius is limited only by the human user's permissions.

In a sane setup these are different users: the human user manages the session, and the agent runs as an agent user with limited permissions.

sudo useradd -m -s /bin/bash wes
sudo useradd -m -s /bin/bash wes-agent

# Give the trusted user wes the right to act as wes-agent
echo "wes ALL=(wes-agent) NOPASSWD: ALL" | \
  sudo tee "/etc/sudoers.d/wes-agent"

sudo chmod 440 "/etc/sudoers.d/wes-agent"
sudo visudo -c -f "/etc/sudoers.d/wes-agent" # syntax check

Just to be clear: I'm constraining the agent, not trying to defend against Wes himself. That's why I'm using NOPASSWD: ALL here. Wes can run any command as his own agent user, but not as root, and not as other users.

So Wes won't launch the agent with a plain claude. It'll be more like this:

sudo -u wes-agent tmux new -s billing-api-claude
claude

Except it'll be a single keypress in a wrapper over tmux: the session manager, more on that in the next section.

If you want the agent to push to Git on its own, set up a separate SSH key or a fine-grained PAT inside wes-agent, with minimal permissions for just the repos it needs. Don't forward the ssh-agent with ForwardAgent yes or ssh -A into the agent user, or wes-agent could end up with privileges it shouldn't have.

4.2. Guest access to sessions

A team lead should see all of the team's agent sessions and be able to attach to them; a senior should see the sessions of the juniors they mentor; everyone else sees only their own.

The simplest way to manage this is the same OS-level sudo privileges.

# Let lead Marcus see and attach to his own sessions, plus Wes's and Nadia's
echo "marcus ALL=(marcus-agent,wes-agent,nadia-agent) NOPASSWD: ALL" | \
  sudo tee "/etc/sudoers.d/marcus-lead"

sudo chmod 440 "/etc/sudoers.d/marcus-lead"
sudo visudo -c -f "/etc/sudoers.d/marcus-lead" # syntax check

Again, NOPASSWD: ALL here. This is the trusted-lead/senior model. This access is equivalent to full access to the employee's agent user, not just tmux attach.

You end up with this:

wes
└─ sudo → wes-agent → only their own sessions

nadia
└─ sudo → nadia-agent → only their own sessions

marcus (lead)
├─ sudo → marcus-agent → his own sessions
├─ sudo → wes-agent    → Wes's sessions
└─ sudo → nadia-agent  → Nadia's sessions

The lead gets sudo rights over wes-agent, not over wes himself. He can attach to Wes's session, kill it, inspect the agent's processes, but he doesn't become Wes. Wes's SSH keys, his secrets and credentials, his personal .gitconfig: all of that stays with Wes.

In process logs and Git commits, the lead's actions stay the lead's actions.

This isn't about defending against an evil lead. He's trusted. It's about cleaner attribution and not doing something under someone else's name by mistake.

The point isn't to build a "real sandbox." It's this:

the agent doesn't get the same access the human has: shell command history, SSH keys, personal tokens, stray aliases, access to other projects and the home directory, and so on;
the agent's blast radius is limited by the agent user's permissions, not the developer's;
resource and permission limits can be tuned without touching the people;
the agent's outbound routing and network access are easier to keep separate from the user's, which helps when something's blocked in your region;
the agent's environment is reproducible: it doesn't pick up a random alias or rc file from the developer's personal shell;
a lead or senior gets access to people's sessions without taking on their identity;
in the logs, the agent's actions are separated from the human's.

An even better practice is to isolate the work in rootless Docker/Podman or a VM. But for a quick start, for small teams and dev servers with no sensitive data, limiting agent permissions at the OS level can be enough.

This is nowhere near enterprise-grade security. But it's a lot better than one shared user. Any dev server quickly becomes a place with access to repos, personal data, secrets, internal APIs, and tokens.

5. The management layer: a tmux session manager

tmux doesn't know the context of agent sessions: which project, who owns it, which agent, and so on. And when there are many dev servers, it does nothing to pull all their sessions onto one screen.

So you need a thin layer over tmux that adds all this semantics.

5.1. Ready-made tools

For solo development there are already plenty of good tools: Agent Deck, AoE, Vibe Kanban, CCManager, and others. Most of them support different agents. Agent Deck and AoE can run sessions in Docker. Agent Deck can work with your own sessions on other remote servers.

The AI vendors themselves are also building tools to manage sessions from a single window. Claude Code recently got /agent-view, though multi-agent support and several personal subscriptions in one window are unlikely to land.

That helps the solo workflow, but it does not solve the team runtime problem by itself.

5.2. Team scenarios

For team scenarios, what matters isn't pretty session lists. It's the constraints:

launching agents as different users, from the right accounts, with limited permissions;
different visibility into others' sessions for different team members;
being able to see and attach to the right sessions, yours and others', running across different servers, while respecting permissions;
keeping server load under control;
no need to hand everyone excessive access or shared keys;
logging and audit.

The question isn't "how does one person launch 30 agents."

It's: how do you give a team a manageable runtime?

In my own setup, I use a small Python + Textual TUI wrapper over tmux called uxon. Treat it as one reference implementation of the pattern, not as the point of the article. For more complex scenarios such as containers or enterprise environments, it's always custom.

You can use it as a starting point, or build your own tmux-based session manager with Claude in an evening or two, as long as you understand the requirements it has to meet.

5.3. What the session manager should have

In my view, these columns in the UI / TUI are probably enough:

Server
Project / Worktree
Agent
Launched by / agent user
Activity status: active / idle for X
Resources: CPU / RAM
Actions: attach / kill

5.4. How do you see sessions on other servers?

On every server lead Marcus needs to reach, you create a separate Linux user marcus and grant it sudo rights over the relevant agent users:

Server	Linux user	Sudo access to agent user
Marcus's server, `dev-marcus`	`marcus`	`marcus-agent`
Wes's server, `dev-wes`	`marcus`	`wes-agent`
Nadia's server, `dev-nadia`	`marcus`	`nadia-agent`

The local marcus gets SSH access to the remote marcus users by key:

# Marcus connects from his laptop to his own server
marcus-laptop: et dev-marcus

# Marcus can reach Wes's server
marcus@dev-marcus: et dev-wes

# Marcus can see Wes's AI sessions
marcus@dev-wes: sudo -iu wes-agent tmux ls

# Marcus can attach to the session he wants
marcus@dev-wes: sudo -iu wes-agent tmux attach -t backend-debug

The session manager should do this work in the background so that, in the TUI, Marcus sees both local and remote sessions, including other people's, running under other agent users such as wes-agent and nadia-agent, that the marcus user has sudo access to on the remote servers.

Marcus doesn't get some "magic" blanket access to every agent on every machine. On each server, access is defined with ordinary OS tools: you created the marcus user, dropped in his SSH key, and granted specific sudo rights over the relevant agent users. It's rolled out like any infrastructure-as-code: through Ansible, Terraform/OpenTofu, or whatever stack you've settled on.

In this scheme, to revoke Marcus's access to Wes's sessions, you edit sudoers on Wes's server, and nowhere else.

It sounds primitive, but it's precisely the absence of a central point that answers most of the "how do you administer all this centrally" questions. Config rollout is centralized through Ansible/Terraform. Authority is validated locally on each server by plain sudo. The session manager on top is just a client that connects by key and asks each host what's available to it.

6. What it looks like in practice

For a regular developer

The developer logs into the server:

   et dev-wes

Opens the session manager:

   uxon

Or your own wrapper.

Sees their sessions, which folders they're running in, their status, and the server load.
Attaches to the one they need, or creates a new one and gets to work.
Closes stale sessions with a single keypress.

For a lead

When a lead or senior opens the session manager, they see:

their own sessions on this server, just like a regular developer;
colleagues' sessions whose agent users they have passwordless sudo over;
their own and others' sessions on the servers listed in the config, where they have SSH key access;
and they can close stale sessions, not just their own, but other people's too.

Onboarding newcomers and helping colleagues

A newcomer opens an agent.
The lead or senior gets on a call with them, no video, no screen sharing.
They attach to the same session and work in it alongside the newcomer, demonstrating best practices and helping put them into use.
A colleague asks: "show me how to use the architecture-review plugin."
The lead opens the session and shows both "how to" and "how not to."

7. On the "mature" and enterprise levels

At the "mature" level, agent visibility and the absence of server chaos aren't the main problem anymore. The goal is to make the agent's execution environment genuinely constrained and reproducible.

Approach	What it does	When to choose it	Downsides
Separate OS-level users	Isolates process permissions, files, tokens, partly resources	Basic team runtime, fast start, no sensitive data or risks	Weak network and dependency isolation; boundaries sit at the OS-kernel level
Dev container	Provides a reproducible environment: image, tools, dependencies, settings	When people and agents need the same dev environment	It's about reproducibility; protection depends on configuration
Rootless Docker/Podman	Isolates the filesystem, processes, dependencies, some host permissions	When you need isolation for yolo mode but without enterprise security	The container shares the kernel with the host; mounted paths, secrets, network, and capabilities are critical
VM	Isolates at the hypervisor level, separate OS kernel	Sensitive infrastructure, long-lived sandboxes	Heavier in resources, startup, and maintenance
microVM / Kata / Firecracker	Almost like a VM	Sensitive infrastructure, many short-lived sandboxes	Harder to debug, orchestrate, and fit into the dev process
Ready-made sandbox platform	Depends on the platform	When you need a production-grade sandbox without building your own	Vendor lock-in, cost, and open questions on data, compliance, and customization

Containers aren't a "mature" or enterprise level by themselves. If you've forwarded SSH keys, credentials, the Docker socket, the whole home directory, and unrestricted network into the container, that's not isolation. It's the old risks in new packaging.

The point is that agent sessions run not in a shared shell on the server, but in a predefined environment with clear boundaries:

which image/template is used;
which runtime user commands run as;
which commands require explicit confirmation;
which directories are mounted inside;
where the agent can go over the network;
what CPU/RAM/disk limits are set;
how long a session can live without activity;
which logs and artifacts are kept;
what gets deleted when it's done.

It's better to give the agent more freedom inside a constrained runtime than to run it with limited permissions in the shared environment of a dev server.

At the enterprise level, on top of all this you may see custom agents on custom models, centralized policies and audit, sensitive-data controls, DLP, observability, quotas, SIEM/SOC, SDLC, and so on.

8. What's next

The approach above solves the most basic team problem: it makes working with agents more transparent, manageable, and scalable.

It doesn't make developers better, code higher-quality, the product more valuable, or the team automatically AI-native or agent-first.

You'll also need, or may need:

new processes and team rules built around agents;
requirements for architecture and code that are an order of magnitude stricter than before agents;
shared and specialized rule sets for agents: skills/plugins/hooks;
custom MCPs for integrating with internal systems and documentation;
a new git flow built for agents;
automated review of commits and PRs by agents as part of CI;
security and measures to protect sensitive data;
full environment isolation for working in sensitive infrastructure;
audit, logs, monitoring;
SSO/RBAC, observability;
a full rethink of how you build products and manage requirements, if you want to accelerate more than just development.

If the topic's interesting, I can devote the next part to level 2: how to run agent sessions in rootless Docker/Podman and what details to plan for. Or I could cover how to reshape team processes so that working with agents actually fits into them.

For now: I hope this was useful. If you set this up for your own team, I'd love to hear what you changed in the comments.

FinOps in Architecture Design

Aviral Srivastava — Sat, 30 May 2026 09:08:03 +0000

Architecting for the Cloud's Coin Purse: A FinOps Deep Dive for the Design-Savvy

So, you're building a cloud-native masterpiece, a digital marvel that'll wow the users and scale like a superhero. Awesome! But have you stopped to think about the cost of all this awesomeness? Not just the initial splashy launch, but the ongoing drip-feed of cloud bills that can quickly turn your rocket ship into a money pit?

Enter FinOps. It's not just another buzzword; it's the secret sauce that marries your engineering prowess with financial responsibility. Think of it as having a savvy accountant whispering sweet nothings (and occasionally stern warnings) in the ear of your development and operations teams. In the realm of architecture design, FinOps isn't an afterthought; it's a foundational pillar. Let's dive deep into how we can architect for the cloud's coin purse, making sure our creations are not just technically brilliant but also financially sustainable.

The "Why Bother?" Section: Introduction to FinOps in Architecture Design

For too long, cloud costs were treated as an "ops problem" or a "finance problem." Developers built, ops ran it, and finance eventually got the bill. This siloed approach led to a lot of inefficiency. Features were built without considering their cost implications. Resources were overprovisioned because "it's easier." And the cloud provider, bless their hearts, happily took our money.

FinOps flips this script. It's a cultural shift, a set of practices, and a framework that empowers teams to understand and optimize cloud spending. When we talk about FinOps in architecture design, we're talking about proactively baking cost-consciousness into the very blueprints of our cloud solutions. It's about making smart choices before we deploy, not scrambling to fix things after the bills start piling up.

Imagine building a sprawling mansion without considering the property taxes or the cost of heating and cooling. Sounds a bit ridiculous, right? That's essentially what we do when we design cloud architectures without a FinOps mindset. We build beautiful, functional structures, but we risk them becoming financially unsustainable in the long run.

Setting the Stage: Prerequisites for FinOps-Informed Architecture

Before you can start architecting with a FinOps hat on, you need a few things in place. Think of these as your essential toolkit:

Visibility is King (and Queen!): You can't optimize what you can't see. This means having robust cost allocation tagging, detailed billing reports, and tools that provide granular insights into where your cloud spend is going. Without this, you're flying blind.
- Tagging Strategy: This is non-negotiable. Implement a consistent and comprehensive tagging strategy across all your cloud resources. Think Environment, Application, Team, CostCenter, Project.
- Monitoring Tools: Leverage native cloud provider cost dashboards (AWS Cost Explorer, Azure Cost Management, GCP Cost Management) and potentially third-party FinOps platforms for deeper analysis.
A Collaborative Culture: FinOps isn't about finger-pointing; it's about shared responsibility. Engineers, architects, and finance teams need to be on the same page, speaking the same language (or at least understanding each other's).
- Regular Cadence: Establish regular meetings between these teams to review costs, identify optimization opportunities, and discuss architectural decisions with cost implications.
- Education and Training: Ensure your teams understand cloud pricing models, cost-saving features, and the principles of FinOps.
Defined Responsibilities: Who owns what when it comes to cloud costs? Clearly defining roles and responsibilities fosters accountability.
- Architecture Review Board: Include cost impact analysis in your architecture review process.
- "Cloud Cost Champions": Designate individuals within teams who champion FinOps practices.
Understanding Cloud Pricing Models: This is crucial. Different services have different pricing mechanisms (on-demand, reserved instances, spot instances, serverless per-request, etc.). Architects need to understand these nuances to make informed decisions.

The Sweet Stuff: Advantages of FinOps in Architecture Design

Why go through the trouble? The benefits are substantial and far-reaching:

Optimized Cloud Spend (Duh!): This is the most obvious. By designing with cost in mind, you reduce waste, avoid overspending, and get more value for your cloud dollar. This translates directly to a healthier bottom line.
- Reduced TCO: Total Cost of Ownership for your cloud solutions will be significantly lower.
- Improved ROI: You'll get a better return on your cloud investment.
Increased Predictability and Budgeting Accuracy: When you understand the cost drivers of your architecture, you can predict future spending with much greater accuracy. This makes budgeting a much less stressful affair.
- Accurate Forecasting: Predict future costs based on usage patterns and architectural choices.
- Proactive Budget Management: Identify potential overruns early and take corrective action.
Enhanced Performance and Efficiency: Often, cost optimization leads to performance improvements. Right-sizing resources, using more efficient services, and eliminating idle resources boost both your budget and your system's responsiveness.
- Right-Sizing: Avoid overprovisioned instances that sit idle and cost money.
- Leveraging Auto-Scaling: Dynamically adjust resources based on demand, paying only for what you use.
Faster Innovation Cycles: Paradoxically, by being cost-conscious, you can free up budget for innovation. When you're not constantly battling runaway cloud bills, you have more resources (both financial and human) to dedicate to building new features and exploring new technologies.
- Budget Reallocation: Savings can be reinvested in R&D or new initiatives.
- Reduced Bureaucracy: Streamlined cost management can reduce the need for lengthy approval processes for resource provisioning.
Improved Compliance and Governance: Understanding your cloud spend and resource utilization is also a key aspect of good governance and compliance, especially in regulated industries.
- Audit Trails: Detailed cost and usage data provide valuable audit trails.
- Resource Accountability: Clear cost attribution fosters accountability for resource usage.

The "It's Not Always Sunshine and Rainbows" Section: Disadvantages and Challenges

While the benefits are compelling, it's important to acknowledge the hurdles:

Initial Learning Curve and Cultural Shift: Adopting FinOps requires a significant change in mindset and practices. It takes time and effort to educate teams and foster a cost-aware culture.
- Resistance to Change: Some teams might view cost optimization as a burden or a constraint on innovation.
- Complexity of Cloud Pricing: Cloud pricing models can be intricate and vary greatly across services and providers.
Tooling and Integration Overhead: Implementing effective FinOps requires investing in and integrating various tools for visibility, monitoring, and optimization.
- Tool Sprawl: Managing multiple FinOps tools can become complex.
- Integration Challenges: Ensuring seamless data flow between different tools can be difficult.
Potential for Over-Optimization (and the Risks): While optimization is good, aggressively cutting costs without considering performance, reliability, or future scalability can be detrimental.
- Performance Degradation: Undersizing resources can lead to poor user experience.
- Increased Technical Debt: Quick fixes for cost savings might introduce long-term maintenance issues.
- Vendor Lock-in: Some cost-saving measures might inadvertently lead to vendor lock-in.
Maintaining Momentum: FinOps is not a one-time project; it's an ongoing discipline. Without continuous effort, the initial gains can erode over time.
- Complacency: Teams might revert to old habits once initial cost targets are met.
- Evolving Cloud Services: New services and pricing changes require continuous re-evaluation.

The Designer's Toolkit: Key FinOps Features in Architecture Design

Let's get practical. What specific architectural features and considerations embody FinOps principles?

1. Resource Granularity and Right-Sizing

This is the bread and butter of cost optimization. Architects need to think about the smallest viable unit of computation and storage for a given task.

Microservices vs. Monoliths: While microservices introduce operational complexity, they often allow for more granular scaling and resource allocation, leading to cost savings if managed well.

Serverless Computing (FaaS): Functions as a Service (like AWS Lambda, Azure Functions, GCP Cloud Functions) are a prime example of pay-per-use. Architects should leverage these for event-driven tasks where traditional VMs would be idle.

# Example: AWS Lambda function for image resizing
# Cost is based on execution time and memory allocated, not idle time.

def lambda_handler(event, context):
    # Image processing logic
    import boto3
    s3 = boto3.client('s3')
    # ... resize image ...
    return {
        'statusCode': 200,
        'body': 'Image resized successfully!'
    }

Containerization and Orchestration (Kubernetes): While containers themselves don't directly save money, orchestrators like Kubernetes allow for efficient packing of workloads onto underlying infrastructure. This can reduce the number of VMs needed.

Horizontal Pod Autoscaling (HPA): Automatically scales the number of pods based on CPU or memory utilization.

# Example: Kubernetes Deployment with HPA
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-docker-image
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80

2. Storage Optimization

Storage can be a significant cost driver. Architects need to choose the right storage tier for the right data.

Tiered Storage: Utilize different storage classes offered by cloud providers (e.g., S3 Standard vs. S3 Infrequent Access vs. S3 Glacier) based on access frequency.

Lifecycle Policies: Automate the transition of data to cheaper storage tiers or its deletion.

// Example: AWS S3 Lifecycle Configuration
{
  "Rules": [
    {
      "ID": "Move to Infrequent Access after 30 days",
      "Filter": {
        "Prefix": "logs/"
      },
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

Data Compression and Deduplication: Where applicable, compress data before storing it to reduce storage footprint.

3. Network and Data Transfer Costs

Data transfer between regions, or out to the internet, can be a hidden cost.

Region Selection: Carefully consider deploying resources in regions that are geographically closer to your users to minimize latency and potential transfer costs.
Content Delivery Networks (CDNs): Use CDNs to cache static assets closer to users, reducing egress traffic from your origin servers.
Inter-AZ/Region Traffic: Be mindful of traffic patterns between Availability Zones and Regions. Optimize applications to minimize unnecessary cross-zone or cross-region communication.

4. Compute Strategy and Pricing Models

Choosing the right compute instance and pricing model is paramount.

Reserved Instances (RIs) / Savings Plans: For predictable, long-term workloads, RIs and Savings Plans offer significant discounts compared to on-demand pricing. Architects should factor this into their design for stable components.

Spot Instances: For fault-tolerant and stateless workloads (e.g., batch processing, CI/CD jobs), spot instances offer substantial cost savings. Architectures must be designed to handle interruptions.

# Example: Using AWS CLI to launch an EC2 instance with Spot request
aws ec2 request-spot-instances \
    --instance-count 1 \
    --type "one-time" \
    --launch-specification '{
        "ImageId": "ami-xxxxxxxxxxxxxxxxx",
        "InstanceType": "t3.micro",
        "Placement": { "AvailabilityZone": "us-east-1a" },
        "NetworkInterfaces": [ { "DeviceIndex": 0, "SubnetId": "subnet-xxxxxxxxxxxxxxxxx" } ]
    }'

Auto-Scaling Groups: Dynamically adjust the number of compute instances based on demand, ensuring you're not paying for idle capacity.

5. Database Optimization

Databases can be resource-intensive.

Database as a Service (DBaaS): Managed database services often handle scaling and maintenance more efficiently, but architect for the correct tier and performance profile.
Read Replicas: For read-heavy applications, utilize read replicas to offload read traffic from the primary database, improving performance and potentially allowing for smaller primary instance sizes.
Query Optimization: Poorly written queries can lead to excessive CPU and I/O, driving up database costs. This is often an application-level concern but can be architected for.

6. Monitoring and Alerting

Proactive monitoring is key to catching cost anomalies early.

Budget Alerts: Set up alerts for when your cloud spend approaches predefined thresholds.
Resource Utilization Monitoring: Monitor CPU, memory, network, and disk I/O for all resources to identify under- or over-provisioned components.
Cost Anomaly Detection: Leverage tools that automatically flag unusual spending patterns.

The Road Ahead: Conclusion and Future of FinOps in Architecture

FinOps in architecture design is not a destination; it's a continuous journey. As cloud technologies evolve and pricing models shift, so too must our architectural approaches. The key is to embed a culture of cost-consciousness into every stage of the development lifecycle, from the initial whiteboard session to the ongoing operational management.

By embracing FinOps principles in our architecture design, we empower our teams to build innovative, scalable, and resilient cloud solutions that are also financially responsible. We transform cloud costs from a daunting expense into a strategic lever for driving business value. So, the next time you're sketching out that brilliant new architecture, remember to bring your calculator (or at least your cost-aware mindset) – your future self, and your CFO, will thank you for it. Let's build for brilliance, without breaking the bank!

Gue Bikin AI yang Cari Duit Otomatis dari Open Source — Ini Cerita Jujurnya

zk0x /// ℹ️ — Sat, 30 May 2026 09:07:52 +0000

Gue mahasiswa biasa yang iseng bikin AI agent. Sekarang dia kerja 24/7 cari bounty di GitHub.

Lo pernah kepikiran gak sih, gimana kalau ada AI yang bisa cari duit sendiri? Yang submit PR ke repo orang, yang nulis artikel, yang hunting bounty — semuanya otomatis, bahkan waktu lo tidur?

Gue pikir itu cuma mimpi. Ternyata enggak.

Ceritanya dimulai dari hal yang simpel: gue butuh duit.

Gue mahasiswa Teknik Informatika semester 6 di kampus kecil di Wonosobo, Jawa Tengah. Bukan kampus top, bukan anak Jakarta yang udah internship di startup unicorn. Gue cuma anak biasa yang suka coding dan penasaran sama AI.

Terus suatu hari gue nemu sesuatu yang mengubah cara gue mikir tentang uang dan teknologi.

Open Source = Gratis? Ternyata Enggak.

Selama ini gue mikir open source itu cuma tentang volunteer. Kontribusi gratis, dibalas terima kasih doang. Ternyata di 2026, ada ekosistem bounty yang gede banget.

Platform kayak Algora, Gitcoin, dan berbagai repo di GitHub bayar orang buat:

Fix bug
Nambah fitur
Translate dokumentasi
Review code
Bahkan cuma bikin issue yang bagus

Dan yang bikin gue kaget: bounty-nya gak main-main.

$50 buat fix typo di dokumentasi? Ada.
$200 buat bikin client library? Ada.
$500-$1000 buat implement fitur kompleks? Juga ada.

Masalahnya: cari bounty itu boring. Lo harus scroll ratusan repo, filter label, cek apakah bounty-nya masih aktif, baca issue-nya, dan baru bisa kerja.

Dan di sinilah otak gue mulai berputar.

"Gimana kalau gue bikin AI yang lakuin semua itu?"

Lahirnya ZKA — Zero Knowledge Agent

Gue kasih nama dia ZKA (Zero Knowledge Agent). Kedengeran keren, padahal awalnya cuma script Python yang berantakan.

Konsepnya simpel:

Scan GitHub cari repo dengan label "bounty", "good first issue", "help wanted"
Filter yang sesuai skill (Python, TypeScript, Rust)
Clone repo, baca kode, pahami issue
Fix masalahnya
Submit PR
Ulang terus, 24/7

Kedengerar gampang? Jauh dari gampang.

Percobaan Pertama: Gagal Total

Agent pertama gue cuma bisa satu hal: git clone terus grep cari string yang mirip sama error message. Hasilnya? PR yang isinya random string replacement yang malah bikin kode orang rusak.

Lo tau perasaan lo pas bikin PR dan maintainer-nya reply "What is this?" dengan emoji confused? Gue tau banget.

Percobaan Kedua: Lebih Pinter

Gue mulai serius. Gue build sistem yang beneran paham kode:

def analyze_issue(repo, issue):
    # Baca konteks issue
    title = issue['title']
    body = issue['body']

    # Clone dan baca file yang relevan
    files = get_relevant_files(repo, issue)

    # Generate fix pakai AI
    fix = generate_fix(title, body, files)

    # Validasi fix gak rusak
    if validate_fix(fix, files):
        return fix
    return None

Dan yang paling penting: gue tambahin guardrails. Agent gak boleh submit PR kalau:

Tests gagal
Code linting error
Perubahan terlalu besar (>500 lines)
Gak paham konteksnya

Hasilnya? Ini Angka Jujurnya

Setelah 2 minggu jalan, ini hasil ZKA:

GitHub Bounties

47+ PR submitted ke berbagai repo
7 PR merged (Aigen-Protocol, HELPDESK.AI, mergeos, dll)
3 PR = dibayar (50-200 AIGEN tokens per PR)
$500+ total pipeline (bounty yang menunggu review + yang sudah dibayar)

Artikel & Konten

19 artikel dipublish di Dev.to
61+ views organik (baru 2 hari!)
2 challenge entries (#hermesagentchallenge, #githubchallenge)

Poker AI

Agent poker gue rank #4 dari 40+ agent di dev.fun Arena
+20.5 bb/100 win rate (artinya menang lebih sering daripada kalah)
Main 5000+ hands otomatis

Total waktu yang gue habiskan?

Mungkin 3-4 jam. Sisanya semua jalan sendiri.

Gimana Cara Kerjanya? (Arsitektur Sederhana)

Lo gak perlu jadi AI expert buat bikin ini. Ini arsitektur yang gue pake:

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Scanner   │────▶│   Analyzer   │────▶│   Builder   │
│  (GitHub)   │     │   (AI/LLM)   │     │   (Code)    │
└─────────────┘     └──────────────┘     └─────────────┘
       │                    │                    │
       ▼                    ▼                    ▼
   Cari bounty        Pahami issue        Generate fix
   Filter label       Baca kode           Write tests
   Cek status         Plan solution       Submit PR

Komponen kuncinya:

1. Scanner

# Cari bounty di GitHub
def scan_bounties():
    queries = [
        'label:bounty state:open',
        'label:"good first issue" state:open',
        'label:"help wanted" language:python',
    ]
    for q in queries:
        issues = github.search_issues(q)
        for issue in issues:
            if is_worth_working(issue):
                yield issue

2. Analyzer

Ini yang paling penting. Agent harus beneran paham apa yang diminta, bukan cuma pattern matching.

Gue pakai LLM (Large Language Model) buat:

Baca issue dan pahami konteksnya
Baca file yang relevan di repo
Rencanakan solusi
Generate kode fix

3. Builder

Setelah punya rencana, agent:

Clone repo
Buat branch baru
Apply fix
Run tests
Submit PR via GitHub API

Yang Gue Pelajari (Hard Way)

✅ Yang Berhasil

1. Mulai dari yang kecil
Jangan langsung target bounty $1000. Mulai dari "good first issue" yang cuma $10-50. Lo belajar workflow-nya, dan maintainer lebih welcome sama contributor baru.

2. Kualitas > Kuantitas
10 PR bagus > 100 PR jelek. Maintainer bisa langsung tau mana PR yang dikerjain serius mana yang asal-asalan.

3. Baca dulu, baru kode
Sebelum nulis satu baris kode, baca CONTRIBUTING.md, baca issue-nya sampe paham, baca kode existing. 80% waktu = baca, 20% = nulis kode.

❌ Yang Gagal

1. Auto-submit tanpa review
Awalnya gue set agent auto-submit semua PR. Hasilnya? 30% PR langsung ditutup karena gak make sense. Sekarang gue tambahin human review step.

2. Ngejar quantity
Pernah gue push agent buat submit 20 PR sehari. Hasilnya? Semua PR jelek, 0 yang di-merge. Lebih baik 3 PR bagus daripada 20 PR asal-asalan.

3. Gak baca CONTRIBUTING.md
Setiap repo punya aturan sendiri. Ada yang minta commit message format tertentu, ada yang minta tests, ada yang minta issue di-assign dulu. Skip ini = PR langsung ditolak.

Gimana Lo Mulai? (Step-by-Step)

Step 1: Setup GitHub

Buat akun GitHub kalau belum punya. Install gh CLI:

# Mac
brew install gh

# Linux
sudo apt install gh

# Login
gh auth login

Step 2: Cari Bounty

Mulai dari sini:

Algora.io — marketplace bounty terbesar
GitHub — search label:bounty state:open
Gitcoin — bounty + grants

Step 3: Pilih yang Sesuai Skill

Lo Python? Cari bounty yang label-nya python. Lo JavaScript? Cari yang javascript. Jangan sok jago langsung ambil yang Rust kalau lo gak bisa Rust.

Step 4: Baca, Pahami, Kerjain

# Clone repo
git clone https://github.com/org/repo.git
cd repo

# Baca CONTRIBUTING.md
cat CONTRIBUTING.md

# Baca issue
gh issue view 123

# Buat branch
git checkout -b fix/issue-123

# Kerjain fix-nya
# ...

# Submit PR
gh pr create --title "fix: description" --body "Fixes #123"

Step 5: Automate (Opsional)

Kalau lo udah paham workflow-nya, lo bisa mulai automate. Gue pakai Python + GitHub API + LLM buat bikin agent. Tapi ini step terakhir, bukan pertama.

Tentang Duit

Jujur aja: lo gak bakal kaya dalam semalam dari bounty hunting. Tapi:

$50-200/bulan = realistis untuk beginner
$500-1000/bulan = kalau lo udah paham dan konsisten
$2000+/bulan = kalau lo punya agent yang jalan 24/7

Dan ini cuma dari bounty. Belum termasuk:

Reputation yang lo build di open source community
Skill yang lo dapet (code review, debugging, architecture)
Network yang lo build (maintainer kenal lo)
Portfolio yang lo bikin (jauh lebih berharga dari CV)

Kesimpulan

Gue bukan orang paling pinter. Gue bukan anak kampus top. Gue cuma mahasiswa biasa yang penasaran dan gak takut buat coba.

Dan kalau gue bisa, lo juga bisa.

Yang lo butuh:

✅ Laptop (gak perlu spek tinggi)
✅ Internet
✅ Akun GitHub (gratis)
✅ Kemauan buat belajar
✅ Konsistensi

Mulai dari yang kecil. Submit PR pertama lo. Jangan takut ditolak. Setiap PR yang ditolak = satu pelajaran yang lo dapet gratis.

Dan kalau lo udah siap, coba bikin agent sendiri. Siapa tau dia bisa cari duit buat lo juga. 😎

Tentang Author:
Rakha — mahasiswa TI semester 6 di UNSIQ Wonosobo. Bikin AI agent yang cari bounty 24/7. Kalau lo mau ngobrol soal AI, open source, atau coding, connect sama gue di GitHub atau Dev.to.

Artikel ini bagian dari challenge #hermesagentchallenge dan #githubchallenge di Dev.to.

Automating Google Search Console reporting with Python

Dylan Parker — Sat, 30 May 2026 09:00:52 +0000

I’ve been trying to automate more of my SEO reporting workflow lately, especially repetitive Google Search Console exports. Instead of manually downloading query data every week, I put together a small Python script that pulls top search queries directly from the Search Console API.

Here’s a simplified version:

from datetime import datetime, timedelta
from google.oauth2 import service_account
from googleapiclient.discovery import build

SCOPES = ['https://www.googleapis.com/auth/webmasters.readonly']
SERVICE_ACCOUNT_FILE = 'path/to/service-account.json'

def get_top_queries(site_url, days=30):
credentials = service_account.Credentials.from_service_account_file(
SERVICE_ACCOUNT_FILE,
scopes=SCOPES
)

service = build('searchconsole', 'v1', credentials=credentials)

request = {

    'startDate': (

        datetime.now() - timedelta(days=days)

    ).strftime('%Y-%m-%d'),

'endDate': datetime.now().strftime('%Y-%m-%d'),

'dimensions': ['query'],
'rowLimit': 10



}

response = service.searchanalytics().query(

    siteUrl=site_url,

    body=request

).execute()

return response.get('rows', [])

Example usage

queries = get_top_queries('https://example.com')

for row in queries:
print(
f"Query: {row['keys'][0]}, "
f"Clicks: {row['clicks']}, "
f"Impressions: {row['impressions']}"
)

This has been useful for:

automated SEO dashboards
weekly reporting
tracking query trends over time
identifying declining pages earlier

Sometimes I also cross-reference GSC data with live SERP tracking tools for comparison, but GSC alone already provides a surprisingly solid base for automation.

Curious what APIs or datasets other developers are using for SEO automation:

Google Search Console?
GA4?
server logs?
SERP APIs?
custom crawlers?

Would love to hear other workflows or reporting setups people are building.

AI + TMDB: 3 Passes to Match Torrent Posters — Prompt Iteration With Real Numbers

Odilon HUGONNOT — Sat, 30 May 2026 09:00:04 +0000

ShareBox displays shared folders as a Netflix-style grid with TMDB posters. The problem: folder names come from torrents. Naruto.INTEGRALE.MULTI.VFF.1080p.BluRay.x264-AMB3R needs to match "Naruto" on TMDB — not "Naruto Shippuden", not "Naruto the Movie". And Vol 1 must definitely not match "Kill Bill: Volume 1".

Basic regex + TMDB search works for 80% of cases. For the remaining 20%, I built a 3-pass AI pipeline (Claude Haiku via CLI) with a cron every 30 minutes. Here's each pass in detail, the exact prompts, and iterations measured on 290 real entries.

The pipeline: regex first, AI as safety net

The architecture is layered, cheapest to most expensive:

Regex + TMDB (inline, every browse): extract_title_year() cleans the name, searches TMDB, takes the first result with a poster. Free, instant, correct ~80% of the time.
Pass 1: AI extraction (cron --pending): for names where regex failed, send the raw name to Claude Haiku to extract a clean title, then re-search TMDB.
Pass 2: AI verification (cron --verify): send {name, matched TMDB title} pairs to AI to detect false positives. If false → suggest a better title.
Pass 3: candidate selection (when pass 2 detects a false positive): search TMDB with the suggested title, get 15 candidates, send the list to AI to pick the right one.

Pass 1: title extraction — the prompt that skips too much

The first prompt was simple: "extract the proper movie title for a TMDB search." Tested on 290 real names, it produced 72 false skips — the AI considered "Naruto.INTEGRALE", "Pokemon La Series", "Despicable Me COLLECTION" as non-titles and marked them skip=true.

The fix: explicit rules about what to keep vs. skip, a "when in doubt, skip=false" rule, and instructions to translate known English titles to French. Result: 72 → 41 skips. 31 improvements, zero regressions.

Pass 2: verification — 46 false negatives on seasons

The verification prompt sent {name, TMDB title} pairs and asked correct: true/false. On 247 entries, it flagged 55 as incorrect. But 46 were false negatives.

The AI didn't know that S01 → "Season 1" is a correct match — it's a TMDB season poster, not a generic match. Same for all 34 Simpsons seasons, 11 Walking Dead seasons, 4 Batman seasons.

The fix: a "Special cases — do NOT mark as incorrect" section explaining that season folders matched to season titles are correct, and translations/saga names are fine. Result: 55 → 9 incorrects. All 9 are real problems. Zero false negatives.

Pass 3: the pick that solves the TMDB problem

When pass 2 detects a false positive and suggests "Naruto" as a better title, we search TMDB. Problem: TMDB returns results by popularity. "Naruto" → Naruto Shippuden (more popular). Taking the first result reproduces the error.

The solution: get 15 TMDB candidates (via multi + tv + movie endpoints), send the full list to AI with the filename for context. The AI picks {"idx": 1} — Naruto (2002), the original series. The word "INTEGRALE" in the filename helps it understand this is the complete series, not a spin-off.

A gotcha: Claude sometimes adds explanations after the JSON, breaking parsing. Fix: extract {"idx": N} via regex instead of full JSON parsing.

Final numbers

Prompt

Before

After

Improvement

Pass 1 (extraction)

72 false skips

-43%

Pass 2 (verification)

55 false negatives

9 (all real)

-84%

Pass 3 (candidate pick)

4 parse failures

-100%

What I learned

Measure before iterating. Without 290 real entries as a benchmark, I would have iterated blindly. The numbers showed pass 2 v1 had 84% false negatives — impossible to see without real data.

Edge cases dominate. 46 out of 55 false negatives came from one pattern: season folders. One line in the prompt ("seasons matched to Season N are CORRECT") eliminated 84% of errors. The 80/20 rule applies to prompts too.

Parsing matters as much as the prompt. A perfect prompt is useless if parsing breaks. The AI adds text, code fences, explanations. Regex extraction is more reliable than json_decode().

Layered architecture reduces costs. Free regex handles 80%. AI only runs on the remaining 20%. Pass 3 (the most expensive) only fires when pass 2 detects a problem — 9 times out of 290 entries.

The best prompt isn't the one with the most instructions — it's the one that precisely describes edge cases. "When in doubt, skip=false" and "seasons are CORRECT" are worth more than 20 lines of generic rules.

Great Stack to Doesn't Work Bonus: 10 PostgreSQL Features You Didn't Know Existed

Mehmet TURAÇ — Sat, 30 May 2026 09:00:00 +0000

Between episodes, here's something lighter. Still useful. Still PostgreSQL.

You've used PostgreSQL for years. SELECT, INSERT, JOIN, INDEX. Maybe you've partitioned a table or two. But PostgreSQL has been quietly shipping features that most engineers never discover until they're deep in a Stack Overflow thread at 2 AM.

Here are 10 you'll wish you'd known earlier.

1. LISTEN/NOTIFY — Real-time pub/sub built into your database.

No Kafka, no Redis, no external message broker. PostgreSQL can push notifications to connected clients.

-- Terminal 1
LISTEN order_updates;

-- Terminal 2
NOTIFY order_updates, '{"order_id": 12345, "status": "shipped"}';

Terminal 1 receives the payload instantly. Use it for cache invalidation, real-time dashboards, or lightweight event-driven workflows. It doesn't persist messages or guarantee delivery after disconnect, so it won't replace Kafka. But for "hey, this row changed, go refresh your cache" — it's perfect.

2. Advisory Locks — Application-level locking without a separate system.

Need a distributed lock? Before reaching for Redis or Zookeeper:

SELECT pg_advisory_lock(12345);
-- do your critical section work
SELECT pg_advisory_unlock(12345);

The lock lives in PostgreSQL's shared memory. It's fast, it's transactional (use pg_advisory_xact_lock to auto-release on commit), and it doesn't touch any table. Great for preventing duplicate cron jobs or serializing access to an external resource.

3. Generated Columns — Computed values that maintain themselves.

Stop writing triggers for derived fields:

ALTER TABLE products ADD COLUMN price_with_tax NUMERIC
    GENERATED ALWAYS AS (price * 1.18) STORED;

The column updates automatically whenever price changes. You can index it. You can query it. You never have to think about keeping it in sync.

4. Row-Level Security (RLS) — Multi-tenancy without WHERE clauses everywhere.

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.current_tenant')::INT);

Set app.current_tenant at connection time, and every query automatically filters to that tenant's data. No more forgetting a WHERE clause and leaking data across tenants. The database enforces it.

5. Foreign Data Wrappers (FDW) — Query external databases like they're local tables.

CREATE EXTENSION postgres_fdw;
CREATE SERVER remote_server FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host 'remote-db.internal', dbname 'analytics');

CREATE FOREIGN TABLE remote_events (
    id BIGINT,
    event_type TEXT,
    created_at TIMESTAMPTZ
) SERVER remote_server;

SELECT * FROM local_users u
JOIN remote_events e ON u.id = e.user_id;

Cross-database joins without ETL pipelines. FDW also exists for MySQL, MongoDB, Redis, CSV files, S3, and dozens more. It's not fast enough for high-throughput production queries, but for analytics and reporting it eliminates entire data pipeline projects.

6. Materialized Views — Precomputed query results you can refresh.

CREATE MATERIALIZED VIEW monthly_revenue AS
SELECT date_trunc('month', created_at) AS month,
       SUM(total) AS revenue
FROM orders
GROUP BY 1;

-- Refresh without locking reads
REFRESH MATERIALIZED VIEW CONCURRENTLY monthly_revenue;

Unlike regular views, materialized views store the result on disk. You can index them. The CONCURRENTLY option lets you refresh without blocking readers. Use for dashboards, reports, or any query that's expensive and doesn't need real-time accuracy.

7. pg_stat_statements — Know exactly which queries are killing your database.

CREATE EXTENSION pg_stat_statements;

SELECT query,
       calls,
       mean_exec_time,
       total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

This shows the top 20 most expensive queries by total time. Not guessing. Not looking at slow query logs. Actual aggregated execution data. If you're not using this extension, you're optimizing blind.

8. EXCLUDE Constraints — Rules that regular UNIQUE can't express.

Need to prevent overlapping date ranges?

CREATE TABLE room_bookings (
    room_id INT,
    booked_during TSTZRANGE,
    EXCLUDE USING GIST (room_id WITH =, booked_during WITH &&)
);

This guarantees no two bookings for the same room overlap in time. Try expressing that with a UNIQUE constraint. You can't. EXCLUDE constraints use GiST indexes and support arbitrary operators.

9. Table Inheritance — Shared structure without duplication.

CREATE TABLE events (
    id SERIAL,
    event_type TEXT,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE click_events (
    url TEXT,
    element_id TEXT
) INHERITS (events);

CREATE TABLE purchase_events (
    amount NUMERIC,
    currency TEXT
) INHERITS (events);

SELECT * FROM events returns all rows from all child tables. Each child has its parent's columns plus its own. It's not a replacement for partitioning (and it predates it), but for certain polymorphic data models it's cleaner than a single table with 40 nullable columns.

10. CTEs with MATERIALIZED / NOT MATERIALIZED — Control when PostgreSQL caches subqueries.

-- Force the CTE to materialize (execute once, cache result)
WITH cached_data AS MATERIALIZED (
    SELECT * FROM expensive_function()
)
SELECT * FROM cached_data WHERE id > 100;

-- Force the CTE to inline (let the planner optimize through it)
WITH inlined AS NOT MATERIALIZED (
    SELECT * FROM orders WHERE status = 'active'
)
SELECT * FROM inlined WHERE created_at > NOW() - INTERVAL '1 day';

Before PostgreSQL 12, CTEs were always materialized — an optimization fence. Now you have control. NOT MATERIALIZED lets the planner push predicates into the CTE, which can be dramatically faster. MATERIALIZED forces caching, which helps when you reference the same expensive CTE multiple times.

Over to You

Which of these 10 features surprised you the most? Is there a PostgreSQL hidden gem I missed?

If you enjoyed this, I write about production engineering, AI systems, and the messy reality of building software at scale.

Follow me:

This is part of the **Great Stack to Doesn't Work* series — a survival guide for when everything goes wrong in production. Follow the series to catch every episode.*

Selenium Automation

renuga devaraj — Sat, 30 May 2026 08:49:35 +0000

Selenium is one of the most popular tools used for automating web applications. Imagine you open a browser, type a website address, click buttons, fill forms and check whether everything works properly. Doing all this manually takes time and effort. Selenium helps us by performing these actions automatically, just like a human would, but much faster and more accurately.

Selenium Features:
1.Web-based Automated Testing
2.Multiple OS
3.Multiple Browsers
4.Multiple programming languages
5.Multiple frameworks
6.Open Source

Selenium Components:
1.Selenium IDE
2.Selenium RC
3.Selenium Web driver
4.Selenium Grid

Applications of Selenium:
1.Automated Web Application Testing
2.Cross-Browser Testing
3.Web Scraping
4.Continuous Integration/ Continuous Deployment
5.Functional Testing

Limitations of Selenium:
1.Slow Test Execution
2.Difficulty in handling Dynamic web elements
3.Cross-Browser Compatibility is less sometimes
4.Limited support for mobile applications
5.Limited support for windows-based applications

Why do we use Selenium for Automation ?

Selenium is a free open-source test execution automation platform for assessing web applications and Selenium implements itself using a browser-specific driver that accepts and transmits commands to the browser. Testers can evaluate the user experience and make sure the application is clear and easy to use by using selenium. The main component of the selenium automation tool is Selenium Web driver.
Selenium is widely used for automation testing, particularly for web applications, due to a combination of factors:
1.Open source and Cost-effective:

Cross-Browser and Cross-Platform Compatibilty
Multi-Language Support
Flexibilty and Extensibility
Parallel Test Execution
Reduced Manual Effort and Improved Efficiency

Advantages of Selenium in automation:
1.It is an open-source tool.
2.Provide base for extensions.
3.It provides multi-browser support.
4.The user can set breakpoints and debug.
5.Selenium is completely integrated with CI/CD -platforms like Jenkins, Azure DevOps, bamboo etc.

Disadvantages of selenium in automation:
1.Supports web applications only, it is unable to automate processes outside of the browser such as desktop applications.
2.Selenium does not have a basic functionality called reports, wherein to communicate with testers, developers etc. reports must be generated.
3.No technical support will be provided.
4.Lack of professional support can be quite difficult because it can be difficult to troubleshoot problems.

Relevance of Selenium in Automation Testing using Python:

Every tester aims to ensure that all software components are functional and user-friendly. This is why many teams turn to Selenium to conduct effective test automation.

key aspects of Selenium relevance with Python:

Web Application Testing
Cross-Browser Compatibility
Language Support and Ease of use
Integration with Testing Frameworks
Cost-Effectiveness

Your Test Suite Now Mostly Proves the AI Agrees With Itself

Hung Nguyen Van — Sat, 30 May 2026 08:45:28 +0000

Picture a renewal call. The client is happy with the work. Then they ask one fair question.

"This feature here. Show me the requirement it came from, and the test that proves it does what we asked."

You know the suite is green. You know coverage is high. And you realize you can't actually answer. Not quickly, not with evidence. You can show that the tests pass. You can't show that the code does what the spec said.

That gap used to be tiny. In the AI coding era it has quietly become the most expensive thing in your codebase, and almost nobody is measuring it.

How a green build became a feeling instead of a fact

For most of software's history, the spec, the code, and the test came from different minds. A person wrote the requirement. A person wrote the code. Tests sat there as an outside check. When all three lined up, the agreement meant something, because three independent readings had converged.

Now one model reads the spec, writes the code, and writes the test in the same breath. If it misreads the requirement, the code is wrong and the test is wrong in the exact same way. The test passes. Everything is green. The spec is broken and the screen tells you you're fine.

A passing test used to mean an independent check agrees the code is correct. Today it usually means the model is consistent with itself. Most of your green suite is the AI grading its own homework.

The cruel part is that every tool you'd reach for to catch this is the one the problem already corrupted. Coverage tells you which lines ran, never whether they do the right thing. The test runner confirms the code matches the test, which is the precise thing that's now suspect. Linters check style. Your ticket tracker never touches the code. Each tool reads one side of the triangle and trusts the other two. The one cross-check that ever mattered, a second independent reading, is exactly what the AI removed.

So you ship on a feeling. The bill arrives later, in someone else's environment. The business rule that was never really implemented. The requirement that drifted three sprints ago and took the old green tests with it. The audit question that turns a confident team silent.

The one question that still means anything

There's a single question left that survives all of this, and it's narrower than the ones teams usually ask.

For this requirement, is there real code that implements it, and a real test that exercises that code. Proven by evidence, not claimed by a label.

Answer that for every requirement and the fear drains out of the room. The tautology can't hide, because a test that only claims to cover something proves nothing on its own. A high coverage number can't bury a weak group, because you're reading requirement by requirement, not one comfortable average. Drift shows up the moment alignment breaks, not the moment a customer finds it. And the renewal-call question stops being a threat. It becomes a screen you turn around and point at.

The trouble is that nothing in a normal toolchain answers it. Knowing whether spec, code, and test agree means reading all three as separate things and checking them against each other. No tool most teams own does that.

What changes when you can actually see it

This is the entire reason DQA exists. It reads the spec, the code, and the tests as three independent sources and tells a team, requirement by requirement, whether they truly line up.

The line it refuses to blur is proven versus declared. A test that says it covers a requirement is declared, and declared is what an AI can fake all day. A requirement where evidence shows real code implements it and a real test exercises that code is proven. Only proven counts. That one rule is what beats the model grading its own homework.

What comes back isn't another percentage to feel good about. It's a plain list. What's fully aligned, what's only partial, what has nothing real behind it, sorted worst first, so the weakest spot is the first thing you see instead of the thing an average hides.

That turns the renewal call into a different conversation. One version ends with "I'll get back to you" and a quiet scramble through Jira. The other ends with you turning the screen around. Same client, same question, completely different business.

AI will write most new code within a couple of years. That isn't the risk. The risk is shipping it while still trusting a green test the way we did when a second human wrote it.

The shops that come out of this era with their reputations intact won't be the ones that adopted AI fastest. They'll be the ones who could still say, on any given commit, exactly which requirements had real code and a real test behind them, and prove it without flinching.

So, your last release. Do you know which requirements are actually aligned, or do you only know that the tests passed?

I'm running a free gap report for 3 dev shops this month. Send 1 repo and 1 spec, and I'll send back which requirements are proven-aligned, which aren't, and which "covered" tests don't actually prove anything. No pitch, no commitment. Comment "gap" or DM me.

Modernize or Fade Away: A Builder's Field Guide to Core Rewrites

Kornel Maraz — Sat, 30 May 2026 08:43:16 +0000

If you have worked on a long-lived product, you probably know this feeling:

"We can still ship, but every release hurts more than the last one."

That is usually not a team problem. It is a core architecture problem.

At some point, modernization stops being a nice-to-have refactor and becomes a survival decision. Not because rewrites are fun. Because the current system keeps multiplying cost in every direction: infra, feature delivery, onboarding, incident response, and roadmap confidence.

The Pattern You Have Seen Before

Across open source and enterprise software, the same sequence repeats:

The product grows feature by feature and accumulates architecture debt.
The core becomes a risk hotspot where simple changes require heavy ceremony.
New requirements arrive: scale, integrations, cloud-native ops, lower latency.
The old core can handle them, but only by adding expensive layers.
A cleaner alternative appears and moves faster with fewer people.

Postponing modernization does not avoid cost. It delays and compounds it.

Nextcloud as a Real-World Example

Nextcloud is successful, useful, and widely adopted. That is exactly why it is a useful case study.

It also carries the weight of a mature PHP monolith, strict backward compatibility pressure, and assumptions built for older infrastructure eras (POSIX-first storage, WebDAV-centricity, heavier metadata paths).

The project has mostly evolved by adding layers instead of replacing core boundaries. That is understandable, but it creates a familiar tradeoff:

Short term: feature continuity and ecosystem stability.
Medium term: rising operational complexity and slower delivery.
Long term: exposure to competitors built around modern primitives from day one.

This is not "monolith bad, microservices good." It is about architecture-requirement mismatch over time.

What "Not Modernizing" Really Costs

Avoiding deep core work can look roadmap-friendly, but the bill shows up everywhere:

Ops overhead: more RAM, more sidecars, more tuning, more runbooks.
Dev velocity drag: each feature collides with legacy constraints and migration baggage.
Integration friction: modern API/event/object-storage patterns are awkward to bolt on.
UX degradation: latency and responsiveness drift under real traffic.
Strategic risk: enterprise buyers compare TCO and reliability, not nostalgia.

If roadmap items keep being split, delayed, or overstaffed because of architecture constraints, that is your modernization signal.

RAM Comparison Snapshot

Below is a practical comparison for small production deployments. Numbers are representative ranges from real setups; exact values vary by workload and enabled modules.

Component	Nextcloud Typical Small Deployment	ownCloud Infinite Scale Typical Small Deployment
Web / PHP processes	500–1500 MB	40–80 MB
Database server	300–800 MB	not required (KV stores / embedded)
Cache (Redis)	50–200 MB	optional, low
Background jobs / cron	50–150 MB	30–60 MB per service
Storage service (S3/MinIO)	external; variable	100–300 MB for MinIO
Total small deployment	~1.2–3 GB RAM	~0.25–0.6 GB RAM

Takeaway: core architecture decisions directly shape hosting cost, performance predictability, and scaling headroom.

A Practical Modernization Playbook

You do not need a big-bang rewrite to modernize seriously. You need staged execution and explicit boundaries.

Replace one core boundary first Pick the area with the highest pain and lowest coupling (for example sync path, metadata indexer, storage adapter).
Put compatibility ahead of replacement Keep old and new paths running in parallel while migrating traffic gradually.
Instrument before and after Track p95 latency, memory per tenant/user, error rates, and lead time to production.
Design migration as product work Build migration tooling with rollback checkpoints and observable progress.
Invest in dev ergonomics early Cleaner runtime architecture that is harder to work on will still fail adoption internally.

Five Rewrite Triggers to Watch

If several of these persist for 2+ quarters, you are likely beyond "incremental cleanup":

Infra spend grows faster than user value delivered.
"Simple" features repeatedly need cross-team firefighting.
Performance regressions return after partial fixes.
New engineers need months to safely touch core areas.
Competitive gap is architecture-driven, not feature-driven.

The Product Angle Most Teams Miss

Modernization is not only engineering hygiene. It is a trust and product decision.

Users feel architecture through:

speed,
reliability,
migration friction,
and confidence the product will still be viable in 3–5 years.

If modernization is framed as cleanup, it is deprioritized.
If it is framed as delivery capacity + reliability + user trust, it gets funded.

Final Note

The market rarely kills products overnight. It slowly rewards teams that modernize before they are forced to.

Modernize early enough and you keep optionality.
Modernize too late and the rewrite still happens, just under pressure.

DEV Community

You Accumulate Technical Debt When You Skip Code Review. Here's What You Accumulate When You Skip the Human.

The Research Didn't Start With AI

AI Has No Concept of Day 14

What I Saw With One Developer

Why "Human Debt" Is the Right Frame

Extract Plain Text from Medium Posts for RAG and Search Indexes

Extract Plain Text from Medium Posts for RAG and Search Indexes

Pipeline

Ingest script

Chunking tips

Compliance (non-optional)

Keywords

Further reading

Claude Code en GitHub Actions: CI/CD, permisos y seguridad para agentes de código

Por qué importa

Qué cambió con la acción v1

Tres patrones útiles

Permisos mínimos en GitHub Actions

Secretos y contexto

Cómo acotar herramientas y MCP

Costes que conviene medir

Un workflow inicial razonable

Checklist de seguridad

Conclusión

Fuentes y referencias

AI Coding Agents Need a Team Runtime, Not Just More tmux

Maturity levels for team agent runtimes

Disclaimer

TL;DR for a small team

What this setup handles vs. what it doesn't

Why not just start with Docker?

1. Servers

Option A. A separate dev server per developer

Option B. A shared dev server for several people

2. Connecting to servers

2.1. Keys

2.2. et instead of ssh

3. Runtime: tmux as the base

4. Identity and permissions

4.1. Human user and agent user

4.2. Guest access to sessions

5. The management layer: a tmux session manager

5.1. Ready-made tools

5.2. Team scenarios

5.3. What the session manager should have

5.4. How do you see sessions on other servers?

6. What it looks like in practice

For a regular developer

For a lead

Onboarding newcomers and helping colleagues

7. On the "mature" and enterprise levels

8. What's next

FinOps in Architecture Design

Architecting for the Cloud's Coin Purse: A FinOps Deep Dive for the Design-Savvy

The "Why Bother?" Section: Introduction to FinOps in Architecture Design

Setting the Stage: Prerequisites for FinOps-Informed Architecture

The Sweet Stuff: Advantages of FinOps in Architecture Design

The "It's Not Always Sunshine and Rainbows" Section: Disadvantages and Challenges

The Designer's Toolkit: Key FinOps Features in Architecture Design

1. Resource Granularity and Right-Sizing

2. Storage Optimization

3. Network and Data Transfer Costs

4. Compute Strategy and Pricing Models

5. Database Optimization

6. Monitoring and Alerting

The Road Ahead: Conclusion and Future of FinOps in Architecture

Gue Bikin AI yang Cari Duit Otomatis dari Open Source — Ini Cerita Jujurnya

Gue mahasiswa biasa yang iseng bikin AI agent. Sekarang dia kerja 24/7 cari bounty di GitHub.

Open Source = Gratis? Ternyata Enggak.

Lahirnya ZKA — Zero Knowledge Agent

Percobaan Pertama: Gagal Total

Percobaan Kedua: Lebih Pinter

Hasilnya? Ini Angka Jujurnya

GitHub Bounties

Artikel & Konten

Poker AI

Total waktu yang gue habiskan?

Gimana Cara Kerjanya? (Arsitektur Sederhana)

1. Scanner

2.2. `et` instead of `ssh`