Prompt Engineering para programación

Qué aprenderás

• Describir un cambio de software sin asumir que el modelo conoce el proyecto.
• Incluir entorno, comportamiento, código, límites y aceptación cuando importen.
• Mantener el prompt independiente del lenguaje aunque cambie el contexto técnico.

Qué contexto técnico hace falta

Según la tarea, indicá lenguaje y versión, framework, runtime, arquitectura, código existente, dependencias, restricciones, comportamiento actual/esperado, error, alcance, compatibilidad y cómo probar. No todas las tareas requieren cada dato: explicá lo que cambia la solución.

No pidas «reescribí todo» cuando necesitás un cambio localizado.

Una plantilla breve:

Objetivo: agregar validación a esta función sin modificar su interfaz pública.
Tecnología: TypeScript / Node.js 20.
Contexto: [módulo y comportamiento actual]
Entrada: [fragmento y caso que falla]
Restricciones: sin paquetes nuevos; mantener compatibilidad; modificar la función indicada.
Criterios: [casos válidos y rechazados]
Salida: causa, diff propuesto y pruebas.

Revisá el cambio, ejecutá compilación/pruebas y comprobá el comportamiento. Una respuesta convincente no es evidencia de que el parche compila.

Ejercicio transversal: alta y validación de clientes

El problema equivalente en las tres tecnologías: validar nombre, email y documento; rechazar documentos duplicados; no guardar parcialmente; informar rechazos y permitir un cliente válido. La estructura del pedido no cambia, pero las herramientas y restricciones sí.

TypeScript

Objetivo: corregir la validación del alta de clientes.
Contexto: servicio TypeScript en Node.js 20; el repositorio ya consulta el documento.
Datos: [función y error observado]
Restricciones: no agregar dependencias ni cambiar la interfaz pública.
Criterios: rechazar nombre/email/documento inválidos y documentos duplicados; guardar datos válidos; tests existentes pasan.
Salida: causa, cambio mínimo, tests y riesgos.

Python

Objetivo: validar importación de clientes desde CSV.
Contexto: servicio Python 3.12; hasta 10.000 filas por lote.
Datos: [función, muestra anonimizada y error]
Restricciones: conservar contrato del servicio; no agregar paquetes.
Criterios: reportar fila inválida sin insertar duplicados; aceptar cliente válido; resumir aceptados/rechazados.
Salida: diagnóstico, cambio y pruebas unitarias recomendadas.

SQL

Objetivo: revisar la estrategia de persistencia de un alta de clientes sin cambiar sus reglas.
Motor y versión: PostgreSQL 16.
Esquema: [tablas, clave única de documento, tipos y relaciones]
Datos: [consulta o procedimiento actual y caso duplicado]
Restricciones: no guardar filas parciales; mantener la respuesta funcional existente.
Criterios: dos altas simultáneas con el mismo documento no crean duplicados; una operación válida se confirma; una inválida se revierte.
Salida: diagnóstico, SQL propuesto, transacción, riesgos y pruebas de concurrencia.

La invariante es la misma; la versión, el lenguaje y el mecanismo que garantiza unicidad son propios de cada entorno.

Tecnologías complementarias y sistemas existentes

La misma disciplina sirve en C#, JavaScript, Java, VB.NET, VB6, PowerShell, React y otros entornos. Ejemplo legacy: «VB6 con ADO 2.8; no migrar a .NET; conserva firma pública y el cálculo de impuestos; reproduce el error con esta entrada; debe compilar en el entorno disponible». Un sistema antiguo puede ser crítico para la organización; no lo trates como una invitación automática a migrar.

Ejemplos complementarios, con el mismo objetivo pero contexto técnico específico:

C#: analizá esta validación en .NET Framework 4.7. Conservá el contrato del método y el manejo de errores existente. Proponé el cambio mínimo y pruebas compatibles con el proyecto.

PowerShell: corregí este script para Windows PowerShell 5.1. Conservá los nombres de parámetros y el formato de objetos que consumen los scripts siguientes. Incluí un caso de prueba para entrada vacía y uno para el archivo válido.

La estructura se mantiene; lenguaje, runtime, dependencias y compatibilidad cambian la solución aceptable.

Autoevaluación

¿Por qué indicar versión y comportamiento actual/esperado? Una sintaxis o comportamiento compatible con una versión puede fallar en otra; comparar lo que ocurre con lo esperado ofrece evidencia para diagnosticar y evita que el modelo asuma un entorno distinto.

Fuentes

• SitioDeRubros, Programación con IA en el ciclo de desarrollo — usos y etapas de desarrollo; consulta: 2026-10-03.
• SitioDeRubros, Contexto para programar con IA — referencia para asistentes sobre proyectos; consulta: 2026-10-03.
• TypeScript, Handbook; Python, Documentación; PostgreSQL, Documentación — documentación primaria de tecnologías; consulta: 2026-10-03.

Seguir aprendiendo

• Unidad 12: elegir entre analizar, generar, refactorizar y depurar.
• Unidad 13: dar a SQL el contexto propio de su motor y sus datos.