Explicar código
Un pull request con una función de doscientas líneas y sin descripción le pide al revisor reconstruir desde cero la intención del autor. Este endpoint lee un bloque de código y devuelve una explicación en lenguaje simple de qué hace y cómo, para que esa reconstrucción no tenga que ocurrir dentro de la cabeza de alguien.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
La función que superó a su propio nombre
La mayoría de las funciones comienzan haciendo una sola cosa clara, con un nombre acorde, y luego van acumulando un caso límite aquí, una rama de reintento allá, un condicional que alguien agregó bajo presión de una fecha límite, hasta que el nombre ya no describe el comportamiento y entender la lógica exige leerla línea por línea. Así evoluciona el código de forma normal, pero eso deja exactamente el tipo de función que frena una revisión o hace tropezar a quien la toque después. dev.code_explain lee esa complejidad acumulada y expresa con claridad qué hace el código ahora, no lo que su nombre sugiere que debería hacer.
Del código fuente al resumen
Envíe POST a /dev/code-explain con la función, método o bloque de código que quiere que se explique, y la llamada devuelve un task_id mientras se analiza en segundo plano. La explicación, entregada por webhook firmado o mediante un enlace firmado válido por 24 horas, cubre qué hace el código, la lógica que sigue y comportamientos notables como manejo de errores, efectos secundarios o casos límite, en un lenguaje que no exige releer el código para entenderlo.
Leer código siempre ha sido más difícil que escribirlo
La observación de que los programadores dedican mucho más tiempo a leer código que a escribirlo aparece desde hace décadas en la literatura de ingeniería de software, y es parte de por qué disciplinas como la programación letrada y el código autodocumentado surgieron como respuestas explícitas al mismo problema: la intención se pierde en cuanto el código cambia de manos o pasa el tiempo desde que se escribió. Los comentarios que explican por qué existe una función tienden a sobrevivir; los comentarios que explican exactamente qué hace cada línea tienden a pudrirse, porque se desincronizan la primera vez que la lógica cambia y nadie actualiza el texto de al lado. Una explicación generada bajo demanda, a partir del código tal como existe en este momento, no tiene ese problema de deterioro.
Dónde cambia realmente cómo trabaja un equipo
En la revisión de código, un revisor que no conoce un módulo recibe un resumen en lenguaje simple antes de meterse al diff, lo que convierte la revisión de una arqueología línea por línea en verificar si el comportamiento descrito es realmente el que debería ocurrir. En la incorporación de personal nuevo, un ingeniero recién llegado puede explicar archivos desconocidos de un sistema heredado sin distraer a un compañero senior de su propio trabajo para que lo narre en voz alta. Y para documentación, generar explicaciones de cada función pública de una biblioteca produce un primer borrador de documentación de API que una persona solo necesita editar, no escribir desde cero. Cobrado por solicitud más por cada mil palabras de código, el costo escala con cuánto hay realmente que explicar, y una explicación fallida nunca se cobra.
Qué puede hacer con ella
Revisión de pull requests
Un revisor explica una función desconocida agregada en un pull request para entender su comportamiento antes de verificar si la lógica es correcta.
Incorporación a un repositorio heredado
Un nuevo ingeniero explica los módulos centrales de un sistema heredado para armar un modelo mental funcional sin interrumpir a un compañero senior para que lo explique en persona.
Primer borrador de documentación de API
Un flujo de documentación explica cada función pública de una biblioteca para producir una descripción inicial que un redactor técnico luego refina.
Auditoría de scripts de automatización heredados
Un equipo de operaciones explica un script de despliegue antiguo que nadie del equipo actual escribió originalmente, antes de decidir si es seguro modificarlo o si conviene reemplazarlo.
Preguntas frecuentes
¿Cómo obtengo la explicación de un código con la API?
Envíe la función o bloque de código por POST a /dev/code-explain, guarde el task_id devuelto y reciba la explicación en lenguaje simple por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API para explicar código?
No, no hay plan gratuito ni prueba; cuesta $0.003 por solicitud más $0.0135 por cada 1,000 palabras de código, y una explicación fallida nunca se cobra.
¿Qué lenguajes de programación soporta?
Maneja código en los lenguajes más usados; indique el lenguaje o cualquier particularidad de la sintaxis para que la explicación refleje bien las convenciones de ese lenguaje.
¿Explica un archivo completo o solo una función?
Puede enviar desde una sola función hasta un archivo o módulo más grande; la explicación se ajusta a lo que envíe y el precio escala con la cantidad de palabras del código enviado.
¿Señala errores o solo describe el comportamiento?
Principalmente describe qué hace el código, incluyendo comportamientos notables como manejo de errores y casos límite; no sustituye una revisión de código dedicada ni una auditoría de seguridad.
¿Puedo explicar muchos archivos por lote?
Sí, envíe una tarea asíncrona por archivo o función y reciba cada explicación por webhook a medida que se complete, lo cual sirve para documentar un módulo completo de una vez.
¿Ya está disponible este endpoint?
Sí, /dev/code-explain está activo y aceptando solicitudes ahora mismo.
¿Se guarda el código que envío?
No, el código enviado y su explicación se eliminan después del período de retención y nunca se usan para entrenamiento.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/code-explain \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"…"}'const res = await fetch("https://api.kit.forhosting.com/dev/code-explain", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/code-explain",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/code-explain", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/code-explain", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"text": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.code_explain",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |