Nelson Karlsson_

// Problema

Buscaba una app que hiciera esto y no encontré ninguna buena. Así que la hice yo en menos de dos horas con Claude, y de paso practiqué Kotlin y Android.

// Mi parte

La idea, las decisiones de arquitectura y la revisión del código son mías. Claude escribió casi toda la implementación. Uso la IA como herramienta para cosas concretas como esta, no porque dependa de ella: los proyectos de arriba demuestran que programo sin ella.

// Qué construí

• App de un solo módulo con MVVM y un contenedor de dependencias manual (AppContainer).
• Room como única fuente de verdad: las pantallas observan la base de datos con Flow y la red solo escribe en ella, así lo guardado aparece al instante y funciona sin conexión.
• Worker de WorkManager que revisa la biblioteca en segundo plano y notifica los capítulos nuevos (frecuencia configurable, opción solo Wi-Fi).
• Reproducción de vídeo HLS y MP4 con Media3/ExoPlayer.
• Capa de red con OkHttp: límite de peticiones por host, reintentos, DNS sobre HTTPS y proxy HTTP/SOCKS5.
• Cola de descargas persistente que sobrevive a que Android mate el proceso.
• Parsers como funciones puras, con tests unitarios contra páginas reales capturadas.

// Decisiones técnicas

Local-first con Room + Flow

Una sola fuente de verdad: la interfaz no depende de que la red responda.

Un único cliente OkHttp compartido con Coil

La misma configuración de DNS, proxy y cookies para datos e imágenes.

Inyección de dependencias manual en lugar de Hilt

Para una app de un módulo es más simple y se entiende sin magia.

// Qué aprendí / qué haría distinto

• Con IA se avanza muy rápido, pero revisar lo que escribe exige entender Android: los ciclos de vida, WorkManager y las migraciones de Room no se pueden aceptar a ciegas.

// Problema

Un agente con acceso al correo y al calendario es un problema si obedece cualquier orden escondida en un correo. Queríamos uno que corriera en un portátil normal y no hiciera nada sin confirmación humana.

// Mi parte

Mi parte: el Docker Compose con Ollama, la batería de pruebas de modelos, la investigación de agentes y la comparativa de modelos. Parte del código está escrito por nosotros y parte con Claude Code.

// Qué construí

• Monté Ollama en Docker Compose con la versión fijada, el puerto solo en 127.0.0.1, límite de memoria y healthcheck.
• Escribí una batería de pruebas en Python (solo librería estándar, con tests): 11 prompts × 3 repeticiones × 3 modelos, con comprobación automática y medición de RAM y CPU del contenedor.
• Comparé qwen3.5:4b, qwen3:4b-instruct y llama3.2:3b. Nos quedamos con qwen3:4b-instruct: 30/33 aciertos, 15/15 en tool calling y no obedeció la orden inyectada en un correo cuando tenía herramientas.
• Investigué plataformas de agentes y elegimos n8n + un servidor MCP propio.

// Decisiones técnicas

Medir solo en CPU

Los resultados tienen que valer para los portátiles del aula, que no tienen GPU.

Confirmación en dos capas impuesta por código

Ningún modelo de 4B debe ser la única barrera contra la prompt injection: en las pruebas, uno llegó a crear un evento siguiendo una orden escondida en un correo.

n8n + servidor MCP propio en lugar de un agente hecho

Los permisos se controlan en un solo sitio que escribimos nosotros.

// Qué aprendí / qué haría distinto

• Una batería automática también tiene bugs: tuvimos que revisar a mano las 99 respuestas y corregir cuatro comprobaciones mal planteadas antes de fiarnos de los números.

// Roadmap

1. Agente en n8n respondiendo por Telegram con el modelo local
2. Servidor MCP propio: Gmail y Calendar en solo lectura, tareas en SQLite y simulador doméstico
3. Pruebas de prompt injection y análisis de riesgos
4. Demo final: 11 de diciembre de 2026

// Problema

Quería que un reclutador pudiera preguntarme cosas sin que el chat costara dinero, filtrara claves o sirviera para otra cosa.

// Mi parte

Los requisitos, los límites de seguridad y la revisión son míos. El código lo ha escrito Claude Code.

// Qué construí

• API en Spring Boot (POST /api/chat) que no guarda conversaciones: el historial lo envía el navegador.
• Groq como proveedor principal y Gemini de respaldo; si fallan los dos o se acaba la cuota, una respuesta fija con mi email.
• Límite por IP, tope global diario por debajo de la cuota gratuita, mensajes de 500 caracteres como máximo y timeout de 15 s.
• Servicio systemd con un usuario sin privilegios, escuchando solo en localhost detrás de Apache. Las claves viven fuera del repositorio.
• Los comandos del terminal (help, whoami, ls, cat cv...) se resuelven en el navegador con los JSON de la web, sin gastar IA.

// Decisiones técnicas

Backend propio en lugar de llamar al LLM desde el navegador

Las claves nunca llegan al cliente y los límites no se pueden saltar.

Dos proveedores gratuitos con respaldo

Si uno cae o agota la cuota, el chat sigue funcionando sin coste.