Cómo mejorar tus habilidades de programación usando IA

• Quiero usar herramientas de codificación con IA para reducir tareas de transformación que a una persona le tomarían 1–2 horas a un nivel de revisión de 15–20 minutos
• Pero, por ahora, la calidad del código que genera la IA no llega ni al 90% del código escrito directamente por mí, así que no parece ser de mucha ayuda en la práctica
• Por eso, quiero saber cómo usar la IA para aumentar al mismo tiempo la productividad y la calidad del código

Consejos prácticos para mejorar la eficiencia y la calidad de la programación con IA

1. Concentrar la IA solo en tareas repetibles

• La IA es más efectiva cuando repite varias veces trabajos de forma similar
• Una vez, una persona lo implementa directamente con la mejor calidad posible y eso se usa como ejemplo base
• Después, las tareas con el mismo patrón se delegan a la IA para procesarlas en volumen
• En trabajos que requieren pensamiento y criterio, la eficiencia esperada cae drásticamente

2. Hacer primero un plan antes de programar

• No generar código de inmediato; primero escribir un plan de solución
• En la etapa de planificación, hacer que salgan a la luz todos los puntos ambiguos y las preguntas
• Si el plan no es satisfactorio, no pasar a la etapa de ejecución
• La calidad del resultado depende más de la claridad del documento de planificación que del prompt

3. Dividir el trabajo en unidades extremadamente pequeñas

• Pedir por archivo, por componente o por unas cuantas funciones
• Solicitudes como “refactorización completa” o “mejorarlo de forma idiomática” tienen alta probabilidad de fallar
• La persona diseña la estructura y la IA se encarga solo de la implementación repetitiva

4. No acumular contexto; reiniciarlo con frecuencia

• Cuanto más larga se vuelve la conversación, más caen el cumplimiento de reglas y la calidad
• En una sesión, procesar solo una tarea
• Si cambia la dirección, volver a empezar en una sesión nueva
• En trabajos largos, conservar el estado en documentos (plan.md, etc.) y volver a inyectarlo

5. Hacer los documentos de reglas breves y mecánicos

• Mantener CLAUDE.md / AGENTS.md dentro de 500–1000 tokens
• En vez de instrucciones declarativas, escribir sobre todo reglas concretas y verificables
• Registrar al mínimo solo los errores más frecuentes
• Todo lo demás se fuerza con el código y verificaciones automáticas

6. Usar pruebas, linter y build como bucle de retroalimentación

• En lugar de “hazlo bien”, definir claramente las condiciones para darlo por válido
• Fijar como objetivo pasar las pruebas, compilar con éxito y tener 0 errores de linter
• La IA solo converge por sí sola si existe un bucle de retroalimentación
• Las pruebas que validan el comportamiento existente reducen mucho la dificultad de una refactorización

7. No corregir sobre la marcha; corregir el plan y volver a ejecutar

• Si el resultado no convence, no repetir solicitudes para modificar el código
• Corregir el documento de planificación y luego volver a ejecutar en una sesión nueva
• Si cambias la dirección durante la ejecución, la calidad se derrumba rápido

8. Enseñar el estilo a partir de ejemplos

• Indicaciones abstractas como “buen código” casi no funcionan
• Proporcionar ejemplos Before / After
• Mostrar con claridad ejemplos buenos y malos
• Ampliar las reglas tomando los ejemplos como eje

9. No renunciar a entender y dejar claros los límites de responsabilidad

• El código generado por IA siempre debe ser entendido y revisado por una persona
• Salvo prototipos y código de bajo riesgo, no se debe usar sin revisión
• En código de seguridad, operación y mantenimiento a largo plazo, la comprensión es una condición previa de calidad

10. Revisar primero si esta tarea es adecuada para IA

• Los trabajos sin una respuesta correcta y con mucho juicio estético o estructural son desfavorables para la IA
• Las refactorizaciones de UI, donde es difícil validar automáticamente el resultado visual, son especialmente complicadas
• Si hace falta:
  • Paso 1: transformación mecánica con el objetivo de mantener el comportamiento
  • Paso 2: una persona realiza la refactorización de calidad

11. Empezar con una expectativa de “mejora del 10%”

• No esperar 10x desde el principio
• Una estrategia de acumular pequeñas mejoras es más efectiva a largo plazo
• La clave es no renunciar al diseño ni a los criterios de calidad

[GN⁺]

Opiniones de Hacker News

• Soy Boris del equipo de Claude Code. Comparto algunos consejos

  1. Conviene anotar en CLAUDE.md las cosas en las que Claude se equivoca con frecuencia o no entiende. Claude lee este archivo automáticamente
  2. Si aprovechas activamente el modo Plan (Shift+Tab dos veces) para armar primero un plan y luego ejecutarlo, puedes obtener resultados 2 o 3 veces mejores en tareas difíciles
  3. Es buena idea darle una forma de validar el trabajo. Por ejemplo, en Svelte puedes usar el servidor MCP de Puppeteer para que verifique el resultado en el navegador
  4. Recomiendo el modelo Opus 4.5. Se siente claramente como un salto de nivel frente a Sonnet 4.5
     Ojalá sirva
  • Yo también experimenté un gran aumento de productividad gracias al modo Plan. Pero en una versión reciente apareció un bug donde el modo Plan sigue consultando solo el primer plan de la sesión, y eso arruinó mi flujo de trabajo. Me pregunto si lo estoy usando de una forma rara
  • Después de corregir a Claude durante el trabajo, conviene ejecutar un prompt de self-reflection. Ese proceso refleja automáticamente en CLAUDE.md las cosas que uno fue ajustando manualmente
  • Coincido con los consejos de arriba. En especial, el bucle de retroalimentación del punto (3) es clave. Hay que permitir que el modelo corrija por sí mismo y luego revise el resultado. Si haces que deje archivos de log o que arme un plan en pseudocode, incluso problemas complejos se resuelven rápido
  • Opus 4.5 de verdad es un game changer. Me ayudó muchísimo al refactorizar un proyecto viejo de React. Si escribes prompts precisos y configuras bien CLAUDE.md, el impacto es grande
  • CLAUDE.md funciona bien solo hasta unas 4 o 5 veces, y después olvida las instrucciones. Por ejemplo, aunque le digas que te llame “Mr. bcherny”, se le olvida enseguida
  • Comparado con Google Jules, Claude Code se sintió mucho más como un desarrollador profesional. Pero Claude Code Web no tiene función de proyectos, así que me respondieron que usara el archivo .clinerules; me gustaría entender la diferencia con CLAUDE.md
  • Una función útil de CLAUDE.md es @import. Si pones @ delante del nombre de un archivo, puedes forzar que se incluya en el contexto. Eso sí, usarlo demasiado lo vuelve ineficiente

• Si usas entrada por voz, el modelo entiende la intención con más precisión. Yo dicto prompts de unas 500 palabras. Al hablar, las ideas fluyen de forma más natural que al teclear.
  Si le dices “haz un plan y pregúntame si tienes dudas”, Claude realmente hace preguntas. También funciona bien indicarle que imite el estilo del código previo

  • Yo también hice casi todo laboratory.love por voz. Uso seguido un atajo con la frase “analiza el problema y los requisitos antes de escribir código, y pregúntame lo que sea ambiguo”
  • Hablar rápido no significa hablar sin pensar. De hecho, el problema puede ser hablar con demasiado poca reflexión
  • Me da un poco de vergüenza hablarle a una IA si hay alguien escuchando, pero las frases largas también las ingreso por voz
  • Me da curiosidad saber qué servicio de reconocimiento de voz usan

• Hay que incluir una condición de bucle (loop condition) en el prompt. Ejemplo: “repite hasta que yarn test pase”.
  Al final, un LLM es un agente que ejecuta herramientas repetidamente, así que hay que tratarlo como tal
  Referencia: Prompting the Agent Loop

• Recomiendo la configuración nori-profiles que hice.
  Después de 4 meses de pruebas, el rendimiento de Claude Code mejoró de forma visible.
  Artículo relacionado: Averaging 10 PRs a Day with Claude

  • Me gustaría saber qué diferencias hay frente a los skills de Claude Code

• En el trabajo manejo una base de código grande en Golang. He probado varias herramientas como Cursor, Claude Code y Gemini CLI, pero a la mayoría las abruma la cantidad de código.
  Sin embargo, aider era mucho más fácil de controlar y tenía mayor precisión. Agregar archivos es manual, pero acierta casi el 100% de las veces.
  Es más preciso cuando se usa con el Claude Sonnet más reciente o con Gemini 2.5 Pro

  • La ventaja de aider es precisamente que no es un agente completamente autónomo. Tú manejas el contexto manualmente, así que no modifica archivos equivocados. También conviene en ahorro de tokens y velocidad

• Cuando trabajo con Cursor, primero le hago generar un archivo de reglas mientras refactoriza una ruta. Después, en las demás rutas, basta con decir “refactor”

  • No hay que tenerle miedo a los prompts largos. Eso es precisamente context engineering. El historial de la conversación en sí enriquece el contexto.
    Conviene estar siempre pendiente de cuánto contexto queda disponible y, si hace falta, hacer un context clear temprano

• Es importante ver al agente como si fuera un compañero de equipo. Hay que observar fortalezas y debilidades mutuas e ir ajustando la forma de colaborar.
  Yo concentro la capacidad del agente en problemas verificables o código para experimentar.
  No conozco bien Svelte, pero parece buena idea inducir una reescritura con tests descartables al estilo TDD.
  A veces lo mejor es descartar el contexto equivocado anterior y empezar de nuevo en un workspace nuevo

  • Estaría bueno que compartieras un resumen de ese texto sobre “estilo cognitivo y trabajo en equipo”

• Yo veo a los LLM como un buscador (searcher). Si haces preguntas pequeñas y concretas, la búsqueda se vuelve más fácil, y mientras más te alejas de los datos de entrenamiento, mayor es la probabilidad de error.

  1. Abro el proyecto en Zed
  2. Conecto Gemini CLI, Qwen code o Claude
  3. Le pido que modifique archivos y pruebo
  4. Si no funciona, pruebo con Grok o Gemini 3 Chat
  5. Si aun así no sale, lo resuelvo manualmente
     En proyectos nuevos, incluso un prompt one-shot puede ser suficiente
  • Pero un prompt demasiado pequeño también genera el problema de falta de especificación (underspecification). Solo reduce el costo computacional, pero en calidad sale perdiendo

• El conjunto de herramientas de Claude Code que más uso es superpowers

  1. Primero explico la funcionalidad en una sesión de brainstorming
  2. Claude redacta un documento de diseño y un plan de implementación y los guarda en disco
  3. En una nueva ventana de Claude, ejecuto el comando Execute Plan para implementarlo por pasos y hacer commits
  4. Cada tres pasos le hago hacer una revisión propia para mejorar la calidad del código
     Llevo dos semanas usándolo y casi nunca me ha fallado

• Mis principios para programar con IA son simples

  1. Terminar todo de una sola vez (one-shot) falla
  2. Divido el trabajo en unidades verificables
  3. Organizo el plan completo en un archivo Markdown
  4. En cada etapa ejecuto en una sesión nueva, reviso y luego hago commit
     La clave es “Less is more”. Mientras más fresca esté la ventana de contexto, mejor; unas 500 a 750 palabras es lo ideal. Todos los pasos deben poder verificarse

• En tareas relacionadas con Java, Claude cambia de dirección constantemente o hace propuestas contradictorias. Siento que ChatGPT funciona mucho mejor

  • Si le das instrucciones más específicas en el prompt, puede mejorar
  • Me pregunto si has probado la versión Claude Code

• Si quieres código idiomático, primero tienes que definir con detalle qué estilo consideras adecuado. Divide en ejemplos pequeños de lo bueno y lo malo, mételos en el modo Plan de Opus 4.5 para que arme un plan y luego ejecútalo. Si no queda perfecto a la primera, modifica el documento del plan e inténtalo otra vez. Intentar guiarlo en exceso, como si fuera un desarrollador junior, en realidad es ineficiente

  • Otra persona compartió que “los modelos de hoy ya no requieren necesariamente empezar una sesión nueva”, y que incluso con refactorización inline ha tenido suficiente estabilidad