Día 1 de onboarding: cómo CliAI sustituye a "pregúntale al senior por Slack"

La primera semana en un trabajo nuevo es un goteo continuo de preguntas pequeñas y vergonzosas. ¿Cómo se hace tail de logs en este stack? ¿Cuál es la convención para conectar a la BD de staging? ¿Dónde miro cuando un deploy falla? Cualquier senior recuerda haber estado del lado del que pregunta y recuerda recibir esas preguntas cinco años después. El coste es real en ambos lados: el nuevo se siente lento; el senior pierde media hora al día en context-switching.

CliAI no sustituye al mentor. Sí aplana el volumen de preguntas que pueden auto-servirse a casi cero.

Un escenario real de la primera semana

Una nueva ingeniera entra a un equipo backend. Producción corre Kubernetes, staging es un cluster más pequeño, observabilidad va por Loki y Prometheus. Para el miércoles necesita debugar un test flaky que solo falla en staging.

Pregunta 1: "¿Dónde están los logs?"

$ clai stream de logs del deployment api en staging, última hora, solo errores→ kubectl -n staging logs -l app=api --tail=-1 --since=1h \    | grep -i error

El comando muestra la estructura: dónde va el namespace, la convención de label-selector, el flag de ventana temporal. En una semana ejecutando comandos similares, la nueva absorbe el sabor del kubectl del equipo sin que nadie se lo explique.

Pregunta 2: "¿Cómo entro a la BD de staging?"

$ clai port-forward del postgres de staging al 5432 local→ kubectl -n staging port-forward svc/postgres 5432:5432

Aprende no nos metemos por ssh a los pods, hacemos port-forward a los servicios. Una norma del equipo que CliAI saca a la luz natural.

Pregunta 3: "¿Por qué falló el último deploy?"

$ clai eventos del deployment api en staging en los últimos 30 minutos→ kubectl -n staging get events --sort-by=.lastTimestamp \    | grep api | tail -20

Por qué esto bate al runbook

Un runbook es estático. El stack del equipo deriva: alguien migra de Loki a OpenSearch, alguien cambia la convención de namespace, alguien introduce un sidecar de Istio que necesita otro flag de exec. El runbook se queda obsoleto. CliAI genera contra la pregunta, no contra una foto congelada.

Lo que CliAI no puede es explicar el por qué. Te da el kubectl correcto; no le dice a la nueva que staging es el único entorno donde está activo el camino de auth heredado, y por eso el test es flaky. Esa conversación sigue perteneciendo al senior.

Ver también

• Refinar comandos — el onboarding es justo el momento donde la primera respuesta a menudo no termina de cuadrar.
• Documentación — referencia completa para cuando la curiosidad alcanza.