Tutorial practico
Como usar Codex dentro de IntelliJ IDEA paso a paso
Guia practica para usar IntelliJ o WebStorm como superficie de trabajo mientras Codex inspecciona el repositorio real, propone cambios, ejecuta comprobaciones y te ayuda a revisar el resultado sin perder criterio tecnico.
CodexIntelliJ IDEAWebStormCLIAppPromptingReview
Que conviene entender antes de empezar
Este tutorial esta pensado para trabajar con Codex desde el propio entorno de IntelliJ o WebStorm, usando el proyecto real como fuente de contexto y no una conversacion desconectada.
Codex rinde mejor cuando lo haces arrancar desde el proyecto real
En IntelliJ el valor no esta en pedir codigo al aire, sino en dejar que inspeccione rutas, componentes, datos, estilos y convenciones del repositorio antes de tocar nada.
No tienes que ceder el volante para ahorrar tiempo
El flujo bueno es delegar busquedas, ediciones y comprobaciones concretas, y reservar para ti la aceptacion final del cambio y la validacion funcional.
Los mejores resultados salen de prompts pequenos, precisos y verificables
Si defines la ruta, el componente, el tono del tutorial, los assets y la forma de validarlo, Codex puede iterar con mucha menos friccion.
Codex no sustituye tu criterio tecnico: acelera la parte mecanica si le das un marco de trabajo claro
La diferencia entre una sesion mediocre y una sesion realmente productiva suele estar en como planteas la primera instruccion. Si abres IntelliJ, localizas las rutas y los componentes equivalentes, y despues formulas el cambio como una tarea verificable, el agente puede operar con mucha mas precision. Si, por el contrario, la peticion es ambigua, la herramienta tendera a rellenar huecos con suposiciones.
Preparacion
Como preparar IntelliJ para una sesion de trabajo con Codex
No hace falta montar nada exotico. Lo importante es reducir friccion visual y dejar accesibles las piezas que el agente necesitara consultar. Cuanto mas rapido pueda orientarse por el repo, menos tiempo perdera inventando contexto.
Abre el proyecto correcto en IntelliJ IDEA o WebStorm y deja visible el arbol de ficheros.
Ten a mano el enrutador principal, los componentes parecidos y la carpeta de assets para que Codex tenga referencias claras.
Formula la tarea como un cambio concreto en el repo, no como una pregunta abstracta.
Indica si quieres una solucion minima, una pagina completa o una refactorizacion con verificacion incluida.
Espacio de trabajo
Distribucion recomendada dentro del IDE
Funciona bien tener el arbol de proyecto a la izquierda, el fichero principal en el editor central y una zona de terminal o panel de interaccion donde Codex pueda ejecutar inspecciones. La idea no es abrir todo, sino abrir lo justo para que la navegacion sea rapida y la revision posterior resulte comoda.
Panel izquierdo
Usa el arbol de ficheros para saltar entre `src/app`, `src/assets` y los datos auxiliares. Si el cambio toca rutas, componentes y catalogos JSON, tener esas carpetas a dos clics ahorra bastante tiempo.
Editor central
Abre primero una referencia cercana al cambio que quieres hacer. Pedir un componente nuevo basandose en uno ya existente suele producir una salida mejor que empezar sin referencia visual ni tecnica.
Terminal o panel de agente
Reservalo para que Codex inspeccione, edite y valide. Es ahi donde compensa delegar busquedas, lectura de rutas, modificaciones puntuales y comprobaciones de compilacion o consistencia.
Flujo actual
Que significa realmente "usar Codex dentro de IntelliJ"
La idea importante no es el nombre del panel, sino el contexto de trabajo compartido. IntelliJ o WebStorm mantiene visible el repositorio; Codex puede trabajar desde terminal, app o superficie de agente; y tu revision final sigue ocurriendo en el IDE donde vive el codigo.
IntelliJ o WebStorm
Mantén el proyecto abierto, usa el árbol de ficheros y el editor como punto de referencia, y haz que Codex trabaje sobre el mismo repositorio en vez de sobre un fragmento copiado.
Terminal integrada o Codex CLI
Un buen flujo en JetBrains consiste en ejecutar Codex desde la raíz del proyecto, para que pueda inspeccionar ficheros, aplicar parches y lanzar los mismos comandos de build que usas tú.
Aplicación Codex y tareas en la nube
Para trabajo largo, investigaciones en paralelo o tareas de seguimiento, la app y el flujo cloud ayudan porque conservan contexto más allá de una edición rápida.
Diff y validación local
El IDE sigue siendo el sitio donde revisas ficheros modificados, comparas el parche, ejecutas la aplicación y decides si el resultado se acepta.
Metodo
Flujo de trabajo paso a paso
Este es el patron que mejor equilibrio da entre velocidad y control. Sirve tanto para cambios pequenos como para tareas editoriales mas largas, como anadir una pagina tutorial completa con assets y ruta propia.
Pide inspeccion antes de pedir codigo
Empieza con una instruccion que obligue a revisar rutas, componentes existentes, estilos reutilizables y datos de apoyo. Asi reduces suposiciones y haces que la solucion respete la estructura real del proyecto.
Fija el entregable exacto
Si quieres una pagina tutorial con ruta propia, dilo con el slug, la carpeta esperada, el tipo de componente, el tono del articulo y si debe aparecer en el listado del blog.
Acota el alcance tecnico
Avisa si debe ser standalone, si tiene que usar utilidades visuales ya existentes, si la SEO va en el propio componente y si prefieres assets SVG creados localmente.
Haz que ejecute validaciones
Despues del parche, pide una comprobacion real: build, test, typecheck o al menos una lectura final de imports, rutas y JSON tocados. Sin eso, la tarea se queda a medias.
Revisa el diff como si fuera una PR pequena
Comprueba que el cambio no solo compila: la ruta debe cargar, el listado debe enlazar bien, los assets deben existir y el texto del tutorial debe responder exactamente a lo que pediste.
Itera sobre el resultado, no sobre la idea inicial
Una vez existe el primer parche, la mejor manera de mejorar la salida es pedir cambios concretos sobre ese diff: mas detalle, otra estructura visual, otro slug o un ajuste de copy.
Playbook
Como cambiar el prompt segun la tarea
No funciona igual pedir un bug, un articulo nuevo, un refactor o una review. Codex se vuelve mas util cuando la peticion encaja con el tipo de trabajo que estas delegando.
Cuando la tarea es un bug
Pide a Codex que reproduzca primero el camino mental: de donde sale el dato, donde se transforma y donde se pinta. Despues pide el cambio minimo que arregle el comportamiento visible.
Cuando la tarea es un articulo nuevo
Dale slug, idiomas esperados, entrada de catalogo, objetivo SEO y comando de validacion. Un articulo nuevo no esta terminado hasta que ruta, listado, metadatos y build coinciden.
Cuando la tarea es refactorizar
Limita el alcance de escritura. Los refactors son donde un agente puede entusiasmarse demasiado, asi que pide conservar comportamiento publico y evitar limpieza no relacionada.
Cuando la tarea es review
Dile que empiece por hallazgos, referencias de linea y severidad. Eso cambia el modo de "hacer mas codigo" a "proteger el codigo".
Prompts
Prompts que suelen funcionar bien
Un buen prompt para Codex dentro de IntelliJ suele parecerse mas a una especificacion corta que a una charla. Debe decir que mirar, que crear, que no tocar y como comprobar que la tarea esta cerrada.
Prompt para arrancar bien
Quiero una nueva pagina tutorial sobre como usar Codex dentro de IntelliJ IDEA.
Revisa primero la estructura del proyecto y detecta donde van rutas, posts y assets.
Despues crea un componente standalone largo, con SEO, dos imagenes locales y una ruta nueva /como-usar-intellij-codex.
Si el blog usa un catalogo o snapshot para listar posts, anadelo tambien.
Valida al final que no has roto imports ni JSON.Este prompt funciona porque marca inspeccion previa, entregables, restricciones y validacion.
Prompt para una segunda iteracion
Sobre el componente ya creado, quiero una segunda pasada.
Haz el tutorial mas editorial y menos generico: anade una seccion de errores comunes,
otra de prompts recomendados y otra de checklist final antes de aceptar cambios.
No cambies la ruta ni el slug.Asi obligas a iterar sobre un artefacto real en vez de volver a empezar desde cero.
Prompt para modo review
Revisa los cambios de este tutorial como si fuera una code review.
Prioriza bugs, riesgos de regresion, errores de ruta, imports rotos, JSON invalido,
imagenes que no existan y texto que contradiga la estructura actual del proyecto.Es util cuando ya no quieres mas escritura sino una lectura critica del parche.
Prompt para corregir un bug
Hay un bug en el listado de proyectos: al buscar "odoo" no aparecen los posts de Odoo.
Primero inspecciona el componente del listado, el catalogo source, el snapshot y las rutas.
Explica brevemente la causa y aplica despues el cambio minimo para que la busqueda funcione por titulo, tematica y URL.
Regenera assets derivados solo si el proyecto lo requiere y ejecuta el build al final.Funciona porque pide diagnostico antes de editar y define el comportamiento observable exacto.
Prompt para mejorar SEO/contenido
Mejora este articulo existente sin cambiar su ruta.
Mantén la estructura bilingue, conserva el estilo visual actual, amplia las secciones flojas,
mejora la meta description y valida que la pagina sigue compilando.
No reescribas archivos no relacionados.Util para mantenimiento del blog porque protege la URL y permite una mejora real del contenido.
Practica real
Como pedir una tarea completa sin dejar cabos sueltos
Supongamos que quieres exactamente lo que se ha hecho en esta pagina: un componente nuevo, una ruta publica, un tutorial largo, assets propios y aparicion en el listado principal del blog. La peticion buena no es "crea una pagina sobre Codex", sino una instruccion como esta.
Especificacion breve pero eficaz
Haz un nuevo componente tutorial en Angular sobre como usar Codex dentro de IntelliJ IDEA.
Debe tener su propia ruta, contenido largo en espanol, dos imagenes locales tipo WebP,
SEO configurado en el componente y alta en el catalogo del blog si existe.
Usa el estilo visual moderno del proyecto y valida al final imports, rutas y JSON.Con esto le das suficiente libertad para ejecutar, pero no tanta como para que derive hacia soluciones que no encajan con el repositorio. Si luego quieres afinar tono, estructura o visual, lo haces en una segunda vuelta.
Checklist antes de aceptar los cambios
- La ruta esta registrada en el router principal y apunta al fichero correcto.
- El componente nuevo es standalone y sus imports coinciden con los helpers usados en la plantilla.
- Las imagenes viven realmente en `src/assets` y sus rutas coinciden con el `src` del HTML.
- El tutorial tiene un titulo, descripcion y canonical coherentes para SEO.
- Los JSON del catalogo siguen siendo validos y el nuevo articulo aparece en el listado.
- Los archivos derivados como snapshots, sitemaps o metadatos SEO se regeneran solo cuando hace falta.
- El comando de validacion es real: build, tests, typecheck o equivalente del proyecto.
- La maquetacion se comporta bien en escritorio y en movil.
Patrones que conviene evitar
- Pedir "hazme un tutorial" sin decir donde debe vivir, como se publica ni como se valida.
- Solicitar cambios grandes sobre varios subsistemas sin ordenar el trabajo en fases.
- Asumir que un resultado largo es automaticamente bueno: si el prompt es vago, el relleno crece y la precision baja.
- Aceptar el parche sin revisar diff, imports, rutas y archivos de datos tocados.
- Usar a Codex como chatbot aislado cuando la ventaja real esta en operar sobre el repo abierto.
Criterio
Cuando usar Codex y cuando bajar una marcha
Codex es especialmente util para trabajo estructurado: localizar ficheros, seguir convenciones, propagar un patron existente, crear nuevas paginas, ajustar imports, tocar rutas y validar consistencia. Si la tarea tiene mucha ambiguedad de producto, arquitectura abierta o decisiones funcionales aun no tomadas, primero conviene cerrar el criterio humano y despues pedir ejecucion.
Muy buen encaje
Cambios delimitados, features pequenas o medianas, tutoriales, secciones de UI, refactors locales, busqueda de referencias y revisiones tecnicas sobre diffs concretos.
Encaje medio
Reestructuraciones grandes donde aun no has decidido el modelo final. Aqui ayuda mas como apoyo de analisis y exploracion que como ejecutor directo de una solucion cerrada.
Mal encaje inicial
Peticiones donde ni el problema esta bien definido ni existe criterio de aceptacion. Si tu brief es borroso, el resultado tendera a ser tambien borroso.
Siguientes lecturas utiles
Si vas a seguir construyendo contenido tecnico en este proyecto, estas tres paginas encajan bien con el flujo de trabajo descrito arriba.
Ver routing en Angular
Util si quieres enlazar este flujo con el patron de rutas del proyecto.
Ver SEO en AngularComplementa este tutorial si vas a publicar paginas nuevas y quieres etiquetarlas bien.
Ver videos responsiveBuen ejemplo si luego quieres enriquecer tus tutoriales con media embebido.
Revisar SSR y SEOUtil cuando la pagina incluye bloques de codigo y necesita HTML limpio renderizado en servidor.
Proteger una API AngularEjemplo backend mas solido si tu tarea con Codex toca claves, proxies o seguridad de despliegue.
Instalar Odoo en AWSArticulo largo de infraestructura que se beneficia del mismo flujo inspeccionar-editar-validar.
Consumir APIs desde AngularUtil cuando pides a Codex conectar un componente frontend con un endpoint REST.
PageRank y enlaces internosContexto para entender por que los enlaces reales y posts relacionados ayudan al descubrimiento.