Páxina pillar

Desenvolvemento de software con IA

Proceso contrastado de automatización do desenvolvemento cun equipo de axentes IA — desde a análise de requirimentos, pasando pola codificación e as probas (unitarias, integración, E2E, seguridade, rendemento), ata o despregamento en produción cun rexistro de auditoría completo.

Falemos dun proxecto piloto Os nosos servizos

Dispoñemos dun equipo de axentes IA especializados que participa en cada etapa do ciclo de desenvolvemento de software — desde a análise de requirimentos, pasando polo deseño da arquitectura, a codificación e as probas multicapa, ata a revisión de código, a documentación e o despregamento cun rexistro de auditoría completo.

Deste xeito desenvolvemos os nosos propios produtos de ESKOM AI — a plataforma multiaxente HybridCrew, o sistema de auditorías Compliance, o microservizo KRS+CRBR e diversas integracións. Aplicamos o mesmo proceso en proxectos para clientes: tanto na construción de novos microservizos como na modernización de sistemas legacy.

Este artigo describe como funciona na práctica: que tarefas asumen os axentes e cales quedan no lado humano, que probas executamos e por que este proceso é repetible.

Para que automatizar o desenvolvemento?

Un ciclo clásico de desenvolvemento de software (análise → código → probas → revisión → despregamento) nun equipo maduro adoita levar 2-4 semanas para unha funcionalidade de tamaño medio. A maior parte dese tempo dedícase a tarefas repetitivas: escribir boilerplate, xerar probas unitarias, revisar cambios, actualizar documentación, xerar migracións de base de datos. Todas elas susceptibles de automatización.

O obxectivo do noso proceso é simple: dúas ou tres persoas con axentes IA entregan o valor que antes daba un equipo de 8-10 persoas — sen esgotamento, con mellor calidade (máis probas, mellor revisión de código, documentación completa) e un time-to-market máis curto.

Isto non é „a IA substituirá os programadores". É „os programadores con IA substituirán os programadores sen IA". Os enxeñeiros experimentados seguen sendo imprescindibles — deseñan a arquitectura, toman decisións estratéxicas, revisan os cambios complexos. Os axentes asumen a rutina.

Seis etapas do proceso

Pipeline desde os requirimentos ata a produción. Cada etapa execútana axentes IA especializados, e o humano supervisa e aproba as decisións clave.

Análise de requirimentos e arquitectura

Os axentes IA analizan a documentación de negocio, as conversas co cliente (a partir de transcricións) e o código existente. Propoñen unha arquitectura de microservizos, esquema de base de datos, lista de endpoints e modelo de permisos. Un humano (CTO/arquitecto) revisa e aproba a proposta antes de comezar a codificación.

Escritura de código (TDD)

Primeiro as probas, despois a implementación. Un axente de backend escribe APIs en FastAPI/Express, un axente de frontend compoñentes React. Cada cambio = un pull request separado cun commit lexible. Os estándares de codificación (Black, ESLint, Prettier) son forzados automaticamente.

Probas multicapa

Unitarias (pytest, Jest), integración (testcontainers con PostgreSQL real), E2E (Playwright), UI snapshot, seguridade (OWASP, gitleaks, bandit), rendemento (k6/locust), accesibilidade (axe). Cada PR executa o pipeline completo — proba en vermello = merge bloqueado.

Revisión de código por IA

O axente SecurityReviewer escanea cara ao OWASP Top 10, o axente QualityReviewer comproba lexibilidade e patróns, o axente ArchitectureReviewer verifica a consistencia co resto do sistema. Os casos dubidosos escálanse a un humano.

Documentación e CHANGELOG

Cada cambio na lóxica = subida de versión + entrada no CHANGELOG.md en formato Keep a Changelog. Documentación da API (OpenAPI/Swagger) xerada automaticamente. CLAUDE.md actualizado tras cada sesión con novas leccións aprendidas.

Despregamento con Change Request

O despregamento sempre vai por Git (NUNCA scp directo). Primeiro o ambiente de proba, verificación con Playwright, e só despois a produción tras a aprobación do CR. O script de despregamento inclúe plan de rollback (<5 min) e health checks.

Que gaña a empresa?

Milleiros de probas automáticas

Cada proxecto de produción ten desde varios miles ata decenas de miles de probas — unitarias, integración, E2E, seguridade, rendemento. As regresións detéctanse no CI antes de chegar ao usuario.

Rexistro de auditoría completo

Cada cambio no código, base de datos ou configuración queda rexistrado: Git, audit log na base de datos, CHANGELOG, Change Request. Cumpre os requirimentos de ISO 27001, EU AI Act e RXPD.

Escalabilidade do equipo

Dúas ou tres persoas con axentes IA entregan o valor que antes daba un equipo de 8-10 persoas. Sen esgotamento, con mellor calidade e cronogramas máis curtos.

Escalado a modelos máis potentes

O roteamento LLM escolle o modelo adecuado para cada tarefa: cambios menores — Ollama local (custo $0), arquitectura complexa — Claude Opus. Optimización de custo e calidade nun só.

Repetibilidade e estándares

Cada proxecto aplica os mesmos estándares: feature branch workflow, squash merge, Conventional Commits, CHANGELOG, EU AI Act, RXPD. Un novo desenvolvedor entende a estrutura en un día.

Seguridade por defecto

Gitleaks en pre-commit + CI, segredos en HashiCorp Vault, repositorios privados, SSO Keycloak, Tailscale VPN para servizos internos. Sen concesións no nome da velocidade.

Probas multicapa — o alicerce da calidade

Cada cambio no código de produción atravesa un pipeline completo de probas. Sen excepcións — mesmo a corrección dunha errata nun comentario dispara o CI, porque o pipeline de probas está integrado nun Git hook, e non depende dunha decisión política do desenvolvedor.

Probas unitarias: pytest, Jest, vitest. Comproban funcións e clases individuais. Cobertura >80% para o código crítico.
Probas de integración: testcontainers con instancias reais de PostgreSQL, Redis, Vault. Mocks só para APIs externas de terceiros.
Probas E2E (extremo a extremo): Playwright en Firefox (por defecto), Chrome (opcional). Simulan rutas completas de usuario: login → acción → verificación.
Probas de UI (snapshot, accesibilidade): Playwright + axe-core. WCAG 2.0 AA como baseline, Lighthouse 100/100/100/100 como obxectivo.
Probas de seguridade: OWASP Top 10 (semgrep, bandit, eslint-plugin-security), gitleaks (escaneo de segredos en pre-commit e CI), trivy (escaneo de imaxes Docker).
Probas de rendemento: k6 ou locust para load tests, comprobación dos tempos de resposta p95/p99 baixo carga.
Probas de regresión: suite completa executada antes de cada despregamento en produción. Cada bug reportado convértese nunha proba de regresión.
Probas smoke: conxunto mínimo de 5-10 probas executadas tras o despregamento no ambiente de produción (se a aplicación arrancou en absoluto).
Probas de aceptación: probas de negocio (Cucumber/Gherkin) que confirman que o requirimento foi satisfeito.

Proba en vermello = merge bloqueado. Sen excepcións. Se unha proba é „flaky" (inestable), un axente de diagnóstico analiza a causa e repara a proba ou o código, pero nunca elimina a proba sen decisión humana.

Casos de uso habituais

Os patróns que aplicamos con maior frecuencia. Cada un ten o seu propio conxunto de axentes, ferramentas e modelos. Time-to-value medido en semanas, non en meses.

Modernización de sistema legacy

•Aplicación monolítica antiga (PHP/.NET, sen probas, difícil de manter)
•Os axentes descompoñen o monolito en microservizos (proceso incremental, sen tempo de inactividade)
•Xeran probas de caracterización (captura do comportamento actual) antes da refactorización
•Migración de datos cun rexistro de auditoría completo e plan de rollback

Novo microservizo enterprise

•Especificación na entrada (ticket Jira, documento PRD, transcrición de reunión)
•Arquitectura → código → probas → revisión → despregamento en 2-3 semanas
•Integración con SSO existente (Keycloak), audit log e monitorización
•Cumprimento completo de EU AI Act e RXPD desde a primeira liña de código

Integración de sistemas

•Conexión de ERP, CRM, KRS, Microsoft Graph, IBM, Cisco, socios externos
•Os axentes escriben adaptadores, mapeamentos, retry/backoff, idempotencia
•Probas de integración en endpoints reais (APIs sandbox)
•Monitorización (Prometheus + Grafana) e alertas (Sentry) conectadas automaticamente

Plataformas multi-tenant

•SaaS multi-cliente con illamento total de datos (esquema per-tenant ou row-level security)
•Onboarding de cliente automatizado (provisión de Keycloak, base de datos, roles)
•Facturación baseada en SSO Billing SDK (seguimento de tokens, fail-open)
•Compliance: RXPD, ISO 27001, EU AI Act listos para auditoría

Comparativa: equipo clásico vs. proceso con IA

Aspecto	Equipo clásico (8-10 persoas)	Equipo con axentes IA (2-3 persoas)
Time-to-market (funcionalidade media)	2-4 semanas	3-7 días
Cobertura de probas	40-60% (se o equipo ten tempo)	>80% por defecto (probas xeradas xunto co código)
Revisión de código	1 persoa, 30-60 min de media	3 axentes (seguridade, calidade, arquitectura) + humano para cambios complexos
Documentación	A miúdo incompleta, „engadida despois"	Xerada xunto co código (OpenAPI, README, CHANGELOG)
Rexistro de auditoría	Historial de Git	Git + audit log na base de datos + CHANGELOG + Change Request
Escalado	Lineal (máis persoas = maior custo de comunicación)	Non lineal (máis axentes = mesmo número de persoas supervisando)
Compliance (EU AI Act, RXPD, ISO 27001)	Adoita ser auditoría externa a posteriori	Integrada no proceso desde a primeira liña de código

Preguntas máis frecuentes

Que é o desenvolvemento de software automatizado con IA?

É un proceso no que axentes IA especializados participan en cada etapa do ciclo de desenvolvemento de software: desde a análise de requirimentos, pasando polo deseño da arquitectura, a codificación, as probas automáticas (unitarias, integración, E2E, seguridade, rendemento, regresión), ata a revisión de código e o despregamento en produción. O humano segue supervisando o proceso e tomando as decisións clave, pero as tarefas rutineiras (escribir código, xerar probas, refactorizar, documentar) execútanas os axentes IA mantendo os estándares de calidade acordados.

En que se diferencia este proceso da programación clásica con Copilot?

Copilot é autocompletado — axuda a escribir liñas individuais de código. O desenvolvemento de software con IA é orquestración completa: un axente planifica a arquitectura, outro escribe o código, un terceiro escribe as probas, un cuarto fai a revisión, un quinto despregamenta. Cada un ten a súa especialización, memoria episódica (aprende de proxectos anteriores), ferramentas e contexto. O resultado: unha escala de automatización moito maior que cun só Copilot, mantendo os estándares enterprise (probas, seguridade, rexistro de auditoría).

Que tipos de probas executa este proceso?

Cada un dos tipos de probas que aplican os equipos de desenvolvemento maduros: probas unitarias, integración, extremo a extremo (E2E), UI (Playwright), seguridade (OWASP Top 10, gitleaks), rendemento (load), regresión, smoke e aceptación. As probas son escritas antes ou en paralelo co código (TDD), e cada cambio require pasar todo o pipeline.

Despregamenta a IA o código en produción de forma autónoma?

Non automaticamente. Os despregamentos en produción requiren un Change Request (CR) aprobado e a decisión dunha persoa. Os axentes IA preparan a documentación dos cambios, executan as probas de regresión, xeran scripts de despregamento con plan de rollback, pero o lanzamento final en produción require a autorización dun operador. Esta regra é deliberada — minimiza o risco de consecuencias imprevistas e mantén un rexistro de auditoría completo.

Funciona este proceso en proxectos enterprise?

Si. Aplicámolo nos nosos propios produtos, incluíndo a plataforma HybridCrew (multiaxente), a plataforma de consultoría con SSO, microservizos con PostgreSQL, integracións con sistemas externos (KRS, MS Graph, IBM, Keycloak). Cada proxecto ten o seu propio pipeline CI/CD, ambientes dev/test/prod, monitorización e audit log. O proceso escala desde un microservizo individual ata unha plataforma con varios contedores.

Canto leva implantar este proceso na nosa empresa?

Depende do contexto. Para un equipo pequeno (1-3 desenvolvedores), a integración co repositorio existente e o pipeline CI/CD adoita levar 2-4 semanas: auditoría, configuración de axentes, axuste aos estándares de codificación, formación. Para organizacións maiores, os proxectos piloto (un equipo, un microservizo) duran 6-8 semanas, seguidos dunha expansión gradual a equipos adicionais.

Que pasa coa seguridade do código fonte?

Os repositorios do cliente nunca van a servizos externos sen consentimento explícito. Por defecto, todo o proceso (axentes IA, modelos LLM, base de datos vectorial, audit log) execútase na infraestrutura do cliente ou na nube privada de ESKOM AI con illamento total. Os segredos xestiónanse a través de HashiCorp Vault, o código escanéase con gitleaks antes de cada commit, e todos os repositorios son privados por defecto.

Substituiredes o noso equipo de desenvolvemento?

Non. Os desenvolvedores experimentados son imprescindibles — deseñan a arquitectura, toman decisións, revisan os cambios complexos, resolven os problemas atípicos. Os axentes IA asumen as tarefas repetitivas e susceptibles de automatización: escribir boilerplate, xerar probas, documentación, refactorización, primeira pasada de revisión de código. Obxectivo: dúas ou tres persoas con IA entregan o valor que antes daba un equipo de 8-10 persoas — sen esgotamento, con mellor calidade e un rexistro de auditoría completo.

Canto custa o desenvolvemento de software con IA?

A valoración é sempre individual e depende da escala, do modelo de facturación (subscrición da plataforma vs. proxecto dedicado), das integracións requiridas e de se os axentes funcionan en modelos LLM locais (Ollama na GPU do cliente — menor custo operativo) ou na nube (Anthropic, OpenAI — maior flexibilidade). Nos proxectos piloto aspiramos a obter retorno do investimento no primeiro trimestre tras a posta en marcha completa.

Cales son os sinais típicos de que unha empresa está preparada para este proceso?

Os mellores resultados acádanos os equipos que xa teñen: repositorio baixo control de versións (Git), estándares de codificación definidos, un pipeline CI/CD básico, requirimentos claramente documentados (Jira/Linear/propios) e cultura de revisión de código. A falta dalgún destes elementos non bloquea a implantación — entón comezamos cunha auditoría e a preparación dos cimentos. As organizacións menos maduras son aquelas sen control de versións ou con código en produción que ninguén proba.

Preparados para un proxecto piloto?

Comezamos cunha auditoría do proceso existente e un piloto nun microservizo escollido. Os primeiros resultados son visibles en 2-4 semanas. Sen compromisos plurianuais.

Reserva unha conversa Ver produtos