Tras meses usando Cluade Code y sus diferentes modelos, te comparto mi workflow de manera muy resumida por si te sirve. A mí me funciona maravillosamente bien. Lo cual no quiere decir que a veces una tarea se atasque un poco y cueste más sacarla:
1. Optimiza el coste de los modelos: Opus es carísimo, solo lo uso para planificación y/o aquellas tareas muy complejas que se atascan. Para ejecutar lo planificado por Opus, uso Haiku. Es muy muy rápido, muy directo (hace lo que está planificado) y muchísimo más barato que Opus y que Sonnet. Sonnet ya casi no lo uso. Yo también tengo la suscripción de $20. Me niego a pagar $200.
2. Contexto: Dale todo el contexto posible a través del CLAUDE.md. Sobre todo estilo, buenas prácticas, ejemplos de cómo sí y cómo no, etc.
3. Planifica la tarea antes de ejecutar. Opus es muy muy bueno en esto. Es como tener un programador senior con muchos tiros dados y muy caro por tanto. Aún así hay que revisar y supervisar esa planificación de tareas y a veces modificar alguna cosa. Casi más por preferencias personales, que porque esté mal en sí.
4. Ejecuta en pair programming con Haiku. Como decía, es muy bueno y directo al grano y muy muy rápido. Aún así hay que estar con el mano a mano y evitar que se salga de los guardaraíles del contexto y la planificación, que a veces pasa.
5. Utiliza Agentes y Skills: Los agentes son muy buenos para subtareas muy específicas: Fronten, Backend, Testing, Seguridad. Las Skills consumen muy pocos tokens para lo que hacen y son muy útiles para procesos muy específicos, especialmente si les das las rutas de los archivos a tocar y los ejemplos.
6. No agotes la ventana de contexto: Cada vez que inicies una nueva subtarea, haz /clear. Haz /compact para continuar dentro de una misma tarea. Conforme se va quedando sin contexto, el LLM se va volviendo menos "inteligente", comete más fallos o tiene más alucinaciones.
Por último, Git. Al contrario de lo que hacen muchos, no le doy la responsabilidad de los commits a Claude Code, tan solo le digo que me sugiera un comentario para el commit. Pero yo reviso fichero por fichero cada commit y tanto el commit como el push, los hago yo manualmente. No quiero sorpresas desagradables en el repo remoto.
Nota adicional: Sé que puede sonar a tontería, pero leí un paper hace unas semanas de cómo funciona la "psicología" de los LLMs y cómo tienden a hundirse a medida que cometen un error, comienzan a decaer y cometer cada vez más errores. Y de cómo el concepto conocido en psicología como "efecto pigmaleon" parece funcionar en los LLMs. Y si tras un error, te pones negativo con él, es como le entrase ansiedad y nerviosismo y cada vez la lía más. Es como si entrara en un bucle de negatividad.
Desde entonces, cada vez que lo borda le felicito, cuando comete un error, se lo hago saber con amabilidad y sin dramas. Le animo a que lo intente de nuevo, que seguro que entre los dos lo vamos a resolver. Parece como que se motiva y suele mejorar en rendimiento (o me lo parece).
De paso, no tratarle como una máquina y más como a un compañero, hace que mis ocho horas de trabajo remoto en solitario se hagan más amenas. Aunque solo sea por eso, ya merece la pena.
Espero que alguna de estas ideas te sirva de algo. Un saludo
- Luego le digo a Haiku que ejecute la primera subtarea de ese plan y que al acabarla se detenga para que yo pueda comprobar lo realizado. Normalmente es ahí cuando, una vez revisado, le digo que la marque como hecha y entonces hago commit.
- Hago /clean
- Y comenzamos de nuevo con la siguiente tarea.
De este modo va todo controlado sobre guardaraíles.
Muy bien tirado. Tengo la misma sensación: nos enfrentamos al problema del 90-90, pero con una enorme diferencia: hasta el momento, ese 90% del trabajo lo habías implementado tú y tu equipo. Ahora, deberás resolver el 10% restante sobre un código que tú no has implementado y del que no sabes nada. ¿Os suena esta situación? Efectivamente: es la que muchos hemos vivido al heredar un proyecto de una empresa o equipo que previamente habían fallado en entregar un producto de calidad, y ahora nos piden a nosotros que nos hagamos cargo a ver “si podemos arreglarlo”.
Quizás por mi forma de trabajar con la IA, no comparto esa visión.
No subo al repo ni una sola línea de código que yo no comprenda ni sepa qué hace y por qué lo hace. Y por supuesto que no cumpla ninguna de las especificaciones, estándares y buenas prácticas que en el equipo nos hemos puesto.
De hecho, como digo en mis comentarios, no delego la responsabilidad de los commits a la IA. Los commits los hago yo. Porque ante el equipo, el responsable de la tarea soy yo, no la IA.
Yo no concibo a día de hoy la IA como una "churrera" de código a la cual le das especificaciones y te devuelve una aplicación o una feature terminada. Mi visión ahora mismo de ella es la de un coworker con el que sacar más trabajo adelante en mucho menos tiempo.
Totalmente de acuerdo en tu caso (que es como lo estamos aplicando también en nuestro equipo), pero de lo que hablan aquí (y en las redes), no es de crear una simple función, añadirte los tests unitarios, o proponerte una eficiencia sobre tu código. Lo que están poniendo sobre la mesa es hacer TODO el producto en base a especificaciones contra una IA.
Bueno, mi uso va un poco más allá de lo que comentas.
A mí me programa el 99% a día de hoy. Lo que quería decir es que todo el código que genera tiene que cumplir los estándares del equipo y tiene que ser supervisado por mí. No suba nada al repo que yo no sepa qué hace y por qué.
Pero yo ya no programo apenas nada desde hace bastantes semanas.
Y aún te diré más, como le pregunto mucho el porqué de las cosas, he aprendido muchísimo con la IA y mi expertise se ha disparado en los últimos meses.
Con la versión pro no basta, hay que tener la MAX, hay ofertas para empresas y equipos. Son muy buenos los consejos de Fernando Val, solo añadiría el crear agentes responsables de cada tipo de tarea o proceso, con documentación compartida entre tipos de procesos o tareas, con un único origen de la verdad y referencias entre ellos. Lanzar claude con dangerously-skip-permissions, pasandole unicamente documentacion necesaria, en varios pasos (flow) y con toda la documentación y prompts bien organizados puede automatizarte tareas. Todos los skills apra mi gusto en python. Próximos pasos, que no se si llegaré a hacerlos, es intentar aislar mis procesos de automatización de tareas del LLM, poder cambiar solo la key, pero eso ya en el 2026. Feliz año
Esta situación que comentas es heredada. Ya ocurría y sigue ocurriendo sin recurrir a entornos de terminal o híbridos.
Cuellos de botella, alucinaciones, limitaciones de memoria, ventanas de contexto, etc.
Ahora súmale el capítulo de coste de créditos (Manus por ejemplo). Cuantos créditos estimas que necesita tu tarea para completarse de manera satisfactoria? Coincide con tu estimación? Quién debe soportar el coste de las iteraciones e inferencias? Es apostar a ciegas a que el entorno agéntico entienda y elabore con eficacia y eficiencia.
Por otro lado, las limitaciones de uso (Anthropic) aunque seas usuario de pago. Por el momento, son sólo ellos los que lo han implantado dentro de los grandes modelos.
El usuario sigue siendo el que ejecuta y soporta el control de calidad.
Tras meses usando Cluade Code y sus diferentes modelos, te comparto mi workflow de manera muy resumida por si te sirve. A mí me funciona maravillosamente bien. Lo cual no quiere decir que a veces una tarea se atasque un poco y cueste más sacarla:
1. Optimiza el coste de los modelos: Opus es carísimo, solo lo uso para planificación y/o aquellas tareas muy complejas que se atascan. Para ejecutar lo planificado por Opus, uso Haiku. Es muy muy rápido, muy directo (hace lo que está planificado) y muchísimo más barato que Opus y que Sonnet. Sonnet ya casi no lo uso. Yo también tengo la suscripción de $20. Me niego a pagar $200.
2. Contexto: Dale todo el contexto posible a través del CLAUDE.md. Sobre todo estilo, buenas prácticas, ejemplos de cómo sí y cómo no, etc.
3. Planifica la tarea antes de ejecutar. Opus es muy muy bueno en esto. Es como tener un programador senior con muchos tiros dados y muy caro por tanto. Aún así hay que revisar y supervisar esa planificación de tareas y a veces modificar alguna cosa. Casi más por preferencias personales, que porque esté mal en sí.
4. Ejecuta en pair programming con Haiku. Como decía, es muy bueno y directo al grano y muy muy rápido. Aún así hay que estar con el mano a mano y evitar que se salga de los guardaraíles del contexto y la planificación, que a veces pasa.
5. Utiliza Agentes y Skills: Los agentes son muy buenos para subtareas muy específicas: Fronten, Backend, Testing, Seguridad. Las Skills consumen muy pocos tokens para lo que hacen y son muy útiles para procesos muy específicos, especialmente si les das las rutas de los archivos a tocar y los ejemplos.
6. No agotes la ventana de contexto: Cada vez que inicies una nueva subtarea, haz /clear. Haz /compact para continuar dentro de una misma tarea. Conforme se va quedando sin contexto, el LLM se va volviendo menos "inteligente", comete más fallos o tiene más alucinaciones.
Por último, Git. Al contrario de lo que hacen muchos, no le doy la responsabilidad de los commits a Claude Code, tan solo le digo que me sugiera un comentario para el commit. Pero yo reviso fichero por fichero cada commit y tanto el commit como el push, los hago yo manualmente. No quiero sorpresas desagradables en el repo remoto.
Nota adicional: Sé que puede sonar a tontería, pero leí un paper hace unas semanas de cómo funciona la "psicología" de los LLMs y cómo tienden a hundirse a medida que cometen un error, comienzan a decaer y cometer cada vez más errores. Y de cómo el concepto conocido en psicología como "efecto pigmaleon" parece funcionar en los LLMs. Y si tras un error, te pones negativo con él, es como le entrase ansiedad y nerviosismo y cada vez la lía más. Es como si entrara en un bucle de negatividad.
Desde entonces, cada vez que lo borda le felicito, cuando comete un error, se lo hago saber con amabilidad y sin dramas. Le animo a que lo intente de nuevo, que seguro que entre los dos lo vamos a resolver. Parece como que se motiva y suele mejorar en rendimiento (o me lo parece).
De paso, no tratarle como una máquina y más como a un compañero, hace que mis ocho horas de trabajo remoto en solitario se hagan más amenas. Aunque solo sea por eso, ya merece la pena.
Espero que alguna de estas ideas te sirva de algo. Un saludo
Duda. ¿Cómo planificas con Opus y ejecutas con otro modelo? ¿Guardas el plan en disco, o directamente puedes hacer el cambio desde la misma sesión?
Siempre guardo el plan en un .md. Dentro de la carpeta /.claude/tasks
Algo como task-feature-x-plan.md.
- Luego le digo a Haiku que ejecute la primera subtarea de ese plan y que al acabarla se detenga para que yo pueda comprobar lo realizado. Normalmente es ahí cuando, una vez revisado, le digo que la marque como hecha y entonces hago commit.
- Hago /clean
- Y comenzamos de nuevo con la siguiente tarea.
De este modo va todo controlado sobre guardaraíles.
Muchísimas gracias, súper útil!
Muy bien tirado. Tengo la misma sensación: nos enfrentamos al problema del 90-90, pero con una enorme diferencia: hasta el momento, ese 90% del trabajo lo habías implementado tú y tu equipo. Ahora, deberás resolver el 10% restante sobre un código que tú no has implementado y del que no sabes nada. ¿Os suena esta situación? Efectivamente: es la que muchos hemos vivido al heredar un proyecto de una empresa o equipo que previamente habían fallado en entregar un producto de calidad, y ahora nos piden a nosotros que nos hagamos cargo a ver “si podemos arreglarlo”.
Quizás por mi forma de trabajar con la IA, no comparto esa visión.
No subo al repo ni una sola línea de código que yo no comprenda ni sepa qué hace y por qué lo hace. Y por supuesto que no cumpla ninguna de las especificaciones, estándares y buenas prácticas que en el equipo nos hemos puesto.
De hecho, como digo en mis comentarios, no delego la responsabilidad de los commits a la IA. Los commits los hago yo. Porque ante el equipo, el responsable de la tarea soy yo, no la IA.
Yo no concibo a día de hoy la IA como una "churrera" de código a la cual le das especificaciones y te devuelve una aplicación o una feature terminada. Mi visión ahora mismo de ella es la de un coworker con el que sacar más trabajo adelante en mucho menos tiempo.
Totalmente de acuerdo en tu caso (que es como lo estamos aplicando también en nuestro equipo), pero de lo que hablan aquí (y en las redes), no es de crear una simple función, añadirte los tests unitarios, o proponerte una eficiencia sobre tu código. Lo que están poniendo sobre la mesa es hacer TODO el producto en base a especificaciones contra una IA.
Bueno, mi uso va un poco más allá de lo que comentas.
A mí me programa el 99% a día de hoy. Lo que quería decir es que todo el código que genera tiene que cumplir los estándares del equipo y tiene que ser supervisado por mí. No suba nada al repo que yo no sepa qué hace y por qué.
Pero yo ya no programo apenas nada desde hace bastantes semanas.
Y aún te diré más, como le pregunto mucho el porqué de las cosas, he aprendido muchísimo con la IA y mi expertise se ha disparado en los últimos meses.
Con la versión pro no basta, hay que tener la MAX, hay ofertas para empresas y equipos. Son muy buenos los consejos de Fernando Val, solo añadiría el crear agentes responsables de cada tipo de tarea o proceso, con documentación compartida entre tipos de procesos o tareas, con un único origen de la verdad y referencias entre ellos. Lanzar claude con dangerously-skip-permissions, pasandole unicamente documentacion necesaria, en varios pasos (flow) y con toda la documentación y prompts bien organizados puede automatizarte tareas. Todos los skills apra mi gusto en python. Próximos pasos, que no se si llegaré a hacerlos, es intentar aislar mis procesos de automatización de tareas del LLM, poder cambiar solo la key, pero eso ya en el 2026. Feliz año
Esta situación que comentas es heredada. Ya ocurría y sigue ocurriendo sin recurrir a entornos de terminal o híbridos.
Cuellos de botella, alucinaciones, limitaciones de memoria, ventanas de contexto, etc.
Ahora súmale el capítulo de coste de créditos (Manus por ejemplo). Cuantos créditos estimas que necesita tu tarea para completarse de manera satisfactoria? Coincide con tu estimación? Quién debe soportar el coste de las iteraciones e inferencias? Es apostar a ciegas a que el entorno agéntico entienda y elabore con eficacia y eficiencia.
Por otro lado, las limitaciones de uso (Anthropic) aunque seas usuario de pago. Por el momento, son sólo ellos los que lo han implantado dentro de los grandes modelos.
El usuario sigue siendo el que ejecuta y soporta el control de calidad.