La generación de asistentes que solo te sugieren una línea de código quedó chica. Los tres editores/extensiones más comentados hoy encaran la IA de forma distinta. Acá las diferencias que importan en el día a día.

1. GitHub Copilot

Se integra como extensión dentro de VS Code, Visual Studio y otros editores que ya usás. Su fuerte es la integración profunda con el ecosistema de GitHub (issues, pull requests, revisiones de código). Es la opción con menor fricción si tu equipo ya vive en VS Code y no quiere cambiar de editor.

2. Cursor

Es un editor completo (un fork de VS Code) pensado desde cero alrededor de la IA: podés pedirle que edite varios archivos a la vez, que entienda todo el proyecto, y chatear con el código como contexto permanente. La curva de adopción es baja porque se siente como VS Code, pero migrar implica dejar tu editor actual.

3. Windsurf

También es un editor propio, con un enfoque fuerte en el modo «agente»: le pedís una tarea de varios pasos (por ejemplo, «agregá un endpoint nuevo y sus tests») y el editor encadena las acciones necesarias con menos intervención manual que sus competidores.

4. ¿Cuál conviene según tu caso?

Si no querés cambiar de editor: Copilot como extensión es el camino de menor resistencia.

Si querés la experiencia más pulida de «chatear con todo tu proyecto»: Cursor suele ser el más mencionado por equipos que migraron completos.

Si tu prioridad es delegar tareas completas de varios pasos: Windsurf apunta directo a eso.

Los tres tienen planes pagos con distintos límites de uso mensual (cantidad de solicitudes o de tokens), así que antes de comprometerte con uno, probá el plan gratuito o de prueba con una tarea real de tu proyecto, no un ejemplo de demo.

Casi todos los que empezamos con Git rompimos un repositorio al menos una vez. La diferencia entre un junior y un senior no es que no se equivoquen, es que ya saben cómo salir del lío. Acá van los errores más comunes y cómo evitarlos.

1. Mensajes de commit sin sentido

«fix», «cambios», «asd». Un mensaje de commit debería explicar el por qué, no solo el qué. Convención simple: tipo: descripción corta (ej. fix: corrige validación de email en registro).

2. Trabajar directo sobre main

Sin darse cuenta, muchos junior programan y commitean directo en la rama principal. Un error ahí puede romper el código que todo el equipo usa. Solución: crear una rama por feature o fix, por chica que sea la tarea.

3. Hacer git push --force sin entender qué hace

Sobreescribe el historial remoto y puede borrar el trabajo de otros. Si necesitás forzar un push, usa --force-with-lease, que al menos verifica que no estés pisando cambios ajenos.

4. No hacer pull antes de empezar a trabajar

Empezar a programar sobre una versión vieja del código genera conflictos innecesarios. Hábito simple: git pull apenas te sentás a trabajar, siempre.

5. Resolver conflictos borrando el código del otro

Ante un conflicto, la tentación es quedarse con «tu» versión y borrar la otra sin leerla. Eso puede eliminar lógica importante. Leé ambas versiones, entendé qué hace cada una, y combiná si hace falta.

6. No usar .gitignore

Subir carpetas como node_modules, archivos .env con credenciales, o binarios pesados infla el repositorio y puede filtrar secretos. Configurá el .gitignore desde el primer commit del proyecto.

7. No entender la diferencia entre merge y rebase

Usarlos sin saber qué hace cada uno genera historiales confusos o duplicados. Regla simple para empezar: merge para integrar ramas compartidas, rebase solo en tu rama personal antes de compartirla.

La buena noticia: ningún error de esta lista es irreversible si lo detectás a tiempo. Git guarda casi todo en su historial interno (git reflog es tu mejor amigo en un momento de pánico).