⏱️ Lectura: 11 min
El 8 de agosto de 2026, el desarrollador Terry Godier redirigió el dominio de su propia aplicación, Dark Hours, hacia un proyecto de otro programador. Una semana antes había lanzado ese sitio (una utilidad para saber qué se puede ver en el cielo esa noche) construido casi enteramente con Claude.
📑 En este artículo
El creador de DarkHours.app, una app de código abierto con el mismo propósito, le respondió en Bluesky mostrándole el parecido: mismo nombre, mismas funciones y hasta un error que su propio proyecto ya había corregido meses atrás.
TL;DR
- Terry Godier lanzó Dark Hours el 1 de agosto de 2026, una utilidad web de astronomía generada casi por completo con Claude.
- El 8 de agosto de 2026, el creador de DarkHours.app le respondió en Bluesky señalando que su app era casi idéntica, incluido el nombre.
- Dark Hours reproducía un bug que DarkHours.app ya había corregido en una versión anterior, la prueba más contundente del parecido.
- Godier redirigió su dominio directamente a DarkHours.app y canceló los planes de lanzar una versión para iOS.
- Publicó una disculpa pública admitiendo que usó IA de forma irresponsable, sin verificar si el proyecto ya existía.
- Dijo que dejará de usar IA para generar aplicaciones web completas, aunque seguirá usándola para debug puntual.
- El caso reabre el debate sobre el ‘vibe coding’: construir apps con IA sin revisar si el resultado copia trabajo ajeno.
Qué pasó
Godier construyó Dark Hours como un experimento personal: una página que le dice al usuario qué planetas, constelaciones o fenómenos son visibles esa noche según su ubicación. Lo armó apoyándose en Claude para gran parte del código y lo publicó a comienzos de agosto de 2026.
Un desarrollador que había creado antes una herramienta con el mismo objetivo, DarkHours.app, respondió a un comentario de Godier en Bluesky. Le mostró capturas y un enlace directo al hilo donde comparaba ambos proyectos: la coincidencia no era solo conceptual, sino de nombre, de funciones y de estructura.
Según relató Godier en su blog, en menos de una hora confirmó que el parecido no era casualidad. Decidió redirigir el dominio de Dark Hours directamente a DarkHours.app y cancelar cualquier plan de lanzar una app nativa para iOS del mismo proyecto.
El intercambio completo quedó documentado en un hilo público de Bluesky, algo poco frecuente en este tipo de disputas, que suelen resolverse en privado o directamente ignorarse. Godier optó por la vía contraria: contar el proceso completo, con nombres y capturas, en vez de simplemente retirar el sitio en silencio.
sequenceDiagram
participant G as Terry Godier
participant D as Creador de DarkHours.app
participant B as Bluesky
G->>B: publica Dark Hours, creado con Claude
D->>G: responde señalando el parecido
Note over G,D: Godier revisa el código y confirma la similitud, incluido un bug ya corregido
G->>B: anuncia la redirección a DarkHours.app
Contexto: qué es el ‘vibe coding’ y por qué este caso es distinto
‘Vibe coding’ es el término que se popularizó para describir la práctica de construir software describiéndole el resultado deseado a un modelo de lenguaje, sin revisar línea por línea el código que produce. Funciona bien para prototipos rápidos, pero tiene un punto ciego conocido: el desarrollador confía en que el resultado es original sin verificarlo.
El caso de Godier no es solo un ejemplo de código con bugs generado por IA. Es un ejemplo de un modelo que, al resolver un problema acotado (mostrar qué hay visible en el cielo nocturno según ubicación y hora), llegó a una solución estructuralmente casi idéntica a un proyecto de código abierto existente, incluyendo el nombre del producto.
El problema que resuelve Dark Hours (cruzar ubicación, hora y catálogo astronómico para decir qué es visible) tiene pocas formas razonables de resolverse desde cero. Eso hace más difícil separar una coincidencia de diseño de una copia directa, salvo por detalles como bugs compartidos, que no tienen ninguna razón lógica para repetirse entre dos implementaciones independientes.
Godier fue explícito en su disculpa publicada en el blog:
📌 Nota: “I was careless in relying on AI to generate the project without doing the work to understand whether it closely resembled an existing project. That’s on me, and I am responsible for what I published.”
Detalles técnicos: la señal que delató el parecido con DarkHours.app
La prueba más contundente no fue el nombre ni el diseño, sino un bug. Dark Hours reproducía un error que el creador de DarkHours.app ya había identificado y corregido en una versión anterior de su propio proyecto. Dos implementaciones independientes rara vez comparten exactamente el mismo bug histórico: si lo comparten, casi siempre es porque una deriva de la otra, directa o indirectamente.
Esto conecta con un problema ya documentado en herramientas de generación de código con IA: los modelos entrenados con grandes volúmenes de repositorios públicos pueden memorizar fragmentos de proyectos específicos y reproducirlos casi textualmente ante un prompt suficientemente similar, en lugar de generar una solución genuinamente nueva. Godier no supo decir con certeza cuál fue el mecanismo exacto, y en su blog aclara que nunca había visto DarkHours.app antes de la respuesta en Bluesky.
Este tipo de memorización no es exclusivo de Claude: es un riesgo conocido de cualquier modelo entrenado sobre código público, y es parte de por qué herramientas como GitHub Copilot incluyen filtros para detectar coincidencias literales con repositorios existentes antes de sugerir una respuesta. Lo distinto del caso Dark Hours es que la coincidencia no fue detectada por un filtro automático, sino por el propio autor del proyecto original al usar la app.
| Proyecto | Origen | Licencia | Resultado tras el caso |
|---|---|---|---|
| DarkHours.app | Desarrollo manual, código abierto | Abierta (según el propio proyecto) | Recibe el tráfico redirigido y el crédito público de Godier |
| Dark Hours (Godier) | Generado casi en su totalidad con Claude | No especificada | Dominio redirigido, cancelado el desarrollo de una app iOS |
Cómo verificar antes de publicar un proyecto generado con IA
El propio Godier reconoce que el error no fue usar Claude, sino no dedicar diez minutos a comprobar si el resultado ya existía. Antes de publicar un proyecto construido con asistencia de IA, hay pasos concretos y rápidos que cualquier desarrollador puede correr desde la terminal.
Buscar por nombre y funcionalidad en GitHub usando su API pública de búsqueda de repositorios:
curl -s "https://api.github.com/search/repositories?q=dark+hours+astronomy+in:name,description&sort=stars" \
| jq '.items[] | {repo: .full_name, stars: .stargazers_count, url: .html_url}'Este comando devuelve los repositorios existentes que coinciden con el nombre y la descripción del proyecto, ordenados por estrellas. Si aparece algo con una idea casi idéntica, es momento de leer su código antes de publicar el propio.
Si el proyecto tiene equivalente como paquete, conviene revisar también el registro correspondiente antes de elegir nombre. En Windows, macOS y Linux el comando es el mismo, ya que corre sobre el gestor de paquetes, no sobre el sistema operativo:
# npm (Windows / macOS / Linux)
npm search dark-hours-app
# PyPI
pip index versions dark-hours-app
# crates.io
cargo search dark-hours-appNinguno de estos pasos toma más de un par de minutos, y hubiera bastado para que Godier encontrara DarkHours.app antes de lanzar Dark Hours, no después.
💡 Tip: buscá el nombre exacto de tu proyecto entre comillas en un buscador antes de registrarlo, incluso si sale de una sesión de vibe coding de una tarde. Cuesta menos que redirigir un dominio después.
Impacto y reacciones
La reacción en Bluesky fue mayormente de respaldo hacia la transparencia de Godier. Reconocer públicamente el error, dar crédito explícito al proyecto original y redirigir el dominio en menos de un día es un desenlace poco común en discusiones sobre apps clonadas con IA, donde lo habitual es la defensa o el silencio.
Godier fue puntual sobre los límites que se impone de ahora en adelante: no volverá a usar IA para generar proyectos web completos. En iOS, donde dice tener más control sobre lo que publica, seguirá usando IA para hacer preguntas y depurar errores puntuales, pero no para generar aplicaciones enteras.
El caso también expone un límite práctico de los agentes de código actuales: pueden producir una solución funcional para un problema acotado sin que el desarrollador tenga forma sencilla de saber si esa solución ya existe en otro lugar, con otro nombre, con otra licencia.
El caso llega en un momento donde cada vez más desarrolladores individuales publican productos completos generados en un fin de semana con asistentes de IA, sin el proceso de revisión que tendría un equipo más grande. La responsabilidad legal y reputacional de lo que se publica, sin embargo, sigue siendo del desarrollador que lo firma, no del modelo que lo generó.
Qué sigue
El dominio de Dark Hours ya redirige a DarkHours.app. Godier confirmó que no habrá una app de iOS derivada del proyecto original, la única plataforma donde tenía planes concretos de expansión.
Para el resto de la comunidad de desarrolladores que usa asistentes como Claude para construir productos completos, el caso deja una pregunta abierta: si un modelo puede reproducir un bug específico de un proyecto que el usuario nunca vio, ¿qué garantías reales existen de que el código generado sea original antes de publicarlo?
💭 Clave: la mejor señal para detectar una copia no es el diseño ni el nombre, es un detalle interno que solo coincide si hay una relación directa entre ambos códigos, como un bug ya corregido en el original.
📖 Resumen en Telegram: Ver resumen
Antes de publicar tu próximo proyecto vibe-coded, corré la búsqueda en la API de GitHub de arriba con el nombre que pensás usar y date esos dos minutos.
Preguntas frecuentes
¿Qué era Dark Hours?
Una utilidad web creada por Terry Godier con ayuda de Claude que le indicaba al usuario qué objetos astronómicos eran visibles esa noche desde su ubicación.
¿Qué es DarkHours.app?
Un proyecto de código abierto con el mismo propósito, creado antes por otro desarrollador, que Dark Hours terminó reproduciendo casi por completo, incluido un bug ya corregido.
¿Godier violó alguna licencia al publicar Dark Hours?
En su blog no menciona una denuncia formal por licencia; el desenlace fue voluntario: reconoció el parecido, dio crédito público al proyecto original y redirigió su dominio sin que mediara un reclamo legal.
¿Godier va a seguir usando IA para programar?
Sí, pero con límites: dice que no volverá a usar IA para generar proyectos web completos, aunque seguirá usándola para depurar errores puntuales, incluso en su trabajo de iOS.
¿Qué es el ‘vibe coding’?
Es construir software describiéndole el resultado deseado a un modelo de lenguaje sin revisar en profundidad el código que produce, lo que facilita prototipos rápidos pero dificulta detectar si el resultado copia un proyecto existente.
¿Cómo puedo evitar publicar algo que ya existe?
Buscar el nombre y la funcionalidad del proyecto en GitHub, en el registro de paquetes correspondiente (npm, PyPI, crates.io) y en un buscador general antes de publicar, no después.
Referencias
- Blog de Terry Godier: el post original donde relata el caso y se disculpa públicamente.
- Bluesky: la red social donde el creador de DarkHours.app le señaló el parecido a Godier.
- GitHub: plataforma de referencia para buscar proyectos existentes antes de publicar uno nuevo.
- Claude (Anthropic): el asistente de IA usado para construir la primera versión de Dark Hours.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Jeremy Thomas en Unsplash
0 Comentarios