Cómo empezar un proyecto de programación en 2026: guía completa con IA

Environment Setup: tu base de trabajo

Antes de escribir una sola línea de código, necesitas un entorno que no te traicione. En 2026, con la IA generando código a velocidad, un package.json mal configurado puede romper tu proyecto en una actualización.

El package.json y el temido ^

Cuando ejecutas npm install react, npm añade "react": "^19.2.5" a tu package.json. Ese ^ significa: “acepta cualquier versión compatible hacia arriba dentro del mismo major”. Suena bien, hasta que una dependencia menor introduce un breaking change y tu build explota.

Qué fijar y qué no:

{
  "dependencies": {
    "react": "19.2.5",
    "react-dom": "19.2.5"
  },
  "devDependencies": {
    "typescript": "5.8.3",
    "vite": "6.4.2",
    "eslint": "9.22.0"
  }
}

Fija siempre (sin ^ ni ~):

• Frameworks principales — React, Vue, Astro, Next.js. Un salto de versión cambia APIs.
• TypeScript — cada minor puede cambiar inferencias y romper tu build.
• Build tools — Vite, esbuild, SWC. Afectan directamente al output.
• CSS frameworks — Tailwind CSS v3 → v4 cambió la sintaxis de configuración.

Puedes dejar con ^:

• Utilidades puras — lodash, date-fns, clsx. API estable, bajo riesgo.
• Plugins de linter/formatter — eslint-plugin-*, prettier-plugin-*. Se actualizan con el core.
• Tipos — @types/*. Son definiciones, no runtime.

El truco del .npmrc que te salva de sustos:

# .npmrc en la raíz de tu proyecto
save-exact=true

Con save-exact=true, cada npm install guarda la versión exacta sin ^ ni ~. Es la configuración más segura para proyectos serios. Sin excepciones.

Lint, Prettier y TypeScript: la santísima trinidad

No necesitas 15 reglas. Necesitas las básicas que evitan errores tontos:

TypeScript (tsconfig.json):

{
  "compilerOptions": {
    "strict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true
  }
}

strict: true activa todo: null checks, tipos implícitos, this seguro. Es el 90% de la protección que necesitas.

ESLint (.eslint.config.mjs):

import js from '@eslint/js';
import ts from 'typescript-eslint';

export default [
  js.configs.recommended,
  ...ts.configs.recommended,
];

No añadas reglas custom hasta que entiendas las defaults. Las recomendadas ya capturan: variables no usadas, promesas sin await, imports rotos.

Prettier (.prettierrc):

{
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100
}

Prettier no discute estilos. Formatea y punto. Configúralo una vez y olvídate.

Scripts mínimos en package.json:

{
  "scripts": {
    "lint": "eslint src/",
    "lint:fix": "eslint src/ --fix",
    "format": "prettier --write \"src/**/*.{ts,tsx,astro}\"",
    "typecheck": "tsc --noEmit"
  }
}

Ejecuta typecheck antes de cada commit. TypeScript te atrapa errores que ni el linter ve.

---

AI Development: agentes, skills y uso eficiente de tokens

La IA no te va a escribir el proyecto entero. Pero si sabes usarla, te ahorra horas de configuración y debugging. La clave está en entender tres conceptos: agentes, skills y tokens.

Qué son los agentes IA

Un agente IA es una instancia de modelo de lenguaje configurada para una tarea específica. No es lo mismo pedirle “escríbeme un componente React” que “revisa este PR buscando bugs de seguridad”.

Tipos de agentes que usarás:

Agente	Para qué se usa	Cuándo activarlo
General	Escribir código, explicar conceptos, generar boilerplate	Desarrollo diario
Reviewer	Revisar código existente, encontrar bugs, sugerir mejoras	Antes de commitear
Security	Auditoría de seguridad, OWASP, secrets, vulnerabilidades	Antes de deploy
Tester	Generar tests, analizar fallos, proponer fixes	Después de escribir features
Architect	Diseño de sistema, patrones, decisiones de arquitectura	Inicio de proyecto o refactor

Cada agente tiene un contexto y herramientas diferentes. Usar el agente correcto para la tarea correcta reduce el consumo de tokens un 40-60%.

Qué son las skills IA

Las skills son instrucciones especializadas que se cargan en el contexto del agente para una tarea concreta. Piensa en ellas como “modos experto” que el agente activa cuando necesita conocimiento específico.

Ejemplo real: cuando le pides a un agente que “mejore la accesibilidad”, se carga la skill accessibility que incluye:

• Criterios WCAG 2.2 con niveles AA/AAA
• Patrones de código para skip links, focus traps, ARIA
• Ejemplos de qué hacer y qué no hacer

Sin la skill, el agente improvisa. Con la skill, sigue estándares reales.

Skills más útiles para desarrollo:

Skill	Cuándo usarla
accessibility	Audit y fix de accesibilidad WCAG
frontend-design	Crear componentes UI con diseño profesional
tailwind-css-patterns	Styling con Tailwind v4
typescript-advanced-types	Generics, conditional types, type safety
nodejs-backend-patterns	APIs, middleware, auth, database
seo	Optimización para buscadores
security	Revisión de vulnerabilidades y OWASP

Uso eficiente de tokens: la guía 2026

Los tokens son tu moneda. Cada mensaje que envías al agente consume tokens de contexto. Si no los gestionas, pagas más y el agente se vuelve lento (contextos grandes = respuestas peores).

Regla de oro: contexto mínimo, resultado máximo.

1. Usa el agente correcto desde el primer mensaje:

❌ "Revisa este código y dime si hay problemas de seguridad"
   → Agente general, contexto genérico, tokens desperdiciados

✅ @security "Audita estos 3 archivos buscando OWASP Top 10"
   → Agente especializado, contexto enfocado, resultado preciso

2. Envía solo lo necesario:

❌ Envías 15 archivos cuando el problema está en 2
✅ Envías los 2 archivos relevantes + contexto mínimo

3. Usa comandos en vez de prompts largos:

❌ "Por favor, podrías revisar el código y ver si hay algo
    que se pueda mejorar en cuanto a rendimiento..."

✅ /review src/components/foro/MatrixForo.tsx

4. Modo caveman para respuestas comprimidas: El modo caveman reduce el output del agente un 75% manteniendo la precisión técnica. Ideal para revisiones rápidas:

/caveman → activa modo ultra-comprimido
/caveman-lite → comprimido pero legible

5. Skills on-demand, no siempre activas: No cargues todas las skills en cada conversación. Cárgalas solo cuando las necesites:

"Revisa la accesibilidad de este componente"
→ El agente detecta que necesita la skill accessibility y la carga

"Ahora optimiza el SEO de esta página"
→ El agente carga la skill seo y descarga la anterior

La mejor configuración del mundo (2026)

Si quieres empezar con la configuración más eficiente hoy:

1. Instala autoskills de midudev:

npx autoskills@latest

Detecta automáticamente las tecnologías de tu proyecto (React, Astro, Tailwind, TypeScript) e instala las skills relevantes. Sin configurar nada manual.

2. Usa caveman-commit para commits:

/caveman-commit
→ Genera mensajes de commit concisos y descriptivos
→ Formato Conventional Commits automático
→ Subject ≤50 chars, body solo cuando el "por qué" no es obvio

3. Configura tu .npmrc para evitar sorpresas: Ya lo vimos arriba. save-exact=true es tu seguro de vida.

4. Agentes por defecto en tu workflow:

Escribir código     → @general
Revisar antes de commit → @reviewer
Revisar seguridad   → @security
Escribir tests      → @tester
Diseñar arquitectura → @architect

Cada agente sabe qué herramientas usar y qué contexto necesita. No mezcles.

---

Security: blindar tu proyecto antes de que sea tarde

La IA democratiza el conocimiento — incluido el de hacking. Hoy cualquiera puede generar scripts de ataque con un prompt. Tu proyecto necesita defensas reales, no solo buenas intenciones.

El .npmrc que te protege

# .npmrc
save-exact=true
audit=false
fund=false

audit=false y fund=false desactivan requests automáticos a npm que filtran metadata de tu proyecto. No es paranoia — es higiene básica.

Nunca instales scripts que no entiendas

Regla #1: si un paquete tiene postinstall en su package.json y no sabes qué hace, no lo instales.

Los scripts postinstall se ejecutan automáticamente al hacer npm install. Un paquete malicioso puede:

• Robar tus variables de entorno
• Instalar keyloggers
• Enviar tus tokens de API a servidores externos
• Modificar tu node_modules para inyectar código en producción

Cómo verificar antes de instalar:

# Ver qué scripts ejecuta un paquete
npm view <paquete> scripts

# Ver el contenido del package.json antes de instalar
npm view <paquete> --json

Señales de alerta:

• Paquetes con nombres similares a populares pero con typos (react-dom vs reactdom)
• Paquetes nuevos con muchas dependencias
• Paquetes sin README o con README genérico
• Dependencias que no necesitas directamente

Variables de entorno: nunca en el código

❌ Nunca hagas esto:

const apiKey = "sk-1234567890abcdef";
const dbPassword = "mi_password_secreto";

✅ Haz esto:

// .env.local (NUNCA commiteado)
DATABASE_URL=postgresql://user:pass@host:5432/db
API_KEY=sk-1234567890abcdef

// En tu código
const apiKey = process.env.API_KEY;

.gitignore obligatorio:

.env
.env.local
.env.*.local

.env.example para documentar:

# Variables necesarias para el proyecto
DATABASE_URL=postgresql://user:pass@host:5432/db
API_KEY=tu_api_key_aqui
PUBLIC_SITE_URL=https://tusitio.com

Firebase y APIs públicas: lo que sí puede ir en el cliente

No todo secreto es secreto. Las API keys de Firebase, Google Maps, o Analytics están diseñadas para ser públicas. Pero necesitan restricciones:

En Firebase Console:

1. API Key → Application restrictions → HTTP referrers
2. Añade solo tus dominios: tusitio.com/*, localhost/*
3. Authorized domains → solo tus dominios

En Google Cloud Console:

1. APIs & Services → Credentials → tu API Key
2. HTTP referrer restrictions → tus dominios
3. API restrictions → solo las APIs que necesitas

Sin restricciones, cualquiera puede usar tu API key desde cualquier dominio.

El archivo que NUNCA debes commitear

serviceAccountKey.json de Firebase Admin da acceso total a tu base de datos. Si lo commiteas:

1. Rota la key inmediatamente en Firebase Console
2. Añádelo a .gitignore
3. Usa variables de entorno en producción

# .gitignore
scripts/serviceAccountKey.json
backups/

---

Testing & Quality: el mínimo que necesitas

No necesitas 100% de cobertura. Necesitas que las cosas críticas no se rompan.

El CI mínimo viable

Un archivo .github/workflows/ci.yml que se ejecuta en cada pull request:

name: CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 9

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'pnpm'

      - run: pnpm install --frozen-lockfile

      - name: Typecheck
        run: pnpm typecheck

      - name: Lint
        run: pnpm lint

      - name: Format check
        run: pnpm format:check

      - name: Build
        run: pnpm build

Qué verifica:

1. Typecheck — TypeScript compila sin errores
2. Lint — No hay errores de ESLint
3. Format check — El código sigue el estilo definido
4. Build — El proyecto se construye correctamente

Si cualquiera de estos falla, el PR no se puede mergear. Simple. Efectivo.

Tests que sí importan

No empieces por los components UI. Empieza por las funciones puras — las que no dependen de estado externo:

Prioridad P0 (escribe estos primero):

// src/lib/__tests__/auth.test.ts
import { validateDisplayName } from '../auth';

describe('validateDisplayName', () => {
  it('acepta nombres válidos (3-23 chars)', () => {
    expect(validateDisplayName('alice')).toBe('alice');
  });

  it('rechaza nombres cortos', () => {
    expect(() => validateDisplayName('ab')).toThrow();
  });

  it('elimina caracteres de control', () => {
    expect(validateDisplayName('test\x00')).toBe('test');
  });
});

Prioridad P1 (después):

• Funciones de validación de formularios
• Utilidades de formato (fechas, monedas, strings)
• Lógica de negocio pura

Prioridad P2 (cuando tengas tiempo):

• Components UI con React Testing Library
• Integration tests con MSW para mock de APIs

Prioridad P3 (si sobra tiempo):

• E2E tests con Playwright

Stack recomendado para Astro + React + TypeScript

Herramienta	Para qué	Por qué
Vitest	Unit tests	Nativo ESM, comparte config con Vite, rápido
React Testing Library	Component tests	Industry standard, testa comportamiento
MSW	Mock de APIs	Intercepta requests a nivel de red
Playwright	E2E tests	Mejor soporte para Astro, multi-browser

Instalación:

pnpm add -D vitest @testing-library/react @testing-library/jest-dom jsdom msw
pnpm add -D @playwright/test
npx playwright install chromium

vitest.config.ts:

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  test: {
    environment: 'jsdom',
    globals: true,
    setupFiles: ['./src/test/setup.ts'],
  },
});

src/test/setup.ts:

import '@testing-library/jest-dom/vitest';

---

Preguntas frecuentes

¿Cómo configurar la IA para mejorar el uso de tokens?

Usa el agente correcto para cada tarea, envía solo los archivos relevantes, y carga skills on-demand en vez de tenerlas siempre activas. El comando npx autoskills@latest detecta tu tech stack e instala solo las skills que necesitas.

¿Qué son las skills IA y los agentes IA?

Los agentes son instancias de modelo configuradas para roles específicos (reviewer, security, tester). Las skills son instrucciones especializadas que se cargan en el contexto del agente cuando necesita conocimiento específico (accesibilidad WCAG, patrones Tailwind, etc.).

¿Cuál es el mínimo de seguridad hoy en día?

.npmrc con save-exact=true, nunca commitear .env ni serviceAccountKey.json, verificar scripts postinstall antes de instalar paquetes, y restringir API keys a tus dominios en las consolas de Firebase y Google Cloud.

¿Qué buenas prácticas son obligatorias en 2026?

TypeScript strict: true, ESLint con config recomendada, Prettier para formato consistente, CI básico que verifique typecheck + lint + build en cada PR, y tests unitarios para funciones puras críticas.

¿Qué conocimientos mínimos de IA necesito para programar?

Saber qué agente usar para qué tarea, cómo estructurar prompts concisos, cuándo cargar una skill específica, y cómo gestionar el contexto para no desperdiciar tokens. No necesitas ser experto en prompts — necesitas ser eficiente con el flujo de trabajo.

¿Debo fijar todas las dependencias en mi proyecto?

No. Fija frameworks principales (React, Astro, TypeScript), build tools (Vite, esbuild), y CSS frameworks. Puedes dejar con ^ utilidades puras (lodash, date-fns), plugins de linter, y tipos (@types/*). save-exact=true en .npmrc es la opción más segura si no quieres pensar en ello.