LO
Desarrollador backend — tareas, una a una
La unidad de análisis es la tarea, no el nombre del puesto. Cada una de las siguientes lleva su dirección, si el juicio se apoya en evidencia o en una inferencia de la plataforma, el razonamiento y lo que no establece.
Todas las tareas de esta página#
Endpoints y la fontanería entre ellos
Automatizándose✓ Con evidenciaCRUD, validación, serialización, llamar a un servicio desde otro, y las pruebas de todo ello.
Bien especificado, muy representado en los datos de entrenamiento y verificable ejecutándolo — las mismas tres propiedades que hacen de cualquier tarea un caso fuerte para la generación. Es además una parte grande de lo que el trabajo de backend parece desde fuera.
Generar un endpoint no es lo mismo que decidir que debe existir, qué tiene que garantizar, o qué pasa cuando se le llama dos veces. Teclear rara vez fue la parte cara de este trabajo.
Mantenerlo correcto cuando las cosas pasan a la vez
Sigue llevándola una persona≈ Inferencia de la plataformaTransacciones, idempotencia, reintentos, orden — decidir qué no puede ser verdad nunca y asegurarse de que nunca lo es.
Estos fallos no aparecen en las pruebas y a menudo no aparecen en meses. Razonar sobre ellos exige sostener un modelo de qué más está corriendo y qué deja detrás un fallo parcial, y la respuesta correcta depende de garantías que ha dado el negocio y no del código que tienes delante.
Es un juicio sobre la naturaleza del trabajo, no uno medido. Los incidentes casi nunca se atribuyen en público a código de concurrencia generado, y ese silencio no es evidencia de que no ocurra: un análisis posterior que nombre una causa tan concreta es infrecuente en cualquier empresa.
El modelo de datos, y cambiarlo mientras está en uso
Sigue llevándola una persona≈ Inferencia de la plataformaDiseñar qué se guarda, y migrarlo después sin parar el servicio ni perder nada.
Las decisiones tempranas de esquema salen caras años más tarde de formas que ninguna herramienta puede ver desde el código actual, porque el coste vive en lo que ya se escribió dentro de los datos. Una migración es además irreversible en la práctica, lo que la mete en la categoría donde alguien tiene que responder y no solo asistir.
No dice nada sobre cuántas veces redactan ya las herramientas las migraciones, cosa que hacen de forma rutinaria. La afirmación va de quién decide y responde por ello, no de quién lo teclea.
Quién puede ver qué
Sigue llevándola una persona≈ Inferencia de la plataformaAutorización, fronteras entre inquilinos, qué se escapa en un mensaje de error, y qué expone un endpoint interno si alguien lo encuentra.
La generación optimiza para la petición que se describió, y un fallo de autorización es justo el caso que nadie describió. Es además el área donde una respuesta segura, plausible y equivocada es más peligrosa, porque parece exactamente una correcta hasta que alguien la explota.
Esto descansa en la estructura del problema, no en una medición; lo que lo zanjaría es un estudio de defectos que separe el código generado del escrito a mano dentro de la misma base de código. Los entornos regulados ya exigen aquí la firma de una persona, y puede que sea eso, más que la dificultad, lo que está sosteniendo el trabajo.
Cuánto cuesta y cuán rápido es
Aumentada por la máquina✓ Con evidenciaPlanes de consulta, caché, la factura, y la petición que se puso lenta porque cambió algo aguas arriba.
Las herramientas son de verdad fuertes detectando la consulta patológica y sugiriendo el índice. Son débiles en el compromiso — gastar dinero para ir más rápido es una decisión de negocio, y saber qué petición importa exige saber para qué sirve el producto.
Nada de esto mide cuánto de esto está hoy dirigido por herramientas en la práctica, y la respuesta difiere enormemente entre un equipo con presupuesto de observabilidad y uno sin él.
Ser a quien despierta el busca
Sigue llevándola una persona≈ Inferencia de la plataformaGuardia: decidir bajo presión de tiempo qué revertir, qué degradar y qué contarle a la gente mientras todavía está roto.
El diagnóstico está cada vez más asistido y eso ayuda de verdad. La decisión no: elegir aceptar una pérdida conocida para restaurar el servicio es un criterio con consecuencias que alguien tiene que asumir, y se toma con información incompleta por diseño.
Esto no dice nada sobre si la carga de guardias está subiendo o bajando, que es la pregunta que de verdad importa a la mayoría de los ingenieros y la que nadie publica.