Grok para desarrolladores

Un revisor rápido y gratis para cuando te trabas con el código: descifra stack traces, halla bugs de desbordamiento, crea pruebas y redacta la documentación.

5 min de lecturaActualizado

Grok es un excelente patito de goma que te responde. En grok.online no cuesta nada y no necesitas cuenta: Grok 4.20 es rápido para dudas puntuales, Grok 4.3 Thinking razona antes de responder y es la mejor opción para corregir bugs, y Grok 4.7, el modelo más nuevo, está disponible para los problemas más difíciles con 10 de tus 30 mensajes diarios. Los tres pueden leer capturas de pantalla. Aquí tienes siete casos de uso, cada uno con un prompt que puedes abrir en el chat y adaptar a tu gusto.

Encuentra y corrige errores

La mayor parte del tiempo de depuración se va en entender qué está pasando. Estos prompts aceleran esa parte.

Descifra un stack trace

Pega el error completo, sin parafrasear, junto con las líneas a las que apunta. Pide la causa en palabras sencillas antes de cualquier solución para que puedas evaluar la respuesta.

Estoy usando [lenguaje y versión] con [framework]. Aquí está el error completo y el stack trace: [pega el error]. Aquí está el código al que apunta: [pega el código]. Explica con palabras sencillas qué salió mal y por qué, menciona primero la causa más probable y luego muestra el cambio más pequeño que lo solucione.

Ábrelo en el chat. El Code Assistant hace lo mismo en un solo panel.

Obtén un mapa de código que no escribiste tú

Heredar un archivo sin comentarios es un rito de iniciación. Antes de cambiar nada, pide un recorrido guiado que señale las partes más delicadas.

Acabo de heredar este archivo en [lenguaje] y necesito modificar [funcionalidad]. Dame un recorrido breve: de qué se encarga el archivo, las funciones principales en el orden en que se ejecutan, qué estado global o efectos secundarios debo vigilar y cuál es el lugar más seguro para hacer mi cambio: [pega el código]

Pide el recorrido y luego pregunta sobre cualquier función que todavía te parezca extraña.

Caza un error de lógica con un modelo de razonamiento

Cuando el programa no falla pero el resultado es incorrecto, necesitas un seguimiento minucioso. Grok 4.3 Thinking analiza el código paso a paso antes de responder, ideal para errores de desfase por uno (off-by-one) y condiciones mal planteadas.

Esta función en [lenguaje] debería [comportamiento esperado], pero para la entrada [entrada] devuelve [salida real] en lugar de [salida esperada]. Sigue la ejecución paso a paso con esa entrada, muestra los valores de las variables clave en cada paso y señala la línea exacta donde ocurre el fallo: [pega la función]

Rastréalo con Grok 4.3 Thinking.

Arregla un diseño roto a partir de una captura

Adjunta una captura de pantalla de la página tal como se ve ahora, pega el HTML y CSS relevante y describe cómo debería verse.

Adjunto una captura de pantalla de una página donde [describe el problema, p. ej., la barra lateral se superpone al contenido en pantallas estrechas]. Aquí está el HTML y CSS de esa parte: [pega el código]. Explica qué lo causa y dame el CSS corregido, modificando lo menos posible.

Abre este prompt y adjunta tu captura.

Planifica una refactorización arriesgada

Desentrañar un módulo enorme es justo donde vale la pena gastar uno de los mensajes diarios del modelo más nuevo. Pide un plan, no una reescritura directa.

A continuación tienes un módulo en [lenguaje] que se ha vuelto difícil de modificar: [pega el código]. No lo reescribas todavía. Describe sus responsabilidades, las dependencias ocultas y un plan de refactorización en pasos pequeños donde el código siga funcionando tras cada uno. Indica qué pruebas debería agregar antes del primer paso.

Planifícalo con Grok 4.7 y luego envía los pasos uno a uno a Grok 4.20.

Escribe el código que rodea a tu código

Pruebas, consultas, revisiones y documentación son las partes que suelen descuidarse cuando se acercan las fechas de entrega.

Escribe pruebas para los casos límite que pasaste por alto

Pide primero la lista de casos y el código de prueba después. En la lista es donde está el verdadero valor.

Aquí tienes una función en [lenguaje]: [pega la función]. Primero lista los casos límite que vale la pena probar, como entradas vacías, valores en los bordes y tipos no válidos, con una línea explicando el porqué de cada uno. Luego escribe las pruebas usando [framework de pruebas], una prueba por caso y con nombres claros.

Genera las pruebas, ejecútalas y quédate con las que fallen por buenas razones.

Consigue una revisión de código al estilo de un senior gruñón

Grok asumirá con gusto el papel del revisor que ya ha visto todos los bugs dos veces. Que sea gruñón está bien; que sea vago, no. Así que pide referencias de líneas.

Revisa este diff como un ingeniero senior gruñón pero justo. Señala errores, nombres poco claros, falta de manejo de errores y cualquier cosa que vaya a dar problemas en seis meses, cada uno con su referencia de línea y una sugerencia de arreglo. Ordena los problemas por gravedad y omite quejas puramente de estilo: [pega el diff]

Pide la revisión antes de que la vean tus compañeros de equipo.

Convierte un esquema en SQL y un README

Proporciona las definiciones de las tablas y la consulta en palabras sencillas, y pide una explicación breve junto con el código SQL.

Aquí están las definiciones de mis tablas para [base de datos, p. ej., PostgreSQL]: [pega el esquema]. Escribe una consulta que devuelva [lo que necesitas en palabras sencillas]. Explica cada join y filtro en una sola línea, y dime qué índice podría acelerarla cuando las tablas tengan millones de filas.

Escribe la consulta y luego pide una sección de README para documentar las tablas.

Qué evitar

  • Pegar información confidencial. Las claves de API, contraseñas, tokens y datos de clientes no deben entrar en ningún chat. Reemplázalos con marcadores de posición.
  • Confiar a ciegas en detalles de librerías. Los modelos tienen una fecha límite de conocimiento y no tienen acceso a internet, por lo que una función o parámetro podría estar desactualizado o inventado. Consulta la documentación oficial.
  • Subir a producción código sin probar. Un código que parece impecable aún puede fallar. Ejecútalo, pruébalo y revísalo.
  • Enviar repositorios enteros. Los mensajes muy largos se recortan. Envía solo la función relevante.

Páginas relacionadas

¿Listo para preguntarle algo a Grok?

Sin cuenta, sin descargas y sin tarjeta. Abre el chat, escribe tu pregunta y lee la respuesta de Grok al instante.

Abrir chat