Errores a evitar en una hackatón

El error más común no es escribir un mal prompt, sino enviar comandos demasiado pronto, antes de haber definido claramente qué se quiere construir. La velocidad de la plataforma puede engañar a los participantes para que se salten la etapa de pensar, lo que los lleva a tener que arreglar lo que un solo prompt bien estructurado podría haber logrado.

En el otro extremo: dedicar la mitad de la hackatón a documentar. Acá no buscamos un producto de software completo ni complejo con documentación extensiva. Un producto funcional, aunque sea mínimo, es lo que te permite enfrentarte a la realidad: testear, validar y mostrar. Sin algo en pantalla, no hay aprendizaje.

Es tentador escribir una instrucción gigante que describa cada página, característica e interacción al mismo tiempo. Pero los prompts masivos abruman al modelo, que termina adivinando los detalles no especificados. El resultado es un producto a medias en muchos aspectos, que requiere más tiempo para corregir que para avanzar.

Es mucho más efectivo construir pieza por pieza, como bloques de Lego.

Un error habitual es empezar a modificar colores, fuentes y sombras justo después de generar la estructura inicial. Como las siguientes fases de desarrollo —añadir lógica, bases de datos o formularios— van a cambiar la distribución, el trabajo de diseño prematuro suele perderse.

La regla principal: primero el esqueleto, luego la función, al final el pulido.

Muchos participantes son demasiado precavidos y se demoran decidiendo si su prompt es correcto antes de enviarlo. Eso los frena considerablemente. La herramienta tiene un historial como red de seguridad: si el resultado sale mal, podés revertir el proyecto a la última versión funcional con un par de clics. Probá, observá, ajustá.

Usar el modo incorrecto para una tarea es una de las principales razones por las que se agotan créditos innecesariamente. Conviene tener claros los tres:

• Plan mode para pensar y estructurar antes de construir.
• Build mode para construir.
• Visual Edit para pequeños retoques visuales sin gastar tokens en cambios grandes.

A nivel técnico, es muy frecuente añadir sistemas de inicio de sesión (autenticación) pero omitir las políticas de seguridad a nivel de fila (Row-Level Security). La autenticación sin RLS es como tener la puerta principal cerrada pero todas las habitaciones por dentro abiertas de par en par: cualquier usuario puede ver o borrar los datos de otros.

Intentar lograr la perfección en un evento de tiempo limitado, en lugar de publicar una versión funcional, es una trampa habitual. Una aplicación que funciona —aunque tenga detalles por pulir— impresiona mucho más que un diseño perfecto que nunca llega a tener una URL en vivo.

Una hackatón de 3 a 4 horas es mucho más breve que la tradicional de 54 horas que parte un viernes y termina un domingo. Por lo mismo, más allá de la buena onda y de compartir experiencias, es importante que las personas avancen para lograr materializar su proyecto. La conversación es valiosa; el código en pantalla, también.