Introducción
Hay una frase que últimamente se repite demasiado en tecnología: “lo hicimos desde cero”. Suena épico, inspira, vende… pero también abre una pregunta incómoda: ¿desde cero de verdad, o desde cero “con un poco de ayuda” (o con muchísima)?
En estos días se volvió viral una historia que mezcla todo lo que estamos viviendo en 2026: agentes de IA, proyectos gigantescos generados en poco tiempo, y una conversación que se está poniendo cada vez más tensa dentro del software libre. Todo arranca con un experimento asociado a Cursor: un agente corriendo durante una semana que produjo un navegador experimental llamado FastRender, con millones de líneas distribuidas en miles de archivos. La afirmación más repetida fue que el motor de renderizado estaba “hecho desde cero” en Rust, y que más o menos funcionaba.
Hasta ahí, cualquiera diría: “esto es un salto histórico”. Pero cuando devs empezaron a mirar el repo con lupa, surgió la polémica real: muchas partes críticas se apoyaban en dependencias existentes (parsers, selectores, SVG, layout, JS engine). Y ese matiz lo cambia todo, no porque quite mérito, sino porque nos obliga a hablar de algo más importante: la confianza.
Y esa misma discusión conecta con otro fenómeno que ya está afectando proyectos open source: la llegada masiva de contribuciones “aparentemente correctas”, pero sin contexto, sin criterio y sin seguimiento, hechas con IA. El resultado: mantenedores agotados, repos que se cierran a contribuciones externas y un cambio cultural que nadie quería… pero que ya empezó.
Tabla de contenido
FastRender: el experimento que emocionó a todos (y luego encendió el debate)
Para que estemos en la misma página: FastRender es un proyecto open source de motor de renderizado en Rust que busca demostrar hasta dónde puede llegar la programación asistida por agentes en paralelo. Puedes ver el repositorio aquí: FastRender (repo oficial).
Lo interesante no es solo el número de líneas. Es la idea: “si una IA puede coordinarse en un código enorme, ¿qué pasa con tareas que antes parecían imposibles para una persona sola?” En el repo se describe como un motor capaz de parsear HTML/CSS, computar estilos, hacer layout, pintar, y ejecutar JavaScript usando un motor embebido.
Y aquí aparece el punto que generó la polémica: en redes se popularizó la frase “motor de renderizado desde cero”, como si se hubiera reimplementado todo sin apoyarse en piezas externas. Pero varios análisis de la comunidad señalaron que una parte importante del trabajo “difícil” estaba delegada en librerías y componentes existentes.
“Desde cero” vs “con dependencias”: el matiz que define la conversación
En desarrollo, usar dependencias no es pecado. De hecho, es lo normal. Nadie compila un sistema operativo escribiendo desde cero la gestión de fuentes, el parser de todo, el motor de imágenes, el stack completo de red y la VM de JS.
Pero hay una diferencia enorme entre estas dos frases:
🔶 “Construimos un motor de renderizado desde cero.”
🔶 “Construimos un navegador experimental integrando librerías maduras y generando una capa grande de glue code con agentes.”
La primera sugiere reinventar el core.
La segunda sugiere ingeniería de integración a escala + experimentación con agentes.
Ambas pueden ser impresionantes. Pero solo una es transparente.
Y aquí está el riesgo: cuando los titulares exageran, la comunidad hace lo que siempre hace… revisa el código, encuentra los matices, y la conversación pasa de “qué increíble” a “por qué lo contaron así”.
Con IA esto se amplifica, porque hay otra realidad: la IA tiende a producir muchísimo “código puente” (wrappers, adaptadores, integraciones) que infla las métricas sin necesariamente equivaler a “dificultad resuelta”. Eso no significa que no sirva. Significa que medir valor por cantidad de líneas es cada vez menos útil.
Si algo nos deja FastRender como lección es esto:
En la era de agentes, el valor no se prueba con volumen; se prueba con claridad, reproducibilidad y trazabilidad.
El efecto colateral: “PRs de IA” y el cansancio de los mantenedores
Y ahora viene lo más importante (y lo más práctico para tu comunidad).
Mientras discutimos si un proyecto es “desde cero” o “desde 0.5”, está pasando algo real en open source: mantenedores recibiendo toneladas de Pull Requests hechos con IA.
El patrón se repite:
- La PR “parece correcta” a primera vista.
- Compila. Incluso pasa algunas pruebas.
- Pero… no entiende el contexto del repo.
- No sigue las guías del proyecto.
- Cambia cosas que nadie pidió.
- Mete refactors innecesarios.
- Y, peor: quien la envía muchas veces no da seguimiento.
Ese último punto es devastador. Porque mantener open source no es “recibir código”; es recibir responsabilidad compartida.
Un caso muy sonado fue el de tldraw, que anunció una política temporal para cerrar automáticamente PRs de contribuyentes externos debido al incremento de contribuciones de baja calidad generadas con IA. Si quieres leer el argumento completo del autor, está aquí: “Stay away from my trash!” (tldraw).
No es que odien a la IA. Es que odian el costo humano de revisar basura. Y eso conecta con un sentimiento que ya se ve en más proyectos: “si escribir código es lo fácil, ¿por qué querría que otra persona lo escriba sin entenderlo?”
Además, no es solo tldraw. Se está volviendo conversación común que varios proyectos están ajustando reglas: contribuciones con IA solo si son sobre issues aceptados, obligación de declarar uso de IA, o directamente cierre a PRs “drive-by”. Una lectura buena para entender este clima es: We’re Losing Open Contribution (Continue.dev).
La traducción al mundo real es dura:
La IA está bajando el costo de producir código, pero subiendo el costo de revisarlo
El problema no es la IA: es la falta de contexto (y de oficio)
Aquí hay una trampa mental: creer que el problema es “IA mala”. No. El problema suele ser:
- Gente usando IA sin entender el repo
- PRs grandes y ruidosas
- Cambios no solicitados
- Falta de comunicación
- Cero ownership
Los mantenedores no están rechazando ayuda. Están rechazando trabajo que les crea más trabajo.
Y esto se nota mucho cuando ves PRs que hacen cosas como:
- “ya que estaba, cambié esta estructura”
- “aproveché y reorganicé carpetas”
- “refactoricé todo el archivo”
- “actualicé dependencias” (sin razón)
- “cambié naming” (sin necesidad)
Ese “exceso de iniciativa” sin contexto es un olor típico de IA mal dirigida.
Buenas prácticas: cómo usar IA sin convertirte en “AI slop contributor”
Si tu comunidad de ClickPanda desarrolla, contribuye a open source o mantiene repos internos, esto te sirve ya.
Regla 1: PR pequeña, propósito claro
Si la PR no se puede explicar en una frase, es demasiado grande.
✅ Bien: “Corrige null pointer en X”
❌ Mal: “Mejoras generales y limpieza de código”
Regla 2: nada de cambios colaterales
Si estás arreglando un bug, arregla el bug. No aproveches para “ordenar todo”.
Regla 3: explica el contexto como humano
Incluye:
- por qué ocurre
- cómo lo reproduciste
- qué cambiaste
- cómo lo validaste
Regla 4: si usaste IA, dilo
No para castigarte, sino para ayudar al revisor a entender el riesgo: ¿esto está verificado o solo “suena bien”?
Regla 5: tests > palabras
Si tu cambio no tiene test y el proyecto lo permite, estás pidiendo fe. Y la fe en open source se está acabando.
Regla 6: sé dueño del cambio (follow-up)
Si el mantenedor te deja comentarios, responde, itera, corrige. Si vas a enviar “y desaparecer”, mejor no envíes.
¿Qué tiene que ver ClickPanda con esto? La parte práctica que nadie te cuenta
Todo esto suena filosófico… hasta que lo vives en producción.
La calidad no depende solo de “quién escribe el código”, depende de:
✅ entornos de staging bien montados
✅ pipelines de CI estables
✅ pruebas automatizadas
✅ observabilidad mínima
✅ y la facilidad de replicar bugs
Ahí es donde ClickPanda puede ayudarte de manera muy concreta:
- Si estás empezando o necesitas un staging rápido para tu app: Hosting SSD en ClickPanda
- Si necesitas administrar varios sitios/subdominios con facilidad: Hosting cPanel
- Si ya estás en nivel “proyecto serio” con runners, Docker, pruebas E2E y control total: VPS SSD
- Si aún no tienes tu identidad digital bien armada: Dominios en ClickPanda
La diferencia entre un equipo que usa IA “bien” y otro que sufre es esta:
El primero tiene un sistema que detecta errores rápido (CI + staging + tests). El segundo confía en que “se ve bien”.
Comparativa útil (no de marcas, sino de enfoques)
Enfoque | Ventaja | Riesgo |
“IA escribe todo, yo solo acepto” | Rapidez | PRs ruidosas, cambios sin sentido, deuda técnica |
“IA como copiloto + PR pequeñas + tests” | Mantiene calidad y velocidad | Requiere disciplina |
“Sin IA, todo manual” | Control total | Pierdes competitividad en velocidad |
“IA para generar + CI fuerte para validar” | Escala sin perder confianza | Necesitas infraestructura estable |
Si estás construyendo un producto, una plataforma o un repo que quieres mantener sano mientras usas IA, lo más inteligente es combinar velocidad con un entorno estable:
- Monta tu staging en Hosting SSD ClickPanda y valida cambios rápido.
- Si necesitas control real para pipelines, contenedores y pruebas: sube a VPS SSD ClickPanda.
- Y si todavía no tienes tu dominio listo: arranca hoy en Dominios ClickPanda.
Conclusión
FastRender y toda esta polémica sirven para aterrizar una verdad: la IA ya puede producir software a una escala que antes era impensable. Pero eso no elimina lo más valioso del desarrollo: el criterio, el contexto y la responsabilidad.
Cuando alguien dice “desde cero” y no es preciso, la confianza se resiente. Y cuando miles de PRs llegan “bien formateadas pero vacías de entendimiento”, el open source se protege cerrando puertas.
Tu ventaja no está en “usar IA” (eso ya lo hará todo el mundo). Tu ventaja está en usar IA con oficio, con reglas claras, PR pequeñas, tests, seguimiento y entornos donde validar rápido.
Si haces eso, la IA no te llena el repo de ruido: te multiplica. Y ahí sí, de verdad, cambia el juego.
