Experiencia del desarrollador

La IA generativa no solo es útil para implementar características en tu aplicación; también es útil para generar el código para implementar esas características.

Desafortunadamente, no es tan fácil como pedirle a un agente de codificación por IA que "construya una aplicación Flutter que resuelva crucigramas". Estoy seguro de que ese prompt produciría algo, pero dudo mucho que nos diera la potente combinación asistida por IA y validada por el usuario que proporciona el Crossword Companion.

Con un mejor prompting, sin embargo, la aplicación de ejemplo se implementó con Gemini 2.5 Pro para la mayor parte de la funcionalidad y Gemini 3 Pro Preview para agregar los toques finales. El proceso para obtener los mejores resultados de ambos modelos fue el mismo:

• Planificar
• Programar
• Validar
• Iterar

El objetivo del proceso de planificación es iniciar el proceso de codificación con suficiente detalle para permitir que el agente sepa lo que tienes en mente. El proceso de planificación del Crossword Companion se inició con el siguiente prompt:

I'd like to create a file called requirements.md in the plans folder at the root of the project. here's a description of the project:

The application will be an open-source sample hosted on GitHub in the flutter/demos directory. It aims to demonstrate the use of Flutter, Firebase AI Logic, and Gemini to produce an agentic workflow that can solve a small crossword puzzle (one with a size under 10x10)....lots more description of the app along with a sample puzzle screenshot...
Ask any questions you may have before you get started.

Este prompt, con un poco de preguntas y respuestas, ediciones manuales por parte de un humano y algunas actualizaciones durante el proceso de codificación, dio como resultado el archivo de requisitos.

Antes de saltar al diseño arquitectónico, se le pidió a la Gemini CLI que inicializara el archivo de reglas GEMINI.md y luego que lo actualizara con una lista de principios arquitectónicos:

DRY (Don't Repeat Yourself) – eliminate duplicated logic by extracting shared utilities and modules.

Separation of Concerns – each module should handle one distinct responsibility.

Single Responsibility Principle (SRP) – every class/module/function/file should have exactly one reason to change.

Clear Abstractions & Contracts – expose intent through small, stable interfaces and hide implementation details.

Low Coupling, High Cohesion – keep modules self-contained, minimize cross-dependencies.

Scalability & Statelessness – design components to scale horizontally and prefer stateless services when possible.

Observability & Testability – build in logging, metrics, tracing, and ensure components can be unit/integration tested.

KISS (Keep It Simple, Sir) - keep solutions as simple as possible.

YAGNI (You're Not Gonna Need It) – avoid speculative complexity or over-engineering.

El archivo GEMINI.md se carga en cada nuevo prompt que creas con Gemini; proporciona el conjunto de reglas que deseas que recuerde para cualquier actividad. Gemini se estaba ejecutando dentro de un proyecto de aplicación Flutter vacío, por lo que el comando /init documentó cómo compilarlo, probarlo y ejecutarlo, lo cual fue útil durante la codificación.

Si estás construyendo algo más que un ejemplo, también recomiendo añadir algo para el desarrollo guiado por pruebas:

- **TDD (Test-Driven Development)** - write the tests first; the implementation
  code isn't done until the tests pass.

Esto ayuda a construir límites de seguridad para garantizar que el agente de codificación escriba código sólido a lo largo del tiempo.

Con los requisitos y las reglas en su lugar, lo siguiente fue solicitar el archivo design.md:

great. i'd like to work on the design with you to be created in a design.md file to be stored in the plans folder. please use the @GEMINI.md and @requirements.md files as input. ask any questions you may have before you get started.

Después de inspeccionar y editar el diseño de la aplicación generado, se le solicitó a Gemini desglosarlo en tareas:

please read the files in the @specs folder and create a corresponding tasks.md file in the same folder that lays out a set of tasks and subtasks representing the functionality of this app. lay out the top-level tasks as minimal new functionality that the user can see in the running app, step-by-step as each top-level task is completed. each top-level task should include sub-tasks for creating and running tests and updating the @README.md with a description of the current functionality of the app. ask any questions you may have before you get started.

Todo esto sucede antes de escribir cualquier línea de código. No tienes que dividir las cosas en archivos separados, pero al considerar cuidadosamente los requisitos, el diseño y el desglose de tareas, estás ayudando al agente a proporcionar resultados que cumplan con tus expectativas. Esto se llama "Desarrollo impulsado por especificaciones" y actualmente es la mejor manera que conocemos para actualizar tu proceso de "vibe coding" a "desarrollo de software asistido por IA".

Además, la frase que dice "haz cualquier pregunta que puedas tener antes de comenzar" es una excelente manera para que el agente aclare cualquier cosa que no entienda en lugar de simplemente inventar las respuestas a medida que avanza. También es útil para ayudarte a decidir sobre detalles que de otro modo no habrías considerado.

Con los requisitos, las reglas, el diseño y las tareas en su lugar, iniciar la parte de codificación es fácil:

Read the @tasks.md file and implement the first milestone.

Puedes ver al agente de codificación en acción, interviniendo para corregirlo mientras trabaja, o simplemente dejarlo ir. De cualquier manera, cuando termine, es hora de revisar su trabajo.

En este punto, tienes algo de código y (en el mundo fuera de los ejemplos de muestra) algunas pruebas. Para validar, hazte algunas preguntas:

• ¿Muestra el analizador que está libre de errores? ¿De advertencias?
• ¿Se ejecuta la aplicación?
• ¿Tiene las características que solicitaste? ¿Funcionan?
• ¿Pasan las pruebas?
• ¿Pasa el código tu revisión?

Las respuestas a estas preguntas son el insumo para la siguiente fase.

Reúne los problemas que deben abordarse y entrega los que necesitan solución de vuelta al agente de codificación, realizando iteraciones entre su codificación y tu validación hasta llegar a un buen punto desde el punto de vista funcional.

Ahora realiza otra ronda de validación desde el punto de vista de los principios arquitectónicos, iniciando un nuevo agente para verificar el código. Al limpiar el contexto del agente, eliminas los sesgos que el agente original adquirió al elegir qué código escribir en primer lugar. Para basarlo únicamente en los cambios de código que el agente acaba de realizar, utiliza un prompt como este:

Use git diff to find the new code and check it against the architectural principles listed here: @GEMINI.md. Make recommendations for important improvements.

Hacer esto unas cuantas veces mantiene el código en buena forma tanto para los agentes de IA como para los humanos.