Última verificación: 16 de julio de 2026.
DeepSeek puede apoyar tareas delimitadas: explicar un módulo, convertir requisitos en casos de prueba, proponer un parche pequeño, comparar alternativas o revisar un cambio con una lista de riesgos. No sustituye al repositorio, al compilador, al análisis estático, al escáner de dependencias ni a la persona que aprueba el cambio. El modelo no conoce por defecto tu código, no ejecuta lo que produce y no tiene acceso nativo a GitHub, GitLab, Jira o al entorno de producción.
La API oficial ofrece DeepSeek V4 Flash y DeepSeek V4 Pro. Ambos son modelos de texto, admiten llamadas a herramientas y modos con o sin razonamiento. Su contexto amplio ayuda a trabajar con especificaciones y varios archivos, pero enviar un repositorio completo suele ser innecesario, costoso y arriesgado. La ficha de DeepSeek V4 recoge límites y capacidades comprobados.
Para una nueva integración utiliza identificadores explícitos como deepseek-v4-flash o deepseek-v4-pro y consulta la documentación antes del despliegue. Los alias históricos pueden cambiar o retirarse. Tampoco debe describirse toda la plataforma como «código abierto»: algunos pesos o repositorios tienen licencias específicas, mientras que la API alojada es un servicio con sus propias condiciones.
Aviso de independencia: DeepSeek Español es un sitio independiente y no oficial. No pertenece a DeepSeek ni representa a la empresa. Los ejemplos siguientes requieren revisión, pruebas y controles de seguridad; ningún código generado debe desplegarse únicamente porque compila.
Principio central: contexto mínimo, cambio pequeño y prueba reproducible
La calidad mejora cuando la tarea tiene límites verificables. En lugar de «arregla mi aplicación», entrega el comportamiento esperado, el error observado, versiones relevantes y el fragmento mínimo que reproduce el problema. Pide una hipótesis antes del parche, limita los archivos que pueden modificarse y exige pruebas que fallen antes y pasen después.
Objetivo: corregir la condición de carrera descrita abajo.
Entorno: Python 3.13, FastAPI 0.x, PostgreSQL 17.
Archivos permitidos: app/jobs.py y tests/test_jobs.py.
Restricciones: no cambies la API pública ni añadas dependencias.
Primero explica dos hipótesis comprobables. Después propón un diff unificado y una prueba que reproduzca el fallo. Si falta información, pregunta; no inventes funciones ni versiones.Flujo de trabajo recomendado
1. Especifica el contrato
Describe entradas, salidas, invariantes, errores y requisitos no funcionales. Añade qué no debe cambiar. Una historia de usuario es insuficiente si no define qué ocurre con datos vacíos, duplicados, concurrencia, permisos o fallos de red. Convierte criterios ambiguos en ejemplos observables antes de pedir código.
Transforma este requisito en criterios Given/When/Then. Señala ambigüedades sobre autorización, zona horaria, idempotencia y errores parciales. No propongas implementación todavía. Formula como máximo siete preguntas al equipo de producto.2. Selecciona el contexto
Incluye el árbol de directorios relevante, interfaces públicas, tipos, pruebas existentes, mensaje de error y configuración no secreta. Sustituye credenciales y datos reales. Si hay documentación interna, identifica su fecha y versión. Pedir al modelo que enumere primero lo que sabe y lo que infiere ayuda a detectar supuestos ocultos.
- Necesario: código que participa en el flujo, contrato y prueba mínima.
- Útil: convenciones, versiones bloqueadas y decisiones arquitectónicas vigentes.
- Excluir: archivos
.env, claves, tokens, datos de clientes, volcados y módulos no relacionados. - Marcar: fragmentos truncados, código generado y dependencias que el modelo no puede confirmar.
3. Pide un plan que pueda refutarse
Un plan útil relaciona cada cambio con una evidencia. Solicita riesgos, alternativa descartada y modo de comprobar el resultado. Si el modelo propone una biblioteca o método, verifica su existencia en la documentación de la versión exacta. No aceptes una migración amplia para resolver un fallo local sin justificar el alcance.
4. Genera el menor diff posible
Pide un parche, no archivos completos, salvo que se trate de un archivo nuevo. Limita funciones y dependencias. Revisa línea por línea: manejo de errores, recursos, límites, permisos y compatibilidad. El texto explicativo del modelo no demuestra que el parche tenga esas propiedades.
Produce un diff unificado mínimo. No modifiques formato ajeno al cambio. Añade comentarios solo donde expliquen una decisión no obvia. Después del diff, lista: supuestos, riesgos restantes y comandos exactos que un humano debe ejecutar para validarlo.5. Prueba en capas
Ejecuta el parche en una rama o entorno aislado. Empieza por la prueba que reproduce el fallo y continúa con unitarias, integración, análisis estático, tipos, dependencias y pruebas de seguridad apropiadas. Revisa casos negativos: entrada maliciosa, timeout, reintento, doble envío, falta de permisos y datos inesperadamente grandes. La aprobación humana debe basarse en resultados guardados, no en la seguridad verbal del modelo.
6. Revisa y documenta la decisión
El autor revisa lógica; otra persona revisa riesgos y mantenibilidad según el impacto. Registra qué sugirió la IA, qué cambió el equipo, qué pruebas se ejecutaron y quién aprobó. Actualiza comentarios, ADR, runbook y notas de migración cuando corresponda. Si no puedes explicar el código sin el chat, todavía no está listo.
Casos de uso concretos
Comprender código heredado
Pide un mapa de responsabilidades y flujo de datos basado solo en los archivos entregados. Exige que cada conclusión cite archivo y símbolo. Después contrasta con pruebas, historial y ejecución. El modelo puede confundir una ruta muerta con comportamiento actual o pasar por alto configuración externa.
Explica el flujo desde POST /orders hasta la escritura en base de datos. Para cada paso cita archivo, clase o función. Separa «observado en el código» de «inferencia». Señala llamadas externas, transacciones y puntos donde puede duplicarse una operación. No supongas contenido de archivos ausentes.Diseñar pruebas
Entrega el contrato y pruebas existentes, y pide una matriz de particiones y límites. No aceptes pruebas que simplemente reproduzcan la implementación. Incluye propiedades, errores y concurrencia cuando sean relevantes. El equipo debe revisar que una prueba fallaría ante el defecto que pretende detectar.
Crea una matriz de pruebas para esta función. Incluye caso nominal, límites, entrada inválida, repetición e invariantes. No escribas código hasta que yo apruebe la matriz. Indica qué riesgo cubre cada caso y cuál no.Depurar un incidente
Comparte métricas y logs anonimizados, con periodo y zona horaria. Pide hipótesis ordenadas por evidencia y una observación que confirme o descarte cada una. No permitas cambios destructivos ni acceso de escritura desde un agente sin controles. Durante un incidente, una respuesta rápida pero inventada puede ampliar el daño.
Con estos eventos anonimizados, formula como máximo cuatro hipótesis. Para cada una indica evidencia a favor, evidencia en contra, consulta de solo lectura para comprobarla y riesgo de esa consulta. No recomiendes reiniciar, borrar o migrar datos.Revisar código y seguridad
Usa una lista específica del sistema: autenticación, autorización, inyección, exposición de datos, SSRF, rutas de archivos, deserialización, criptografía, límites y registros. Una revisión del modelo es una señal adicional, no una auditoría. Valida con herramientas especializadas y una persona con experiencia en el lenguaje y el dominio.
Revisa este diff como apoyo a una revisión de seguridad. Informa solo hallazgos vinculados a una línea. Para cada uno incluye escenario de abuso, precondición, impacto, confianza y prueba segura. No marques una vulnerabilidad como confirmada si depende de código no mostrado.Documentación y migraciones
El modelo puede transformar un diff aprobado en borrador de changelog, instrucciones o ADR. Aporta el comportamiento real y evita promesas. Para migraciones, exige reversión, compatibilidad durante el despliegue, estimación de volumen, observabilidad y criterio de parada. Nunca ejecutes comandos de migración generados sin revisión y copia de seguridad verificada.
Integrar la API en herramientas internas
Una integración típica coloca un servicio controlado entre el repositorio y la API. Ese servicio selecciona contexto, elimina secretos, aplica una plantilla, llama al modelo y devuelve una sugerencia. El modelo solo recibe lo que la aplicación envía. El acceso a ramas, tickets o pipelines debe implementarse mediante las APIs de esos sistemas, con permisos mínimos y registros propios.
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["DEEPSEEK_API_KEY"],
base_url="https://api.deepseek.com",
)
response = client.chat.completions.create(
model="deepseek-v4-flash",
messages=[
{"role": "system", "content": "Revisa solo el diff aportado. No inventes archivos."},
{"role": "user", "content": sanitized_diff},
],
)
print(response.choices[0].message.content)La clave se obtiene de una variable del servidor; sanitized_diff debe generarse después de filtrar secretos y datos personales. Añade timeout, reintentos con límite, control de tamaño, métricas y tratamiento de errores antes de producción. Consulta nuestra guía actual de la API para formatos de respuesta, JSON y herramientas.
En llamadas a herramientas, valida cada argumento contra un esquema y una lista permitida. Una herramienta de lectura no debe convertirse en ejecución arbitraria. Si se usa el modo de pensamiento durante tool calls, sigue exactamente el ciclo oficial: la aplicación debe conservar el mensaje de asistente requerido, incluido reasoning_content, al enviarlo de vuelta con el resultado de la herramienta. Omitirlo puede causar un error de API. No registres ese contenido por defecto.
Dependencias, datos y operaciones
Dependencias, versiones y código inexistente
Un fallo frecuente es aceptar una función, bandera o paquete plausible que no existe en la versión bloqueada. Adjunta el manifiesto y el fragmento relevante de la documentación, y pide que el modelo no utilice interfaces fuera de ese material. Después comprueba el registro oficial, la licencia, el mantenimiento y las vulnerabilidades de toda dependencia propuesta. No instales un paquete solo porque su nombre aparece en una respuesta.
Cuando el código depende de una API externa, prueba respuestas incompletas, cambios de esquema, límites de cuota, reintentos y duplicados. Usa versiones fijadas y contratos. Si el modelo sugiere actualizar una dependencia para resolver un problema, separa la actualización del parche funcional cuando sea posible; así puedes atribuir fallos y revertir con menor riesgo.
Cambios de base de datos y operaciones
Trata SQL, infraestructura y comandos de shell como material de alto impacto. Pide una explicación de lecturas, escrituras, bloqueos y volumen, pero verifica con el motor real y un plan de ejecución. Ensaya sobre datos sintéticos o una copia autorizada. Exige copia de seguridad comprobada, reversión, observabilidad y criterio de interrupción. No permitas que un agente ejecute automáticamente DROP, borrados masivos, cambios de permisos o despliegues.
Analiza esta migración sin ejecutarla. Enumera bloqueos posibles, impacto por volumen, compatibilidad durante un despliegue gradual, consulta de verificación y plan de reversión. Marca cualquier operación destructiva. No supongas índices, tamaño ni versión que no aparecen en la entrada.Seguridad y privacidad
Considera el prompt y la salida como datos que cruzan una frontera de confianza. La política oficial de DeepSeek indica que sus servicios directos pueden recopilar prompts y que la información puede procesarse o almacenarse en China; no promete retención cero de forma general. Si tu aplicación usa la API, tú también debes definir finalidad, acceso, conservación, borrado y transparencia para tus usuarios.
- Bloquea claves, tokens, certificados, cookies, datos personales y secretos detectados.
- Aplica permisos de solo lectura por defecto y separa propuesta de ejecución.
- Trata el contenido de issues, comentarios y código como entrada no confiable frente a prompt injection.
- Limita archivos, tokens, coste, tiempo y número de llamadas por tarea.
- No envíes código sujeto a restricciones contractuales sin autorización.
- Registra decisiones y resultados, minimizando prompts y contenido sensible.
- Requiere aprobación explícita para fusionar, desplegar o modificar datos.
Consulta la información de privacidad y la guía de seguridad. El equipo jurídico y de seguridad debe evaluar proveedor, transferencias, licencias y requisitos regulatorios del proyecto.
Cómo evaluar si realmente ayuda
Crea un conjunto de tareas representativas con respuestas o criterios conocidos. Mide corrección funcional, defectos de seguridad, precisión de referencias, porcentaje de sugerencias aceptadas, tiempo total hasta aprobación y coste. Incluye casos adversos y entradas incompletas. Compara el flujo con y sin asistencia; velocidad de generación no equivale a menor tiempo de ingeniería.
| Métrica | Pregunta |
|---|---|
| Correctitud | ¿Pasa pruebas independientes y respeta el contrato? |
| Seguridad | ¿Introduce permisos, exposición o dependencias de riesgo? |
| Mantenibilidad | ¿El equipo comprende y puede modificar el resultado? |
| Tiempo total | ¿Reduce ideación, revisión y corrección combinadas? |
| Fiabilidad | ¿Mantiene calidad ante versiones y casos distintos? |
| Coste | ¿Incluye tokens, infraestructura y revisión humana? |
Preguntas frecuentes
¿DeepSeek puede acceder a mi repositorio?
No por defecto. Una aplicación de terceros debe recuperar y enviar el contenido mediante la API del proveedor del repositorio. Esa aplicación controla permisos, filtrado y registro.
¿Puede ejecutar o probar el código?
El modelo de texto no ejecuta código por sí solo. Un sistema externo puede ofrecer una herramienta aislada, pero necesita límites, supervisión y aprobación. Siempre revisa los resultados reales del entorno.
¿Qué modelo debo usar?
Evalúa Flash y Pro con tus tareas, lenguaje, latencia y presupuesto. Un nombre de modelo no sustituye una prueba interna. La página de precios de DeepSeek API permite estimar el coste.
¿Es seguro pegar un error de producción?
Solo después de eliminar tokens, identificadores, datos personales, payloads y detalles sensibles. Prefiere un caso mínimo sintético. Sigue la política de tu organización y del proveedor.
¿Un review de IA reemplaza el code review?
No. Puede señalar posibilidades, pero produce falsos positivos y omisiones. La aprobación debe seguir en manos de personas responsables y herramientas verificables.
¿Debo conservar todos los prompts?
No por defecto. Define una finalidad y un periodo; minimiza contenido sensible y controla acceso. Para auditoría puede bastar registrar versión, plantilla, hash del cambio, resultado y aprobación.