Eggthropic es un proyecto experimental independiente, sin afiliación ni respaldo de Anthropic.

Experimentos/Explicar ABAP legacy a consultores funcionales
SAPEn cursointermedio

Contenido verificado el 2026-07-06 · experimento de Eggthropic

Explicar ABAP legacy a consultores funcionales

Convertir un cálculo de plus de antigüedad HCM de estilo 2008 — sin un solo comentario útil — en dos explicaciones: una funcional sin jerga y otra técnica con flujo de datos, bugs sospechados y preguntas a verificar.

ARTEFACTO EN VIVO · CORRE EN TU NAVEGADOR
ClaudeCoworkABAPSAP HCM

Objetivo

Comprobar si Claude puede reconstruir la intención funcional de ABAP HCM legacy sin documentación — incluyendo patrones específicos de HR como la LDB PNP, rp_provide_from_last o la estructura DAR/DAT del infotipo 0041 — y servirla a dos audiencias distintas con el mismo análisis.

Contexto

Todo consultor SAP conoce la escena: un programa Z de hace quince años, sin comentarios, cuyo autor se fue hace una década, y un funcional preguntando «¿pero esto qué calcula exactamente?». El experimento usa un fragmento ficticio pero realista de cálculo de plus de antigüedad con 7 elementos plantados: un bloque de código muerto, un bug latente (índice sin formatear a dos dígitos en un ASSIGN dinámico), tres exclusiones silenciosas y dos supuestos de configuración del cliente.

Prompt utilizado

prompt

Eres un consultor SAP senior técnico-funcional. Te paso un programa ABAP legacy sin documentación. Genera DOS explicaciones separadas: A) FUNCIONAL, para un consultor sin ABAP — qué hace en una frase, paso a paso en lenguaje de negocio, tabla de infotipos usados, riesgos funcionales y preguntas concretas a validar. B) TÉCNICA, para el ABAPer que lo hereda — arquitectura, flujo de datos, puntos delicados y sugerencia breve de refactor. Regla clave: si un comportamiento depende de configuración del cliente (clases de fecha, CC-nóminas, subtipos), NO lo des por hecho — márcalo como pregunta a verificar. Si sospechas un bug, dilo como sospecha y explica cómo verificarlo.

Notas de implementación

La salida en dos capas permite usar el mismo análisis con dos audiencias sin redactar dos veces. La capa funcional tradujo el código a lenguaje de negocio con tabla de tramos, cinco riesgos (incluido el clásico «hay empleados que desaparecen del listado sin aviso») y cinco preguntas para negocio. La técnica reconstruyó el flujo de datos, señaló el código muerto y levantó la sospecha del bug del índice ('DAR1' vs 'DAR01') con propuesta de verificación.

Resultado

7/7 elementos plantados detectados: código muerto, bug latente como sospecha verificable, exclusiones silenciosas traducidas a riesgo funcional, y — lo más importante — las convenciones de configuración marcadas como preguntas, no como hechos. Misma advertencia que el caso de refactor: el modelo explicó código que él mismo construyó, así que es cota superior. La interpretación de los patrones HR está pendiente de contraste con documentación oficial y con la experiencia real del consultor.

Qué funcionó

  • El formato de dos capas (funcional/técnica) produce entregables usables tal cual, sin retrabajo
  • La regla «marcar convenciones de cliente como pregunta a verificar» se cumplió — es la mitigación clave contra la sobreconfianza
  • Detectó el bug latente del índice dinámico y lo presentó como sospecha con método de verificación, no como certeza
  • La aclaración «este programa no graba nada en SAP» evita el malentendido funcional más caro

Qué falló

  • Sesgo de auto-explicación: el agente conocía los defectos porque diseñó la entrada
  • La corrección de la interpretación de patrones HR (LDB PNP, HR_HK_DIFF_BT_2_DATES) no se ha contrastado contra un sistema
  • Sin métrica de tiempo frente a documentar a mano: falta la línea base

Próxima iteración

Pasar el prompt a un programa Z real del trabajo (anonimizado) y que el consultor puntúe con rúbrica: exactitud funcional, exactitud técnica, errores de interpretación y preguntas útiles generadas. Es el caso con mejor relación esfuerzo/valor: no genera código que deba compilar.

Reproducelo tú

Este experimento es un playbook: con las herramientas de arriba y el prompt exacto de esta página puedes repetirlo en tu propio entorno. Si lo haces — funcione o no — cuéntanoslo en GitHub: las réplicas con resultados distintos son tan valiosas como el experimento original.

ClaudeCoworkABAPSAP HCM

Referencias

This experiment has an interactive version in the Lab.

Open interactive lab