7 minute read

¡Hola, soy LISA! 🙂

En mi post anterior, les mostré el proceso de Requirements → Design de Kiro. ¡Hoy compartiré cómo se desarrolla el desarrollo real en detalle!

Creación de Tasks: ¡El Diseño se Convierte en Trabajo!

Lista de Tasks

Una vez que el diseño está completo, Kiro genera automáticamente las tareas. ¡Y esto fue realmente lo que me impresionó!

Diferencia con Task Master

Task Master toma un PRD y crea tareas, pero sin una fase de diseño intermedia:

  • Falta de gestión sistemática: Diseño e implementación están mezclados dentro de las tareas
  • Sin proceso de aprobación: PRD → generación directa de tareas → ejecución inmediata
  • Difícil de predecir: El trabajo comienza antes de ver el panorama general

El Modo Spec de Kiro se enfoca en la confirmación paso a paso:

  • Requisitos organizadosYo apruebo
  • Documento de diseño creadoYo apruebo
  • Lista de tareas generadaYo apruebo
  • Comprensión clara y aprobación en cada etapa hace la predicción mucho mejor

Lista de Tasks Generadas

✅ Task completada: Extender estructura de front matter para soporte multilingüe
  - Agregar campo 'lang' para identificar idioma del post
  - Agregar campo 'translation_key' para vincular traducciones relacionadas
  - Agregar hash 'translations' con URLs de idiomas disponibles
  - Actualizar posts existentes con nuevos campos de front matter

✅ Task completada: Implementar sistema de traducción de categorías
  - Crear filtro Liquid para traducción de nombres de categorías
  - Actualizar páginas de archivo de categorías para usar nombres traducidos
  - Modificar plantillas de visualización de posts para mostrar categorías traducidas
  - Asegurar que URLs de categorías reflejen el idioma seleccionado

🔵 Task en progreso: Crear estructura de directorios para posts traducidos
  - Crear directorio '_posts/en/' para traducciones al inglés
  - Crear directorio '_posts/es/' para traducciones al español
  - Configurar colección Jekyll apropiada para directorios de idiomas
  - Probar descubrimiento de posts y generación de URL para contenido traducido

⭕ Iniciar task: Implementar optimización SEO para contenido multilingüe
  - Crear '_includes/hreflang-tags.html' para generación automática de hreflang
  - Actualizar '_includes/seo.html' para incluir meta tags específicos de idioma
  - Agregar información de idioma a datos estructurados (JSON-LD)
  - Asegurar configuración apropiada del atributo lang HTML basado en idioma del contenido

¡Miren! ¡El contenido de la fase de diseño se convirtió directamente en tareas!

Ejecución de Tasks: ¡Más Rápido que Cursor!

Proceso de Ejecución de Tasks

¡El proceso de ejecutar tareas una por una fue realmente impresionante!

Por qué es Rápido

Con Cursor:

  • “Haz esto” → generación de código → verificar → solicitar cambios → generar de nuevo

Con Kiro:

  • Métodos específicos ya determinados en la fase de diseño
  • Durante la ejecución de tareas, solo implementa el contenido del diseño
  • Sin tiempo perdido preguntándose “¿cómo debería hacer esto?”

Proceso de Trabajo Real

Task 7: Configurar estructura de configuración multilingüe desde tasks.md
Estado: En Progreso

Implementaré la task 1 para configurar la estructura de configuración multilingüe. Empezaré examinando el archivo _config.yml actual para entender la configuración existente.

📂 Leer archivo(s) _config.yml

Ahora necesito examinar los posts existentes para entender las categorías actuales que necesitan mapeos de traducción.

📂 Leer archivo(s) 
  • 2025-09-04-tipsmart-development-story.md 1 → 16
  • 2025-09-05-jekyll-blog-setup-guide.md 1 → 16  
  • 2025-09-06-what-is-vibe-coding.md 1 → 16
  • 2025-09-07-ai-development-tools-comparison.md 1 → 16

Ahora tengo una buena comprensión de las categorías existentes. Agregaré la configuración multilingüe al archivo _config.yml. Basado en los posts, puedo ver las siguientes categorías que necesitan mapeos de traducción:

• 바이브코딩 (Vibe Coding)
• AI도구 (AI Tools)  
• Mobile
• Development
• Story
• Jekyll

✅ Ediciones aceptadas a _config.yml

Ahora verificaré que la configuración se agregó correctamente leyendo el archivo actualizado:

📂 Leer archivo(s) _config.yml 90 → 131
📂 Leer archivo(s) _config.yml 130 → 171

¡Perfecto! La configuración multilingüe se ha agregado exitosamente a _config.yml.

¡Miren! ¡Verifica y procede sistemáticamente paso a paso! Mucho más natural que la combinación Task Master + Claude Code.

Finalización de Task: ¡Resumen de Resultados!

Resumen de Finalización de Task

Cuando una tarea se completa, resume ordenadamente lo que se logró:

Task 1 Completada: Configurar estructura de configuración multilingüe

Agregada configuración de idioma en _config.yml con idiomas soportados: • Coreano (ko) - establecido como predeterminado
• Inglés (en) • Español (es)

Agregados mapeos de traducción de categorías para categorías existentes: • 바이브코딩 → vibe-coding (en), codificacion-vibe (es) • AI도구 → ai-tools (en), herramientas-ia (es)
• Mobile → mobile (en), movil (es) • Development → development (en), desarrollo (es) • Story → story (en), historia (es) • Jekyll → jekyll (en), jekyll (es)

Configurados metadatos de idioma incluyendo: • Locales (ko-KR, en-US, es-ES) • Dirección del texto (ltr para todos los idiomas) • Banderas de idiomas y nombres de visualización

La configuración ha sido validada con jekyll doctor y todo se ve bien. La base multilingüe está ahora en lugar para las próximas tareas en el plan de implementación.

¡Este nivel de sistematización es como trabajo humano real!

Pruebas Automáticas: ¡Verificando que Realmente Funciona!

Proceso de Pruebas Automáticas

¡La parte más impresionante fueron las pruebas automáticas!

🔍 Espacio de trabajo buscado
Buscando datos estructurados en el HTML generado

Déjame verificar específicamente los datos estructurados de traducción:
📂 Leer archivo(s) what-is-vibe-coding.html 840 → 861

¡Perfecto! Ahora déjame probar los escenarios de manejo de errores. Crearé un post sin translation_key para probar el comportamiento de fallback:

📝 Creado 2025-09-08-test-no-translation-key.md

Déjame reconstruir el sitio para probar el manejo de errores:
⚡ Comando
bundle exec jekyll build --trace

Archivo de configuración: /Users/jongrokkm/XcodeProjects/blogs/_config.yml
Para usar retry middleware con Faraday v2.0+, instala `faraday-retry`
        Fuente: /Users/jongrokkm/XcodeProjects/blogs
   Destino: /Users/jongrokkm/XcodeProjects/blogs/_site
 Construcción incremental: deshabilitada. Habilita con --incremental
      Generando...
           Tema remoto: Usando tema mmistakes/minimal-mistakes
                    listo en 2.947 segundos.
 Auto-regeneración: deshabilitada. Usa --watch para habilitar.

Ahora déjame verificar si el manejo de errores funciona para el post sin translation_key:
📂 Leer archivo(s) test-no-translation-key.html 770 → 811

Noto que el manejo de errores para translation_key faltante no se está mostrando. Déjame verificar si el componente de enlaces de traducción se está incluyendo. El problema podría ser que la condición en el layout está verificando page.lang pero no translation_key.

¡Prueba como un desarrollador real!

  • Verifica casos normales
  • También prueba casos de error
  • Realmente construye para verificar funcionalidad
  • Analiza causas raíz cuando se encuentran problemas

Diferencias Claras con Cursor y Claude Code

1. Flujo de Trabajo de Aprobación Paso a Paso

  • Task Master: PRD → generar todas las tareas de una vez → ejecución inmediata
  • Cursor/Claude Code: Cada uno trabaja por separado → el contexto se rompe en el medio
  • Kiro: Aprobación de requisitos → Aprobación de diseño → Aprobación de tareas → ejecución paso a paso

2. Predictibilidad del Trabajo

  • Herramientas existentes: “¿Qué creará esta vez?” ansiedad
  • Kiro: Todo mostrado en la fase de diseño → predecible

3. Control de Calidad

  • Existentes: Yo pruebo y verifico manualmente
  • Kiro: Prueba automáticamente y verifica casos de error

4. Estilo de Colaboración

  • Existentes: Yo → herramienta IA (unidireccional)
  • Kiro: Yo ↔ Kiro (mejora interactiva)

Reseña General Honesta

👍 Aspectos Realmente Geniales

  • Enfoque sistemático: Flujo perfecto Requirements → Design → Tasks
  • Predictibilidad: Puedes saber qué y cómo se hará todo por adelantado
  • Calidad: Las pruebas automáticas lo hacen confiable
  • Velocidad: Sin tiempo perdido vagando en el medio

😅 Áreas de Mejora

  • Curva de aprendizaje: El modo Spec se ve un poco complejo al principio
  • Servicio pago: Ya pago por otras herramientas, así que no puedo continuar usándolo inmediatamente
  • Enfocado en desarrollo web: Curioso sobre cómo funcionaría para desarrollo de apps móviles

Conclusión: ¡Encontré un Reemplazo para Task Master!

Honestamente, creo que podría reemplazar completamente la combinación Task Master + Claude Code.

Especialmente para:

  • Desarrolladores en solitario
  • Personas que quieren procesos sistemáticos
  • Proyectos de desarrollo web

¡En estos casos, el modo Spec de Kiro sería mucho mejor!

Cuando mis otras herramientas pagas expiren, estoy considerando seriamente cambiarme a Kiro. Este nivel de calidad definitivamente vale la inversión.

¡Por supuesto, esto no significa que Task Master sea malo en absoluto! Es solo un enfoque diferente. Task Master también es una herramienta fantástica, y pude crear exitosamente TipSmart gracias a la combinación Task Master + Claude Code.

Comenzando con el próximo post, regresaré a la historia originalmente planeada e introduciré sistemáticamente el proceso real de desarrollar una app iOS con Task Master y Claude Code! ¡Compartiré todo desde la creación de PRD hasta manejar 50-60 tareas, incluyendo los problemas reales que encontré!

📱 ¡Sigan Amando TipSmart!

¡Me emocioné tanto con las historias de nuevas herramientas que casi olvido mi primer trabajo! 😅

Descargar TipSmart de App Store 📱


¡Si este post fue útil, por favor compártelo en redes sociales! ¡Ayudará a aquellos que están comparando Kiro con otras herramientas IA!