Notas prácticas: Preguntas útiles para agentes de IA que todo desarrollador debería tener guardadas
Guía práctica paso a paso de Notas útiles: Prompts para agentes de IA que todo desarrollador debería guardar, incluyendo contratos, verificaciones y espacios para código listo para usar en equipos que implementan este patrón.
Deje de escribir las mismas instrucciones desde cero. Aquí tiene una biblioteca probada en el campo para su flujo de trabajo diario.
Revisión de código y calidad
Revisión profunda de código
You are a senior software engineer doing a thorough code review.
Review the following code for:
- Correctness and logic errors
- Edge cases that aren't handled
- Security vulnerabilities (injection, auth issues, data exposure)
- Performance problems (N+1 queries, unnecessary loops, memory leaks)
- Readability and naming clarity
- Missing or misleading commentsFor each issue, state: the problem, why it matters, and a concrete fix.
Don't mention things that are fine. Only flag real issues.Code:
[PASTE CODE HERE]
Utilizar el método del pato de goma para detectar errores sutiles
I have a bug I can't figure out. I'll describe what I expect to happen and what's actually happening. Ask me clarifying questions one at a time to help me find the root cause. Don't guess the answer yet — walk me through it.
Expected behavior: [DESCRIBE]
Actual behavior: [DESCRIBE]
What I've already tried: [DESCRIBE]Relevant code:
[PASTE CODE HERE]
Identificar los cuellos de botella en el rendimiento
Analyze this code for performance issues. Focus on:
- Time complexity of key operations
- Unnecessary re-computation or redundant work
- Memory allocation patterns
- Any blocking operations in an async context
- Database query efficiency (if applicable)
Suggest specific optimizations with expected impact. Show before/after where relevant.Language/framework: [e.g., Node.js / PostgreSQL]
Code:
[PASTE CODE HERE]
Escribir y mejorar código
En la etapa de escritura e mejora de código, defina las entradas, el responsable de la tarea y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar la tarea a partir de un punto de control conocido sin tener que adivinar el estado oculto. Guarde la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben encontrarse en un lugar que los operadores puedan auditar sin necesidad de leer todo el sistema. Prefiera salidas estructuradas con validación de esquema sobre textos libres cuando el siguiente paso sea escribir código o realizar una llamada a una herramienta.
Implementar una funcionalidad según las especificaciones
En la fase de implementación de una funcionalidad, se deben definir las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Se debe documentar tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores. Se prefieren salidas estructuradas con validación de esquema sobre textos en formato libre cuando el siguiente paso sea escribir código o realizar una llamada a una herramienta.
Implement the following feature in [LANGUAGE/FRAMEWORK].
Requirements:
- [REQUIREMENT 1]
- [REQUIREMENT 2]
- [REQUIREMENT 3]Constraints:
- Must integrate with: [EXISTING SYSTEM OR PATTERN]
- Must handle errors by: [e.g., throwing custom errors / returning Result types]
- Must be testable in isolation (no hidden dependencies)Do not add features beyond what's listed. Add inline comments only where the logic is non-obvious.
Refactorizar para mejorar la legibilidad sin cambiar el comportamiento
Para el refactoring con el fin de mejorar la legibilidad sin pasar por etapas, se deben definir las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Es preferible utilizar unidades pequeñas y verificables en lugar de scripts extensos. Cuando un paso falla, el error debe indicar una única responsabilidad y no un proceso complicado. Cuando el siguiente paso sea código o una llamada a una herramienta, es mejor utilizar salidas estructuradas con validación de esquema en lugar de texto sin formato.
Refactor the following code to improve readability. Rules:
- Do NOT change behavior or external API
- Rename variables and functions to be self-documenting
- Break up functions longer than 20 lines if it improves clarity
- Remove clever one-liners that sacrifice readability for brevity
- Add a brief comment above any function whose purpose isn't obvious from its name
Show the refactored version with a short explanation of the key changes made.Code:
[PASTE CODE HERE]
Convertir código de estilo callback a async/await
Para llevar al siguiente paso el código en estilo de callback de Convert, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Considere esta etapa como un contrato entre las entradas y los resultados validados. Asigne nombres a los artefactos, defina verificaciones de éxito y rechace las completaciones parciales silenciosas. Prefiera resultados estructurados con validación de esquema sobre textos en formato libre cuando el siguiente paso sea código o una llamada a una herramienta.
Convert the following callback-based Node.js code to use async/await with proper error handling. Preserve all logic exactly. Use try/catch blocks. If the original uses EventEmitters or streams that can't be straightforwardly promisified, flag them and suggest an approach.
Code:
[PASTE CODE HERE]
Escribir una función utilitaria a partir de una descripción
En la etapa de escribir una función utilitaria, defina las entradas, el responsable del paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Registre los tiempos de ejecución y el costo en tokens o consultas junto con los resultados funcionales. La visibilidad temprana de los costos evita facturas inesperadas cuando el proceso pasa de entornos de demostración a entornos compartidos. Prefiera salidas estructuradas con validación de esquema sobre texto en formato libre cuando el siguiente paso sea escribir código o realizar una llamada a una herramienta.
Write a [LANGUAGE] utility function that:
- Does: [DESCRIBE WHAT IT SHOULD DO]
- Input: [DESCRIBE INPUT TYPE AND SHAPE]
- Output: [DESCRIBE OUTPUT TYPE AND SHAPE]
- Edge cases to handle: [LIST THEM, e.g., empty arrays, null values, negative numbers]
Include TypeScript types if applicable. Include 3–5 usage examples as comments below the function.
Pruebas
En la fase de pruebas, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido, sin tener que adivinar el estado oculto. Mantenga la configuración fuera del código de la aplicación. Los archivos de entorno, los almacenes de datos secretos y las banderas de funcionalidad deben estar en un lugar donde los operadores puedan auditarlos sin necesidad de leer todo el sistema. Prefiera salidas estructuradas con validación de esquema sobre texto libre cuando el siguiente paso sea escribir código o realizar una llamada a una herramienta.
Genere pruebas unitarias exhaustivas
En la fase de generación de pruebas unitarias exhaustivas, defina las entradas, el responsable de cada paso y los criterios de finalización antes de modificar el código. Los operadores deben poder volver a ejecutar el paso a partir de un punto de control conocido sin tener que adivinar el estado oculto. Documente tanto la ruta óptima como la ruta de recuperación. Las reintentos, los controles humanos y el manejo de mensajes no entregados forman parte del producto, no son mejoras posteriores.
Write unit tests for the following function using [JEST / VITEST / MOCHA / etc.].
Cover:
- The happy path
- All documented edge cases
- Invalid inputs (null, undefined, wrong types, out-of-range values)
- Any error conditions the function is supposed to throwUse descriptive test names that read as plain English. Group related tests with describe blocks. Mock external dependencies.Function to test:
[PASTE FUNCTION HERE]
Escribir pruebas de integración para una ruta API
Write integration tests for this Express route using supertest and Jest.
Test:
- Successful response (correct status code and response shape)
- Validation errors (missing or invalid fields)
- Authentication/authorization failures
- Resource not found
- Any side effects (e.g., email sent, DB record created)Mock the database and any external services. Use beforeEach/afterEach for setup and teardown.Route handler:
[PASTE CODE HERE]
Generar datos de prueba / fixtures
Generate realistic test fixtures for the following data model. Create:
- 1 valid "happy path" example
- 1 example at boundary values (min/max lengths, edge dates, zero amounts)
- 1 example that should fail validation and why
Format as [JSON / TypeScript const / JS object]. Add a comment on each fixture explaining what scenario it represents.Data model / schema:
[PASTE SCHEMA HERE]
Depuración y diagnóstico
Explicar un mensaje de error enigmático
I'm getting this error in my [LANGUAGE/FRAMEWORK] application. Explain:
1. What exactly this error means in plain English
2. The most common causes, ranked by likelihood
3. Step-by-step how to diagnose which cause applies to my situation
4. The fix for each cause
Error:
[PASTE FULL ERROR AND STACK TRACE HERE]Context (what I was doing when it happened):
[DESCRIBE]
Diagnosticar fugas de memoria
Help me diagnose a memory leak in my Node.js application.
Symptoms: [e.g., heap grows steadily under load, never GC'd, crashes after ~2 hours]
Environment: Node.js [VERSION], [FRAMEWORK]
What I've already checked: [LIST]Here are the relevant parts of the code:
[PASTE CODE]Walk me through:
1. What patterns in this code are likely culprits
2. How to confirm the leak with heap snapshots or --inspect
3. The fix
Comprender código desconocido
Explain this code to me as if I'm a competent developer but unfamiliar with this codebase/library.
Tell me:
- What it does at a high level (1–2 sentences)
- What each major section does
- Any non-obvious patterns or idioms being used and why
- What I'd need to understand before safely modifying itCode:
[PASTE CODE HERE]
Arquitectura y diseño
Diseñar un componente del sistema
I need to design [COMPONENT NAME] for a [TYPE OF APPLICATION].
Context:
- Scale: [e.g., ~10k requests/day, 1M users]
- Existing stack: [e.g., Node.js, PostgreSQL, Redis, deployed on AWS]
- Key constraints: [e.g., must be horizontally scalable, strong consistency required]Give me:
1. A high-level design with the main components and how they interact
2. The data model (tables or document schemas)
3. The API surface (endpoints or function signatures)
4. Where the hard problems are and how you'd approach them
5. What you'd defer to a v2
Evaluar una decisión arquitectónica
I'm deciding between two approaches for [PROBLEM].
Option A: [DESCRIBE]
Option B: [DESCRIBE]My context:
- Team size: [N developers]
- Expected scale: [DESCRIBE]
- Existing infrastructure: [DESCRIBE]
- Main concerns: [e.g., operational complexity, cost, latency]Compare them honestly. Don't hedge — give me a recommendation and explain the trade-offs I'd be accepting.
Diseñar un esquema de base de datos
Design a PostgreSQL schema for the following domain.
Domain description:
[DESCRIBE YOUR DATA AND RELATIONSHIPS]Requirements:
- [e.g., support multi-tenancy]
- [e.g., soft deletes]
- [e.g., audit log of all changes]
- [e.g., efficient queries for X and Y access patterns]Output:
- CREATE TABLE statements with constraints and indexes
- Brief explanation of key design decisions
- Any denormalization choices and why
Documentación
Escribir un README para un proyecto
Write a README.md for the following project.
Project name: [NAME]
What it does: [DESCRIBE]
Tech stack: [LIST]
Target audience: [e.g., internal devs, open source contributors, end users]Include sections for: overview, prerequisites, installation, usage with examples, environment variables, running tests, and contributing. Use a practical, no-fluff tone. Don't add sections that would be empty.
Documentar una función o módulo
Write JSDoc / docstring documentation for the following code.
Include:
- A one-sentence summary of what it does
- @param tags with types and descriptions for every parameter
- @returns with type and description
- @throws for any errors it can raise
- A usage example in @exampleBe precise about types. If a parameter has constraints (e.g., must be positive, must be ISO 8601), document that.Code:
[PASTE CODE HERE]
Escribir un documento de diseño técnico (TDD)
Write a technical design document for the following feature.
Feature: [NAME AND BRIEF DESCRIPTION]
Author: [YOUR NAME]
Status: DraftSections to include:
1. Problem statement — what problem this solves and for whom
2. Goals and non-goals
3. Proposed solution — high-level design
4. Detailed design — data models, API changes, key logic
5. Alternatives considered and why they were rejected
6. Open questions
7. Security and privacy considerations
8. Rollout planContext to incorporate:
[PASTE ANY CONTEXT — TICKETS, DISCUSSIONS, EXISTING CODE]
Git y flujo de trabajo
Escribir un mensaje de commit significativo
Write a commit message for the following change. Follow the Conventional Commits format (type(scope): description). Add a body paragraph explaining *why* the change was made, not just what changed. Keep the subject line under 72 characters.
Changes made:
[PASTE DIFF OR DESCRIBE THE CHANGE]
Escribir una descripción para una solicitud de pull
Write a pull request description for the following change.
Include:
- What this PR does (2–3 sentences)
- Why it's being done (the problem or requirement it addresses)
- How to test it manually
- Any risks or areas that need careful review
- Links to related issues or tickets: [LIST]Changes:
[PASTE DIFF SUMMARY OR DESCRIBE KEY CHANGES]
Resumir una PR para un stakeholder no técnico
Summarize the following code changes for a non-technical stakeholder. Avoid jargon. Focus on what changes from the user's perspective, what risk (if any) it introduces, and when it will be available.
Keep it under 5 sentences.Changes:
[PASTE PR DESCRIPTION OR DIFF SUMMARY]
Aprendizaje y exploración
Explicar un concepto con un ejemplo práctico
Explain [CONCEPT] to me. I'm a [junior/mid/senior] developer familiar with [RELEVANT BACKGROUND].
Use a concrete, practical example — not a toy one. Show me code I'd actually write in a real project. After the example, explain the underlying mechanism in plain language. Then tell me: when should I use this, and when should I avoid it?
Descubrir lo que no se sabe sobre un tema
I know the basics of [TOPIC]. List 10 things about [TOPIC] that intermediate developers often don't know but should. For each one, give a one-paragraph explanation and a practical example of why it matters.
Prepárese para un tema de entrevista técnica
I have an interview coming up and I want to study [TOPIC] deeply.
Give me:
1. The 10 most important concepts to understand
2. For each concept: a clear explanation, a code example, and a common interview question about it
3. The 3 questions most likely to trip up mid-level candidates on this topic, with ideal answers
Consejos para formular preguntas que son aplicables a todos estos casos
Lista de verificación operativa
Lecturas relacionadas
- Notas prácticas: 7 mejores agentes de programación con IA que cada desarrollador debería conocer en 2026 — Guía práctica de Notas prácticas: 7 mejores agentes de programación con IA que cada desarrollador debería conocer en 2026: contratos, verificaciones y espacios para código listo para usar en equipos que implementan este patrón.
- Notas prácticas: Entonces, ¿con qué Agent SDK deberías desarrollar? — Guía práctica de Notas prácticas: Entonces, ¿con qué Agent SDK deberías desarrollar?: contratos, verificaciones y espacios para código listo para usar en equipos que implementan este patrón.