Yo conocía la página web porque me sonaba que era “Pesa”, pero lo más natural era buscarlo en internet, y esto es lo que sucedió:

• Si buscabas en Google “autobuses Donosti Vitoria” o “Autobuses San Sebastián Vitoria” el resultado correcto era el séptimo, te salen resultados en PDF donde no puedes comprar el billete online y la web que los vende no lo parece.
• Usando Google Maps o comparadores de autobuses como Omnio te muestran ALSA o RENFE y no disponen más que de 2 o 3 autobuses al día (mientras que en Pesa había 1 cada hora o menos).
• ChatGPT también te informaba de que había varios comparadores que lo vendían como Movalia y Omnio pero llegabas igual que Google Maps, con resultados como ALSA o RENFE y la existencia de otro autobús llamado 0B2332 que debes encontrar (y si buscabas eso llegabas de nuevo al PDF).

De hecho la mayoría de la gente que conozco suele ir con tiempo a la estación (o incluso ir unos días antes a comprarlo a la terminal de venta o a taquilla) porque al no reservarlo online muchos de los autobuses se llenan y te tienes que esperar al siguiente que sale una hora más tarde.

Definir el problema (el primero de muchos)

Este problema se repite una y otra vez con rutas muy populares y usando otros proveedores distintos a Pesa o Lurraldebus, como para ir de Logroño a Bilbao o de Vitoria al Aeropuerto de Loiu (BIO), que es una ruta nueva de otra compañía que usan miles de personas.

Una vez analizado el problema: la idea es cruzar los datos de los distintos proveedores y ofrecer la mejor ruta indicándole la página web donde puede hacer la compra, ese al menos es el MVP¹ que diseñé para Enrique.

Así es como nació la primera versión de Sarebus.

GTFS y cómo funcionan los datos

Enrique recogió todos los datos GTFS del NAP o Punto de Acceso Nacional de datos del transporte de España (National Access Point), que centraliza datos de transporte público bajo el Ministerio de Transporte (autobús, tren, metro, marítimo, aéreo, etc.), es la única fuente centralizada, accesible y estándar que comparten todas las compañías de transporte público.

Los GTFS (General Transit Feed Specification) son un estándar abierto para describir servicios de transporte público con datos interesantes como las paradas, rutas, horarios etc. Fue impulsado originalmente por Google y hoy es el formato más utilizado para intercambiar datos de transporte entre operadores y aplicaciones.

La información ya la teníamos, y la prueba de concepto resultó que funcionaba, pero con otros problemas que ya sabíamos que íbamos a tener:

1. Los nombres son distintos y se duplican, mientras que una compañía llama a la estación de Autobuses de Bilbao “Bilbo Bilbao Intermodal” otra la llama “Estación de autobuses Bilbao Intermodal”.
2. Hay paradas que están juntas pero que están geolocalizadas en latitudes y longitudes distintas, dos paradas (el bus de ida y de vuelta que pasa por el mismo sitio) pero que localizan como si fueran dos paradas distintas.
3. Los datos no están agrupados ni por provincia, ni tampoco en sus propios municipios y ciudades, no podía seleccionar “Bilbao” (todas las paradas), sino “Bilbao Bolueta” o “Bilbao Intermodal” (adjunto imagen justo debajo).
4. Los nombres de los lugares estaban en mayúsculas, minúsculas, en euskera/castellano o directamente la parada la llaman distinta, no siguen ninguna nomenclatura específica, mientras que un proveedor usa todo en mayúsculas “BILBO BILBAO (DEUSTO)” otro lo llama “Deusto (Bilbo / Bilbao)”, y si buscas paradas aleatorias mientras que uno usa la calle completa “Apalategi Kalea 3 Parean, Apalategi” otro de los proveedores usa “Apalategi Eroski” o “Apalategi Gasolinera” que entendemos que es algo más distintivo del lugar.

Trabajando con los datos

Creamos un panel de administración que nos sirviera para trabajar los datos, y Enrique preparó el sistema de tal forma que permitiese no solo buscar las paradas y renombrarlas, sino agruparlas (forman parte de un mismo grupo), unificarlas (son la misma parada), geolocalizarlas visualmente en un mapa para deducir si merece la pena agruparlas o unificarlas, e incluir más información adicional que la que ya teníamos en la base de datos.

Entre otros muchos cambios ahora estamos inmersos en tres muy concretos:

1. Geolocalizamos las paradas mediante coordenadas cercanas y las unificamos, aunque haya una parada claramente de “estación de autobuses”, los datos nos devuelven 5 o 6 paradas distintas, cuando la parada es la misma: estación de autobuses, la herramienta nos permite conectar unas paradas con otras para que entienda que son la misma parada. Gracias a un mapa que hemos generado identificamos rápidamente dónde están.
2. Agrupamos en lo que llamamos City Hubs grandes ciudades y los municipios más importantes, por ejemplo, hay pueblos donde localizamos 6 o 7 paradas distintas, una en la gasolinera, otra en la plaza del pueblo y otra en la estación de autobuses (multiplicado por las 6 o 7 paradas duplicadas) creamos una herramienta que nos permite unificarlas y renombrarlas de forma fácil para que tengan una nomenclatura legible, para poder ir a Eibar seleccionando “Todas las paradas” o si lo deseas localizar la más específica (Gasolinera, Estación, etc.).
3. Hicimos que algunos de estos puntos fueran definibles, aunque llamemos a la parada correctamente “Bilbo / Bilbao (Intermodal)”, debajo en pequeño declaramos que esta parada es una Estación de autobuses (autobus geltokia o bus station). Hacemos eso también con los aeropuertos, universidades etc.

Próximos pasos

Todavía hay muchos frentes que resolver, como la recomendación de rutas con transbordo, o si recomendarle una alternativa (ir andando, en metro, etc.) para cuando seleccione rutas que se queden cortas y no alcancen el destino deseado.

Hay mejoras a muchos niveles sin siquiera meternos en el asunto de la venta de billetes, que no es nuestro principal objetivo, todavía estamos creando una serie de contenidos para posicionar cientos de rutas en Google alimentándola con nuestro propio contenido, queremos que más usuarios lleguen a nuestra web localizando dónde y cómo pueden ir desde el punto A al punto B.

Ya tenemos una base muy importante, si quieres entrar en más detalles sobre los avances del proyecto y las soluciones también hemos abierto un blog en sarebus donde vamos contando novedades del proyecto.

Según el modelo de IA que utilices y qué instrucciones le indicas, la IA puede devolver unos resultados u otros, según las entradas de información que haya obtenido o que tú mismo le hayas proporcionado. Es decir, no son deterministas, si tu le das la misma instrucción dos veces a un modelo de IA u otro, puede devolverte resultados diferentes (a veces incluso al mismo modelo si éste ha sido alimentado por ti con otro contexto y necesidades diferentes).

Hace poco leía que podría resultar interesante que, a medida que la IA se vuelve omnipresente, recordemos cómo construimos los primeros proyectos como si se tratasen de las notas de un laboratorio.

Al final del artículo dejo apuntadas aclaraciones por si algún término te parece marciano o por si quieres profundizar.

Las instrucciones

Monta un blog llamado codecantor en el que vamos a escribir todos los contenidos a mano:

1. Seguir los guidelines del diseño en Figma¹.
2. Usa un generador de páginas estáticas como Jekyll²: HTML en build, sin framework de cliente; quiero escribir los posts con Markdown y HTML.
3. Estilos con Tailwind CSS³, tokens en tailwind.config.js y cumplimiento de estándares WCAG 2.2 AA⁴.
4. Tres vistas: home, índice de artículos (/blog/) y post individual (/blog/title-post) .
5. Todo el contenido en español.
6. Estructura predecible: layouts en _layouts/, fragmentos en _includes/, autores en _data/authors.yml.
7. Deploy en GitHub Pages⁵ al mergear a main vía GitHub Actions.
8. SEO por página: títulos y descripciones únicos, JSON-LD⁶ en posts, RSS y Open Graph⁷ con imágenes generadas en build (Satori + Resvg)⁸.
9. Crea un fichero README.md⁹ con la documentación necesaria para arrancar, editar y publicar el proyecto.
10. Crea un fichero front-end-prompt.md¹⁰ con reglas básicas para cambios de UI: fidelidad al diseño, accesibilidad y convenciones del código, cuando acabes añadiremos más directrices del front.
11. Escribe 3 posts de ejemplo para trabajar en los detalles del diseño.

A medida que iba hablando con la IA me sugería si le podía dar información de los autores etc, haciendo muy fácil construir la base. En poco más de 15 minutos tenía una base sobre lo que trabajar, y tuve que darle 30 directrices de diseño (micro-interacciones, detalles del diseño muy dificiles de apreciar etc), así como incluir el contenido que quería que fuese 100% humano.

Quería un sitio sencillo en el que poder escribir y publicar, y quitando alguna corrección de código que hizo mal (como el contador de minutos de los artículos que lo metió manual y yo quiero que lo haga automático), el resultado para mi fué el deseado.

Es increíble además que me sugería ciertas dudas que yo sabía que tenía que resolver pero que no supe detallar a la hora de darle las primeras instrucciones, pero son detalles que iré resolviendo sobre la marcha.

Ahora sí, podemos centrarnos en construir, documentarlo y en aprender de todo lo que vendrá próximamente.