Las herramientas de codificación de IA aún están en la etapa de I+D

Según la encuesta de Stack Overflow de 2024 , el 76 % de los desarrolladores están usando o planean usar herramientas de IA; ahora son solo una parte del trabajo. Ayudan con las tareas mundanas, pero pueden resultar molestas cuando generan tonterías con confianza. Mientras los YouTubers crean "startups de mil millones de dólares" con indicaciones de ChatGPT y los agentes de IA se apoderan del mundo todas las semanas, los equipos reales aún están descubriendo cómo usar estas herramientas de manera efectiva. Hoy, dominar la asistencia de IA es tan fundamental como la codificación o el diseño de sistemas; necesitamos adaptarnos y rápido.

El problema es que estas herramientas se encuentran todavía en una etapa de investigación y desarrollo: cambian constantemente, se copian entre sí y merecen el crédito por resolver problemas que antes no se habían resuelto. Todas carecen de guías de uso claras. Incluso Copilot, a pesar de estar más consolidada, carece de tutoriales claros y prácticas recomendadas. ¿La solución? Haremos lo que los desarrolladores hacen mejor: organizar y crear un marco de trabajo nosotros mismos.

Un cambio de juego

...y también " salto cuántico ", " cambio de paradigma ", " llegan los agentes ", etc. Si bien estas herramientas están transformando nuestro flujo de trabajo, el cambio es más práctico: los desarrolladores ahora operan como líderes de equipo y administran asistentes de IA en lugar de escribir código directamente. Las habilidades básicas han cambiado al diseño, la planificación, la descripción y la revisión.

Los principales conceptos de UX que introducen estas herramientas son:

1. Sugerencias en línea : el patrón de integración más natural. Cuando funcionan, son perfectas, pero cuando interrumpen el código, suponen una interrupción inmediata de la productividad.
2. Chat : enfoque clásico donde los LLM interactúan con su base de código a través de indicaciones guiadas
3. Composer (" Copilot Edit ", " Cline act ") es un nuevo concepto que a muchos les resulta confuso . Es un cambio hacia agentes autónomos. Composer trabaja en varios archivos y puede aplicar cambios e iterar automáticamente en función de errores, problemas de linting, etc.
4. Agentes : la próxima evolución esperada: asistentes de IA totalmente autónomos y personalizados integrados directamente en su IDE.

Familiarizarse con las " sugerencias " no es complicado. Los asistentes de IA empezaron con ellas, lo que nos llamó la atención en primer lugar. Los chats son sencillos: inserta archivos en el contexto, itera, aplica y valida los resultados.

Las herramientas de tipo Composer presentan más desafíos para dominar, ya que requieren una curva de aprendizaje y algunos enfoques no obvios. Actualmente, el editor Cursor ofrece la herramienta de "composición" más accesible, mientras que Copilot le sigue de cerca con " Copilot Edits ", habiendo introducido recientemente flujos de trabajo basados en agentes.

Para dominar a los compositores, es necesario comprender tres conceptos clave:

1. Instrucciones
2. Normas
3. Contexto

Examinemos cada uno de ellos.

Instrucciones

Como líderes de equipo y no solo como desarrolladores, deberíamos comenzar cualquier proyecto nuevo o característica importante creando un Documento de diseño o un Documento de requisitos del producto claro. Esta práctica desarrolla una sólida capacidad de ingeniería y pensamiento de producto, al tiempo que ahorra un tiempo de implementación sustancial. La mejor parte es que estos documentos pueden ser:

1. Generado con IA
2. Y luego se utilizó como instrucciones para los compositores.

Para crear estos documentos, primero se recopilan los requisitos de los humanos y luego se consulta el modelo de razonamiento en Chat. Tanto Copilot como Cursor tienen modelos de razonamiento integrados adecuados para esta tarea. o1 y o3-mini de OpenAI están disponibles de forma predeterminada, mientras que Chat de Cursor es compatible con DeepSeek-R1 (aunque todavía no en su Composer ), todas ellas excelentes herramientas para este propósito.

Una buena práctica es almacenar los documentos de diseño en el nivel superior de su repositorio (usaremos una carpeta requirements ) organizados por características, con un ProjectOverview.md en la raíz. Aquí hay un ejemplo de estructura para los requisitos de una aplicación web de Twitter:

 requirements/ ├── ProjectOverview.md # Core product description └── Features/ ├── Authentication.md # User registration ├── Tweet.md # Tweet CRUD ├── UserProfile.md # Profile management ├── Engagement.md # Likes, retweets ├── Infrastructure.md # Storage, caching, etc └── ...

Si todo está configurado correctamente, agregar un documento de diseño para una nueva función es tan simple como escribir este mensaje:

Almacenar instrucciones en la base de código ofrece claras ventajas: control de versiones, mantenimiento sencillo y flujo de trabajo de relaciones públicas estándar. Sin embargo, los miembros no técnicos del equipo, como los propietarios de productos, los gerentes y los diseñadores de UX, pueden necesitar acceso sin usar Git. A continuación, se ofrecen tres soluciones:

1. Almacene todo en Notion, publique páginas de instrucciones e inyéctelas como documentación usando el acceso directo @Docs

2. Cree una canalización que convierta las páginas de Notion en archivos .md y las almacene en el repositorio
3. Enseñe a su equipo a usar Git: la opción más beneficiosa para todo el equipo

Una vez que las instrucciones estén accesibles en el editor, cambie al editor y comience a implementarlas. Esto nos lleva a organizar las reglas .

Normas

Actualmente, solo Cursor admite " reglas ": instrucciones de implementación directa para archivos o carpetas específicos. Es probable que esta función se extienda a otros editores, incluido VSCode Copilot, que actualmente solo ofrece " archivos de solicitud " que no se pueden adjuntar directamente al código base.

Las reglas de Cursor son más completas: imagine CONTRIBUTING.md combinado con reglas de linter y mejorado con capacidades LLM. Estas reglas son independientes del producto, se pueden compartir y transfieren eficazmente el conocimiento, las mejores prácticas y los detalles de implementación entre equipos y usuarios de la biblioteca.

Las reglas se pueden crear a través de la paleta de comandos y se almacenan en la carpeta .cursor/rules de su proyecto con una extensión .mdc . Este formato permite funciones avanzadas como @mentioning archivos específicos en su base de código. Se recomienda encarecidamente enviar estas reglas a su repositorio y colaborar para mejorarlas. Este es el flujo de trabajo para usar reglas:

1. Investiga las reglas de cursor específicas para tu conjunto de tecnologías, comenzando con listas seleccionadas como referencias. Por ejemplo, puedes encontrar reglas de cursor bien redactadas para Next.js y React que sirven como buenas plantillas.
2. Actualice las reglas de forma proactiva durante el desarrollo. Cuando note un patrón que podría formalizarse en una regla mientras escribe código, documéntelo inmediatamente en su archivo de reglas.
3. Aprenda de los mejores en el campo. Un nuevo enfoque para que los creadores de bibliotecas compartan conocimientos y aumenten la adopción es la creación de reglas especializadas para los asistentes de IA. Conozco pocas empresas que hagan esto: Convex se destaca por crear reglas para los modelos OpenAI y Anthropic y compartirlas en su documentación . Si bien no he usado su producto, su enfoque en mejorar la experiencia del desarrollador a través de la integración de IA es convincente. Supabase es otro gran ejemplo .

Muchas bibliotecas necesitan reglas de IA con urgencia. Desde la perspectiva de un desarrollador frontend, me beneficiaría tenerlas para TanStack Query , React Spring , Firebase y muchas más. Estas reglas ahorrarían mucho tiempo y ayudarían a prevenir errores comunes que cometen los desarrolladores cuando aprenden nuevas tecnologías.

Contexto

Recuerde incluir todo el contexto relevante: cuanto más datos de calidad proporcione, mejores resultados obtendrá. El editor de cursores tiene una ventaja sobre Copilot en este aspecto, ya que permite varios tipos de contexto:

1. Documentación: funciona muy bien, solo proporciónele un punto de entrada a cualquier documentación, la descargará, la analizará y la guardará para necesidades futuras.
2. Búsqueda web: no estrictamente contextual, proporciona acceso rápido a recursos en línea.
3. Varias herramientas de desarrollo: confirmaciones de Git específicas, errores de lint, blocs de notas y otros artefactos
4. Los servidores MCP pueden proporcionar contexto en tiempo real. Aunque la configuración puede ser un poco complicada, son valiosos cuando se necesita acceso a datos en tiempo real.

Después de dominar estas herramientas, el siguiente paso es optimizar el rendimiento tanto individual como del equipo. Pero ¿cuál es el camino a seguir a partir de aquí?

Cline y Roo-Code. El control

Siempre tendrás que elegir entre simplicidad y control, entre soluciones automatizadas y toma de decisiones manual. Si estás dispuesto a profundizar y no temes lidiar con errores, problemas de rendimiento y asperezas, considera probar Cline (o su bifurcación Roo-Code , que tiene una filosofía ligeramente diferente).

Ambas herramientas están diseñadas para proporcionar la mayor claridad posible sobre lo que realmente sucede debajo del capó:

1. Son de código abierto y sin suscripción. En su lugar, utilizas tus propias claves API LLM o servicios como OpenRouter y pagas solo por lo que utilizas.
2. Cline muestra claramente todas sus operaciones, incluidos qué archivos lee y modifica.
3. Cline proporciona información detallada sobre las comunicaciones de LLM, el estado de la ventana de contexto y el costo de cada sesión de chat.
4. Cuenta con modos intuitivos Planificar/Actuar: un enfoque lógico que otras herramientas deberían considerar adoptar.

La característica destacada es que Cline realmente puede ejecutar y depurar tu aplicación: es real y funcional, como verás cuando lo pruebes.

Si todo esto le interesa, consulte el reciente artículo de Addy Osmani , que ofrece una excelente introducción a estos editores.

Conclusión

Adoptar estas herramientas no es un proceso sencillo y no esperes escribir "todo el proyecto desde cero en menos de 5 minutos". Sin embargo, este es un camino claro a seguir.

La tecnología ya está ahí, pero nos falta un flujo de trabajo sólido integrado con IA que organice a todo el equipo (no solo a los desarrolladores, sino, fundamentalmente, a los gerentes y diseñadores) en torno a estas nuevas herramientas. La IA puede resultar intimidante y compartir su impacto puede resultar incómodo al principio (como decirle al líder de tu equipo que la IA escribió el 80 % de una característica mediante una configuración cuidadosa). Sin embargo, el desarrollo de software solo evolucionará cuando estas herramientas se conviertan en parte integral de los flujos de trabajo del equipo. Las transiciones más exitosas ocurren en equipos que fomentan el debate abierto sobre las experiencias de IA, la exploración colaborativa de herramientas y contribuyen activamente con las mejores prácticas aprendidas a la comunidad de desarrollo más amplia.