¿Qué aprenderás utilizando Kiro y Spec-Driven Development en tus proyectos de software?
¿Qué puede cambiar cuando empezamos definiendo requisitos, diseño y tareas en lugar de simplemente escribir código? En este artículo comparto lo que fui descubriendo al utilizar Kiro y Spec-Driven Development en uno de mis proyectos, desde la planificación hasta los cambios que aparecieron durante la implementación.
Kiro y Spec-Driven Development en tus proyectos de software
Cuando te animas a utilizar Kiro y Spec-Driven Development, piensas que es una IA más que te ayudará en tus proyectos. Lo interesante sucede cuando empiezas a darte cuenta de que algunos problemas que normalmente aparecen mientras programas pueden aparecer mucho antes.
Eso fue justamente lo que quería probar.
Hace poco empecé a utilizar Kiro para trabajar en uno de mis proyectos y decidí no usarlo simplemente como otra herramienta para generar código. Quise probar su enfoque de Spec-Driven Development y ver qué pasaba si primero intentaba definir mejor lo que quería construir.
No tenía claro si realmente iba a cambiar mi forma de desarrollar software. Así que decidí probarlo con un proyecto real.
¿Por qué probar Spec-Driven Development?
Normalmente, cuando tengo una idea para un proyecto, mi primer impulso es comenzar a programar.
Pienso más o menos en lo que quiero hacer, creo el proyecto y empiezo a construir.
El problema es que muchas cosas que no había pensado aparecen después.
"No funcionaba como lo esperaba."
"Creo que también necesitamos estos casos."
"¿Qué pasa si el usuario hace esto?"
Y entonces vuelvo al código, hago cambios y sigo avanzando.
Esta vez quise probar algo diferente.
En lugar de empezar directamente a implementarlo, utilicé un flujo basado en:
Requirements → Design → Tasks → Implementation
La idea parecía bastante sencilla. Lo interesante fue descubrir qué te obligaba a pensar durante cada etapa para que todo fuera acorde con lo que querías.
PASO 1: Empezar por los requisitos
El primer cambio fue probablemente el más sencillo de entender.
En lugar de decir:
"Quiero hacer esta aplicación."
tenía que explicar con más detalle qué debía hacer.
Y ahí aparecieron cosas que inicialmente no había considerado.
Por ejemplo, mientras trabajaba en un generador de badges para un evento, una de las funcionalidades era permitir que el usuario cargara una fotografía.
A simple vista, el requisito parecía ser simplemente:
"El usuario puede subir una foto."
Pero cuando intentas definir realmente cómo debería funcionar, aparecen más preguntas.
- ¿La fotografía puede moverse?
- ¿El usuario querrá hacer zoom a las fotos?
- ¿Qué pasa si la fotografía es demasiado pequeña?
- ¿Será mejor si mantengo el fondo original?
- ¿La posición de la fotografía debería mantenerse cuando cambio el formato del badge?
De repente, una funcionalidad que parecía bastante pequeña tenía muchas decisiones detrás.
Esto fue una de las primeras cosas que me hizo pensar que escribir requisitos no es solamente “hacer documentación”.
También es una forma de descubrir qué es exactamente lo que estás intentando construir.
PASO 2: El diseño me hizo pensar en cómo debería funcionar
Después de definir los requisitos, el siguiente paso fue pensar en el diseño.
Aquí empecé a pasar de:
"¿Qué quiero que haga?"
a:
"¿Cómo debería funcionar para conseguirlo?"
En el caso del generador de badges, tenía que considerar diferentes formatos.
Por ejemplo:
- 4:5 — 1080 × 1350
- 9:16 — 1080 × 1920
Esto parecía un detalle de diseño, pero terminó afectando también al comportamiento de la aplicación y la calidad de las imagenes que se iban generando.
La fotografía no podía simplemente estirarse para ocupar el espacio disponible. El usuario debía poder moverla y hacer zoom sin deformarla.
Al pensar estas cosas antes de implementar, pude detectar problemas que probablemente habría encontrado después mientras escribía el código.
Y creo que esa fue una de las partes más útiles del proceso.
PASO 3: Después vienen las tareas
Una vez definidos los requisitos y el diseño, el proyecto podía dividirse en tareas más concretas.
En vez de tener una idea grande como:
"Construir el generador de badges."
podía separarla en partes más pequeñas:
- carga de fotografías,
- posicionamiento de la fotografía,
- controles de zoom,
- selección del rol,
- formato 4:5,
- formato 9:16,
- vista previa,
- exportación del badge.
Esto hizo que el proyecto fuera más fácil de seguir.
También me ayudó a entender mejor qué parte estaba implementando en cada momento y qué requisitos estaban relacionados con cada tarea.
PASO 4: Aquí es donde entra la IA
Una de las razones por las que me interesó probar este enfoque fue precisamente utilizarlo junto con una herramienta de IA.
Kiro podía trabajar a partir del contexto que había definido en las especificaciones.
Esto cambió un poco mi manera de pensar sobre el desarrollo asistido por IA.
Muchas veces hablamos de estas herramientas desde una perspectiva bastante simple:
"Le digo lo que quiero y la IA escribe el código."
Pero para mi eso fue un poco diferente.
Mientras más claro tenemía el problema, más fácil fue explicar lo que esperaba de la implementación.
Eso me llevó a pensar que quizás una parte importante de trabajar con IA no consiste solamente en aprender a escribir mejores prompts.
También consiste en aprender a definir mejor los problemas.
Lo que pasó cuando empecé a implementar
Por supuesto, tener requisitos y diseño no significó que todo saliera perfecto desde el principio.
Mientras implementaba y probaba el proyecto, aparecieron cosas que no había considerado.
Algunas funcionalidades necesitaban ajustes.
Algunos requisitos tenían que ser más específicos.
Y en algunos casos tuve que volver a las especificaciones y cambiar las tareas.
Esto me pareció importante porque inicialmente podía imaginar el proceso como algo completamente lineal:
Requirements → Design → Tasks → Code → Done
Pero en un proyecto real se parece más a esto:
Requirements → Design → Tasks → Code → Test → Change → Update → Code
Y creo que esto también es parte de aprender a desarrollar software.
No podemos saber absolutamente todo antes de empezar.
A veces necesitamos construir algo para entender mejor el problema.
Entonces, ¿qué aprendí realmente?
Después de probar este flujo, hubo varias cosas que me quedaron más claras.
1. Una idea sencilla puede esconder muchos requisitos
Decir "quiero hacer una aplicación que haga X" es muy diferente a definir exactamente cómo debería comportarse.
Los requisitos ayudan a encontrar esas diferencias antes de llegar demasiado lejos con la implementación.
2. Es más fácil dividir un problema cuando primero lo entiendes
Tener las tareas separadas hizo que el proyecto se sintiera menos como una sola cosa grande.
Podía concentrarme en una parte y después pasar a la siguiente.
3. La IA también necesita contexto
Una herramienta de IA puede generar código, pero eso no significa que automáticamente entienda todo lo que tenemos en mente.
Mientras mejor definido estaba el proyecto, más fácil era trabajar sobre él.
4. Las especificaciones no reemplazan el desarrollo
Tener requirements.md, design.md y tasks.md no significa que el proyecto esté resuelto.
Todavía hay que implementar, probar, equivocarse y corregir.
Para mí, las especificaciones funcionan mejor como una guía durante el desarrollo.
5. Los requisitos pueden cambiar
Esta fue quizás una de las cosas que más me gustó del proceso.
No tuve que considerar la primera versión de los requisitos como algo definitivo.
Cuando descubrí algo nuevo durante la implementación, podía volver atrás, actualizarlo y continuar.
¿Utilizar Kiro hizo que programara más rápido?
No creo que pueda responder simplemente que sí.
Hubo momentos en los que escribir los requisitos y pensar en el diseño tomó más tiempo que si hubiera empezado directamente a programar.
Pero también creo que comparar solamente el tiempo que tardamos en escribir código no cuenta toda la historia.
Para mí, el beneficio estuvo en tener más claro qué estaba haciendo y por qué.
Antes podía empezar a programar y descubrir los problemas después.
Con este enfoque, algunos de esos problemas aparecieron durante la planificación.
Y eso cambió la forma en la que veía el proyecto.
¿Lo utilizaría nuevamente?
Sí, pero probablemente no intentaría utilizar exactamente el mismo nivel de detalle para todos los proyectos.
Para un proyecto muy pequeño puede ser innecesario crear especificaciones demasiado extensas.
Pero cuando el proyecto empieza a tener varias funcionalidades, diferentes comportamientos y requisitos que pueden cambiar, creo que vale la pena probar este enfoque.
Especialmente cuando además estás utilizando herramientas de IA para ayudarte durante la implementación.
Lo que me llevo de esta experiencia
Cuando empecé a probar Kiro, esperaba principalmente conocer una nueva herramienta para desarrollar software.
Me di cuenta de que muchas veces el problema no está en no saber programar una funcionalidad, sino en no haber definido suficientemente bien qué debería hacer esa funcionalidad.
Spec-Driven Development te obliga a detenerte un poco antes de escribir código.
A pensar.
A hacer preguntas.
A dividir el problema.
Y también a aceptar que algunas respuestas solamente aparecen cuando empiezas a construir.
Todavía estoy experimentando con este enfoque y no creo que tenga una respuesta definitiva sobre cuál es la mejor manera de desarrollar software.
Pero después de utilizarlo en un proyecto real, sí creo que hay algo que vale la pena probar:
antes de preguntarte como vas a escribir el código, preguntate exactamente qué estas intentando construir.
¿Y ustedes cómo suelen empezar sus proyectos?
¿Primero escriben los requisitos y planifican lo que van a construir, o prefieren comenzar directamente con el código?
Me gustaría conocer sus experiencias con Spec-Driven Development, Kiro u otras herramientas de desarrollo asistido por IA. ¿Qué les ha funcionado y qué cosas no? Leo sus comentarios :)
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article