Claude como pair programmer: cómo aprovecharlo al máximo

Si usás Claude solo para preguntarle "¿cómo hago X en Python?" estás dejando el 80% del valor sobre la mesa. Claude no es un buscador glorificado — es un pair programmer que puede pensar con vos, revisar tu código, proponer arquitecturas y atrapar bugs antes de que exploten en producción.

El truco está en saber cómo trabajar con él.

Tratalo como un colega, no como un oráculo

El error más común es hacer preguntas vagas y esperar magia. Si le decís "haceme una app de tareas", vas a recibir código genérico que no se adapta a tu contexto.

En cambio, hacé lo que harías con un dev humano: dale contexto.

Ejemplo malo:

"Cómo conecto una base de datos en Next.js"

Ejemplo bueno:

"Estoy buildando una app de turnos médicos con Next.js 14 y Supabase. Tengo el schema de la tabla appointments ya creado. ¿Cómo conecto Supabase desde un Server Component para traer los turnos del día de hoy?"

La diferencia en la respuesta es brutal. Con contexto, Claude te da código que realmente podés pegar y que funciona.

El flujo que realmente funciona

1. Empezá con el problema, no con la solución

Antes de pedirle código, describí qué querés lograr. Dejá que Claude proponga el approach. A veces te va a sugerir una solución más simple que la que tenías en mente.

"Necesito que los usuarios puedan filtrar productos por precio, categoría y rating. ¿Cuál es la mejor forma de manejar el estado de esos filtros en React?"

Vas a recibir opciones con pros y contras. Elegís vos. Después le pedís la implementación.

2. Iterá en bloques chicos

No le pidas "toda la app". Pedile una función, un componente, un endpoint. Revisá, testeá, entendé lo que te dio. Después avanzás al siguiente bloque.

Esto tiene dos beneficios: primero, el código que recibís es más preciso. Segundo, si algo falla, sabés exactamente dónde está el problema.

3. Pegale el error completo

Cuando algo no funciona, no describas el error con tus palabras. Pegá el stack trace completo. Claude puede leer eso mejor que vos en este momento, y va directo al punto.

Formato ideal:

Tengo este error al hacer X:

[stack trace completo]

Este es el código relevante:

[código]

¿Qué está pasando?

Prompts específicos que te cambian el juego

Para revisar código que ya escribiste:

"Revisá este componente y decime: ¿hay algún problema de performance, de seguridad o algo que pueda romperse con edge cases?"

Para entender código que no escribiste vos:

"Explicame este código línea por línea como si yo no supiera nada de [tecnología]. Después decime qué hace en una sola oración."

Para refactorizar:

"Este código funciona pero está feo. Refactorizalo manteniendo exactamente la misma lógica. Explicame qué cambiaste y por qué."

Para escribir tests:

"Escribime tests unitarios para esta función. Cubrí el happy path y al menos 3 edge cases que podrían romperla."

Para diseñar una feature nueva:

"Quiero agregar autenticación con Google a mi app. Antes de escribir código, explicame el flujo completo que tendría que implementar y qué librerías me recomendás."

Usá el modo "rubber duck" con superpoderes

A veces el problema no es que no sabés codear — es que no sabés bien qué querés buildear. Claude es perfecto para esto.

Describile tu idea en palabras simples y pedile que te haga preguntas para clarificarla:

"Quiero hacer una herramienta para que dueños de restaurantes gestionen sus reservas. Haceme preguntas para entender mejor qué necesito antes de empezar a codear."

Vas a descubrir en cinco minutos que no habías pensado en casos obvios: ¿qué pasa si cancela el cliente? ¿Se mandan confirmaciones? ¿Hay mesas con capacidad diferente?

Lo que Claude no va a hacer por vos

Ser honesto acá es importante. Claude comete errores. Inventa funciones que no existen, a veces da código desactualizado para librerías que cambiaron, y puede ser demasiado confiado en soluciones que tienen problemas sutiles.

Tu trabajo como builder es revisar lo que recibís. No copies y pegues sin leer. Aunque no entiendas todo el código, al menos corré el linter, leé los comentarios y preguntale a Claude que te explique las partes que no entendés.

La regla de oro: Claude escribe el primer draft, vos sos el responsable del código final.

El setup que te recomiendo

Si trabajás seguido con Claude en proyectos, creá un archivo CONTEXT.md en tu repo con:

• Qué hace el proyecto
• El stack tecnológico
• Convenciones de código que usás
• Qué ya está implementado

Cada vez que empieces una sesión nueva, pegale ese contexto primero. Claude "recuerda" todo lo que está en la conversación, así que cuanto mejor sea el contexto inicial, mejor va a ser todo lo que venga después.

Arrancá hoy con esto: agarrá el último bug que te trabó más de una hora, describilo con contexto real usando el formato que vimos, y fijate la diferencia. Después no vas a querer volver a hacer preguntas vagas nunca más.