Escribo para que el conocimiento circule. En 2026 una parte enorme de la gente ya no lee resultados de búsqueda: le pregunta a un agente. Si el agente no puede leerte, no existes en esa conversación.

SEO vs GEO

No se reemplazan: GEO se construye sobre un SEO técnico sano.

1. robots.txt: invitar a los agentes

Muchos sitios bloquean a los bots de IA por defecto. Si tu objetivo es compartir, haz lo contrario y sé explícito:

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: PerplexityBot
User-agent: Google-Extended
Allow: /

Sitemap: https://nathanlazo.website/sitemap.xml

2. Una entidad clara: quién escribe

Los motores de respuesta razonan sobre entidades. Defino una sola entidad Person con @id estable, perfiles (sameAs) y temas (knowsAbout), y cada artículo la referencia como autor:

{
  "@type": "BlogPosting",
  "headline": "GEO: cómo hice mi portafolio legible para agentes de IA",
  "datePublished": "2026-10-20",
  "inLanguage": "es",
  "author": { "@id": "https://nathanlazo.website/#person" }
}

Así cada post suma autoridad a la misma identidad en lugar de quedar huérfano.

3. Una sola fuente de verdad para metadatos

En Next.js (Pages Router) centralicé todo en dos piezas:

• src/lib/site.js: URL, autor, perfiles, temas y rutas.
• src/components/Seo.jsx: título, descripción, canonical, Open Graph, Twitter y JSON-LD en un componente.

Cada página declara solo lo suyo:

<Seo title="Articles" description="Long-form writing on AI agents, WebGPU..." />

Menos lugares donde equivocarse = menos metadatos inconsistentes (en mi caso había descripciones heredadas de la plantilla con el nombre de otra persona).

4. llms.txt y llms-full.txt generados en build

Al compilar, el mismo paso que genera el RSS escribe tres archivos:

• sitemap.xml con todas las rutas y fechas de los artículos.
• llms.txt: resumen del sitio, páginas clave y un índice de artículos con descripción.
• llms-full.txt: el texto completo de cada artículo en markdown limpio, con URL, autor y fecha.

Un agente que llega al sitio puede entenderlo completo en una sola lectura, sin ejecutar JavaScript ni adivinar qué es navegación y qué es contenido.

5. Escribir para ser citado

La técnica más rentable no es técnica:

• Respuesta directa en el primer párrafo. Lo que un agente cita es lo que responde la pregunta sin rodeos.
• Encabezados que son preguntas o conceptos. Facilitan extraer fragmentos.
• Definiciones explícitas. "X es…" es la frase más citable que existe.
• Tablas para comparaciones. Los modelos las resumen muy bien.
• FAQ al final, también expuesta como FAQPage en JSON-LD.
• Fechas y autor visibles. La frescura y la atribución importan.
• Enlaces internos entre artículos relacionados para que el grafo del sitio tenga sentido.

Checklist GEO

• robots.txt permite a los crawlers de IA y apunta al sitemap.
• sitemap.xml actualizado en cada build.
• Canonical, Open Graph y Twitter en todas las páginas.
• JSON-LD: Person + WebSite global, BlogPosting y BreadcrumbList por artículo, FAQPage si aplica.
• llms.txt y llms-full.txt publicados.
• lang correcto por artículo.
• Respuesta directa al inicio y FAQ al final de cada post.

Cierre

GEO no es engañar a un algoritmo; es ser la fuente más clara sobre lo que sabes. Si escribes para enseñar, haz que tu conocimiento sea legible para humanos y para máquinas. Es la forma más simple de devolverle algo a la comunidad que te enseñó.

Más del tema: cómo construí Roger-arq y WebGPU y modelado 3D en la web.

Te cuento cómo la construí para que hagas la tuya.

El problema: explicar lo mismo diez veces

Trabajo en varios productos a la vez: un ERP, apps móviles, plataformas con pagos y facturación. Todos comparten stack (Next.js, tRPC, Prisma, Zod, Tailwind, shadcn) y, sobre todo, comparten decisiones: cómo se manejan errores, dónde vive la autorización, cuándo se abre una transacción.

Con agentes, cada sesión empezaba igual: "no uses any", "no hagas db push", "el error es un código, no texto libre", "filtra en el where, no después". Si una regla vive solo en mi cabeza, cada agente —y cada persona nueva— la va a romper.

La estructura de Roger-arq

Después de muchas iteraciones, la skill quedó organizada así, y el orden importa:

1. Reglas críticas (no negociables). Lo primero que el agente lee: no ejecutar builds que toquen la base de datos, no correr migraciones, no imprimir secretos. Pocas, absolutas y verificables.
2. Prioridades. Cuando dos reglas chocan, cuál gana: correctitud y seguridad de datos, tipado estricto, separación por capas, módulos localizados, respuestas uniformes, cambios pequeños.
3. Stack. Qué librerías se usan y cuáles no se agregan (una sola librería de animación, una de gráficas).
4. Anatomía de módulo. Un árbol de carpetas concreto: page.tsx delgado, _components privados, servicio de dominio en servidor, reglas puras en src/lib, i18n y spec.
5. Capas. UI → cliente tRPC → procedure → servicio → Prisma. Cada capa con una responsabilidad y prohibiciones claras.
6. Autorización y alcance por fila. Una fila fuera del alcance responde 404, nunca 403. Toda escritura carga primero la fila dentro del alcance del usuario.
7. Contrato tRPC. Toda procedure responde con la misma forma (result, error, status, message), construida solo con ok/fail, y el error siempre es un código de catálogo que la UI traduce.
8. Datos, UI, tablas, dashboards, motion. Reglas de transacciones, serialización, shell, vistas de tabla y kits de diseño.
9. Checklist final y anexos con skills complementarias y referencias a implementaciones reales.

Decisiones que la hicieron funcionar

• Reglas, no opiniones. "Escribe código limpio" no sirve. "Prohibido any, as any y @ts-ignore" sí: es verificable.
• Ejemplos reales, no inventados. Cada patrón apunta a un archivo de un proyecto mío donde ya funciona. El agente copia de algo probado.
• Fuente de verdad para cada kit. Mis kits de UI (shell, tablas, gráficas, chat de agente) se copian siempre desde un repo concreto, y toda mejora vuelve ahí. Sin esto, cinco proyectos terminan con cinco versiones divergentes.
• Lo que el agente NO debe hacer, explícito. Las prohibiciones evitan más daño que cualquier instrucción positiva. Un agente que corre db push en el proyecto equivocado te arruina la semana.
• Composición con otras skills. Roger-arq no intenta saberlo todo: delega diseño, motion, 3D y móvil a skills especializadas y declara que, si contradicen el contrato, gana el contrato. Para móvil tengo una variante hermana, Roger-arq-mobile.

Un ejemplo del contrato

list: salesProcedure.input(listSchema).query(async ({ ctx, input }) => {
  try {
    return ok(await listOrders(ctx.db, viewerFromSession(ctx.session), input), 'OK')
  } catch (error: unknown) {
    const { code, status } = normalizeError(error)
    return fail(code, status, 'No se pudo listar')
  }
}),

Tres reglas en diez líneas: el servicio recibe el viewer (nunca lee la sesión), el error se normaliza a un código estable y nada interno llega al cliente.

Cómo construir tu propia skill (paso a paso)

1. Junta tus repeticiones. Revisa tus últimos 20 code reviews y prompts. Lo que corregiste más de dos veces es tu primer borrador.
2. Crea el archivo. Un SKILL.md con frontmatter:

---
name: mi-arq
description: Contrato de arquitectura para proyectos X. Úsala al crear o modificar módulos, endpoints o modelos de datos.
---

# Mi Arq

## 1. Reglas críticas
1. Nunca ejecutes migraciones; entrega el comando al usuario.
2. ...

3. Escribe primero lo no negociable, en imperativo y verificable.
4. Añade la anatomía: un árbol de carpetas real vale más que tres párrafos.
5. Apunta a ejemplos reales de tu código.
6. Pruébala en una tarea real con un agente. Cada error del agente es una regla que falta o que está mal escrita.
7. Versiónala y mejórala como cualquier otro código.

La description es crítica: es lo que el agente lee para decidir si cargar la skill. Di qué hace y cuándo usarla.

Por qué deberías hacerlo

Una skill es tu experiencia en un formato que escala: la usan tus agentes, tu equipo y tu yo del futuro. Y si la compartes, ayudas a que la comunidad deje de aprender las mismas lecciones a golpes. Yo empecé con diez reglas escritas en una tarde; hoy es el contrato que siguen todos mis proyectos.

No necesitas una arquitectura perfecta para empezar. Necesitas escribir la que ya tienes.

Relacionado: el flujo de desarrollo ya vive en la nube.

Empecé a programar a los 16 años con una app en Three.js. Diez años después, el 3D en la web cambió más en los últimos 18 meses que en toda esa década.

WebGL vs WebGPU en una tabla

La consecuencia práctica: cosas que antes requerían trucos (millones de partículas, físicas, instancing gigante, cálculos en texturas) ahora son código directo en la GPU.

Three.js con WebGPU y fallback

import * as THREE from 'three/webgpu'
import { color, positionLocal, sin, time } from 'three/tsl'

const renderer = new THREE.WebGPURenderer({ antialias: true })
await renderer.init() // usa WebGPU o cae a WebGL 2

const material = new THREE.MeshStandardNodeMaterial()
// TSL: el mismo nodo compila a WGSL o GLSL según el backend
material.colorNode = color(0x6366f1).mul(sin(time).mul(0.5).add(0.5))
material.positionNode = positionLocal.add(sin(time.add(positionLocal.y)).mul(0.05))

TSL (Three Shading Language) es lo que hace que esto sea sostenible: escribes shaders como funciones de JavaScript componibles y Three.js los traduce al backend correcto. Se acabó mantener dos versiones de cada shader.

Mi pipeline 3D actual

1. Generar. Parto de una imagen o concepto y genero una malla GLB con un modelo de IA de imagen a 3D. Lo que antes eran días en Maya para un prop ahora es un primer borrador en minutos.
2. Corregir. El modelo generado es un punto de partida: reviso topología, escala, pivote y materiales. El criterio de modelado sigue importando.
3. Optimizar. Con gltf-transform: deduplicar, simplificar, comprimir geometría (meshopt o Draco) y texturas (KTX2/WebP). Un GLB de 40 MB baja fácilmente a 2–4 MB.
4. Integrar. En Next.js, el canvas es un componente cliente cargado con next/dynamic y ssr: false, con un fallback estático (imagen) mientras carga.
5. Cuidar. Liberar geometrías, materiales y texturas al desmontar (dispose), pausar el loop fuera de pantalla y respetar prefers-reduced-motion.

import dynamic from 'next/dynamic'

const Scene = dynamic(() => import('./scene'), {
  ssr: false,
  loading: () => <img src="/hero-fallback.webp" alt="Vista previa de la escena" />,
})

Skills: cómo hago que un agente programe 3D bien

El 3D es donde más se nota un agente sin contexto: crea renderers en cada render, olvida dispose, carga texturas sin comprimir. Por eso trabajo con un set de skills especializadas (fundamentos, geometría, materiales, iluminación, shaders, loaders, post-proceso, animación, interacción) que codifican esas reglas. El agente no "sabe" Three.js mejor por arte de magia: sigue las reglas que yo ya aprendí rompiendo cosas.

Las reglas base que meto en cualquier proyecto 3D:

• Componentes 3D siempre "use client" y sin SSR.
• Un solo renderer por canvas; nada se instancia dentro del render de React.
• Todo recurso creado se libera al desmontar.
• Fallback estático y respeto a movimiento reducido.
• Assets comprimidos antes de llegar a public/.

Lo nuevo que podemos hacer

• Configuradores de producto con materiales PBR reales y cambios en tiempo real.
• Héroes interactivos con millones de partículas animadas por compute shaders.
• Visualización de datos 3D que antes exigía una app nativa.
• Inferencia en GPU dentro del navegador: WebGPU también acelera modelos de IA locales, sin servidor.

Cierre

WebGPU no es "WebGL más rápido": es la GPU tratada como ciudadano de primera clase en la web. Sumado a generación de modelos con IA y agentes que siguen reglas de producción, el 3D dejó de ser un lujo de estudios grandes. Si sabes JavaScript, hoy puedes publicar experiencias que hace tres años requerían un equipo.

Lee también: cómo el flujo de desarrollo se movió a la nube y cómo construí Roger-arq.

Este artículo es mi lectura de ese cambio desde la práctica: lo uso todos los días en mis proyectos (ERPs, apps móviles, plataformas T3 y experiencias 3D).

Qué cambió exactamente

Hace dos años un "asistente de código" autocompletaba líneas. Hoy una sesión de agente:

1. Clona el repo en un contenedor efímero con el entorno configurado (Node, pnpm, navegador headless, variables y red controladas).
2. Lee las reglas del proyecto (CLAUDE.md, AGENTS.md, skills) antes de tocar código.
3. Implementa, corre lint y typecheck, y hace commit en una rama dedicada.
4. Abre el PR y se suscribe a sus eventos: si el CI falla, reproduce el error, lo corrige y vuelve a empujar; si un reviewer pide un cambio pequeño, lo aplica.
5. Se despierta solo cuando llega un evento (CI, review, conflicto) en lugar de que yo esté refrescando la pestaña.

Lo radical no es que el modelo escriba mejor código. Es que el ciclo completo —editar, compilar, probar, integrar— ya no necesita mi máquina ni mi atención continua.

Tareas que ya no hago a mano

• Builds rotos. Antes: leer 300 líneas de log, encontrar el import circular. Ahora: el agente reproduce el fallo, aísla la causa y propone el parche con la prueba de que pasa.
• Manejo de sesiones y entornos. Ya no mantengo cinco terminales, tres versiones de Node y un .env por proyecto en mi laptop. Cada tarea arranca en un entorno limpio y reproducible.
• Rondas de review mecánicas. Renombrar, extraer una función, agregar un test pedido: se resuelve en la misma conversación del PR.
• Scaffolding con convenciones. Crear un módulo nuevo con su página, router, servicio, schema Zod, i18n y estados de carga sigue un patrón; un agente con la skill correcta lo hace igual que yo, pero en minutos.

Lo que la nube no reemplaza

La velocidad aumentó tanto que el cuello de botella se movió de lugar. Ahora lo escaso es:

• El contrato. Si no defines reglas (capas, errores, autorización, nombres), el agente produce código plausible pero inconsistente. Por eso escribí Roger-arq, mi skill de arquitectura.
• La revisión con criterio. Un diff limpio puede esconder un IDOR o una transacción con I/O externo dentro. Revisar es el nuevo trabajo de senior.
• Los límites de ejecución. Hay comandos que un agente no debe correr nunca: migraciones, db push, scripts que escriben datos. Eso se declara explícitamente y se respeta.

Mi flujo real, de punta a punta

Idea (desde el teléfono)
  → sesión de agente en la nube, rama dedicada
  → skills del proyecto cargadas (arquitectura, UI, 3D)
  → implementación + lint + typecheck
  → PR + suscripción a CI y reviews
  → fixes automáticos hasta verde
  → yo reviso el diff, pruebo el preview y hago merge

Lo que hago yo: la primera línea y las dos últimas. Todo lo demás es delegable si el repositorio está preparado para que un agente lo entienda.

Cómo preparar tu repo para este flujo

1. Un archivo de contexto en la raíz (CLAUDE.md / AGENTS.md): stack, comandos, convenciones y qué no se ejecuta.
2. Checks rápidos y locales: lint, typecheck y tests unitarios que corran en segundos. El agente los usa como señal de verdad.
3. Skills para lo que repites: si explicas lo mismo en tres proyectos, eso es una skill.
4. CI determinista: un CI que falla aleatoriamente entrena a todos —humanos y agentes— a ignorarlo.
5. Entornos sin secretos en el repo: variables en el entorno de ejecución, nunca en archivos versionados.

Cierre

La pregunta ya no es si la IA programa bien. Es qué tan bien defines el sistema en el que programa. En 2026 el ingeniero que rinde más no es el que escribe más rápido, sino el que convierte su criterio en reglas que una máquina puede seguir y otro humano puede auditar.

Si quieres ver cómo aplico esto al 3D, lee WebGPU y modelado 3D en la web.

Software: speed became normal, judgment did not

Shipping stopped being the applause line. Teams discovered that velocity without narrative produces a museum of half-finished experiments. The interesting split was not “AI vs no AI” but orchestration vs improvisation: who owned the system when the machine proposed the patch, and who owned the outcome when the patch was wrong.

What 2025 and 2026 revealed is that tooling plateaus are short. The durable skill is still editing: choosing constraints, naming trade-offs, and keeping a product legible to the humans who maintain it.

Music: taste under algorithmic weather

Electronic music in this stretch did not lack content; it lacked shared time. Scenes still formed, but they formed in smaller rooms—literal and digital—where curation mattered more than raw reach. The platforms kept optimizing for engagement; the artists kept searching for long arcs: sets that breathe, albums that assume attention, communities that remember last month’s night, not only tonight’s drop.

The lesson rhymes with software: when generation is cheap, sequence and context become the art.

Blockchain and internet culture: fewer costumes, harder questions

On-chain culture shed some costumes and kept the uncomfortable questions: what is being trusted, by whom, and at what cost? Speculation still exists, but the conversation in 2026 is more willing to say “this is infrastructure for a narrow case” than “this changes everything.” That honesty is boring and useful.

Internet culture, meanwhile, kept oscillating between irony as armor and sincerity as risk. The through-line is authenticity fatigue: audiences can smell performance, and they punish inconsistency faster than they reward novelty.

Creativity as a discipline of limits

Across domains, the revelation was the same in different fonts: creativity is not infinite generation. It is decision density—what you refuse, what you repeat, what you protect. The tools widened the river; someone still has to build the banks.

Closing

2025 and 2026 did not hand us a single future. They handed us mirrors: faster pipelines, thinner attention, and a quieter respect for systems that survive their own hype. The work ahead is not only to make more—it is to make coherent things in a world that rewards volume. That is the harder craft, and the one that still belongs to people.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Credentials are contracts, not stickers

A credential is a small contract between issuer, holder, and verifier. The technology—JWTs, passkeys, W3C verifiable credentials, or domain-bound certificates—matters less than the semantics: what is being claimed, under what policy, and with what liability if it is wrong. Teams that ship identity well spend more time on revocation and display rules than on the ceremony of minting a token.

Authenticity in an age of synthetic media

Authenticity used to mean “this file has not been edited.” Now it means provenance: where something came from, when it was captured, and which tools touched it. That shift pushes trust outward—from pixels to pipelines. We verify not only the artifact but the chain of custody: cameras, editors, and distribution platforms that each leave a trace someone can challenge.

The uncomfortable part is that authenticity is always partial. Perfect provenance is rare; useful provenance is selective, privacy-preserving, and honest about gaps.

Digital trust is social infrastructure

Trust is not a boolean. It is graded, contextual, and repairable. Recovery flows, dispute resolution, and rate limits on verification are as central as cryptography. When identity systems ignore the social layer, they produce technically correct outcomes that feel hostile to humans—locked accounts, brittle migrations, and “support” that cannot reason about edge cases.

Closing

Ownership of identity in 2026 is less about owning a username and more about owning your relationship to verification: who can speak for you, how you can rotate that authority, and what you can prove without becoming transparent. The hard problems are not only mathematical—they are policy, UX, and institutional memory dressed as login screens.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Velocidad sincronizada y el riesgo del “todo encaja”

Cuando diseño, ingeniería y marketing comparten herramientas de borrador rápido, el producto puede parecer cerrado antes de estarlo. Las pantallas se alinean visualmente, el texto suena convincente y el demo engaña incluso al equipo. El problema no es la velocidad sino la ilusión de integración: tres capas que coinciden en la superficie pero no en supuestos, métricas ni límites.

El antídoto más barato sigue siendo aburrido: definiciones compartidas de usuario, de éxito y de “no haremos esto en v1”. Sin eso, la IA solo acelera la dispersión.

Criterio como recurso escaso

Si las herramientas barren la fricción mecánica, lo que queda en escasez es criterio: qué problema merece existir, qué trade-off es aceptable, qué experiencia no negociamos por un lanzamiento apurado. Los equipos que han confundido velocidad con claridad han terminado lanzando más cosas y recordando menos por qué las lanzaron.

En la práctica, criterio se entrena con revisiones honestas: demos que muestran límites, no solo happy path; decisiones documentadas en una frase; métricas que contradicen narrativas bonitas.

Coherencia entre código, diseño y narrativa

Un producto creíble necesita que las tres capas cuenten la misma historia. Cuando cada disciplina itera en silos acelerados por IA, aparecen micro-incongruencias: el flujo promete simplicidad pero el código expone diez casos borde; el diseño asume datos que el backend no garantiza; el mensaje de marketing describe un superpoder que el producto solo insinúa.

La solución no es frenar a nadie, es sincronizar puntos de control: un mismo documento vivo de alcance, pruebas que atraviesan capas, y responsables claros cuando el texto y la implementación divergen.

De la aceleración a la mantenibilidad

Construir rápido sin dejar huellas es construir deuda con estética. Los equipos maduros invierten parte del tiempo ganado en higiene: nombres consistentes, pruebas que importan, logs que explican decisiones automáticas. La IA puede ayudar a redactar y refactorizar, pero alguien tiene que decidir qué merece sobrevivir al próximo sprint.

Cierre

La aceleración por IA no elimina el trabajo duro del producto; lo reubica en decisiones de foco, coherencia y confianza. La ventaja competitiva deja de ser “lo hicimos antes” y pasa a ser lo hicimos entendible, defendible y sostenible cuando el ritmo externo sigue subiendo.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Strategy as curation, not heroics

Early-stage technical leadership used to look like long nights and personal mastery of the stack. In 2026 it often looks like choosing what not to automate yet, which abstractions survive contact with customers, and which experiments get a budget of trust. Strategy becomes curation: picking the few bets that deserve deep context, instrumentation, and human review—while letting the rest stay deliberately shallow until the signal is real.

Founders who confuse curation with hesitation lose to founders who sequence—they know which layer of the product must be boring and reliable before the flashy layer earns the right to exist.

Systems thinking beats tool fluency

Tool fluency is table stakes. What compounds is systems thinking: how data flows between humans and machines, where failure modes cluster, and what “done” means when part of the pipeline is non-deterministic. Technical founders are increasingly judged on whether they can draw those boundaries clearly enough that a growing team does not need to re-derive them every sprint.

That means explicit interfaces between “human decides” and “machine proposes,” shared definitions of quality, and observability that answers why something happened—not only that it happened.

Decision-making when the default is “ask the model”

AI-heavy startups inherit a subtle risk: decision drift. When the path of least resistance is to generate another option, teams can churn through plausible answers without ever converging on a committed one. The founder’s job is to install decision hygiene: short written rationales, time-boxed exploration, and kill criteria that survive enthusiasm.

The best technical founders I have watched in this cycle are neither skeptics nor cheerleaders—they are editors. They know when speed is cheap and when it is expensive, and they protect the expensive moments.

Closing

The new role is not less technical; it is more architectural. Founders still need taste and craft, but the leverage moves upstream—to the systems that decide what is allowed, what is measured, and what stays human. In a world of abundant generation, the founder who curates well builds something that still makes sense a year later.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Comunidad después del algoritmo

La escena siempre fue tribal en el buen sentido: códigos, referencias, lugares. Hoy esas tribus se fragmentan en feeds que no comparten calendario ni contexto. Eso no borra la pertenencia, la redistribuye: parte ocurre en la fila, parte en el chat del after, parte en un directo que nadie archivó. Quien produce o cura tiene que asumir que la “comunidad” es un mosaico, no un solo grupo de WhatsApp.

Lo interesante es que, cuando algo funciona, suele ser porque alguien ancló un gesto repetible: un sonido, un visual, una frase que la gente puede llevarse sin explicación. No es manipulación barata; es diseño cultural mínimo viable.

Espectáculo como contrato emocional

El espectáculo grande no compite solo con otro festival; compite con la expectativa acumulada en pantalla. Si el público ya vio mil transiciones imposibles en TikTok, el escenario tiene que ofrecer otra clase de imposible: presencia, volumen físico, sincronía con extraños. La producción luminosa y el vídeo en vivo no son “decoración”; son la forma en que el evento cumple o rompe la promesa que se hizo online.

Reflexionar en frío: el riesgo del hiper-espectáculo es homogeneizar la emoción. Cuando todo brilla igual de fuerte, el recuerdo se vuelve genérico. Las noches que quedan suelen ser las que mezclaron imperfección legible con un pico bien colocado.

Economía del creador y presión de formato

La economía del creador alimentó a una generación de DJs y productores que también son editores, guionistas y community managers. Eso abrió ingresos y visibilidad, pero también introdujo una métrica paralela: no solo “¿funciona en la pista?” sino “¿funciona en el primer segundo?”. No todo lo bueno para el clip es bueno para el club, y viceversa.

En 2026, quien sobrevive con criterio suele separar canales: el short-form como puerta, el largo formato (sets, álbumes, newsletters) como profundidad. No es snobismo; es conservar autoría cuando la plataforma premia la variación constante.

Presencia digital como extensión, no sustituto

Tener presencia digital ya no es opcional, pero tampoco es reemplazar el contacto real. Es traducir lo que haces a idiomas que la gente ya habla: memes, loops, anuncios honestos. La paradoja es que la sobreexposición puede erosionar el misterio que antes vendía entradas. Por eso algunos proyectos recuperan silencios estratégicos o límites claros en qué se documenta y qué queda solo para quien estuvo ahí.

Cierre

La música electrónica en 2026 sigue siendo, en el fondo, un acuerdo colectivo: vibrar al mismo tiempo. Las herramientas cambian; el problema que permanece es cómo hacer que la gente siga sintiendo que pertenece a algo que vale la pena cuidar, tanto en la cabina como en el feed.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Tokenización para sistemas reales, no para teatro

En sistemas reales, tokenizar es formalizar límites: quién puede entrar, cuántas veces, durante cuánto tiempo, y con qué obligaciones. Eso aparece en acceso a APIs, licencias de software, derechos de contenido y mercados secundarios regulados. La utilidad no está en el token como objeto mágico sino en que las reglas viajan con el permiso y pueden auditarse.

Los equipos que fracasan suelen confundir el mapa con el territorio: emiten un token y olvidan gobernanza, cumplimiento y soporte humano cuando algo sale mal.

Acceso fino sin burocracia infinita

La tokenización brilla cuando el acceso debe ser granular y revocable. Un pase de un solo uso, un rol temporal, un cupo que se transfiere con condiciones: esos patrones existían antes, pero costaban integraciones frágiles. Un diseño maduro combina tokens con políticas claras—límites de tasa, caducidad, y caminos de recuperación que no dependen de un héroe en un chat de soporte.

Incentivos que alinean comportamiento

Los incentivos mal diseñados convierten cualquier sistema en un juego perverso. La tokenización no arregla ética; solo hace explícitos los pagos, las recompensas y las penalizaciones. Cuando esos incentivos son legibles, es más fácil detectar externalidades: qué comportamiento se subsidia sin querer y quién paga el costo oculto.

Diseño operativo: lo aburrido salva lo visible

Lo que sostiene la tokenización útil no es el whitepaper sino la operación: monitoreo, incident response, actualización de políticas y comunicación con usuarios. Si el sistema no puede explicar en una frase qué representa un token, probablemente no debería existir todavía.

Cierre

La tokenización sigue importando porque algunos problemas son problemas de límites. Donde el acceso, la propiedad fraccionada o los incentivos necesitan reglas compartidas y verificables, el patrón vuelve a aparecer—con menos ruido y más ingeniería. El reto no es convencer a nadie de creer; es construir algo que funcione cuando el mercado no aplaude.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Roles: from pixel-pusher to interaction owner

When boilerplate, layout drafts, and test scaffolds arrive in seconds, the differentiator is not raw output volume. It is taste under constraint: latency budgets, accessibility, motion that communicates state instead of decorating it, and error paths that respect the user’s time.

Teams still need people who can read the DOM like a score, but the title matters less than the responsibility: owning the quality bar for what ships in the browser, regardless of who—or what—wrote the first pass.

Interaction quality as a moving target

“Looks fine in Chrome on my machine” was never enough; now it is dangerously easy to generate plausible-looking UI that fails basic interaction hygiene. Focus order drifts, live regions are missing, loading states lie, and optimistic UI overshoots trust.

The craft shifts toward verification habits: keyboard runs, screen readers on a schedule, performance profiles on representative hardware. AI can suggest fixes, but someone must decide which failures are unacceptable before release—not after a viral complaint.

Prototyping speed without prototype thinking

Rapid prototyping is a gift when it tightens feedback loops. It is a trap when every experiment looks merge-ready. The discipline that separates exploration from production is unchanged: boundaries on scope, explicit assumptions, and a willingness to throw away the pretty draft that solved the wrong problem.

Useful pattern: treat AI-generated UI as disposable clay—shape fast, learn, then rebuild the slice you keep with clearer state modeling and tests that encode intent.

Beyond implementation-only thinking

Frontend engineers who thrived on speed alone may feel displaced. Those who think in systems—routing, caching, design tokens, data fetching contracts, edge behavior—gain leverage. The implementation is still there; it is just no longer the full story.

The mental model looks more like orchestration: coordinating design systems, API shapes, analytics hooks, and runtime constraints so the surface stays coherent when backends and copy change underneath.

Closing

AI-native workflows do not retire frontend; they raise the floor on how fast mediocre UI can be produced. The ceiling still belongs to people who care how software feels when it fails, when it waits, and when it wins. That is not nostalgia for hand-coded divs—it is recognition that speed without judgment is just faster noise.

Author

• Nathan Lazo [nathan-lazo.com] [github]

From prompts to orchestration

A prompt is a moment. An agent is a policy wrapped in a loop: perceive, plan, act, verify (or fail loudly). Once software stopped being “call the model once and hope,” orchestration became the real design surface—queues, retries, tool permissions, human checkpoints.

That change rewards people who think like systems designers, not like clever typists. You sketch boundaries before you sketch UX copy: which tools exist, what credentials they carry, how state is shared across steps, and where the human must remain in the loop.

Context as a first-class budget

Agents exposed how expensive context really is—not only in tokens, but in trust. Feeding an agent everything is tempting and dangerous. The mature pattern looks more like curation: structured memory, retrieval with provenance, explicit “working set” files, and audit trails for decisions that touched production.

Developers who grew up optimizing CPU and memory now optimize attention surfaces: what the agent is allowed to see, when it refreshes, and how conflicts resolve when two sub-agents disagree.

Security and blame lines

When an agent can open tickets, edit code, or query internal APIs, security stops being “lock the repo” and becomes capability graphs. Who granted which scope? Can it be narrowed? What happens when a third-party tool misbehaves?

Late 2025’s lesson was blunt: the attack surface scales with autonomy. Teams that shipped agents without crisp blame lines learned quickly that “the model did it” is not an incident narrative anyone wants to read twice.

Thinking in systems, not isolated tricks

The cultural shift is easy to understate. Engineers began reasoning in graphs—dependencies between services, humans, and automated actors—rather than in linear scripts. Design reviews started asking: what is the failure mode if step three hallucinates a parameter? What is the rollback if the agent merges the wrong branch?

That mindset spills into non-agent code too. Once you habitually ask “who observes this?” and “what verifies it?”, you write smaller, inspectable units even when no LLM is involved.

Outlook

Agents did not replace developers in 2025. They re-centered the job on judgment: where to automate, what to verify, and how to keep software legible when more of the pipeline moves at machine speed. The winners were not the teams with the flashiest demos but the ones who treated agents as components—versioned, testable, and owned.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Edits, referencia y velocidad

Hacer un edit viral o un mashup limpio dejó de ser, para muchos, un proyecto de fin de semana en solitario. Hay presión por cadencia: si no publicas, el algoritmo asume que no existes. Las IA y los DAW asistidos acortan el camino entre idea y archivo exportable. Eso democratiza la producción y, al mismo tiempo, sube el piso técnico mínimo que la audiencia asume como normal.

El riesgo no es solo “suena parecido”. Es que la referencia se vuelva circular: modelos entrenados con lo mismo que ya escuchas, optimizados para lo que ya funciona en redes. El DJ que quiere sonar distinto tiene que empujar contra esa inercia con criterio, no solo con más plugins.

Herramientas que cambian el flujo, no la noche

En cabina, la IA raramente reemplaza el gesto completo. Lo que cambia es el entorno previo: búsqueda de pistas, etiquetado, limpieza de stems, ideas de transición, versiones para practicar. Es trabajo invisible que antes consumía horas. Quien lo automatiza bien gana tiempo para escuchar y para ensayar decisiones bajo presión.

Lo que las herramientas no resuelven es el momento: leer una sala, ceder cuando la pista “correcta” mata el piso, o insistir cuando la teoría dice que no y el cuerpo de la gente dice que sí. Eso sigue siendo improvisación social.

Identidad performática

Ser DJ hoy incluye ser personaje público: historias, estética, coherencia entre lo que prometes online y lo que entregas en vivo. La IA puede ayudar a generar contenido, pero la confianza se gana cuando el set demuestra que entiendes contexto, historia y riesgo. La audiencia perdona un error humano antes que una noche que suena a playlist generada sin alma.

Qué sigue teniendo valor

Tres cosas, al menos, siguen siendo escasas:

1. Curaduría con criterio —no acumular, sino construir un arco que tenga intención.
2. Presencia en tiempo real —reaccionar al espacio, no solo al plan del USB.
3. Voz propia —una combinación de gustos, referencias y límites que no es copiable con un solo prompt.

La IA no elimina al DJ; reordena qué trabajo es commodity y qué trabajo sigue siendo arte y oficio. El margen profesional se mueve hacia quien puede decidir mejor, no hacia quien solo produce más rápido.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Utilidad real: acuerdos que necesitan huella

La utilidad persistente no es “hacer todo descentralizado”; es registrar hechos compartidos entre partes que no se confían por completo pero necesitan coordinarse: origen de activos, condiciones de liquidación, derechos reproducibles en software. Donde un PDF firmado ya no alcanza y un solo administrador genera fricción política, la infraestructura distribuida vuelve a entrar en la conversación—no como moda, sino como costo asumido a cambio de auditabilidad.

Infraestructura silenciosa

Lo más aburrido suele ser lo que sobrevive. Las integraciones B2B, los estándares de identidad y las capas de cumplimiento no generan titulares, pero sostienen mercados. Ahí el blockchain dejó de ser un personaje principal y pasó a ser cableado: APIs, oráculos, puentes con límites claros, y equipos que piensan en operación antes que en narrativa.

El hype prometía democratizar todo; la práctica madura delimita dónde la descentralización reduce riesgo sistémico y dónde solo añade latencia.

Confianza como diseño, no como eslogan

La confianza no nace de “estar en cadena”; nace de gobernanza, de claves bien custodiadas, de modelos de recuperación realistas y de transparencia sobre supuestos. Los proyectos que sobrevivieron el choque aprendieron a hablar menos de “inmutabilidad mágica” y más de límites explícitos: qué puede fallar, quién puede pausar qué, y cómo se audita un cambio.

Cierre

Blockchain después del hype no desapareció: se encogió al tamaño de sus mejores problemas. Donde la infraestructura de confianza vale el precio, sigue ahí. Donde solo había especulación con adjetivos, el vacío se notó de inmediato—y eso también cuenta como claridad.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Bass as culture, not just an EQ curve

“Bass culture” is more than subwoofers. It is a set of listening habits, social signals, and shared references: the appreciation for sound system culture, the patience for long blends, the humor and memes that orbit certain artists and labels. A festival that centers that frequency range is aligning with a community grammar that mainstream pop EDM often smooths away. The result is cohesion: people know why they are there.

Resilience through shared stakes

Niche scenes survive touring economics, algorithm shifts, and platform churn because participants treat the scene as partially theirs. Grassroots labels, regional crews, and online archives create redundancy: if one node fails, others carry the memory. Large branded events plug into that resilience when they respect the sound’s history rather than treating it as a costume. The tension appears when scale demands accessibility that the core audience experiences as dilution.

Growth as symbol

When a specialized gathering expands, every choice is read symbolically. More stages can mean more room for sub-styles; it can also mean genre sprawl that tests the original promise. Lost Lands sits in that conversation as both a destination for bass heads and a beacon visible from outside the niche—proof that “heavy” electronic music can fill fields and headlines. Growth, here, is not only commercial; it is cultural visibility for a corner of dance music that rarely gets the default mainstream narrative.

What the symbol costs

No scene scales without tradeoffs: ticket prices, travel, environmental footprint, and the inevitable gap between OG memory and new arrival enthusiasm. The strength of bass culture has been its ability to argue for depth over polish. Festivals that inherit that argument inherit its scrutiny too.

Lost Lands works as a mirror: it shows how a tight aesthetic and sonic focus can become a rallying point—and how easily rallying points become brands. The interesting question is whether the brand can keep feeding the culture that named it.

Author

• Nathan Lazo [nathan-lazo.com] [github]

When the novelty wears off

Early usage often looks like improvisation: big prompts, vague goals, paste-and-pray. That can still unblock a solo developer on a Sunday. It scales poorly. Once AI assistance becomes daily infrastructure, the bottleneck moves from “can it generate code?” to “can we trust the diff?” and “who owns the architecture when everyone is pair-programming with the same generic partner?”

The shift is psychological as much as technical. You stop asking for magic and start asking for bounded tasks: a function, a test case, a refactor with explicit invariants.

Workflow discipline beats model hype

Models will keep improving. Your process should not depend on treating each release like a religious holiday. Practical discipline looks boring on paper:

• Scope the ask so the model cannot hide ambiguity in a fifty-line patch.
• Keep context local: point it at the files and conventions that actually govern the change.
• Treat output as a proposal, not a merge-ready artifact—especially for security, data handling, and anything that touches money or identity.

None of that requires heroics. It requires treating AI like a fast intern with infinite stamina and finite accountability.

Review quality is the real product

If your team’s review culture was already shallow—rubber-stamp approvals, “LGTM” without reading—AI will pour gasoline on it. Generated code can look polished while violating invariants only your senior engineers remember.

Strong review is not gatekeeping; it is compression of organizational memory into a few sharp questions: What breaks if this input is hostile? What happens on partial failure? Does this match how we name things, log things, and test things?

The teams that benefit most from AI coding are often the ones that were already serious about review. The tool amplifies throughput; culture decides whether that throughput is progress or debt.

Practical usage that survives contact with reality

What tends to work in production settings:

• Spikes and throwaways: explore with AI, then rewrite the slice you keep so it matches house style.
• Tests as contracts: let the model draft tests, but treat failing tests as non-negotiable signals, not annoyances to “fix” by weakening assertions.
• Documentation that earns its keep: use assistants to draft, but have a human verify procedures against the actual repo state.

What tends to fail: asking for “the whole feature” and merging because it compiles.

Closing thought

AI-assisted coding is settling into the same category as search, formatters, and linters—infrastructure you forget until it misbehaves. The competitive edge is not who toggles autocomplete fastest; it is who can integrate assistance into a workflow that still produces software people can maintain when the hype graph flattens.

Author

• Nathan Lazo [nathan-lazo.com] [github]

In November 2022, OpenAI launched GPT-3. It was a revolution. LLM (Large Language Models) offered a conversational interface that anyone could use. However, their true evolution began with GPT-4 in 2023, which introduced deeper language understanding, greater reasoning capacity, and multimodality (text and image).

By 2024 and 2025, models were not only more intelligent but also more integrable. Now they can be customized through tools like OpenAI Assistants or programmatic functions. Additionally, multi-agent environments have emerged where several models collaborate to solve complex problems, such as agents that analyze data, generate reports, and execute actions together.

Content creation tools: the creator's new studio

Before, making a reel, an article, or a design required mastering multiple platforms. Today, AI-powered tools allow generating videos with text, synthesizing voices, writing scripts, and even editing images in seconds.

In my work, we have integrated these tools into projects for multimedia content, generating ideas, or even generating audio through AI. From Cursor, v0, and Midjourney to AI-powered automations, the creative flow has become continuous, iterative, and more accessible.

Introduction to Model Context Protocols (MCPs)

One of the most promising advances of the present is the development of MCPs (Model Context Protocols), a standardization proposal to allow multiple language models (LLMs) to share context, collaborate, and execute tasks securely and interoperably.

Imagine an ecosystem where you can connect a model specialized in law, another in financial analysis, and another in creativity, all working under a common protocol. That's what MCPs propose. Beyond the typical "prompt," identities, roles, objectives, and resources are now defined in multi-agent environments. This is the gateway to a new way of building software: not just interfaces, but digital societies of intelligent agents.

For more details, you can explore the official introduction to MCPs.

Conclusion: designing with intelligence

Artificial intelligence has ceased to be an auxiliary tool to become an essential layer of digital design. As a developer and CTO of The Noro, my focus has shifted from simply building interfaces to orchestrating flows of intelligence between humans and machines.

From 2022 to 2025, we have seen unprecedented acceleration: more intelligent LLMs, more powerful creation tools, and now, protocols that enable collaboration between intelligences. In the coming years, the challenge will not just be using AI, but designing experiences where intelligence is distributed ethically, creatively, and with purpose.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Worldbuilding as infrastructure

A festival that invests in recurring motifs (characters, “realms,” mythic language) is not merely decorating tents. It is building narrative infrastructure: assets that can travel across years, trailers, collaborations, and merchandise. That continuity turns each edition into a sequel rather than a reset. From a design perspective, the question is not “how big can the stage be?” but what world does this stage imply, and can the audience enter it without a manual.

Stage design as plot device

Main stages at this level function like set pieces in a film. Lighting, pyro, LED architecture, and pacing are not garnish; they are the grammar of escalation. Drops read louder when the visual arc has already told you a story of ascent. This is why criticism of “too much production” often misses the point: for many attendees, the production is the narrative—especially when the music is shared across dozens of festivals worldwide.

Fantasy and the economics of belonging

Fantasy narratives at festivals do emotional work. They offer permission to dress up, to speak in shorthand with strangers, to suspend ordinary social rules. They also bundle identity: “I am the kind of person who belongs in this story.” Product designers in tech talk about onboarding; festival storytelling is a form of cultural onboarding with costumes instead of tooltips.

Where festival storytelling is heading

Streaming and short-form video have made the off-season as visible as the event. The future of festival storytelling is less a single climax weekend and more a distributed canon: clips, artist spotlights, and ambient lore that keep the world warm between gates. The risk is sameness—when every fantasy realm starts to look like the same CGI trailer. The opportunity is specificity: worlds that feel authored rather than generated.

Tomorrowland sits at the intersection of live spectacle and franchise logic. Whether that excites or exhausts you, it is a useful lens for any large gathering that wants loyalty beyond the last kick drum.

Author

• Nathan Lazo [nathan-lazo.com] [github]

Marca como atmósfera

La fuerza de marcas como Electric Daisy Carnival no está solo en el cartel. Está en la coherencia visual y emocional: un lenguaje que funciona en TikTok, en el recinto y en la memoria colectiva. El “rave” deja de ser un género difuso y se vuelve algo que puedes reconocer aunque nunca hayas estado en el desierto. Eso es diseño de identidad aplicado a la escala del espectáculo: tipografías, mascotas, colores y ritmos de reveal que convierten la anticipación en parte del producto.

Espectáculo y comunidad en tensión

Hay una paradoja honesta en los mega-festivales. Por un lado, el show busca singularidad —“esta noche es irrepetible”—. Por otro, depende de repetición industrial: circuitos, tours, formatos que se replican entre ciudades. La comunidad no nace solo del escenario; nace de los grupos de chat, los aftermovies, los memes y las discusiones sobre “cómo estuvo” versus “cómo se vio”. La cultura digital amplifica la marca: cada clip es un embajador involuntario.

El rave como símbolo exportable

Hoy “ir de rave” puede significar cosas distintas según el país, pero ciertos festivales han logrado que su nombre funcione como atajo semántico para una fiesta grande, colorida y electrónica. Eso tiene costos: la homogeneización estética, la presión por contenido siempre “instagrammable”, la sensación de que el underground original queda narrado desde arriba. Aun así, el fenómeno muestra cómo la música dance se articula con capital simbólico y con plataformas que premian la legibilidad instantánea.

Lectura desde afuera

No hace falta haber vivido cada edición para observar el patrón: un festival que escala convierte la experiencia en marca, la marca en historia compartida y la historia en motor de la siguiente temporada. Preguntarse por EDC es preguntarse qué versión del “nosotros” del dance floor se está vendiendo —y qué espacio queda para lo local, lo ruidoso y lo que no cabe en un trailer de dos minutos.

Autor

• Nathan Lazo [nathan-lazo.com] [github]

Server Components: Leveraging Server Infrastructure

Server Components offer several advantages over Client Components. They enable developers to leverage server infrastructure more effectively. By moving data fetching closer to the server and keeping large dependencies on the server, Server Components improve overall performance. They provide the flexibility to write React applications that feel akin to frameworks like PHP or Ruby on Rails, while still benefiting from the power and flexibility of React's component model for UI templating.

With Server Components, the initial page load is faster, and the client-side JavaScript bundle size is reduced. The base client-side runtime remains cacheable and predictable in size, regardless of application growth. Additional JavaScript is only added when client-side interactivity, through the use of Client Components, is required.

Client Components: Adding Interactivity

Client Components allow developers to incorporate client-side interactivity into their applications. In Next.js, these components are pre-rendered on the server and then hydrated on the client side. You can think of Client Components as similar to components in the Pages Router, providing a familiar approach to building interactive UI elements.

The "use client" Directive: Defining the Component Boundary

The "use client" directive serves as a convention for declaring the boundary between Server and Client Components. Placed at the top of a file, above imports, it marks the transition point from server-only to client code. Once defined in a file, all modules imported into it, including child components, become part of the client bundle.

It's important to note the following regarding the "use client" directive:

• Components in the Server Component module graph are rendered exclusively on the server.
• Components in the Client Component module graph are primarily rendered on the client side, but Next.js allows them to be pre-rendered on the server and hydrated on the client.
• The "use client" directive must be defined at the top of a file before any imports.
• It only needs to be defined once, typically at the entry point of your application, to encompass all subsequently imported modules as Client Components.

'use client'

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  )
}

Choosing Between Server and Client Components

To simplify the decision-making process, it is recommended to use Server Components (the default in the app directory) unless there is a specific use case for a Client Component. Server Components offer benefits such as improved performance, reduced client-side JavaScript, and optimized server infrastructure utilization.

Patterns: Moving and Composing Components

Two patterns worth noting are moving Client Components to the leaves of the component tree and composing Server and Client Components.

Moving Client Components to the leaves involves separating interactive logic from static elements, keeping the layout as a Server Component and moving the interactive logic to a Client Component. This optimization reduces the amount of component JavaScript sent to the client.

Composing Server and Client Components allows you to combine both types of components within the same component tree. React handles the rendering process, merging the server and client work seamlessly to produce a faster initial page load.

It's important to be aware of the restriction on importing Server Components into Client Components. This pattern requires an additional server round trip and is not supported.

Good to know: In Next.js, during the initial page load, both the rendered result of Server Components from the above step and Client Components are pre-rendered on the server as HTML to produce a faster initial page load.

Unsupported Pattern: Importing Server Components into Client Components

The following pattern is not supported. You cannot import a Server Component into a Client Component:

'use client'

// This pattern will **not** work!
// You cannot import a Server Component into a Client Component.
import ExampleServerComponent from './example-server-component'

export default function ExampleClientComponent({
  children,
}: {
  children: React.ReactNode
}) {
  const [count, setCount] = useState(0)

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>

      <ExampleServerComponent />
    </>
  )
}

Recommended Pattern: Passing Server Components to Client Components as Props

Instead, when designing Client Components you can use React props to mark "holes" for Server Components. The Server Component will be rendered on the server, and when the Client Component is rendered on the client, the "hole" will be filled in with the rendered result of the Server Component.

A common pattern is to use the React children prop to create the "hole". We can refactor <ExampleClientComponent> to accept a generic children prop and move the import and explicit nesting of <ExampleServerComponent> up to a parent component.

'use client'

import { useState } from 'react'

export default function ExampleClientComponent({
  children,
}: {
  children: React.ReactNode
}) {
  const [count, setCount] = useState(0)

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>

      {children}
    </>
  )
}

Now, <ExampleClientComponent> has no knowledge of what children is. In fact, from its perspective, it doesn't even know that children will eventually be filled in by the result of a Server Component. The only responsibility ExampleClientComponent has is to decide where whatever children will eventually be should be placed.

In a parent Server Component, you can import both the <ExampleClientComponent> and <ExampleServerComponent> and pass <ExampleServerComponent> as a child of <ExampleClientComponent>:

// This pattern works:
// You can pass a Server Component as a child or prop of a
// Client Component.
import ExampleClientComponent from './example-client-component'
import ExampleServerComponent from './example-server-component'

// Pages in Next.js are Server Components by default
export default function Page() {
  return (
    <ExampleClientComponent>
      <ExampleServerComponent />
    </ExampleClientComponent>
  )
}

With this approach, the rendering of <ExampleClientComponent> and <ExampleServerComponent> are decoupled and can be rendered independently - aligning with Server Components, which are rendered on the server before Client Components.

Good to know

• This pattern is already applied in layouts and pages with the children prop, so you don't have to create an additional wrapper component.
• Passing React components (JSX) to other components is not a new concept and has always been part of the React composition model.
• This composition strategy works across Server and Client Components because the component that receives the prop has no knowledge of what the prop is. It is only responsible for where the thing that it is passed should be placed.
• This allows the passed prop to be rendered independently, in this case, on the server, well before the Client Component is rendered on the client.
• The very same strategy of "lifting content up" has been used to avoid state changes in a parent component re-rendering an imported nested child component.
• You're not limited to the children prop. You can use any prop to pass JSX.
• Passing props from Server to Client Components (Serialization)
• Props passed from the Server to Client Components need to be serializable. This means that values such as functions, Dates, etc, cannot be passed directly to Client Components.

Where is the Network Boundary?

In the App Router, the network boundary is between Server Components and Client Components. This is different from the Pages where the boundary is between getStaticProps/getServerSideProps and Page Components. Data fetched inside Server Components do not need to be serialized as it doesn't cross the network boundary unless it is passed to a Client Component. Learn more about data fetching with Server Components.

Keeping Server-Only Code out of Client Components (Poisoning)

Since JavaScript modules can be shared between both Server and Client Components, it's possible for code that was only ever intended to be run on the server to sneak its way into the client.

For example, take the following data-fetching function:

// lib/data.ts

export async function getData() {
  const res = await fetch('https://external-service.com/data', {
    headers: {
      authorization: process.env.API_KEY,
    },
  })

  return res.json()
}

At first glance, it appears that getData works on both the server and the client. But because the environment variable API_KEY is not prefixed with NEXT_PUBLIC, it's a private variable that can only be accessed on the server. Next.js replaces private environment variables with the empty string in client code to prevent leaking secure information.

As a result, even though getData() can be imported and executed on the client, it won't work as expected. And while making the variable public would make the function work on the client, it would leak sensitive information.

So, this function was written with the intention that it would only ever be executed on the server.

The "server only" package To prevent this sort of unintended client usage of server code, we can use the server-only package to give other developers a build-time error if they ever accidentally import one of these modules into a Client Component.

To use server-only, first install the package:

npm install server-only

Then import the package into any module that contains server-only code:

// lib/data.js

import 'server-only'

export async function getData() {
  const res = await fetch('https://external-service.com/data', {
    headers: {
      authorization: process.env.API_KEY,
    },
  })

  return res.json()
}

Now, any Client Component that imports getData() will receive a build-time error explaining that this module can only be used on the server.

The corresponding package client-only can be used to mark modules that contain client-only code – for example, code that accesses the window object.

Third-Party Packages and Compatibility with Server Components Not all third-party packages have been updated to support Server Components. Some packages may rely on client-only features and lack the "use client" directive required for Server Components. In such cases, these packages won't work within Server Components.

To address this, you can create wrapper components for third-party packages, marking them as Client Components and enabling their usage within Server Components.

As the ecosystem around Server Components continues to evolve, more third-party packages are expected to incorporate the "use client" directive, providing seamless support for Server Components.

Note: The code examples provided are for illustrative purposes and may not represent the exact implementation in your project. Please adapt the code to your specific use case.

Using Context in Client Components

Context is a powerful feature in React that allows for sharing data between components. In Next.js 13, context is fully supported within Client Components. You can create context using createContext and consume it using useContext. For example:

'use client'
 
import { createContext, useContext, useState } from 'react'
 
const SidebarContext = createContext()
 
export function Sidebar() {
  const [isOpen, setIsOpen] = useState()
 
  return (
    <SidebarContext.Provider value={{ isOpen }}>
      <SidebarNav />
    </SidebarContext.Provider>
  )
}

function SidebarNav() {
let { isOpen } = useContext(SidebarContext)

return (
  <div>
    <p>Home</p>

    {isOpen && <Subnav />}
  </div>
)
}

Rendering Context Providers in Server Components

Creating context directly at the root level in Server Components is not supported. To overcome this, you can create your context within a Client Component and render it in your Server Component. For example:

// theme-provider.tsx
'use client'
 
import { createContext } from 'react'
 
export const ThemeContext = createContext({})
 
export default function ThemeProvider({ children }) {
  return <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>
}

// layout.tsx
import ThemeProvider from './theme-provider'

export default function RootLayout({
children,
}: {
children: React.ReactNode
}) {
return (
  <html>
    <body>
      <ThemeProvider>{children}</ThemeProvider>
    </body>
  </html>
)
}

This way, you can consume the context in other Client Components throughout your application.

Rendering Third-Party Context Providers in Server Components

Rendering third-party context providers directly in Server Components may cause errors if they haven't implemented support for Server Components. To resolve this, you can wrap third-party providers in your own Client Component and render it in your Server Component. For example:

// providers.js
'use client'
 
import { ThemeProvider } from 'acme-theme'
import { AuthProvider } from 'acme-auth'
 
export function Providers({ children }) {
  return (
    <ThemeProvider>
      <AuthProvider>{children}</AuthProvider>
    </ThemeProvider>
  )
}

// layout.js
import { Providers } from './providers'
 
export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  )
}

This ensures that the third-party providers work as expected within your Server Components.

Sharing Data Between Server Components

Since Server Components are not interactive and do not rely on React state, you don't need React context to share data between them. Instead, you can use native JavaScript patterns for data sharing. For example, you can create a module to share a database connection across multiple components:

// utils/database.ts
export const db = new DatabaseConnection()

Then, you can import and use this module in your Server Components:

// users/layout.tsx
import { db } from '@utils/database'
 
export async function UsersLayout() {
  let users = await db.query()
  // ...
}

// users/[id]/page.tsx
import { db } from '@utils/database'
 
export async function DashboardPage() {
  let user = await db.query()
  // ...
}

By importing the @utils/databasemodule, both components can access the shared database connection. This approach is known as global singletons.

Sharing Fetch Requests Between Server Components When fetching data in Server Components, you may want to share the fetched result between a page or layout and its child components. Instead of passing props back and forth, it's recommended to colocate data fetching alongside the component that consumes the data. Next.js automatically deduplicates fetch requests in Server Components, so each component can request the specific data it needs without worrying about duplicate requests. Next.js will read the same value from the fetch cache.

Note: the code examples provided are for illustration purposes and may require adaptation to fit your specific use case.

Author

• Nathan Lazo [github]

References

• React Tutorial (https://reactjs.org/tutorial/)
• Thinking in React (https://reactjs.org/docs/thinking-in-react.html)
• Learn React (https://reactjs.org/docs/hello-world.html)
• Next.js Documentation (https://nextjs.org/docs/getting-started)

Remember to consult the official Nextjs documentation for the most up-to-date information on React.

Understanding Prompt Engineering - Before delving into prompt crafting, let's understand the concept of prompt engineering. In the context of generative AI coding tools, prompts are code blocks, individual lines of code, or natural language comments that developers write to generate specific suggestions from GitHub Copilot. Prompt engineering involves providing instructions or comments in the IDE to guide Copilot in generating coding suggestions that align with the desired output.

Best Practices for Prompt Crafting

Set the Stage with a High-Level Goal

When starting a new coding task, it's helpful to set the stage by providing Copilot with a high-level goal. Imagine having a conversation with a programming partner. Break down the problem and discuss how you would approach it together. By describing the big picture and the desired outcome, Copilot gains a clear understanding of what you want to achieve. This sets the context and primes Copilot to generate code snippets that align with your intentions.

For example, when building a markdown editor in Next.js, you can write a comment like this:

/*
Create a basic markdown editor in Next.js with the following features:

Use react hooks
Create state for markdown with default text "type markdown here"
A text area where users can write markdown
Show a live preview of the markdown text as I type
Support for basic markdown syntax like headers, bold, italics
Use React markdown npm package
The markdown text and resulting HTML should be saved in the component's state and updated in real time
*/

This prompt will guide Copilot to generate code for a simple, unstyled, but functional markdown editor in less than 30 seconds. You can then focus on styling the component while having a solid starting point.

Make Your Ask Simple and Specific

To improve the accuracy of Copilot's suggestions, break down your request into simple and specific steps. Instead of asking for a large chunk of code all at once, articulate the logic and steps required to achieve your goal. By providing incremental instructions, Copilot can better understand your intentions and generate code after each step. This approach is akin to following a recipe, where each cooking step is described individually.

For example, if you want to reverse a function, you can provide Copilot with step-by-step instructions like this:

// Given a function "reverseString" that takes a string parameter and returns the reversed string
// Step 1: Convert the string into an array of characters
// Step 2: Reverse the array of characters
// Step 3: Convert the reversed array back into a string
// Step 4: Return the reversed string

By breaking down the logic into separate steps, Copilot can generate code for each step, leading to a comprehensive and accurate solution.

Give GitHub Copilot Examples to Learn From

Just like humans, Copilot learns from examples. Providing relevant examples helps Copilot understand the desired outcome more effectively. When giving Copilot an example, make sure it reflects the specific behavior or result you expect. By showcasing the desired output, Copilot can generate code that aligns with your expectations.

For instance, suppose you have an array of data and want to extract the names and store them in a new array. Providing an example helps Copilot generate the correct code:

// Map through an array of arrays of objects to transform data
const data = [
  [
    { name: 'John', age: 25 },
    { name: 'Jane', age: 30 },
  ],
  [{ name: 'Bob', age: 40 }],
]

// Extract names from the data array
// Desired outcome: ['John', 'Jane', 'Bob']
const mappedData = data.flatMap((sublist) =>
  sublist.map((person) => person.name)
)
console.log(mappedData)

By demonstrating the desired outcome and providing clear instructions, Copilot generates the correct code to extract the names from the array.

Additional Tips for Prompt Crafting Experiment with Your Prompts Prompt crafting is more of an art than a science. Experimentation is key to finding the most effective prompts for your coding tasks. By trying different approaches, you can discover patterns that resonate well with Copilot. Keep refining and adjusting your prompts based on the results you get. Through iterative experimentation, you'll improve your prompt crafting skills and achieve better outcomes.

Use Contextual Information Copilot leverages contextual information to generate accurate suggestions. It takes into account the code you've written before and after the cursor, as well as data from your open files. Utilize this contextual information by providing relevant code snippets and comments in your prompts. This helps Copilot understand the desired behavior more accurately and generate code that aligns with the context.

Collaborate with the Community The GitHub Copilot community is a valuable resource for learning and sharing prompt crafting techniques. Engage with other developers, share your experiences, and learn from their insights. By collaborating and exchanging ideas, you can collectively accelerate the growth and adoption of AI-powered software development practices.

Summary

Mastering prompt crafting is essential to effectively utilize the power of GitHub Copilot. By following the best practices and tips shared in this guide, you can communicate your coding intentions more effectively and generate accurate and relevant code suggestions. Remember to experiment, provide clear examples, and leverage contextual information to enhance Copilot's understanding of your desired outcomes. With practice and collaboration, you can unlock the full potential of GitHub Copilot and revolutionize your software development process.

We hope this comprehensive guide has provided you with valuable insights into prompt crafting with GitHub Copilot. Happy coding!

tRPC is a game-changing library that transforms the way APIs are built in TypeScript. It offers developers a powerful and intuitive solution to create end-to-end typesafe APIs without the hassle of code generation or complex schema definitions. With tRPC, you can seamlessly ensure type safety across all layers of your application, from the server to the client, enabling a robust and reliable development process.

One of the standout features of tRPC is its deep integration with TypeScript, leveraging its static typing capabilities to enforce type bindings throughout your codebase. This means that you can catch potential errors and inconsistencies at compile time, reducing the likelihood of runtime issues and enhancing the overall stability of your application.

In tRPC v10, your favorite IDE becomes your best friend. They have introduced features that make your development workflow smoother and more efficient. Let's take a closer look at some of the enhancements:

• "Go to Definition": Jump straight from your frontend consumer to your backend procedure. This feature allows you to navigate seamlessly between the frontend and backend code, saving you time and effort [1].

• "Rename Symbol": Easily rename input arguments or procedures across your entire application. With a single action, you can propagate changes throughout your codebase, ensuring consistency and reducing the chances of introducing errors [1].

• Easier Type Inference: Infer types effortlessly when you want to utilize your tRPC types manually in your application. This improvement simplifies the process of working with tRPC types, making it more intuitive and convenient for developers [1].

• End-to-End Type Safety: One of the core strengths of tRPC is its ability to provide end-to-end type safety from your server to your client, without the need for explicit type declarations [3]. By following a simple convention, you can ensure that your backend returns data in a function, and on the frontend, you can consume that data based on the endpoint name [3]. This approach eliminates the hassle of maintaining separate schemas and facilitates seamless collaboration between frontend and backend teams.

• Validator Integration: tRPC v10 comes equipped with a comprehensive set of input and output validators [4]. These validators not only enable you to define validation logic for your procedures but also play a crucial role in inferring the types of inputs and outputs [4]. The framework provides first-class support for popular validators and allows seamless integration with others, ensuring your API contracts remain robust and error-free.

With tRPC v10, the world of full-stack TypeScript development has reached new heights. The improved developer experience, end-to-end type safety, and seamless validator integration empower you to build fully typesafe APIs without the need for schemas or code generation [5]. Whether you're a seasoned tRPC user or new to the framework, this release opens up new possibilities for building high-quality, efficient, and maintainable applications. Embrace the power of tRPC v10 and elevate your TypeScript development to new horizons.

tRPC vs GraphQL: A Comparative Analysis

In the world of modern web development, there are various options available for building typesafe APIs. Two popular choices are tRPC and GraphQL. Here is a comparison between these two technologies to help you understand their strengths, differences, and use cases. Whether you're deciding which technology to adopt for your project or simply exploring new possibilities, this analysis will provide valuable insights.

1. Approach to Typesafety: tRPC focuses on end-to-end typesafety by leveraging TypeScript's static typing capabilities. It ensures that the client and server communicate using shared types, minimizing the risk of runtime errors and providing a seamless development experience [5]. On the other hand, GraphQL relies on a schema definition language (SDL) to define the shape of the API and its types. While GraphQL provides strong typesafety within the GraphQL ecosystem, integrating it with the broader TypeScript ecosystem may require additional tooling and code generation [5].

2. Flexibility and Query Control: GraphQL offers fine-grained query control, allowing clients to specify exactly what data they need. This reduces the problem of over-fetching and under-fetching commonly associated with RESTful APIs. Clients can retrieve nested and related data in a single request, enhancing performance and reducing network round trips. In contrast, tRPC follows a convention-based approach, where clients consume data based on the endpoint name. While tRPC doesn't provide the same level of flexibility as GraphQL, it offers simplicity and ease of use, especially in scenarios where the API structure is well-defined and stable [3].

3. Ecosystem and Tooling: GraphQL has a mature and extensive ecosystem with a wide range of tools, libraries, and community support. This includes powerful tools for schema management, caching, client generation, and debugging. GraphQL's introspection capabilities make it highly adaptable and enable the automatic generation of documentation, IDE integrations, and more. tRPC, being a newer framework, has a growing ecosystem and a smaller community but provides lightweight and efficient solutions for full-stack TypeScript developers without the need for additional code generation or build pipelines [1].

In summary, tRPC and GraphQL are both powerful options for building typesafe APIs. tRPC focuses on end-to-end typesafety with a TypeScript-first approach, providing simplicity and a seamless development experience. GraphQL offers fine-grained query control and flexibility, making it ideal for projects requiring advanced data retrieval capabilities. Consider your project requirements and team expertise when choosing between the two.

Author

• Nathan Lazo [github]

References:

• [1.] Announcing tRPC v10 | tRPC. Retrieved from here
• [2.] Blog | tRPC. Retrieved from here
• [3.] Introducing tRPC | tRPC. Retrieved from here
• [4.] tRPC server documentation | tRPC. Retrieved from here
• [5.] tRPC | tRPC. Retrieved from here

One of the most significant advantages of blockchain technology is its ability to create a tamper-proof and secure database. This feature is particularly useful for businesses that require secure and transparent record-keeping, such as financial institutions, supply chain management, and healthcare providers. The blockchain technology allows businesses to create a permanent, verifiable record of all transactions that cannot be altered or deleted by any one entity, ensuring that all data is accurate and immutable. This increased security and transparency are essential for businesses to maintain their reputation and build trust with their customers.

Another benefit of blockchain technology is its ability to automate complex processes, reducing the cost and time required for manual intervention. For instance, smart contracts can automate the execution of a contract's terms, ensuring that all parties comply with the agreed-upon conditions. This automation can streamline business operations, reducing the risk of errors and increasing efficiency. The blockchain technology also allows businesses to track the progress of transactions in real-time, providing greater visibility and control over their operations.

Blockchain technology also enables businesses to create decentralized applications that run on a peer-to-peer network. This feature eliminates the need for intermediaries, reducing the cost and time required for transactions. Decentralized applications are particularly useful for businesses that require a high level of security and transparency, such as voting systems and digital identity management. For example, blockchain technology can be used to create a secure and transparent voting system, where each vote is recorded on a blockchain and cannot be altered or deleted.

Blockchain offers a range of benefits for businesses and companies looking to accelerate, decentralize, and innovate their processes. Its tamper-proof and secure nature, ability to automate complex processes, and support for decentralized applications make it an ideal solution for organizations looking to enhance their efficiency, transparency, and security. As the technology continues to evolve, businesses will have even more opportunities to leverage the benefits of blockchain technology to improve their operations and stay ahead of the competition.

Author

• Nathan Lazo [github]

The metaverse is a universal mixed reality world facilitated by virtual and augmented reality headsets. It has gained significant attention in recent years as companies envision a future where individuals can coexist in immersive virtual settings. The metaverse has the potential to revolutionize industries, transforming the way we collaborate, design, and make decisions.

Mixed Reality: Merging Real and Virtual Worlds

Mixed Reality (MR) is at the core of the metaverse. It refers to the merging of real and virtual worlds, combining Physical Reality (PR), Augmented Reality (AR), Diminished Reality (DR), Augmented Virtuality (AV), and Virtual Reality (VR) ¹.

In Physical Reality (PR), we experience the real world around us. On the other end of the spectrum, Virtual Reality (VR) generates a completely computer-generated reality. Augmented Reality (AR) enhances the real world by overlaying computer-generated information onto real-world objects. Diminished Reality (DR) involves removing or diminishing information from the real world, while Augmented Virtuality (AV) augments virtual environments with real-world objects or people ¹.

The applications of mixed reality are diverse. In industries such as education and training, Virtual Reality (VR) is utilized to simulate real-world scenarios and provide immersive learning experiences. For example, VR can be used to train crane operators to manipulate heavy loads in adverse conditions, offering a safe and controlled environment for skill development ¹.

Understanding the Metaverse

The term "metaverse" originated from Neal Stephenson's science fiction novel "Snow Crash" and refers to a universal mixed reality world beyond our physical reality. It is a comprehensive virtual space that transcends our current limitations ².

Companies like Microsoft, Accenture, and Meta (formerly Facebook) are actively exploring the metaverse's potential. They envision a future where individuals can coexist in virtual settings as avatars or holograms, enabling immersive experiences and collaboration. Microsoft's Mesh for Teams application, for example, aims to provide access to virtual settings through mixed-reality headsets, smartphones, and laptops ².

Digital Twins and the Metaverse

Digital twins play a crucial role in the metaverse. They are real-time digital counterparts of physical objects, processes, or systems. By building metaverses, companies create virtual spaces where employees and consumers can interact through their digital twins ².

Automotive and aerospace companies, for instance, are leveraging digital twins to enhance collaboration and decision-making. Employees can virtually collaborate using their digital twins through various communication channels, including chats, emails, video calls, and face-to-face meetings. This virtual collaboration enables seamless interaction and unlocks new possibilities for remote work and global cooperation ².

Powering the Metaverse: Fundamental Technologies

Building and operating the metaverse require a range of fundamental technologies. These technologies can be categorized into five groups ²:

1. Communications and Computing Infrastructure: The metaverse relies on robust communication networks and powerful computing infrastructure to perform large-scale, compute-intensive tasks and access extensive databases that merge the real and virtual worlds.

2. Management Technology: Effective management technology is necessary to govern virtual spaces, facilitate user access and permissions, and manage content creation and moderation.

3. Artificial Intelligence (AI) and Spatio-Temporal Consistency: Artificial Intelligence (AI) and spatio-temporal consistency are fundamental technologies that underpin the metaverse. AI enables intelligent interactions and simulations within the metaverse, while spatio-temporal consistency ensures consistency and synchronization across the real and virtual worlds.

4. Virtual Reality Object Connection: Establishing 1:1 connections between real-world objects and their virtual counterparts is essential for the metaverse. Technologies like blockchain and identity modeling facilitate secure and seamless integration between the real and virtual worlds.

5. Virtual Reality Space Convergence: The metaverse demands a new medium for interaction. Technologies such as Physical Reality (PR), Augmented Reality (AR), Diminished Reality (DR), Augmented Virtuality (AV), brain-computer interfaces (BCIs), and gaming technologies enable users to engage with the metaverse in immersive and interactive ways.

Applications of the Metaverse in Various Industries

The metaverse holds immense potential for transforming industries across the board. Let's explore some examples:

Automotive Industry

In the automotive industry, the metaverse offers opportunities for optimizing production planning and accelerating design processes. Digital twins and virtual simulations enable automotive design teams to run complex simulations on virtual models, identifying optimizations that may be difficult to detect in the physical environment alone. By leveraging the power of simulation, automotive companies can make better business decisions and improve overall production efficiency ².

Aerospace Industry

Similar to the automotive industry, the aerospace sector can benefit from the metaverse's capabilities. Design teams can utilize digital twins and simulation technologies to enhance design processes and improve product performance. The metaverse enables collaborative design reviews, virtual testing, and optimization, leading to accelerated innovation and increased efficiency in aerospace manufacturing ².

Manufacturing Industry

The manufacturing industry can leverage the metaverse to enhance production efficiency and accuracy. By creating virtual replicas of manufacturing processes, companies can simulate and optimize production lines, identify bottlenecks, and make informed decisions to streamline operations. The metaverse's immersive nature allows manufacturers to visualize and analyze complex systems, leading to cost savings and improved quality ².

Consumer-Packaged Goods Industry

Consumer-packaged goods companies can utilize the metaverse to enhance product development, marketing, and consumer experiences. Virtual simulations and digital twins can aid in product design, testing, and optimization, ensuring better alignment with customer preferences. Additionally, the metaverse enables immersive virtual shopping experiences, allowing consumers to explore and interact with products in a virtual environment ².

Conclusion

The metaverse and mixed reality technologies are poised to revolutionize industries by enabling immersive experiences, enhanced collaboration, and data-driven decision-making. As companies embrace digital twins, simulation technologies, and immersive reality solutions, they unlock new possibilities for innovation and efficiency. The metaverse represents a paradigm shift in how we interact with the digital world, bridging the gap between physical and virtual realities.

In the coming years, the metaverse will continue to evolve, offering limitless opportunities for industries to thrive in a new era of connectivity and innovation.

Author

• Nathan Lazo [github]

References: