El flujo del ingeniero profesional
Cómo envía código toda empresa de tecnología del mundo
⏱ Estim. ~13 min
01 · Leer
Has aprendido cada habilidad individual: terminal, archivos, git, servidores web, APIs, Claude Code, debug, despliegue. Ahora vamos a juntarlas en el flujo que sigue todo equipo de desarrollo profesional.
Las herramientas cambian — algunos equipos usan GitLab en vez de GitHub, otros despliegan en AWS en vez de Render, otros usan otros lenguajes. Pero el flujo es siempre el mismo. Aprende este flujo y puedes entrar a cualquier empresa de tecnología y entender cómo entregan software.
💡 Imagínalo asíLas habilidades individuales son como aprender a driblar, pasar y tirar. El flujo profesional es el partido real — la secuencia coordinada para juntar lo aprendido y producir resultados. Entender el flujo es la diferencia entre saber programar y poder entregar.
02 · Paso a paso
El ciclo de desarrollo completo. Cada feature, fix de bug y mejora sigue este mismo loop.
1. ISSUE
Alguien reporta un bug o pide una feature. Se registra en GitHub Issues, en un tablero de Jira o en una lista simple de pendientes. Cada tarea empieza con un problema o un objetivo descrito de forma clara.
2. BRANCH
Crea una rama: git checkout -b fix-login-bug. Nunca trabajes directamente en main. La rama aísla tus cambios para que puedas experimentar sin romper nada.
3. CODE
Implementa el arreglo o la feature con Claude Code. Describe con claridad lo que quieres, revisa el resultado e itera hasta que esté bien. Aquí es donde se construye de verdad.
4. TEST
Verifica localmente que funciona. Revisa los casos límite. ¿Esto podría romper algo más? Prueba con entradas raras, campos vacíos, escenarios inesperados. Si hay pruebas automatizadas, córrelas.
5. REVIEW
Corre git diff. Revisa tus cambios línea por línea. ¿Lo aprobarías si lo hubiera escrito otra persona? Busca console.log restantes, valores hardcodeados o cosas que no deberían estar ahí.
6. COMMIT
Haz stage y haz commit con un mensaje descriptivo. Un cambio lógico por commit. 'Fix login validation to reject empty passwords' cuenta una historia. 'Fixed stuff' no.
7. PUSH
Haz push de tu rama a GitHub: git push -u origin fix-login-bug. Esto hace que tus cambios sean visibles y revisables por otros.
8. PULL REQUEST
Crea un PR en GitHub. Describe qué cambiaste y por qué. Aquí es donde tus compañeros (o tu yo del futuro) revisan el código antes de que entre. Incluye contexto: ¿cuál era el bug? ¿cómo lo arreglaste? ¿cómo lo prueban otros?
9. MERGE
Después de la revisión y la aprobación, haz merge a main. La rama de feature ya cumplió y se puede borrar. Tus cambios ya forman parte de la base de código oficial.
10. DEPLOY
Si tienes despliegue automático (como Render), tus cambios salen en vivo automáticamente al hacer merge en main. Si no, dispara un despliegue manual. Sea como sea, el ciclo está completo — de la idea a la feature en vivo.
03 · Leer
Vamos a recorrer en la práctica los pasos clave de git de este flujo. Tienes un proyecto que todavía no está en git — inicialízalo, crea una rama de feature, haz cambios y haz stage.
04 · Práctica de terminal
Todo proyecto empieza con git init. Convierte una carpeta normal en un repositorio de git para que puedas rastrear los cambios.
(Esta sección es interactiva — activa JavaScript para usarla.)
05 · Práctica de terminal
Paso 1: BRANCH — crea una rama de feature nueva. Nunca trabajes directamente en main. La rama te deja experimentar de forma segura.
(Esta sección es interactiva — activa JavaScript para usarla.)
06 · Práctica de terminal
Paso 2: CODE — haz cambios al proyecto. Vamos a agregar un formulario de login a un archivo HTML.
(Esta sección es interactiva — activa JavaScript para usarla.)
07 · Práctica de terminal
Paso 3: COMMIT — haz stage del archivo y haz commit con un mensaje descriptivo. Un buen mensaje de commit explica qué cambió y por qué.
(Esta sección es interactiva — activa JavaScript para usarla.)
08 · Leer
Pausa — terminaste BRANCH → CODE → COMMIT
Acabas de recorrer los primeros tres pasos del día a día de un ingeniero profesional: abrir rama → escribir código → commit con un mensaje descriptivo. Todos los equipos hacen este recorrido de tres pasos, sin importar el tamaño del proyecto.
Lo que queda en la segunda mitad es PR (pull request) → code review → merge — es decir, cómo proponer que tu rama se integre a la rama principal del equipo.
¿Por qué no se puede hacer merge directo a main? Porque si haces merge sin que nadie revise, los bugs entran sin que nadie los detenga. El PR es para que tus compañeros vean tus cambios, te den feedback y confirmen que está bien antes de darles paso. Esa capa de proceso es el corazón del trabajo profesional.
Puntos clave
- Tres pasos: branch / code / commit (hecho)
- Los tres restantes: push / pull request / code review + merge
- El mensaje de commit explica qué cambió y por qué — tu yo del futuro le va a agradecer al de hoy
09 · Quiz
En el flujo profesional, ¿qué creas antes de empezar a escribir código?
- Un repo nuevo
- Una base de datos
- Una rama nueva
- Un issue de GitHub que describe el trabajo
10 · Completar
Después de terminar una feature, creas un pull _____ para proponer hacer merge de tus cambios.
11 · Leer
Felicidades. Acabas de seguir el mismo flujo que usan Google, Stripe, Shopify y todas las demás empresas de tecnología. La escala cambia, pero el flujo es el mismo: issue, branch, code, test, review, commit, push, PR, merge, deploy.
Las empresas grandes recorren este ciclo cientos de veces al día. Ahora tú también.
12 · Quiz
Acabas de terminar de programar un fix de bug en una rama de feature. ¿Qué deberías hacer antes de hacer commit?
- Correr git diff para revisar tus cambios línea por línea
- Hacer push directo a main
- Crear el pull request
- Borrar la rama y empezar de nuevo
13 · Completar
En el flujo profesional, cada tarea empieza con un _____ descrito con claridad — un reporte de bug o una solicitud de feature.
Otras lecciones de este capítulo
⚠ La experiencia interactiva completa necesita JavaScript. Actívalo y vuelve a cargar la página.
※ Este es un proyecto educativo independiente — no es un producto oficial de Anthropic. Claude™ es una marca registrada de Anthropic, PBC.