Mi stack real de IA (y por qué cambia todo el tiempo)

Sale una lista nueva de "las 10 mejores herramientas de IA" cada semana. Ninguna te dice cuáles usa de verdad quien la escribió — ni, más importante, por qué las cambia.

Va la mía. Sin afiliados, sin relleno. Lo que abro un día normal, entre programar y correr una empresa remota:

Total: ≈ USD 150/mes. Suena a mucho hasta que lo comparas con las horas que me devuelve.

Pero acá está lo que quiero que te lleves, y no es la lista.

El stack no es el punto. La costumbre sí es el peligro.

Llevo 20 años programando. Si algo aprendí es que la herramienta que te salvó el año pasado puede ser la que te frena este. Y el enemigo número uno no es elegir mal — es quedarte con lo que usas por comodidad.

Por eso tengo una disciplina, casi un hábito: cada vez que sale un modelo nuevo, una técnica nueva, un enfoque distinto, lo pruebo. No para saltar a cada novedad brillante — la mayoría no se queda. Pruebo para no perderme la que sí importa. Porque en este campo lo que cambia no cambia despacio.

La costumbre es cómoda y cara a la vez: te deja usando algo peor sin darte cuenta, porque nunca miraste al lado.

Acá viene la parte difícil, la que casi todos saltan: hay que sacar el tiempo para probar, incluso cuando estás full con otras cosas. Y siempre estás full. Nunca va a llegar la semana tranquila para "ponerte al día con la IA". Si esperas ese momento, no llega.

Pero ojo — no es probar por probar. Eso es perder el tiempo con cara de productividad. Es probar con un propósito específico: una meta clara, una pregunta que quieres responder. "¿Esta herramienta me resuelve este dolor concreto?" "¿Este modelo local me sirve para esta tarea?" Sales del experimento con un sí o un no, no con más pestañas abiertas.

Tiempo reservado + propósito claro. Sin las dos cosas, experimentar es ruido.

Esto es lo que más me sorprendió, y casi nadie lo dice: las instrucciones que le das al modelo importan tanto o más que el modelo.

He visto a gente usar exactamente las mismas herramientas que yo, mismo modelo, misma suscripción, y sacar resultados malísimos. ¿La diferencia? Cómo lo instruyen. Qué contexto le dan. Cómo arman el "alrededor" del modelo: las reglas, los ejemplos, la forma de pedir las cosas.

Un modelo top mal instruido rinde peor que uno mediano bien manejado. Es como contratar al mejor del rubro y no explicarle qué necesitas, con qué datos, ni cómo esperas el resultado. Va a improvisar, y te va a decepcionar.

La buena noticia para ti: esto no se compra, se aprende. No depende de pagar el plan más caro. Depende de aprender a pedir bien: dar contexto, ejemplos de lo que quieres, y decir claro qué NO quieres. Ahí está la mayor parte del salto de calidad, y es gratis.

Durante un tiempo pagué y usé Cursor un montón. Era buena, no tengo nada malo que decir. Pero hace unos 6 meses probé Claude Code y Codex, me acomodó más su forma de trabajar, y me cambié. Seguí pagando Cursor un par de meses "por si acaso"… sin abrirla.

Ahí había dos errores. El obvio: pagar dos cosas que hacían lo mismo. El de fondo: si no me hubiera obligado a probar algo nuevo, seguiría en Cursor hoy, no porque sea la mejor para mí, sino porque ya estaba instalada la costumbre.

Tres reglas simples:

1. Primero el dolor concreto que se repite. Después la herramienta. Y si una nueva reemplaza a otra, cancelo la vieja el mismo día — no "por si acaso".

2. Saco tiempo para probar, aunque esté full — pero siempre con un propósito claro, no por probar. La mayoría de lo que pruebo no queda. Una de cada diez me cambia la forma de trabajar. Esa una paga las otras nueve.

3. Antes de culpar a la herramienta, reviso cómo se la estoy pidiendo. Nueve de diez veces el problema no es el modelo — soy yo dándole mal el contexto.

No copies mi stack — para cuando leas esto quizá ya cambió. Copia el hábito: elige un dolor semanal, mátalo con una herramienta, aprende a pedirle bien, y saca el tiempo para mirar qué apareció mientras tanto.

Mañana: por qué no uso un solo modelo de IA — y porque no tenemos que quedarnos con la respuesta del modelo como algo definitivo.