Cómo uso la IA como desarrolladora full-stack: mi stack real de automatización
No es un post de hype sobre "10x con IA". Un recorrido concreto por dónde la IA realmente está en mi trabajo diario como desarrolladora full-stack — código, pipelines de contenido, traducciones, pruebas, despliegues — y dónde sigo haciendo el trabajo yo misma.
Me hacen una versión de la misma pregunta: "construyes sitios web y soluciones de IA, entonces ¿cuánto de tu propio trabajo hace realmente la IA?" La respuesta honesta tiene capas. La IA escribe gran parte del primer borrador de mi código. No toma ninguna de las decisiones de criterio. Ejecuta pipelines enteros en este proyecto sin supervisión. Nunca toca producción sin que una persona lea antes el diff. Abajo está el stack real, no la versión de venta.
1. Código: programación en pareja, no piloto automático
La mayor parte de mi uso diario de IA es Claude Code sentado a mi lado en la terminal, dentro de este mismo repositorio. Describo un componente, un bug, un refactor a través de las siete carpetas de idioma bajo src/app, y redacta el cambio. Leo cada diff antes de que aterrice — igual que revisaría el PR de una junior. La IA es muy buena en "aplicar este patrón de forma consistente a 40 archivos" y notablemente peor en "decidir si este patrón debería existir". Así que me quedo con ese segundo trabajo.
Las ganancias concretas: montar una vez una nueva page factory y dejar que la IA conecte desde ahí cada variante de idioma, escribir el primer pase de un conjunto de Vitest para una nueva función de lib, traducir un stack trace a una causa raíz en lenguaje claro antes de ponerme a indagar yo misma, y redactar mensajes de commit a partir de un diff para no quedarme mirando un cursor en blanco.
2. Pipelines de contenido e i18n que corren sin mí
Este sitio publica cada entrada de blog en hasta siete idiomas: en, ua, de, fr, es, it, tr. Escribo las versiones en inglés y ucraniano a mano — esa parte sigue siendo mía, porque el tono y la precisión técnica importan y no quiero una voz traducida por máquina como propia. Los idiomas restantes los rellenan scripts en scripts/ que recorren el árbol de contenido localizado y llaman a una API de traducción para cualquier campo sin idioma, cachean el resultado para que las re-ejecuciones no vuelvan a pagar por strings que ya tengo, y fallan ruidosamente en vez de escribir en silencio un string vacío en una página.
El mismo instinto de automatización aparece fuera del blog: sitemap.ts regenera cada ruta en cada idioma en tiempo de build en lugar de que yo mantenga una lista a mano, el feed RSS y los archivos llms.txt / llms-full.txt se derivan de los mismos datos de posts, así que no pueden desincronizarse de lo que realmente está publicado, y CI ejecuta el paso completo de tests y lint en cada push antes de que algo llegue al workflow de despliegue nextjs.yml.
3. IA dentro del producto, no solo alrededor
La otra mitad de "IA en mi flujo de trabajo" es lo que entrego para GEO — generative engine optimization, hacer que un sitio sea legible para un LLM de la misma forma en que el SEO lo hace legible para un rastreador de búsqueda. Concretamente: llms.txt y llms-full.txt describen este sitio en un formato que un agente puede parsear directamente, datos estructurados JSON-LD en páginas de servicios y blog para que un modelo extraiga hechos en vez de adivinar a partir de la prosa, y un componente de marcado de esquema que se mantiene sincronizado con el contenido real de la página en lugar de un bloque estático que alguien olvidó actualizar.
Esa es la frontera que realmente me importa: la IA que me ayuda a construir el sitio es invisible para una visitante. La IA que ayuda a que el propio sitio sea entendido por otras IA es una función que construyo y pruebo explícitamente — hay un conjunto de Vitest dedicado a los helpers del feed GEO, precisamente para que esto no se pudra en silencio como acaba haciendo toda integración sin pruebas.
4. Dónde mantengo el asiento humano
Nada de esto significa que la IA decida qué sale a producción. No elige la arquitectura de la información, no elige qué páginas de servicios existen, no decide que un formulario de contacto necesita una regla de validación más en vez de tres campos menos — ese criterio es el trabajo real, y es exactamente lo que los clientes pagan cuando contratan a una desarrolladora en vez de un generador. La IA redacta; yo fusiono. La IA traduce; yo escribo la fuente. La IA propone un refactor; yo decido si la abstracción se gana su lugar, siguiendo la misma disciplina de no añadir estructura que el código base todavía no necesita.
Si está tratando de averiguar dónde la IA realmente ahorra tiempo en un producto real — frente a dónde solo mueve la carga de revisión de un lado a otro — esa suele ser la pregunta correcta antes de automatizar cualquier cosa: ¿qué decisión le estoy quitando en realidad a una persona, y estoy de acuerdo con que esa decisión la tome un script?
¿Quiere esto configurado para su proyecto?
También integro este tipo de flujo de trabajo asistido por IA y centrado en la automatización en proyectos de clientes — desde despliegues controlados por CI hasta una estructura de contenido lista para GEO. Escriba por el formulario de contacto y cuénteme qué parte de su proceso todavía le come la semana.
¿Hay que construirlo, no solo leerlo?
Soluciones de IA para empresas: RAG, agentes, Next.js. Contratista directa.
¿Hablamos de tu proyecto?
Soy ingeniera web senior, especializada en React y Next.js - disponible para proyectos freelance en cualquier país.
Ubicación
Kyiv, Ucrania
Upwork
Ver perfilTelegram
ContáctameViber
Contáctame