Cómo funciona tu app por dentro
Ya tienes tu prototipo. De acá en adelante lo vas a convertir en una herramienta de verdad. Esta página te explica, en cristiano, qué es cada cosa que vas a ir escuchando.
Cuatro cosas que conviene tener claras antes de construir de verdad. Son quince minutos y te ahorran la sensación de estar apretando botones sin saber qué pasa.
Cómo se arma tu app, según la que elegiste
No todas las apps llevan las mismas piezas. Estas son las cinco formas que salen de los retos del Laboratorio, de la más simple a la más completa. Abre la tuya y dale play para ver por dónde viaja la información.
Los botones y la lista. Corre en su computadora, no en la tuya.
Rosa hace el mismo viaje, desde su computadora, y por eso ve lo que marcó Ana.
Tiene tus archivos guardados y se los da a quien entre. No decide nada.
¿Esta persona puede? ¿el dato tiene sentido? Acá se decide, lejos de sus manos.
Acá queda de verdad, y por eso lo ven todas.
Toma tu plantilla, le mete los datos en los espacios y devuelve el PDF. Puro código. Un worker es cualquier ayudante que hace lo pesado por detrás, para que la pantalla no se quede congelada esperando.
Tu servidor le pregunta y él responde. No es un paso más de la cadena: es una consulta que se hace en el medio, y hay que esperar la respuesta para seguir. Tarda segundos y cobra por cada vez.
El PDF armado, con los datos de este caso puestos en su lugar.
Esta app no guarda ni decide nada.
Fíjate en algo: las piezas siempre son las mismas y siempre están en el mismo lugar. Lo único que cambia entre una app y otra es cuántas necesitas. Por eso da igual si es un checklist, Netflix o el banco: por dentro se parecen mucho más de lo que uno cree.
Frontend y backend, la línea que divide todo
De todas las palabras que vas a escuchar, estas dos son las que más se repiten. La regla es corta: si lo puedes ver, es frontend. Si tiene que ser verdad para todos, es backend.
La misma pantalla, dos veces. A la izquierda como la ve Ana. A la derecha, la maquinaria que hace que eso sea verdad.
La trampa clásica, y te va a pasar: Claude esconde un botón en la pantalla para que cierta gente no lo vea, y tú piensas "listo, ya está protegido". No está protegido. Cualquiera puede abrir las herramientas del navegador y hacerlo aparecer de nuevo.
Un candado dibujado no es un candado. La seguridad siempre va en el backend. Si dudas, pregúntale directo: "esta regla, ¿está en el frontend o en el backend?"
Git y GitHub, tu botón de deshacer
Esto lo instalas antes de abrir Claude Code, así que conviene tenerlo claro desde ya. Son dos cosas con nombre parecido que no son lo mismo, y confundirlas es lo más normal del mundo.
Git es un programa
Se instala en tu computadora y su único trabajo es llevar la cuenta de cada cambio en tu carpeta. Es el control de cambios de Word, pero para todos los archivos de tu proyecto a la vez, y sin que se vea horrible.
GitHub es una página
Es donde esa cuenta se guarda en internet. Un Google Drive para código, con el historial completo. Si se te pierde la laptop, tu proyecto sigue existiendo.
Repositorio, o "repo" para los amigos, es simplemente la carpeta de tu proyecto ya conectada a esa memoria. Cuando alguien te diga "créate un repo", te está diciendo "hazte la carpeta con memoria".
Se crea en github.com/new y toma treinta segundos. Se hace una sola vez por proyecto.
Y lo que más vas a escuchar: el commit
Un commit es guardar un punto al que puedes volver. Le pones una nota corta de qué cambiaste, y queda ahí para siempre. Es el punto de guardado del videojuego: si más adelante algo explota, vuelves a la última partida que funcionaba en vez de empezar de cero.
No los vas a escribir tú. Claude los hace por ti, pero te va a avisar cada vez: "voy a hacer un commit". Cuando lo diga, ya sabes que te está poniendo un punto de retorno.
Toca cualquier punto y mira para qué sirven
Sin estos puntos, cuando algo se rompe no sabes qué tocaste ni cómo devolverlo.
Si usas Windows y la app de escritorio: instala también Git para Windows y reinicia la app. Si no lo haces, la pestaña Code simplemente no abre y vas a pensar que se rompió tu computadora. No se rompió, le falta Git.
Si usas la versión web en claude.ai/code, no instalas nada: creas el repo en GitHub, instalas la conexión en github.com/apps/claude, y listo.
Las cuatro palabras de Git que vas a escuchar
- Commit. Guardar un punto al que puedes volver. Es el punto de guardado del videojuego.
- Push. Subir esos puntos a GitHub, o sea a internet. Hasta que no haces push, solo existen en tu computadora.
- Rama. Una línea paralela para probar algo sin tocar la versión buena. Si funciona la juntas, si no, la botas y no pasó nada.
- Repositorio privado. Que solo tú lo ves. Ponlo privado siempre, salvo que quieras mostrarlo al mundo a propósito.
No tienes que escribir ninguno de estos comandos a mano. Claude los corre por ti. Pero cuando te diga "voy a hacer un commit", ya sabes que te está poniendo un punto de retorno.
Así se construye con IA hoy
Vas a escuchar estas cuatro palabras por todos lados. No son modas que compiten entre sí: son capas que se van sumando. Y lo bueno es que tú ya vas por la primera.
Le hablas y ves qué sale
vibecodingDescribes lo que quieres, te aparece, lo miras, pides el cambio. Sin plan, sin documento, a puro ojo. Es rapidísimo para llegar a la primera versión de algo, y es una manera perfectamente válida de empezar.
Esto es exactamente lo que hiciste con tu prototipo
Escribes el qué antes del cómo
spec driven developmentAntes de construir de verdad, escriben juntos un documento con qué se va a hacer, con qué tecnología y en qué orden. Suena burocrático y no lo es: es donde discutes barato. Cambiar una línea en ese documento cuesta un minuto. Cambiarla cuando ya está construido cuesta una tarde.
Es tu siguiente paso, el bloque 5
Le pones barandas al proyecto
harness engineeringEscribir buenos mensajes no alcanza. Lo que hace que una app aguante es lo que dejas montado alrededor: pruebas que corren solas, una copia donde experimentar, y las reglas de tu proyecto escritas. Como el arnés de un escalador: no te impide subir, te evita el golpe si resbalas.
Es "el arnés", el bloque 8
Cierras el ciclo para que se revise solo
loop y context engineeringEl nivel donde el agente no solo hace, sino que comprueba su propio trabajo antes de decirte que terminó. Corre las pruebas, ve que algo falló, lo arregla y vuelve a probar, sin que tú estés revisando cada vuelta. Para eso necesita dos cosas: las barandas del punto anterior, y buen contexto sobre tu proyecto.
Se activa solo si armaste el arnésLa frase para llevarte: el vibecoding te lleva rápido a lo primero. Las otras tres capas son las que hacen que no se te caiga. Nadie te está diciendo que dejes de hablarle nomás. Te están diciendo que le pongas piso.
Esta parte no se lee de corrido. Abre cada bloque cuando llegues a ese momento con tu agente.
La spec y las tres preguntas incómodas
La spec es el documento técnico de tu herramienta. El plan del principio decía qué queremos. La spec dice cómo se hace: qué se construye exactamente, con qué tecnología y en qué fases.
Y en ese mismo momento aterrizan tres preguntas que da flojera hacerse:
💸 ¿Cuánto vas a gastar?
Si hay servicios que cobran por uso o suscripción, se define el techo ahora. No cuando llegue el recibo.
🏢 ¿Qué te deja hacer tu organización?
Hay lugares donde no puedes instalar programas, ni sacar datos, ni usar ciertos servicios. Mejor saberlo antes.
🔑 ¿Necesitas login de verdad?
Que cada quien escriba su nombre para entrar no es lo mismo que un login con contraseña. Uno toma minutos, el otro toma rato.
Ahora quiero la spec: qué vamos a construir exactamente, con qué tecnología y en qué fases. Y dime qué me va a costar, qué límites técnicos tengo y si necesito un login de verdad o no.
Si la spec te sale enorme, recórtala. Es la señal más común de que te estás complicando. Pregúntate qué es lo mínimo que ya te sirve el lunes, y manda lo demás a una fase 2. Agregarle cosas a algo que ya funciona es rapidísimo. Terminar algo que nunca funcionó es lo difícil.
La base de datos, o dónde vive la información
Es el lugar donde tu herramienta guarda las cosas para que no se pierdan al cerrar la ventana. Tu prototipo no tenía: por eso, cuando recargabas la página, todo lo que escribiste desaparecía. Ese es exactamente el problema que resuelve.
La típica: la relacional
Es un Excel con superpoderes. Tienes tablas, cada tabla tiene columnas (los campos) y filas (los registros). El superpoder es que las tablas se pueden relacionar entre sí, y de ahí el nombre.
Así se ve tu checklist por dentro. Son tres tablas, y las rayitas son las relaciones: eso es todo lo que significa "relacional".
Las columnas de color son las llaves. El id identifica cada fila sin repetirse nunca. Y proveedor y de no guardan el nombre: guardan el id de la fila que está en la otra tabla. Por eso «Textiles SAC» está escrito una sola vez en toda tu herramienta: si mañana cambia de razón social, lo corriges ahí y se arregla en todos lados.
Y existen otras, para otras cosas
La relacional te va a servir para casi todo lo que hagas este año. Pero conviene que sepas que hay más, porque te las van a nombrar.
De documentos
En vez de tablas parejas, guarda fichas y cada ficha puede tener campos distintos. Sirve cuando la información es despareja, como perfiles o publicaciones. Mongo y Firebase son de este tipo.
De clave y valor
Un casillero gigante: le das una llave, te devuelve una cosa, rapidísimo. No sabe hacer nada más y por eso vuela. Se usa para acelerar lo que se consulta mil veces. Redis es la típica.
Vectorial
Busca por parecido, no por igual. Le preguntas "qué proveedor se parece a este" y encuentra los cercanos aunque no compartan ni una palabra. Es la que se usa cuando le enseñas tus documentos a una IA. Guárdate el nombre, reaparece en el bloque 11.
De hojas de cálculo
Sí, Google Sheets puede funcionar como base de datos chiquita, y para algunas herramientas basta. Aguanta poco volumen y se pone lenta, pero si tu equipo ya vive ahí, es una salida válida para empezar.
RLS: quién puede ver qué fila
Estas son las siglas que más te van a repetir. Row Level Security, o reglas de acceso por fila. Deciden quién puede ver y tocar cada fila de tu base. Prueba los tres botones y mira qué ve cada quien.
| proveedor | paso | estado | de |
|---|---|---|---|
| Textiles SAC | Cotización | recibida | Ana |
| Transportes Sur | Contrato | pendiente | Ana |
| Empaques Lima | Cotización | en revisión | Rosa |
| Textiles SAC | Contrato | aprobado | Rosa |
Lo que hay que entender de RLS: la dirección de tu base de datos viaja dentro de tu página web, así que es visible. Eso no es un error de diseño, es como funciona. Lo que impide que un curioso lea todo no es que la dirección sea secreta, son estas reglas.
Por eso el RLS se planifica antes de crear las tablas, no después. Ponerlo después es reabrir todo.
Antes de crear las tablas, vamos a definir juntas quién puede ver y editar qué. Hazme las preguntas que necesites y después escribe las reglas de acceso por fila.
Tres cosas más que te van a preguntar sobre la base
"¿Usamos Supabase?" Supabase es un servicio que te da la base de datos ya lista y gratis para empezar, sin que tengas que montar nada. Cumple estándares de seguridad serios. Pero ojo: la seguridad de tus datos depende de cómo configures las reglas de acceso, eso no viene resuelto solo.
"¿Qué pasa si borro un proveedor que tiene tareas?" Hay que decidirlo a propósito: o se borran también sus tareas, o se quedan huérfanas, o el sistema no te deja borrarlo hasta que limpies. Las tres son válidas según el caso. Lo que no puede pasar es que nadie lo haya decidido.
"¿Metemos datos reales?" Mientras construyes, trabaja con datos inventados. Cuando la herramienta ya funcione y esté revisada, recién ahí decides si le conectas información de verdad. Nada de datos personales de clientes, contraseñas ni números de cuenta el primer día.
Construir de verdad
Acá tu herramienta deja de ser una maqueta. Es el momento en que los datos empiezan a guardarse de verdad y la lógica empieza a existir de verdad.
Antes: el prototipo
Se veía y se tocaba, pero por dentro no había nada. Los datos eran de mentira y se borraban al recargar. Servía para decidir si te gustaba.
Ahora: la herramienta
Hay backend, hay base de datos, los datos quedan guardados y lo que Ana marca lo ve el resto del equipo. Ya es real.
El orden importa, y es este:
1. Primero el respaldo
El repo antes que el código. Suena al revés y no lo es: es el punto al que vuelves si algo explota. Si ya trabajas en la versión web, tu proyecto ya vive en un repo, no hay que crear otro.
2. Después el código
Claude escribe la lógica real y te va contando qué parte está armando. Es la parte donde más vas a leer y menos vas a escribir.
3. Y lo prueba antes de cantar victoria
Que diga "listo, funciona" no es lo mismo que haberlo probado. Si no te contó cómo lo probó, pregúntale.
Y los commits van todo el rato, en paralelo. No son un cuarto paso al final: cada avance que sirve se guarda en el momento, mientras construyen. Así, cuando algo se rompa, no vuelves al principio sino al martes a las 4.
La frase que más caro sale en esta etapa es "funciona en mi máquina". Tu herramienta tiene que funcionar en la computadora de Ana, en el celular de Rosa y a las once de la noche cuando tú estés durmiendo. Por eso se prueba, y por eso existe el bloque siguiente.
El arnés, lo que evita que se te caiga
Hacer una buena app no es solo escribir buenos mensajes. Igual de importante es lo que dejas montado alrededor. Pero antes del arnés hay algo más básico, y es dónde pruebas.
Primero: dónde rompes sin que nadie se entere
La regla más vieja del oficio, y la que más caro sale ignorar: nunca pruebes sobre la versión que está usando tu equipo. Pero no son dos lugares, como suele contarse. Son tres, y el del medio es justo el que casi siempre se salta.
Piénsalo como montar una obra de teatro.
🪞 Tu cuarto
tu rama · feature
Ensayas tu escena sola, frente al espejo. Te equivocas cuantas veces quieras. Nadie te está viendo, ni siquiera tu equipo.
🎭 El ensayo general
dev · staging
Todo el elenco junto, en el escenario de verdad, pero sin público. Acá recién descubres que tu escena choca con la de otro.
🎬 La función
main · producción
Con público sentado. La que abre Ana desde su trabajo. Acá no se experimenta: acá solo entra lo que ya se probó.
Un cambio nunca salta del cuarto a la función. Sube escalón por escalón, y cada escalón agrega una revisión. Por eso el del medio importa tanto: es el único lugar donde tu trabajo se encuentra con el de los demás antes de que alguien de verdad lo use.
El viaje de un cambio, paso por paso
Dale play y sigue el punto morado. Es el recorrido que hace cualquier cosa que construyas, desde que la empiezas hasta que la ve tu equipo. Se sube con una rama: una copia paralela del proyecto donde trabajas tranquila. Si el cambio funciona, la juntas. Si no, la botas y no pasó nada.
Nada llega a la función sin haber pasado por los dos escalones de abajo. Y si algo malo igual se cuela, ya sabes: hay commits, se vuelve al punto anterior.
El mismo error cuesta distinto según dónde lo cometas
Esta es la razón entera de que existan los tres escalones. Es el mismo error, exactamente el mismo, en tres lugares distintos.
🪞 EN TU RAMA
Cero
Botas la rama y listo. Ni siquiera hay que contarlo.
🎭 EN EL ENSAYO
Una tarde
Alguien lo ve, lo dice, se arregla. Molesta, pero se queda entre ustedes.
🎬 EN LA FUNCIÓN
Ana te escribe un domingo
Y lo peor no es el susto: es que mientras tanto los datos se movieron mal.
Para tu primera app del sábado no necesitas montar esto. Lo pongo porque es lo que vas a escuchar apenas alguien te hable en serio de desarrollo, y porque el día que tu herramienta la use gente de verdad, esto deja de ser opcional.
Tu código y tus datos son dos cosas distintas
Acá va la idea más importante del bloque, y es la que suele pasar de largo: las ramas protegen tu código, no protegen tus datos.
En el código siempre hay cómo volver atrás, porque cada commit es un punto de guardado. En los datos no hay Control+Z. Si un comando mal escrito borra una tabla de verdad, esos datos se fueron. Habrá respaldo, quizá, pero mientras tanto el trabajo de tu equipo está parado.
Por eso tu ambiente de prueba no solo tiene una copia del código: tiene su propia base de datos, con gente inventada. Se le dice base espejo. Misma forma, distinto contenido.
| Nombre | Correo | Monto |
|---|---|---|
| Juan Pérez | test@test.com | S/ 5.00 |
| Prueba Uno | qa1@test.com | S/ 5.00 |
| Prueba Dos | qa2@test.com | S/ 5.00 |
La puedes borrar entera un martes a medianoche. No se entera nadie, y se vuelve a llenar sola.
| Nombre | Correo | Monto |
|---|---|---|
| Ana T••••• | a••••@•••••.com | S/ 4,820.00 |
| Rosa Q••••• | r••••@•••••.com | S/ 1,150.00 |
| Édgar M••••• | e••••@•••••.com | S/ 9,300.00 |
Personas de verdad, plata de verdad. Acá no se practica nunca.
Misma estructura, distinta gente. Y son dos razones separadas, las dos fuertes: una es que en los datos no hay deshacer. La otra es que esa información no es tuya — es de Ana, de Rosa, de Édgar — y nadie practica con los datos de otro.
Guardar, respaldar y publicar no son lo mismo
En el bloque 3 viste commit y push. Falta el tercero, y es el único que de verdad saca algo al mundo.
commit
Guardas un punto. Te protege de ti misma: si mañana rompes todo, vuelves acá.
push
Subes esos puntos a GitHub. Te protege de que se te caiga la laptop, y deja que tu equipo vea en qué andas.
deploy
Publicas la app. Este es el único que sale al aire. Los otros dos no publican nada.
La confusión clásica es pensar que subir a GitHub ya es publicar. No lo es: GitHub es un armario con historial, no un escenario. Puedes tener ahí cien versiones y que tu equipo siga viendo la de la semana pasada.
Ahora bien, sí se puede conectar la manguera: “cuando algo entre a main, publícalo solo”. Se llama deploy automático y es comodísimo. Pero es una decisión que tú tomas, no algo que venga puesto. Y si la tomas, tenlo clarísimo: a partir de ahí, el push a main es el botón de publicar.
Cuando el deploy es automático, lo que te salva ya no es un humano diciendo “espera”. Son las pruebas automáticas: se configura para que solo publique si todas pasan. Si algo falla, no sale nada. Por eso el arnés y el deploy automático van juntos — el segundo sin el primero es manejar sin frenos.
Y ahora sí: el arnés completo
Los ambientes son una de las piezas. Estas son las cuatro juntas. Como el arnés de un escalador: no te impide subir, te evita el golpe si resbalas.
🎭 Ambientes separados
Los tres escalones que acabas de ver, y cada uno con su propia base de datos.
✅ Pruebas automáticas
Chequeos que corren solos y confirman que todo lo que ya funcionaba sigue funcionando después de cada cambio. Sin esto tendrías que revisar la app entera a mano cada vez, y no lo vas a hacer.
📄 CLAUDE.md, tus reglas
Un archivo en español normal donde quedan escritas tus decisiones fijas, para que Claude no las contradiga tres días después. Cosas como "explícame siempre en simple" o "mis colores son estos". Es el archivo que más rinde de todos.
🪝 Hooks
Gatillos automáticos: cuando pasa algo, se dispara otra cosa sola. El más útil corre tus pruebas cada vez que se toca el código, sin que tengas que acordarte.
Y dos revisiones que ya vienen incluidas, no hay que instalar nada. /code-review busca errores y cosas que se pueden simplificar. /security-review busca huecos de seguridad. Este último córrelo siempre antes de publicar.
Se rompió algo. ¿Qué te salva?
Seis situaciones que te van a pasar. Toca cada una y fíjate cuál de las piezas es la que te levanta.
Lo que van a decir, y qué significa
Ya entendiste el mecanismo. Esto es para que la próxima vez que alguien suelte una de estas frases, sepas de qué escalón está hablando.
Camino corto o camino largo
Esto se decide antes de escribir código, no al final. Armar el arnés después es rehacer trabajo.
Camino corto
Construyes tu app y la usas. Igual queda respaldada en GitHub, así que si algo se rompe se puede volver atrás.
- Repositorio con commits
- Archivo CLAUDE.md con tus reglas
Camino largo
Le armas las barandas antes de construir. Toma más rato y consume más cuota, pero después le cambias cosas sin susto.
- Todo lo del camino corto
- Los tres ambientes separados
- Una base espejo con datos inventados
- Pruebas automáticas
- Un hook que las corre solo
La excepción que no se negocia: si tu app va a guardar datos de otras personas (nombres, contactos, notas, información de clientes), la base espejo y la revisión de seguridad entran igual, elijas el camino que elijas. Es corto de hacer, y es lo que evita que se filtre información que no es tuya.
Ármame las barandas del proyecto: los ambientes separados con su base espejo de datos inventados, pruebas automáticas, las reglas del proyecto y un hook que revise el código en cada cambio. Explícame cada pieza antes de armarla, y dime cuál de las ramas dispara una publicación.
Publicarla y tener tu link
El momento bonito. Hasta ahora tu herramienta vivía en tu computadora. Publicar es ponerla en internet para que cualquiera con el link entre. Son tres piezas, y ya las conociste en el bloque 2.
Servidor
Una computadora que está siempre prendida y conectada, esperando que alguien entre. Tu laptop no sirve para esto: la cierras y se acabó la app para todo el mundo.
Hosting
La empresa que te alquila ese servidor y se encarga de mantenerlo prendido. Para lo que vas a hacer hoy, hay opciones gratis que alcanzan de sobra.
Dominio
La dirección que la gente escribe. Sin dominio propio te dan una gratis, larga y fea, y funciona igual. Comprarte una bonita cuesta poco y se hace después.
Dos cosas antes de darle publicar:
Corre /security-review. Toma dos minutos y es la diferencia entre publicar tranquila o enterarte de un problema por el camino difícil.
Y revisa que no hayan quedado llaves o contraseñas dentro del código. Esas van en un archivo aparte que no se sube. Pregúntale directo: "¿hay alguna llave o contraseña metida en el código que se vaya a subir?"
Publícalo para que quede con un link real que pueda compartir con mi equipo. Antes de publicar, corre la revisión de seguridad y confírmame que no hay ninguna llave ni contraseña dentro del código.
Nada de esto lo necesitas hoy. Pero todas vuelven a esta parte, casi siempre la misma semana.
Por qué tú tienes que revisar
Claude se equivoca. No mucho, pero se equivoca. Y lo hace con una seguridad y un aplomo impecables, que es justamente lo que lo vuelve peligroso. Si algo sale raro, no eres tú.
Las cuatro señales de que conviene parar y preguntar:
Dice "listo, funciona" sin contarte cómo lo probó
Respuesta: "¿cómo sabes que funciona? Pruébalo y muéstrame el resultado."
Nombra un archivo o una función que nunca viste
Respuesta: "muéstrame ese archivo." A veces existe y no te diste cuenta. A veces no existe.
Cambió algo que tú no pediste
Respuesta: "muéstrame exactamente qué cambió, y por qué tocaste eso". A veces era necesario y no te avisó bien.
Te da la razón demasiado rápido
Si le dices "creo que está mal" y de una te dice "tienes razón" sin revisar, desconfía. Pídele que revise de verdad antes de cambiar nada.
Cinco cosas que hace, y conviene saber
Ninguna es un defecto que se arregle. Son su forma de trabajar, y saberlas te cambia cómo le pides las cosas.
1. Prefiere que funcione a que esté ordenado
Por detrás te deja código enredado, tablas mal armadas y permisos a medias. Se llama deuda técnica y no se nota hasta que quieres cambiar algo.
2. Te da la razón aunque estés equivocada
Si propones algo, se acomoda. Terminas decidiendo tú cosas de diseño que no sabes decidir. Pídele: "dame el mejor argumento en contra de mi idea".
3. Rellena los huecos sin avisar
Si tu pedido es ambiguo no pregunta: elige. La moneda, la zona horaria, quién ve qué. Decisiones tuyas tomadas por defecto, y te enteras después.
4. Repite en vez de reutilizar
Le pides algo parecido a lo que ya existe y escribe una copia nueva. A los diez pedidos, la misma lógica en cinco sitios y un error que hay que arreglar cinco veces.
5. Pierde el hilo si la conversación se alarga
La memoria se llena y olvida decisiones del principio. Puede contradecir con total naturalidad algo que acordaron hace dos horas.
Ordenado por arriba, enredado por abajo. Se sostiene, hasta que quieres mover algo.
Cómo lo mantienes a raya, sin volverte loca:
Pregunta directo
Al cerrar algo grande: "¿qué deuda técnica dejamos acá?". Te la lista sin problema. Sola no te la cuenta.
Corre las revisiones
/code-review para el desorden y /security-review para los permisos flojos.
Mira qué cambió
/diff te muestra exactamente qué se tocó. Así cachas lo que se metió sin que lo pidieras.
Refresca la memoria
/compact resume la conversación sin perder el hilo. Úsalo cuando notes que se está olvidando.
Escríbelo en CLAUDE.md
Lo que te canses de repetir va ahí. Lo lee cada vez que abres el proyecto, y ya no se olvida.
Decide tú qué se paga
No todo hay que arreglarlo. Seguridad y permisos sí, siempre. El orden, cuando vayas a construir encima.
Tu trabajo acá no es escribir código. Es decidir y revisar. Qué se construye, qué queda fuera, quién puede ver qué. Eso no lo puede hacer nadie por ti, porque solo tú sabes cómo funciona tu área.
Cuándo le metes IA a tu app, y cuándo no
Ojo con esta confusión, que es facilísima de tener: usar Claude para construir tu app no significa que tu app tenga IA por dentro. Son dos cosas distintas. Claude es el albañil. Meterle IA adentro es otra decisión, aparte, y casi siempre viene después.
El código siempre da la misma respuesta. La IA da una de varias posibles, y por eso sirve para unas cosas y para otras no.
La regla, en una frase: si la respuesta correcta siempre es la misma, eso es código normal, no IA.
Toca cada caso de tu checklist y adivina cuál es cuál:
Cómo se conecta, si decides que sí
Tu app le manda el texto al modelo por una API, y el modelo le devuelve la respuesta. Para eso necesitas una llave de API, que sacas del panel de ese servicio. Y desde ese momento, cada vez que tu app pregunta algo, eso cuesta plata. No es como tu suscripción de 20 dólares: se paga por uso.
Los cinco riesgos, sin drama pero sin adornos
💸 El costo se te escapa
Cada pregunta cuesta centavos. Diez preguntas al día son centavos. Una app con un error que pregunta en bucle son cientos de dólares en una noche.
🎭 Inventa con toda seguridad
Es lo que llaman alucinación: te da un dato falso con la misma tranquilidad con que te da uno cierto. No te avisa cuando no sabe.
🎲 No siempre responde igual
El mismo pedido dos veces puede dar dos respuestas distintas. Por eso no se prueba como el código normal, donde 2+2 siempre da 4.
🐢 Se demora
Una consulta a la base tarda un parpadeo. Una al modelo puede tardar varios segundos. Si lo pones en el medio de la pantalla, la app se siente lenta.
📤 Los datos salen de tu casa
Lo que le mandas al modelo viaja a un servicio de un tercero. Antes de mandarle información de clientes o del negocio, revisa qué te deja hacer tu organización.
🔌 Dependes de alguien más
Si ese servicio se cae, se pone lento o sube de precio, tu app se entera. Tu herramienta no debería morirse por eso.
Las cuatro protecciones que sí o sí
1. Valida lo que te devuelve
Si le pediste un número del 1 al 5, revisa que sea un número del 1 al 5 antes de guardarlo. Nunca guardes a ciegas lo que dijo.
2. Ponle tope de gasto
Un límite mensual y una alerta. Se configura en el panel del servicio en dos minutos, y te ahorra el susto.
3. Ten un plan B
Si el servicio no responde, tu app debe seguir funcionando y avisar "esto no se pudo resumir", no quedarse trabada en blanco.
4. Que nunca sea la última palabra
En decisiones que importan (aprobar, pagar, rechazar), la IA propone y una persona confirma. Sugerir sí, decidir sola no.
¿Te acuerdas de la base vectorial del bloque 6? Acá es donde aparece. Cuando quieres que la IA responda sobre tus documentos y no sobre lo que sabe del mundo, se guardan tus textos en una base vectorial, se busca el pedazo parecido a la pregunta, y ese pedazo se le pasa al modelo. Eso es todo lo que significa la sigla RAG cuando la escuches.
Conectarla con las herramientas que ya usas
Tu app no tiene que vivir sola. Puede leer tu Drive, escribir en tu Sheets, mandar por Slack o crear tareas donde ya trabajas. Y Claude Code también puede hacerlo por su cuenta, sin construir nada.
🚪 API
La puerta de servicio de una plataforma. La puerta principal es la pantalla donde tú haces clics. La API es la lateral, hecha para que otros programas entren a pedir cosas sin pasar por la pantalla.
🔑 Llave de API
La contraseña de esa puerta. La sacas del panel de la herramienta. Trátala como contraseña de verdad: no la pegues en chats ni la subas a GitHub.
🔌 MCP o conector
Un traductor ya armado y estandarizado. Es el enchufe universal: si la herramienta tiene MCP, conectarla es rapidísimo. Si no lo tiene, igual se entra por su API, solo que hay que armarlo a mano.
Y lo otro que hace Claude Code, sin construir nada: entra a las herramientas que ya usas y actúa en tu nombre. Ordena tu Drive, arma un reporte desde tu Sheets, revisa correos. Eso son unos quince minutos, no un proyecto.
Antes de conectar cualquier cosa, pregúntale primero: "dime si te puedes conectar a esta herramienta, qué pasos implica, qué podría hacer desde ahí, y qué permisos y riesgos están implicados." Y si te convence, recién ahí conectas.
Y el lunes, ¿qué?
Tu app existe y tiene un link. Lo que sigue no es un curso nuevo: es el mismo ciclo, otra vez, cada vez que quieras mejorar algo.
🔁 Para cambiarle algo
Vuelves al mismo lugar y se lo pides. Junta varios cambios en un solo mensaje: rinde muchísimo más que pedirlos de uno en uno. Y antes de darlo por bueno, /code-review.
🧯 Si algo se rompió
No entres en pánico ni empieces a borrar. Tienes commits. Dile "esto se rompió, volvamos al último punto que funcionaba", o usa /rewind.
📊 Para cuidar tu cuota
/usage te dice cuánto llevas. Y un truco: no tienes que casarte con un plan caro, puedes subir a 100 dólares un solo mes mientras estás metida de lleno, y volver a 20 después.
🧠 Para que no se le olvide
Todo lo que te canses de repetir, va al CLAUDE.md. Y si hay algo que haces seguido, pídele que lo guarde como habilidad y lo llamas con una barra.
Los comandos con barra que más vas a usar
Cuando escribes una barra / estás llamando a una habilidad: un mensaje reutilizable, ya escrito y probado. En vez de explicarle desde cero, invocas la receta con una palabra.
- /init arranca el proyecto y crea el CLAUDE.md.
- /plan lo pone a planificar antes de tocar código. Útil antes de un cambio grande.
- /code-review revisa lo que se acaba de escribir.
- /security-review busca huecos de seguridad. Antes de publicar, siempre.
- /diff te muestra exactamente qué cambió.
- /rewind el botón de deshacer, para el código y la conversación.
- /context cuánta memoria de conversación queda.
- /compact resume la conversación para liberar memoria sin perder el hilo.
- /usage cuánto has consumido.
El decálogo del desarrollador con IA
Diez reglas para construir con orden, seguridad y sin sustos. No son restricciones: son los hábitos que separan un experimento que se rompe de una herramienta en la que se puede confiar. Cada una dice lo que no hay que hacer y lo que sí.
No expondrás tus llaves secretas
Escribir claves, contraseñas o tokens dentro del código, o subirlos a GitHub. Una llave en un repositorio es una llave pegada en tu puerta, y si esa llave gasta dinero, te vacían la cuenta.
Guardarlas en un archivo .env aparte, agregado al .gitignore. En el código solo nombras la llave, nunca escribes su valor.
Versionarás todo: código y base de datos
Trabajar sin respaldo ni historial, ni cambiar la base "a mano" directo en producción, donde un error no se deshace.
GitHub desde el día uno, y cada cambio de la base como una migración numerada, para poder reconstruirla y saber qué cambió.
No construirás monolitos
Amontonar todo en un archivo gigante que mezcla la pantalla, la lógica y los datos. Ni funciones enormes que hacen diez cosas a la vez.
Dividir en piezas pequeñas, cada una con una sola responsabilidad. Más fácil de entender, arreglar y reutilizar.
Protegerás los datos de las personas
Dejar las tablas abiertas para que cualquiera lea o escriba. Los datos de la gente son una responsabilidad legal, no un detalle.
Activar el RLS con permisos por rol, definir bien tus columnas, y pedir solo los datos que de verdad necesitas.
No gastarás de más
Llamar sin control a servicios que cuestan, sin límite ni freno. Un bucle descontrolado te vacía la cuenta en minutos.
Poner tope de uso y un freno de emergencia, medir el consumo, y elegir la opción más barata que resuelva el problema.
Harás pruebas
Dar por hecho que funciona porque "se ve bien" o porque lo escribió la IA. Ni mandar a producción sin probar.
Pruebas que revisen el código solas, y correrlas antes de publicar.
Nombrarás con claridad
Nombres genéricos como data, temp u obj, que no dicen nada y confunden a quien lee. Incluida tú, en un mes.
Nombres que se entienden solos: totalConPropina, listaDeClientes. El código se lee casi como una frase.
Considerarás la escala
Construir para millones cuando tienes diez usuarios, ni armar algo tan frágil que se cae al primer golpe de éxito.
Dimensionar según el uso real. Empezar simple y barato, y crecer cuando el uso lo pida.
Manejarás los errores y validarás lo que entra
Asumir que todo saldrá bien: que internet responde, que el archivo existe, que el dato llega correcto.
Poner una red de seguridad en lo que puede fallar, con mensajes claros y un plan B. Y revisar todo dato que entra antes de usarlo.
No confiarás ciegamente
Aceptar en automático lo que propone la IA. Es probabilística: a veces suena muy segura y se equivoca.
Leer y entender qué hace antes de aceptarlo, sobre todo si toca dinero, datos o seguridad. Tú tienes siempre la última palabra.
Ya sabes de qué te están hablando
Y eso es la mitad del trabajo. La otra mitad es pedir, mirar y decidir. Si algo de acá no te quedó claro, pregúntaselo directo a tu Claude Code: dile "explícame esto más fácil" las veces que haga falta. No hay pregunta tonta.
Guía Tidú · Laboratorio Code · Cómo funciona tu app por dentro