El salto de junior a semi-senior no se define por años ni por cantidad de tecnologías aprendidas: se define por autonomía. Un semi-senior recibe un problema mal definido y devuelve una solución que funciona en producción sin necesitar que alguien le desarme el problema antes. Esta nota desarma esa transición en señales observables y en decisiones concretas.

La razón por la que muchos se quedan estancados es que siguen mejorando en lo que ya los hizo contratar —escribir código que funciona— cuando lo que se evalúa para el ascenso es otra cosa. Y con los asistentes de IA escribiendo cada vez más código base, esa brecha se ensanchó.

Las cinco señales de que ya sos semi-senior

• Estimás con margen de error razonable: podés decir cuánto lleva una tarea y acertar la mayoría de las veces, incluyendo el tiempo de testing y revisión.

• Descomponés problemas grandes: te dan "hay que mejorar el checkout" y salís con cinco tareas ordenadas por dependencia y riesgo.

• Tus pull requests casi no vuelven: no porque nadie revise, sino porque anticipás los comentarios: tests, manejo de errores, casos borde y nombres claros.

• Sabés cuándo no escribir código: reconocés cuándo la solución es una configuración, una conversación con producto o borrar código existente.

• Desbloqueás a otros: alguien te consulta y tu respuesta le ahorra horas. Es la señal más clara y la que más pesa en la evaluación.

Los errores que frenan el ascenso

1. Confundir volumen con impacto

Cerrar muchos tickets pequeños es visible pero no demuestra seniority. Un semi-senior toma la tarea que nadie quiere porque está mal definida y la convierte en algo ejecutable. Esa es la que se recuerda en la revisión de desempeño.

2. Acumular tecnologías en lugar de profundizar

Saber cinco frameworks superficialmente es menos valioso que dominar uno y entender cómo funciona por debajo. La encuesta anual de Stack Overflow para desarrolladores muestra año a año que la rotación de herramientas es alta pero los fundamentos —redes, bases de datos, control de versiones, testing— son los que se mantienen. Ahí conviene invertir.

3. No entender el negocio

Un junior pregunta cómo implementar. Un semi-senior pregunta por qué, y a veces propone algo distinto que resuelve el problema real con menos código. Sin contexto de negocio, ese salto es imposible.

4. Evitar la parte incómoda del oficio

Deploys, monitoreo, incidentes en producción, deuda técnica. Es la zona donde más rápido se aprende y la que más se esquiva. Quien participa de un incidente y escribe el postmortem aprende más en una semana que en tres meses de tickets normales. Las prácticas de entrega y su relación con el rendimiento de los equipos están bien documentadas en la investigación DORA.

5. Usar IA sin criterio

Es el error nuevo y el más caro. Aceptar código generado sin entenderlo produce un perfil que parece productivo hasta que algo se rompe. El uso correcto es al revés: la IA acelera lo que ya sabés revisar. El cambio de rol que esto implica para los perfiles junior está analizado en esta nota sobre cómo cambió el trabajo de los juniors.

Qué hacer diferente: plan de seis meses

La lógica del plan: cada bloque produce algo que un manager puede señalar en una conversación de ascenso. "Mejoré mucho" no es un argumento. "Cubrí con tests el módulo de pagos, reduje los errores reportados y documenté el proceso" sí lo es.

La conversación que hay que tener

Pedir explícitamente a tu líder técnico cuáles son los criterios de semi-senior en tu empresa, y pedir ejemplos concretos de lo que falta. Muchos ascensos se demoran meses porque nadie tuvo esa conversación. Conviene hacerla temprano y volver a ella cada tres meses con evidencia.

El factor IA: cómo cambió el estándar

El piso técnico subió. Escribir código base ya no es diferencial porque un asistente lo hace en segundos. Lo que se valora ahora es revisar, decidir arquitectura, detectar cuándo la solución generada introduce un problema sutil y saber integrar herramientas en el flujo del equipo. El Future of Jobs Report 2025 del World Economic Forum ubica la alfabetización en IA entre las habilidades de crecimiento más rápido, y en desarrollo eso se traduce en una expectativa concreta desde el primer año.

Traducido a una acción: en los próximos tres meses, elegí una parte repetitiva del trabajo de tu equipo y automatizala. Es el tipo de aporte que se nota y que no depende de que te asignen una tarea grande.

Cursos recomendados de Coderhouse

• Curso de Testing QA: nivel inicial-intermedio. El testing es la habilidad que más rápido cambia la percepción sobre tu seniority.

• Curso de DevOps y Cloud: nivel intermedio-avanzado. Cubre la zona incómoda —deploys, monitoreo, infraestructura— que separa juniors de semi-seniors.

• Curso de AI Engineering: para incorporar IA al desarrollo con criterio técnico y no solo como autocompletado.

• Carrera de Desarrollo Backend: el camino profundo si querés consolidar arquitectura, bases de datos y escalabilidad.

Preguntas frecuentes

¿Cuánto tiempo lleva pasar de junior a semi-senior?

Entre uno y tres años, con mucha variación según el contexto. Lo que acelera el proceso no es el tiempo sino la exposición: participar de deploys, incidentes y tareas mal definidas enseña más rápido que acumular tickets simples. Alguien con dos años en un equipo exigente puede estar más listo que alguien con cuatro en un rol repetitivo.

¿Qué diferencia concretamente a un semi-senior de un junior?

La autonomía frente a la ambigüedad. Un junior ejecuta tareas bien definidas; un semi-senior recibe un problema difuso, lo descompone, estima, lo lleva a producción y anticipa los casos borde. La otra diferencia visible es que sus pull requests casi no vuelven con comentarios.

¿Conviene cambiar de empresa para ascender más rápido?

A veces. Si tu rol no te expone a producción, arquitectura o tareas ambiguas, el techo de aprendizaje llega rápido y cambiar acelera. Si sí tenés esa exposición y mentoría, quedarte suele rendir más, porque el conocimiento del dominio es parte de lo que se evalúa como seniority.

¿Usar IA para programar frena mi crecimiento como developer?

Depende de cómo la uses. Aceptar código generado sin entenderlo frena el crecimiento y crea un perfil frágil. Usarla para acelerar tareas que ya sabés hacer, revisar lo que devuelve y estudiar las soluciones que propone lo acelera. La habilidad que hoy se evalúa es la revisión crítica, no la escritura desde cero.

¿Qué evidencia sirve para pedir un ascenso?

Cosas verificables: una feature llevada de punta a punta con documentación, cobertura de tests agregada a un módulo crítico, un postmortem de incidente escrito, revisiones de código que mejoraron el trabajo de otros, o una automatización que le ahorró tiempo al equipo. "Mejoré mucho" no funciona como argumento.