8 años de anhelo, 3 meses para completarlo: la fórmula de los side projects que cambió la IA
(lalitm.com)- Una herramienta de desarrollo de alta calidad para SQLite que hacía falta desde hace mucho se completó en poco tiempo con ayuda de la IA
- La mayor dificultad fue construir el parser debido a la ausencia de una especificación gramatical oficial y a una compleja base de código en C
- Usando agentes de codificación con IA como Claude Code, la implementación inicial avanzó rápido, pero por el problema del código espagueti se decidió una reescritura basada en Rust
- La IA mostró gran eficiencia en generación de código, refactorización, apoyo al aprendizaje y mejora de UX, pero también trajo efectos secundarios como retraso en el diseño, desconexión con el código y adicción a la dependencia
- En conclusión, la IA es solo una herramienta para acelerar la implementación; el diseño y la dirección del software siguen siendo responsabilidad humana
Tres meses construyendo una herramienta de desarrollo para SQLite con IA
- Desde hacía mucho tiempo se quería una herramienta de desarrollo de alta calidad para SQLite, pero las herramientas open source existentes se quedaban cortas en confiabilidad, velocidad y flexibilidad
- Mientras se mantenía PerfettoSQL, había demanda de funciones como formateador, linter y extensión para editor, pero no existía una herramienta adecuada
- Se quería crear una nueva herramienta como proyecto personal, pero por la dificultad y la carga del trabajo repetitivo se fue posponiendo durante años
Dificultades del proyecto
- SQLite no tiene una especificación gramatical oficial ni una API de parser estable
- Internamente no genera un árbol de parseo, así que hubo que extraer directamente la lógica del parser desde el código fuente
- Había que mapear manualmente más de 400 reglas gramaticales, y escribir pruebas y depurar era un trabajo muy repetitivo y agotador
- La base de código en C de SQLite es compleja y densa, por lo que resulta difícil de entender
- La estructura es tan enredada que solo entender la API de tablas virtuales y su implementación tomó varios días
Proceso de desarrollo junto con la IA
- Desde finales de 2025 se empezó a usar de lleno Claude Code y otros agentes de codificación con IA
- Al principio se delegó a la IA la mayor parte del diseño y la implementación, avanzando con un enfoque de “vibe-coding”
- El resultado funcionaba, pero la base de código se volvió un código espagueti tan compleja que era imposible de mantener
- Después se reescribió todo en Rust para reordenar la estructura
- Se usó Rust en lugar de C para facilitar el desarrollo de componentes de nivel superior, como el validador y el servidor de lenguaje
- La IA se limitó a una “herramienta de autocompletado potenciada”, mientras que el diseño, la revisión y las pruebas fueron dirigidos directamente por la persona desarrolladora
- Se construyó un andamiaje para verificar lo generado por la IA, como linting, validación y automatización de pruebas
Lo que la IA hizo posible
-
Superar la inercia
- La IA divide el trabajo en problemas concretos, haciendo más fácil empezar
- En vez de “tengo que entender el parsing de SQLite”, se pasó a “voy a revisar el enfoque propuesto por la IA”, acelerando la ejecución
-
Velocidad de generación de código y refactorización
- Cuando los requisitos están claros, la IA escribe rápido código estándar y consistente
- En diseños no estándar (como la estructura del parser), más bien estorba y hace falta escribirlo directamente
- Tras generar grandes volúmenes de código, la refactorización continua es indispensable para mantener la calidad
-
Rol como asistente de aprendizaje
- La IA explicó en tiempo real conceptos nuevos como el algoritmo de formateo Wadler-Lindig
- También permitió entrar rápidamente en áreas menos familiares, como Rust o extensiones de VS Code
- Cuando se perdía el contexto del proyecto, consultas como “explícame este componente” permitían una recuperación inmediata del contexto
-
Mejora del nivel de acabado
- Redujo el costo de desarrollar funciones adicionales como extensión de editor, bindings para Python, playground en WASM y sitio de documentación
- Al bajar la carga de implementación, fue posible enfocarse en mejorar la UX, reforzando la experiencia de usuario en mensajes de error, diseño del CLI y más
Efectos secundarios del uso de IA
-
Adictividad
- Existe una estructura de recompensa tipo tragamonedas de “un prompt más” una y otra vez
- Cuanto más cansancio hay, peor se vuelve la calidad de los prompts, y los resultados empeoran, creando un círculo vicioso
-
Desconexión con la base de código
- A medida que aumenta el código generado por IA, se pierde la sensibilidad por la estructura detallada
- Cuando se pierde el contexto, las conversaciones con la IA también se alargan y se vuelven ineficientes
- Como solución, se adoptó el hábito de leer el código directamente justo después de generarlo y revisar “qué partes yo habría escrito distinto”
-
Retraso y erosión del diseño
- Como refactorizar es fácil, surge la tendencia a posponer decisiones clave de diseño
- Incluso con muchas pruebas, es difícil ocultar errores fundamentales de diseño, y al final puede hacer falta reescribir todo
-
Falta de sentido del tiempo
- La IA no entiende el contexto temporal ni el proceso de evolución del código
- Esto provoca ineficiencias, como repetir errores del pasado o volver a explorar problemas ya resueltos
- Puede compensarse con documentación, pero es difícil registrar por completo incluso la intención de diseño
La relatividad del uso de IA
- En áreas que se entienden a fondo, la IA sobresale y permite revisiones rápidas e iteración ágil
- Ejemplo: generar reglas del parser es eficiente porque hay una respuesta clara
- En áreas que se conocen parcialmente, sirve como herramienta de aprendizaje, pero requiere atención constante
- Ejemplo: aprender algoritmos de formateo
- En la etapa en que todavía no se sabe qué construir, más bien resulta perjudicial
- Ejemplo: en la fase de diseño de arquitectura puede generar bucles improductivos
- La IA es fuerte en problemas verificables (compilar y pasar pruebas),
pero débil en problemas sin respuesta correcta, como el diseño y la calidad de una API
Conclusión
- Haber podido materializar en 3 meses una herramienta para SQLite que se llevaba 8 años imaginando fue gracias a la IA
- Pero el proceso no fue una simple historia de éxito, sino que vino acompañado de los límites y el costo de depender de la IA
- La IA es un acelerador de implementación, pero no un sustituto del diseño
- Responde con precisión a preguntas técnicas, pero carece de historia, criterio y sensibilidad hacia el usuario
- La verdadera lección es que, aunque con la IA se pueda chocar contra la pared más rápido,
los humanos deben asumir la responsabilidad por la dirección del diseño y el “alma del software” - Lo que hace falta hacia adelante es compartir casos de proyectos capaces de soportar usuarios reales y mantenimiento real
- No simples experimentos, sino la acumulación de experiencias de desarrollo colaborativo con IA que sean realistas y sostenibles
1 comentarios
Comentarios de Hacker News
Me pareció refrescante ver una visión equilibrada sobre la programación con AI
Es una experiencia con la que probablemente se identificaría la mayoría de los desarrolladores serios: al principio te sorprende lo bien que la AI escribe código, pero después ves que la base de código terminó hecha un desastre de código espagueti
Algunos ni siquiera hacen code review y andan diciendo que “la programación manual ya se terminó”, mientras que otros concluyen que “programar con AI no sirve para nada”
Pero la realidad está en algún punto intermedio. La AI puede ser un gran acelerador de productividad, pero hay que integrarla bien al flujo de trabajo y mantener a las personas involucradas
Al principio era un prototipo, pero rápidamente evolucionó a un servicio real. Después sufrí bastante refactorizando y quitando código inútil
Aun así, gracias a ese prototipado rápido existe el producto actual. Claude fue útil para limpiar código, casi como una motosierra
Hace poco agregué un type checker con hooks de pre-commit y corregí 90 errores en solo 2 horas.
Programar con AI es impresionante, pero en código de producción sigue siendo indispensable la revisión y el criterio humano
Aun así, como este caso era un proyecto greenfield individual, es difícil aplicarlo de forma directa al desarrollo en equipo en general
De todas formas, si haces el prototipo con la idea de “tirarlo”, creo que hasta el código espagueti está bien.
El problema fue que el autor pensó erróneamente que podía convertir eso en un producto real.
Pero supongo que gracias a ese fracaso aprendió un diseño mejor
Primero te sorprendes, luego te decepcionas y al final encuentras un equilibrio.
Se ve como una especie de versión AI del modelo de Kübler-Ross
Claro que la calidad importa, pero ahora la calidad del código en sí está importando menos
Está aumentando la cantidad de código que no necesita mantenimiento, como las apps personales, y la capacidad de diseño de la AI también está mejorando rápido
Al final, la “verdad de programar con AI” sigue cambiando y esta tendencia no se va a detener
Primero, la mayoría de los desarrolladores simplemente disfrutan en silencio una mejora de productividad de entre 2% y 50% y no sienten necesidad de hablar del tema
Segundo, la programación real con AI es aburrida y poco vistosa.
Al final, un LLM no es más que una herramienta para “no tener que memorizar boilerplate”, pero la esencia de programar sigue siendo la misma
A mí también me pasó lo mismo con la generación de tests usando AI
Tener más tests te da tranquilidad, pero en realidad no logran cubrir bien los casos límite
Sobre todo al refactorizar código legacy sin tests, los tests que crea la AI solo verifican que funcione, pero no garantizan la consistencia del comportamiento
En apps de React este problema fue especialmente grave. Por eso estoy pensando en combinar BDD + desarrollo basado en especificaciones con AI
En unit tests la clave está en diseñar mocks creativos; en integration tests, en manipular los datos; y en tests e2e, en la estabilidad de los selectores
Ese tipo de juicio creativo sigue siendo algo que a la AI todavía le cuesta alcanzar
Incluso con 97% de cobertura, seguía habiendo muchos huecos en el espacio lógico de entradas.
Últimamente he automatizado con agentes de AI técnicas clásicas como equivalence partitioning y las apliqué a 60 modelos
La clave es aislar al máximo las funciones puras y probar de forma completa el mapeo entre entrada y salida
A largo plazo, creo que el verdadero valor de la AI estará en su papel como herramienta para amplificar la comprensión
Por ejemplo, analizando las reglas de código C complejo y documentando su estructura
Si esta extracción de conocimiento se vuelve posible, se podrá automatizar desde documentación de APIs y mapeo de reglas hasta análisis de bugs y optimización de arquitectura
Al final, más que generar código, va a importar más la capacidad de estructurar el contexto
① el tipo oráculo omnisciente, que solo lanza requisitos y hace que se genere toda la app
② el tipo herramienta de apoyo, que revisa línea por línea dentro del IDE
Para construir servicios sostenibles, la opción ② es mucho más realista
Me impactó la frase: “La arquitectura emerge cuando interactúan piezas locales”
La AI es fuerte en la ejecución local, pero débil en las etapas ambiguas del diseño
En realidad, esto también pasa con los desarrolladores humanos. El diseño es una secuencia de trade-offs sin una respuesta única
En particular, me ayudó mucho con el diseño de SQL para ClickHouse
Gracias al método de inclusión de SQL basado en plantillas que propuso la AI, pude reducir duplicación y mejorar el rendimiento
Quizá ese enfoque ya existía, pero sin AI me habría costado mucho más encontrarlo
Este texto resulta convincente porque incluye 250 horas de esfuerzo real
Creo que un proyecto de esta escala es un modelo realista de lo que hoy es la programación de sistemas asistida por AI
La expresión “programar con AI es como una tragamonedas” me representó por completo
En mi empresa también me dieron acceso ilimitado a agentes de AI, y cuando caes en el “solo un prompt más”
de pronto ya pasaron 12 horas. Tiene una capacidad de absorción casi adictiva
Probablemente este sea el momento más difícil para programar con AI
Hace 6 meses eran impensables cosas que ahora ya son posibles
Estoy trabajando en proyectos en varios lenguajes, y la AI produce código tan rápido
que ahora el cuello de botella es la velocidad de revisión
Cuando pasan cierta cantidad de tests, aparece la duda de “¿será suficiente con esto?”
Yo especifico en los prompts atributos de calidad como principios SOLID, acoplamiento y cohesión
Le pido ideas de refactorización a la AI y, si me convencen, solo digo “bien, hazlo”
Al final, lo importante es el arte de diseñar prompts
Pero creo que pronto la AI incorporará por defecto este tipo de guardrails de calidad
El lenguaje en sí no suele ser el cuello de botella del rendimiento, pero experimentar con lenguajes nuevos ayuda a aprender
Esto me recordó la filosofía de Fred Brooks de “haz uno para desecharlo”
La AI es ideal para construir rápido esa primera versión desechable
Esperar calidad de producción de inmediato es un enfoque ingenuo
Lo correcto es construir rápido, aprender y después refactorizar
También coincido en que cuando estás cansado, los prompts se vuelven ambiguos y los resultados empeoran
Me sorprendió saber que el parser SQL de SQLite no fue generado con lemon
Cuando porté pikchr a Go, primero trasladé lemon, pero SQLite ni siquiera construye un árbol de parser
Viendo la documentación de lemon, esto parece un caso de definición insuficiente del problema en la etapa de diseño
Yo también coincido totalmente con la conclusión de este texto
Es un buen ejemplo que muestra la realidad de programar con AI de forma honesta y sin exageraciones