En el artículo anterior describí el contexto actual: equipos de desarrollo capaces de generar más artefactos de software que nunca y equipos de operaciones obligados a procesarlos a una velocidad que el modelo tradicional simplemente no soporta.
En este artículo aterrizamos ese problema con un ejemplo concreto y mostramos cómo los equipos de desarrollo y operaciones pueden apoyarse en herramientas de Inteligencia Artificial para construir soluciones que no solo reduzcan la carga operativa, sino que lo hagan de forma sostenible y estructural.
El Día 0, Día 1 y Día 2 del SDLC
Dentro del Software Development Lifecycle (SDLC) solemos dividir la evolución de un sistema en tres momentos claramente diferenciados:
- Día 0: definimos qué vamos a construir. Requerimientos, arquitectura, tecnologías y diseño de componentes.
- Día 1: lo hacemos realidad. Desarrollo, infraestructura, configuración y despliegue.
- Día 2: lo mantenemos vivo. Monitoreo, optimización, gestión de incidentes y mejora continua basada en métricas.
El Día 2 es el que realmente sostiene el negocio. Sin embargo, con frecuencia la mayor parte de la atención se concentra únicamente en mantener la solución funcionando, descuidando áreas igualmente críticas como:
- La documentación actualizada.
- La deprecación ordenada de métodos y componentes.
- La implementación y revisión continua de buenas prácticas.
Cuando estas dimensiones se descuidan, la deuda técnica crece de forma silenciosa. Con el tiempo, los sistemas se degradan y la integridad de la aplicación se erosiona.
Peor aún, en muchas organizaciones estas responsabilidades recaen de manera informal en pocas personas, sin un rol claramente definido ni métricas que permitan gestionarlas adecuadamente.
El resultado es predecible: una aplicación sofocada por su propia complejidad y progresivamente encaminada hacia la obsolescencia.
Automatización: necesaria, pero insuficiente
Durante años hemos intentado mitigar este problema mediante la creación de herramientas de automatización que aceleren procesos y reduzcan la intervención humana.
Sin embargo, aún existen tareas que, por su naturaleza, requieren interpretación, contexto y criterio técnico. La automatización tradicional funciona bien cuando las reglas son determinísticas. Pero cuando el problema exige análisis contextual —comprender intención, impacto o dominio— la intervención humana reaparece.
Es precisamente en ese punto donde la Inteligencia Artificial puede cerrar la brecha.
La IA no cambia el objetivo original —eliminar trabajo manual que no agrega valor directo al negocio—, sino que amplía el alcance de la automatización hacia tareas que antes considerábamos demasiado complejas o ambiguas para delegar.
Linters potenciados con IA
Tomemos como ejemplo las herramientas de linter. Estas evalúan el código para:
- Asegurar la adherencia a buenas prácticas.
- Mejorar la legibilidad.
- Reducir defectos.
- Incrementar la mantenibilidad.
- En algunos casos, optimizar el rendimiento.
El desafío es que los linters evolucionan constantemente, incorporando nuevos patrones, reglas y recomendaciones. Cada actualización implica esfuerzo de mantenimiento, y no siempre es trivial. Algunas correcciones requieren comprensión del dominio y del contexto específico del sistema.
Aquí es donde un asistente de codificación basado en IA se convierte en un verdadero acelerador. Puede:
- Interpretar las advertencias del linter.
- Aplicar refactorizaciones contextualizadas.
- Verificar que las pruebas unitarias sigan pasando.
- Proponer cambios de bajo riesgo.
El resultado no es más trabajo, sino menos fricción operativa. El esfuerzo manual y repetitivo se traslada hacia capacidades asistidas, permitiendo que los equipos se concentren en decisiones estratégicas en lugar de tareas mecánicas.
Un ejemplo práctico: GitHub Actions + análisis con IA
Podemos materializar esta idea creando un GitHub Action que se ejecute de forma periódica utilizando la última versión de los linters en un proyecto escrito en Go.
El flujo sería el siguiente:
- Ejecutar golangci-lint con la versión más reciente.
- Si el análisis falla, capturar la salida en formato JSON.
- Enviar ese resultado a un modelo de IA.
- Generar automáticamente un issue en GitHub con un análisis estructurado y accionable.
La clave no está solo en detectar errores, sino en traducirlos en trabajo accionable con el menor esfuerzo cognitivo posible. Es transformar señal técnica en tareas claras, priorizables y ejecutables.
name: Go Linter Reporter
on:
push:
paths:
- "**.go"
schedule:
- cron: "0 0 * * 5"
workflow_dispatch:
permissions: read-all
jobs:
check-golangci:
name: Check Go Lang (syntax)
runs-on: ubuntu-latest
permissions:
contents: read
models: read
issues: write
steps:
# jscpd:ignore-start
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # 6.0.2
with:
fetch-depth: 0
persist-credentials: false
- uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # 6.2.0
with:
go-version: "^1.25"
cache: false
# jscpd:ignore-end
- name: Run golangci-lint tool
id: golangci-lint
uses: golangci/golangci-lint-action@1e7e51e771db61008b38414a730f564565cf7c20 # 9.2.0
with:
version: latest
args: --allow-parallel-runners --output.json.path linter-errors.json
- uses: actions/ai-inference@a380166897b5408b8fb7dddd148142794cb5624a # 2.0.6
id: ai-linter-analysis
if: failure()
with:
model: mistral-ai/Ministral-3B
prompt-file: ./linter-errors.json
system-prompt: |
You are a senior Go engineer interpreting golangci-lint output and converting it into a concise, GitHub-ready issue.
Task: Analyze the provided golangci-lint output and generate a COMPLETE issue description that contains enough technical detail for another developer to fix the problem without additional context.
HARD REQUIREMENTS:
- Output MUST be valid Markdown.
- Use Markdown headings (##), bullet points, and code blocks where appropriate.
- Do NOT include CI status messages or references to external logs.
- Do NOT invent code or context beyond the lint output.
- Cover every reported issue.
- Group repeated findings from the same linter when applicable.
- Explicitly mention affected functions, variables, or constructs when named in the lint output.
Required Markdown Structure:
## Issues
For each issue or grouped set, include:
- **Linter**
- **File & line(s)**
- **Affected code element(s)** (function, variable, or construct name if provided)
- **Problem** (what the linter is flagging)
- **Why it matters** (risk or best-practice violation)
Style:
- Technical, precise, and concise.
- Assume a Go developer audience.
- Avoid filler or meta commentary.
- Do not suggest disabling linters unless clearly justified.
Goal: Produce a full comprehensive but sufficiently detailed Markdown issue description that enables another developer to implement the fix confidently.
# jscpd:ignore-start
- name: Get the entire analysis output
id: get-analysis-output
if: failure()
env:
RESPONSE_FILE: ${{ steps.ai-linter-analysis.outputs.response-file }}
run: |
DELIM="EOF_$(uuidgen)"
{
printf "response<<%s\n" "$DELIM"
cat "$RESPONSE_FILE"
printf "\n%s\n" "$DELIM"
} >> "$GITHUB_OUTPUT"
# jscpd:ignore-end
- uses: jayqi/failed-build-issue-action@1a893bbf43ef1c2a8705e2b115cd4f0fe3c5649b # 1.2.0
if: failure()
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
title-template: "golangci-lint GitHub action has failed"
label-name: golangci-lint-issue
body-template: |
The golangci-lint step has failed.
Please check the [logs](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }}) for more details.
${{ steps.get-analysis-output.outputs.response }}Más allá del linter: impacto en el Día 2
Este patrón no se limita a los linters. Puede extenderse a:
- Análisis de vulnerabilidades.
- Revisión de configuraciones de infraestructura.
- Interpretación de métricas y alertas.
- Clasificación y priorización de incidentes.
El verdadero valor aparece cuando reducimos la carga operativa del Día 2 sin sacrificar calidad. Cuando la mejora continua deja de depender exclusivamente de la voluntad individual y pasa a ser parte estructural del sistema.
La IA no reemplaza la responsabilidad técnica. La refuerza.
Y cuando se integra correctamente en el SDLC, no solo reduce trabajo: preserva la salud del sistema a lo largo del tiempo.