Claude Code para no ingenieros: flujos seguros, prompts, permisos y casos de uso

Claude Code no es solo para equipos de ingeniería. También puede ayudar a marketing, operaciones, soporte, ventas, recursos humanos y fundadores a ordenar documentación, actualizar textos de una web, preparar informes con CSV y convertir una petición confusa en una lista de tareas revisable.

La clave es no tratarlo como piloto automático. Claude Code puede leer archivos, modificarlos y ejecutar comandos. Por eso, si le dices “arréglalo todo y publícalo”, puedes terminar con cambios que no sabes revisar. Para una persona no técnica, la regla básica es: pedir tareas pequeñas, leer el resumen del diff y parar cuando aparezcan secretos, datos de clientes, producción, pagos o seguridad.

Si necesitas la instalación básica, revisa la guía de inicio de Claude Code. Para trabajar con menos riesgo, combina este artículo con approval y sandbox y la guía de permisos.

Conceptos sin jerga

La terminal es una ventana de texto para dar órdenes al ordenador. Un diff es la comparación entre antes y después de un cambio. Los permisos indican qué puede hacer Claude Code sin preguntar, qué requiere aprobación y qué está bloqueado.

Concepto	Traducción sencilla	Qué debes mirar
Terminal	Panel de control por texto	¿Estás en la carpeta correcta?
Diff	Cambios realizados	¿Solo cambiaron los archivos esperados?
Approval	Pausa para aprobar	¿Entiendes la acción?
Sandbox	Zona de trabajo limitada	¿El comando toca solo lo permitido?
Secreto	Token, API key o contraseña	No lo leas sin una razón clara

Flujo seguro recomendado

flowchart LR
  A["Define el objetivo"] --> B["Pide solo inspección"]
  B --> C["Revisa preguntas y riesgos"]
  C --> D["Aprueba una edición pequeña"]
  D --> E["Lee el resumen del diff"]
  E --> F{"¿Producción o secretos?"}
  F -->|Sí| G["Para y consulta a ingeniería"]
  F -->|No| H["Ejecuta checks y decide manualmente"]

La frase más útil al inicio es: “Todavía no edites archivos”. Obliga a Claude Code a investigar, hacer preguntas y proponer un plan antes de tocar nada.

Ejemplo básico de permisos

Documentación oficial útil:

Para un primer proyecto, permite lectura y pruebas, pide confirmación para escribir y bloquea secretos o acciones irreversibles.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)"
    ],
    "ask": [
      "Edit",
      "Write",
      "Bash(git diff)",
      "Bash(git status)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard)",
      "Bash(git push *)",
      "Bash(npm publish *)"
    ]
  }
}

allow significa permitir, ask significa preguntar antes de actuar y deny significa bloquear. Los archivos .env suelen contener claves privadas o tokens, así que no deberían formar parte de una tarea cotidiana de contenido.

Convierte una petición vaga en checklist

Usa este prompt antes de pedir cambios.

Actúa como asistente cuidadoso de trabajo. Todavía no edites archivos.

Objetivo:
Quiero que la página de contacto sea más clara para clientes nuevos.

Haz lo siguiente:
1. Encuentra los archivos que probablemente estén relacionados.
2. Escribe cinco preguntas que debo responder antes de editar.
3. Divide el trabajo en tareas pequeñas.
4. Marca las tareas arriesgadas que requieren a ingeniería.
5. Recomienda la tarea segura más pequeña para hacer hoy.

Funciona para páginas web, FAQs, documentación, plantillas de email y procesos internos.

Caso 1: actualizar textos de una web

No publiques ni despliegues nada.

Revisa solo el texto de la página de precios.
Archivos:
- site/src/content/pricing.mdx
- site/src/pages/pricing.astro

Tareas:
1. Detecta frases poco claras para un comprador nuevo.
2. Propón reemplazos en una tabla.
3. Espera mi aprobación.
4. Aplica solo los textos aprobados.
5. Explícame el git diff en lenguaje sencillo.

No mezcles textos, diseño, lógica de precios, checkout y publicación en el mismo pedido. Cada uno tiene un riesgo distinto.

Caso 2: documentación y formación interna

Lee docs/onboarding/ y crea docs/onboarding/day-one-checklist.md.

Reglas:
- No borres documentación existente.
- Explica los términos técnicos la primera vez que aparezcan.
- Deja lo dudoso como "Pendiente de confirmar".
- Termina con tres preguntas para RR. HH. o IT.

Para profundizar, lee generación de documentación con Claude Code.

Caso 3: CSV y hojas de cálculo

Empieza con datos de prueba antes de tocar registros reales.

date,customer,plan,status,amount
2026-06-01,Acme,Standard,open,12000
2026-06-01,Northwind,Pro,closed,30000
2026-06-02,Contoso,Standard,open,12000

Inspecciona data/inquiries.csv y crea un script seguro de extracción.

Reglas:
- Primero informa solo nombres de columnas y número de filas.
- Para si alguna columna parece dato personal.
- Crea scripts/open-inquiries.mjs.
- node scripts/open-inquiries.mjs debe generar output/open-inquiries.csv.
- Informa cuántas filas se extrajeron.

Si trabajas mucho con hojas de cálculo, revisa automatización de spreadsheets con Claude Code.

Caso 4: automatización de negocio

Antes de automatizar todo, crea una lista que una persona pueda seguir.

Crea docs/daily-ops-checklist.md para la rutina de operaciones de las 9:00.

Entradas:
- Revisar consultas de clientes sin resolver.
- Revisar ingresos de ayer.
- Revisar notificaciones de error.
- Publicar la prioridad del día en Slack.

Salida:
- Checklist paso a paso.
- Tiempo estimado.
- Qué se puede automatizar.
- Qué necesita criterio humano.
- Plan de recuperación si falla.

Para pasar de checklist a scripts, lee ejemplos de automatización de flujos.

Tabla de riesgos

Riesgo	Qué puede pasar	Respuesta segura
”Arréglalo todo”	Cambios imposibles de revisar	Un archivo y un objetivo
Leer `.env`	Exposición de secretos	Bloquear y consultar
Permitir `git push`	Cambios no revisados salen fuera	Publicación manual
Datos reales de clientes	Problemas de privacidad	Usar muestras primero
Sin prueba ni preview	Errores visibles en producción	Build, test y revisión visual
Reintentar errores a ciegas	Se repite el fallo	Pedir explicación del error

Para si aparecen borrado, publicación, pagos, login, datos personales, contratos o sistemas de producción.

Checklist diario

Momento	Comprobación
Antes de empezar	Define una sola tarea para terminar hoy
Investigación	Escribe “todavía no edites”
Antes de editar	Confirma archivos objetivo
Aprobación	Lee herramienta y comando
Después	Pide resumen del diff
Antes de compartir	Verifica que nada se publicó, envió, borró o desplegó
Si dudas	Envía diff y duda a ingeniería

CTA de formación y consultoría

ClaudeCodeLab puede ayudar a equipos no técnicos a crear prompts, permisos, reglas de revisión y primeras automatizaciones para webs, FAQs, informes CSV y documentación interna.

El mejor primer proyecto no es una gran automatización. Es una tarea pequeña y repetible donde el equipo aprende a pedir, revisar y parar.

Resultado probado

Probé este flujo con tres tareas: edición de textos web, checklist de onboarding y extracción de CSV. La mejora más clara llegó al añadir “todavía no edites”, “haz preguntas primero” y “separa lo arriesgado” al prompt inicial. Sin esas frases, el diff fue mucho más difícil de revisar para una persona no técnica.