Marketing Online

Joan Boluda

Todo lo que siempre has querido saber y nunca te has atrevido a preguntar sobre Marketing Online.

  1. 1d ago

    3150. Píldoras de inteligencia artificial: Bases de datos de desarrollo y producción

    Hoy os cuento cómo separo las bases de datos de desarrollo y producción para probar cambios sin poner en peligro los datos reales. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Hoy finaliza el curso de storytelling en crowdfunding. Esta mañana veremos las victorias y esta tarde los aprendizajes que cierran la historia. ¡A por él! Ahora sí, vamos al lío. Hoy es viernes y durante la edición de verano dejaré la publicación en abierto, pero todos los suscriptores encontraréis una skill relacionada con la píldora de hoy en la zona de descargas del campus. Cuando desarrolláis una aplicación, los archivos resultan fáciles de entender. Tenéis una copia en el entorno de desarrollo, realizáis los cambios, los probáis y finalmente desplegáis la versión nueva en producción. La base de datos plantea una decisión más delicada. ¿Debe el entorno de desarrollo conectarse directamente a la base de datos real o debe utilizar una base separada? Durante un tiempo utilicé una única base de datos por comodidad. Así, al abrir la aplicación local veía los usuarios, contenidos y datos más recientes. No necesitaba mantener dos copias ni preparar información de prueba. El problema aparece en cuanto el desarrollo modifica la estructura o escribe datos. Imaginad que una columna llamada nombre pasa a llamarse username. El código local ya conoce el cambio, pero el código publicado todavía busca la columna anterior. Como ambos entornos comparten la base de datos, producción deja de funcionar antes de que hayáis desplegado el código nuevo. Y ese es el caso amable. Una prueba puede borrar registros, ejecutar una migración incorrecta o alterar información de clientes reales. La comodidad deja de compensar rápidamente. Por eso recomiendo tener una base de datos para desarrollo y otra para producción. Además, conviene utilizar la misma tecnología en ambos lados. Si producción trabaja con PostgreSQL o Supabase, el entorno de desarrollo debería parecerse todo lo posible. Utilizar SQLite porque resulta sencillo puede ocultar diferencias que solo aparecerán al desplegar. Para disponer de datos realistas podéis generar periódicamente una copia o dump de producción hacia desarrollo. Pero hacedlo siempre en una sola dirección, conservad una copia de seguridad y anonimizad los datos personales o sensibles cuando no sean imprescindibles para la prueba. Los cambios de estructura deberían quedar definidos mediante migraciones repetibles. Primero se prueban en desarrollo y después se aplican de manera controlada en producción. Así el código y la base de datos evolucionan juntos y podéis saber exactamente qué transformación se ha realizado. También conviene recordar que Git protege el código, no el contenido vivo de una base de datos. Para los datos necesitáis copias de seguridad, snapshots, migraciones comprobadas y un procedimiento real de recuperación. Para facilitar este proceso he preparado una skill que explica al agente cómo separar ambos entornos, utilizar la misma tecnología y actualizar la copia de desarrollo sin poner en riesgo producción. Los suscriptores podéis descargarla desde la zona de descargas. Entregad el ZIP a vuestro agente, pedidle que lo revise y aplique las instrucciones al proyecto. Antes de ejecutar nada, comprobad qué datos copiará, dónde los guardará y cómo protegerá la información sensible. Espero que os sea útil para trabajar con datos realistas sin convertir cada prueba local en una operación sobre clientes reales. Separar desarrollo y producción requiere un poco más de preparación, pero evita sustos muchísimo más caros. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Es viernes, o sea que ya sabéis lo que toca: descansad, relajaros y recargad pilas, aunque estemos en pleno agosto. Regresamos el lunes con más y mejor: la edición de verano del podcast de Marketing Online. Como siempre, a las 07:07. Hasta entonces... ¡Muy buen fin de semana!

  2. 2d ago

    3149. Píldoras de inteligencia artificial: /project y /clear

    Hoy os presento dos comandos muy sencillos para moveros entre proyectos y empezar una conversación con el contexto completamente limpio. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de storytelling en crowdfunding. Esta mañana veremos la fase de superación y esta tarde cómo incorporar los fracasos a la historia. ¡A por él! Ahora sí, vamos al lío. El primer comando es /project. En la app de Codex permite escoger el proyecto en el que queréis iniciar una nueva conversación. Esto resulta especialmente útil cuando tenéis muchos proyectos en la barra lateral. En mi caso puedo acumular varias decenas y, como los ordeno por uso reciente, no siempre encuentro rápidamente el que necesito. Al ejecutar /project aparece el selector. Empezáis a escribir una parte del nombre, la lista se filtra y podéis escoger el resultado con el teclado. Así salto directamente a Boluda.com, Sara, PrestoCast o cualquier otro proyecto sin recorrer toda la barra lateral. También podéis iniciar una conversación sin proyecto cuando solo queréis comentar una idea que no necesita acceder a archivos ni conservar contexto compartido. La clave es utilizar un proyecto cuando el trabajo depende de una carpeta, unas instrucciones o unas fuentes comunes, y prescindir de él cuando se trata de una consulta aislada. El segundo comando es /clear. Su disponibilidad y comportamiento exactos dependen del agente y de la superficie. En los entornos donde está disponible, sirve para descartar el contexto actual y empezar una conversación limpia. La CLI de Codex, por ejemplo, limpia la interfaz y crea un chat nuevo. Aquí conviene tener cuidado, porque no estamos hablando de compactar. /compact conserva un resumen con las decisiones importantes. /clear, en cambio, parte de cero. Después no podéis escribir «como íbamos diciendo», porque el nuevo contexto ya no sabe a qué os referís. Puede ser útil cuando habéis dedicado una conversación larga a explorar alternativas y finalmente ya tenéis clarísimo qué queréis construir. Antes de limpiar, guardad la decisión en un documento o copiad el encargo final. Después iniciáis el contexto nuevo y entregáis únicamente las instrucciones necesarias para ejecutar. Es como el dispositivo de Men in Black: vosotros recordáis lo que habéis decidido, pero el agente empieza sin toda la charla anterior. Esto puede ahorrar contexto y evita que pruebas, dudas descartadas o caminos abandonados condicionen la implementación. No lo utilicéis si todavía necesitáis información de la conversación actual. Y tampoco lo confundáis con archivar o borrar permanentemente un chat guardado; cada producto puede gestionar el historial de una manera distinta. Así pues, /project os ayuda a llegar rápidamente al espacio correcto y /clear permite empezar de cero cuando ya no necesitáis el contexto anterior. Dos instrucciones muy básicas, pero tremendamente prácticas. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana viernes con más píldoras de inteligencia artificial. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

  3. 3d ago

    3148. Píldoras de inteligencia artificial: Permisos

    Hoy os cuento cómo ajusto los permisos de Codex para que pueda avanzar con autonomía sin tocar producción alegremente. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de storytelling en crowdfunding. Esta mañana veremos el papel de los colegas y amigos, y esta tarde los problemas que pueden aparecer al construir la historia de una campaña. ¡A por él! Ahora sí, vamos al lío. Un agente no se limita a contestar preguntas. Puede leer y modificar archivos, ejecutar comandos, conectarse a servicios y realizar cambios reales. Por eso es importante decidir qué autonomía necesita en cada momento. Codex separa esta cuestión en dos partes. Las aprobaciones determinan cuándo debe detenerse para pediros permiso. El sandbox establece qué archivos, directorios y recursos puede alcanzar aunque quiera continuar. En la app podéis encontrar perfiles como Ask for approval, Approve for me, Full access y perfiles personalizados, dependiendo de vuestra configuración. En la CLI podéis abrir el selector mediante /permissions. Cuando empecé, utilizaba siempre la opción más restrictiva. El problema es que el agente se detenía continuamente para preguntar si podía leer un archivo, modificar otro o conectarse a un servicio. Me marchaba pensando que la tarea estaba avanzando y, al regresar, descubría que llevaba una hora esperando la primera confirmación. Además, cuando aparece el mismo aviso treinta veces, acabáis aceptándolo por inercia sin leerlo. Y eso tampoco aporta demasiada seguridad. Actualmente prefiero dar autonomía suficiente dentro de proyectos que conozco y controlo, pero mantengo una frontera mucho más estricta alrededor de producción. Si una operación va a desplegar, modificar datos reales o afectar a usuarios, quiero revisarla expresamente. Esto no significa que todo el mundo deba activar Full access. Ese modo elimina las restricciones del sandbox y debe reservarse para entornos en los que entendéis perfectamente el alcance. Para la mayoría de trabajos, el acceso de escritura limitado al proyecto ofrece un equilibrio mucho más razonable. Si necesitáis un comportamiento específico, podéis definir perfiles en config.toml y añadir reglas que permitan, pregunten o prohíban determinados prefijos de comandos. Por ejemplo, podéis autorizar el trabajo local y exigir confirmación para las órdenes utilizadas en un despliegue. También podéis reforzar esa frontera mediante instrucciones permanentes y hooks, como vimos la semana pasada. Cada capa cumple una función distinta: los permisos limitan, las reglas controlan comandos concretos y las instrucciones recuerdan cómo queréis trabajar. Git ayuda a deshacer cambios en el código, pero no convierte producción en un lugar seguro para experimentar. Una web rota durante diez minutos sigue estando rota para todos sus usuarios, y una operación sobre la base de datos puede requerir algo más que volver a un commit anterior. Mi recomendación es que escojáis el perfil más estrecho que permita completar la tarea sin interrupciones absurdas. Dad libertad dentro del entorno de desarrollo y mantened producción detrás de una revisión consciente. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana jueves con más marketing online veraniego. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

  4. 4d ago

    3147. Píldoras de inteligencia artificial: Side chats

    Hoy os hablo de los side chats, conversaciones temporales para resolver una duda sin interrumpir ni ensuciar la tarea principal. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de storytelling en crowdfunding. Esta mañana veremos al enemigo y esta tarde los retos a los que se enfrenta el protagonista de la campaña. ¡A por él! Ahora sí, vamos al lío. Cuando trabajáis durante mucho tiempo con un agente, es fácil que aparezca una duda secundaria. Quizá estáis planificando una migración y Codex os pregunta si queréis organizar el contenido mediante categorías o mediante un tipo de contenido personalizado. Si no sabéis qué significa una de las opciones, podéis empezar a preguntarlo dentro de la misma tarea. Pero esa explicación, sus alternativas y todos los ejemplos pasarán a formar parte de la conversación principal, aunque solo necesitabais aclarar un concepto durante unos minutos. Antes, cuando me ocurría esto, abría ChatGPT en otra ventana, investigaba la duda y después regresaba a Codex con la decisión tomada. Así evitaba llenar la tarea principal de información que ya no sería necesaria. Ahora puedo hacerlo directamente mediante /side. En la app de Codex abre una conversación temporal al lado de la principal. En otras superficies también podéis encontrar /btw, de by the way, con la misma idea: hacer una consulta puntual sin interrumpir el hilo de trabajo. El chat lateral parte del contexto en el que estabais trabajando, de modo que no tenéis que volver a explicar todo el proyecto. Podéis preguntarle qué es un CPT, qué diferencia existe entre dos tecnologías o qué consecuencias tendría escoger una alternativa. Cuando la duda queda resuelta, cerráis la conversación lateral y regresáis a la tarea principal. Si solo necesitabais decidir entre dos opciones, basta con comunicar la elección. Si la investigación ha producido información importante, podéis pedir un resumen, copiarlo y añadirlo al hilo principal. La clave es que estos chats son temporales. No están pensados para guardar decisiones que necesitaréis consultar dentro de tres meses. Si una conclusión debe permanecer en el proyecto, trasladadla a la tarea principal o a la documentación correspondiente antes de cerrar. Esto ofrece dos ventajas. La conversación principal conserva un contexto más limpio y, además, no acabáis con veinte tareas permanentes creadas para preguntas que solo tenían sentido durante cinco minutos. Tampoco hace falta abrir un side chat para cualquier comentario. Utilizadlo cuando una explicación pueda crecer, cuando necesitéis comparar alternativas o cuando queráis explorar una idea sin desviar el trabajo que ya estaba en marcha. Así pues, la próxima vez que aparezca una duda secundaria, probad /side. Investigad lo que necesitéis, trasladad únicamente la conclusión relevante y continuad con vuestra vida. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana miércoles con más píldoras de inteligencia artificial. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

  5. 5d ago

    3146. Píldoras de inteligencia artificial: Batch API

    Hoy os cuento cómo utilizar la Batch API para ejecutar trabajos que no son urgentes con un 50% de descuento en el coste de los tokens. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Hoy empieza el curso de storytelling en crowdfunding. Esta mañana veremos el nacimiento de la historia y esta tarde la motivación que impulsa al protagonista. ¡A por él! Ahora sí, vamos al lío. Hace unos meses estaba curioseando por el panel de OpenAI cuando encontré un apartado llamado Batches. Empecé a leer la documentación y descubrí una opción estupenda para todos aquellos procesos que pueden esperar un poco. Normalmente, cuando una aplicación llama a un modelo mediante API, envía una petición y espera la respuesta. Esto tiene sentido cuando estáis hablando con un usuario o necesitáis el resultado inmediatamente. Pero hay otros trabajos que no tienen ninguna urgencia. Por ejemplo, quizá queráis resumir miles de textos, clasificar una base documental, generar embeddings, preparar muchas imágenes o poner en cola varios vídeos. En esos casos podéis agrupar las peticiones y enviarlas a la Batch API para que se procesen de forma asíncrona. La mecánica consiste en preparar un archivo JSONL con todas las solicitudes, subirlo y crear el lote. OpenAI dispone entonces de una ventana de hasta 24 horas para completarlo. Cuando termina, descargáis otro archivo con los resultados y podéis relacionar cada respuesta con su petición mediante un identificador propio. ¿Qué ganáis a cambio de no exigir una respuesta inmediata? Un descuento del 50% respecto a las llamadas síncronas, límites separados y mucho más margen para procesar grandes cantidades de solicitudes. Aquí conviene hacer una precisión importante. La Batch API no reduce el número de tokens utilizados. Reduce a la mitad su precio dentro de la API. Tampoco aumenta los límites incluidos en vuestra suscripción de ChatGPT o Codex, porque trabaja con una clave de API y una facturación separada. No es un comando mágico que convierta cualquier tarea del ordenador en un lote. Solo sirve para los endpoints compatibles. Actualmente permite trabajar, entre otros, con Responses, Chat Completions, embeddings, moderación, generación y edición de imágenes, y generación de vídeo. Podéis consultar la lista actualizada en la documentación oficial de la Batch API. Lo más cómodo es pedirle a vuestro agente que prepare la integración. Primero probad una única solicitud de manera normal. Cuando sepáis que el formato y el resultado son correctos, pedidle que construya el archivo por lotes, lo envíe, consulte su estado y procese el resultado cuando esté disponible. OpenAI garantiza una ventana de hasta 24 horas, aunque en muchos casos el trabajo termina antes. No debéis depender de que esté listo en cinco minutos, porque precisamente el descuento existe a cambio de aceptar ese procesamiento asíncrono. Así pues, reservad esta opción para procesos grandes que no requieran una respuesta inmediata. Si tenéis miles de resúmenes, clasificaciones, imágenes o tareas similares pendientes, la diferencia de coste puede ser considerable. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana martes con otra píldora de inteligencia artificial. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos lunes, y mejor semana!

  6. Aug 14

    3145. Píldoras de inteligencia artificial: Al grano

    Hoy regalo a los suscriptores una skill para conseguir respuestas mucho más breves, directas y económicas en tokens. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Hoy finaliza el curso de Devbox con VPS. Esta mañana veremos cómo cambiar de dispositivo al vuelo y esta tarde cómo preparar copias de seguridad, snapshots y una recuperación real cuando algo se tuerce. ¡A por él! Ahora sí, vamos al lío. Hoy es viernes y durante la edición de verano dejaré la publicación de hoy en abierto, pero todos los suscriptores encontraréis la skill de hoy en la zona de descargas del campus. Cuando habláis con un modelo de inteligencia artificial, muchas veces agradecéis un tono cercano y conversacional. Pero hay otras ocasiones en las que ya sabéis exactamente qué queréis y la respuesta llega rodeada de introducciones, felicitaciones, contexto y explicaciones que no habíais pedido. Acabáis escaneando ocho párrafos para encontrar una instrucción que cabía en dos líneas. Es como aquellos artículos posicionados en Google que empezaban explicando la historia del Macintosh cuando vosotros solo queríais conocer un atajo de teclado. Esta verborrea no solamente consume tiempo. También consume tokens. Cada frase innecesaria ocupa contexto, cuenta dentro de los límites y vuelve a viajar con la conversación en las interacciones siguientes. Codex permite escoger una personalidad más amistosa o más pragmática desde la configuración o mediante /personality. La opción pragmática ya ayuda a reducir rodeos, pero en algunas tareas yo quería ir todavía más lejos. Esta skill elimina felicitaciones, introducciones, repeticiones y explicaciones accesorias. El agente entrega directamente el resultado, utilizando listas o frases breves cuando son suficientes. En mis pruebas le he pedido explicar la relatividad especial, la general y sus diferencias. En lugar de generar una pequeña conferencia, ha condensado la respuesta en unos pocos puntos claros. Según el tipo de tarea, he llegado a recortar alrededor del 70% o 75% del texto generado. Evidentemente, no es el estilo adecuado para todas las conversaciones. Si queréis explorar una idea, debatir posibilidades o escuchar un punto de vista desarrollado, quizá os interese una respuesta más humana y extensa. Pero cuando ya existe un plan y solo queréis ejecutar, se agradece muchísimo que el agente vaya directo al tema. Podéis activar esta forma de trabajar únicamente en una tarea concreta, mantener otra conversación con un tono normal o adaptar la skill para que no sea tan extrema. Basta con pedirle al agente que cree una versión propia con un poco más de contexto o de prosa. Los suscriptores podéis descargarla desde la zona de descargas. Entregad el archivo comprimido a vuestro agente, pedidle que lo revise e instale y preguntadle cómo invocarla cuando la necesitéis. Al principio puede dar un poco de pena, porque neutraliza bastante la personalidad y el agente responde casi como Terminator o Data de Star Trek. Pero cuando tenéis una lista de tareas clara, queréis resultados rápidos y los tokens empiezan a escasear, os aseguro que se agradece. Espero que os sea útil para ahorrar muchos tokens y poder seguir gastando tokens. La pela es la pela. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Es viernes, o sea que ya sabéis lo que toca: descansad, relajaros y recargad pilas, aunque estemos en pleno agosto. Regresamos el lunes con más y mejor: la edición de verano del podcast de Marketing Online. Como siempre, a las 07:07. Hasta entonces... ¡Muy buen fin de semana!

  7. Aug 13

    3144. Píldoras de inteligencia artificial: Hooks

    Hoy os hablo de los hooks, pequeños ganchos que permiten ejecutar acciones automáticamente en momentos concretos del trabajo con un agente. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de Devbox con VPS. Esta mañana veremos cómo organizar los archivos locales y remotos, y esta tarde cómo trabajar con Visual Studio Code y previews remotas. ¡A por él! Ahora sí, vamos al lío. Quienes trabajáis con WordPress seguramente ya conocéis el concepto. Un hook permite enganchar una acción a un evento: cuando ocurra esto, ejecuta automáticamente aquello. Los agentes también tienen momentos a los que podéis enganchar vuestros propios scripts. Por ejemplo, al empezar una sesión, cuando enviáis una petición, antes o después de utilizar una herramienta, al compactar el contexto, cuando termina una tarea o cuando se detiene un subagente. Esto permite automatizar pequeñas comprobaciones sin tener que repetirlas en cada conversación. Podéis registrar la actividad, revisar que un mensaje no contenga una clave privada, ejecutar una validación al terminar, actualizar una memoria persistente o mostrar una advertencia cuando vaya a ocurrir una acción delicada. Uno de los casos que más me interesa es el trabajo con producción. Yo suelo dar bastante autonomía a mis agentes para que no se detengan cada pocos segundos preguntando si pueden leer o modificar un archivo. De lo contrario, les encargas algo, te marchas y al regresar descubres que no han avanzado porque estaban esperando una confirmación desde el primer minuto. Sin embargo, producción merece un tratamiento distinto. Una consulta inocente puede acabar convirtiéndose en un despliegue si el agente interpreta que esa es la mejor manera de resolverla. Y quizá vosotros solo queríais estudiar el cambio o probarlo primero en local. Por eso utilizo un hook que detecta las acciones relacionadas con producción e introduce una revisión explícita antes de continuar. Cuando el flujo va a desplegar, modificar archivos remotos o ejecutar una operación sensible, aparece la advertencia correspondiente y el agente debe detenerse a confirmar el siguiente paso. El hook no sustituye a los permisos, al sandbox ni a las reglas de seguridad. Es una capa adicional para recordar una condición justo en el momento adecuado. Podéis combinarlo con políticas que realmente limiten o bloqueen comandos cuando necesitéis una protección más estricta. También podéis crear ganchos para observar la compactación. Uno puede ejecutarse antes de resumir el contexto y otro justo después. O podéis aprovechar el final de cada tarea para lanzar las pruebas, comprobar el estado de Git o guardar un registro de lo que se ha hecho. Los eventos disponibles y su configuración dependen del agente y de la superficie que utilicéis. Mi recomendación es que le preguntéis directamente qué hooks admite vuestro entorno y que empecéis por un caso pequeño y fácil de verificar. Si trabajáis con acceso amplio, yo empezaría por producción. Pedidle que os ayude a preparar un hook que detecte esas operaciones y fuerce una revisión antes de seguir. Puede ahorraros algún que otro disgusto cuando el agente se emocione más de la cuenta. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana viernes con una nueva skill para ahorrar tokens. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

  8. Aug 12

    3143. Píldoras de inteligencia artificial: /status, /model y /reasoning

    Hoy os presento tres comandos para controlar mejor el consumo de Codex: /status, /model y /reasoning. Pero antes, recordemos que en Boluda.com tenéis cursos para emprendedores, marketing online, desarrollo web, y todo lo que necesitáis para vuestro negocio online. Esta semana estamos con el curso de Devbox con VPS. Esta mañana veremos cómo instalar Claude Code y otros agentes, y esta tarde cómo trabajar con proyectos reales utilizando rsync y Git. ¡A por él! Ahora sí, vamos al lío. El primero es /status. Al ejecutarlo, Codex muestra información sobre la tarea actual, el modelo activo, el contexto utilizado y los límites disponibles. Es una forma rápida de saber cuánto margen os queda antes de empezar un trabajo largo. No hace falta consultarlo después de cada mensaje, porque acabaríais más pendientes de los tokens que del proyecto. Pero sí resulta útil al principio de una sesión, antes de arrancar una funcionalidad compleja o cuando lleváis un buen rato trabajando y queréis decidir cómo organizar lo que queda. El segundo comando es /model. Sirve para escoger el modelo con el que queréis trabajar. Y aquí mi recomendación es que no utilicéis siempre la opción más potente simplemente porque está disponible. Es como conducir todo el tiempo con la misma marcha. Para comentar una idea, modificar un texto sencillo o retocar unas líneas de CSS quizá no necesitáis el modelo más capaz y costoso. Podéis trabajar con una opción más rápida y reservar los modelos superiores para arquitectura, depuración difícil o cambios que requieran más razonamiento. Utilizar el modelo adecuado para cada tarea no significa renunciar a calidad. Significa asignar la herramienta correcta al problema correcto. Poner al mejor modelo a resolver una suma sencilla funcionará, por supuesto, pero probablemente no sea el uso más inteligente de vuestros límites. El tercer comando es /reasoning para Codex, o /effortpara Claude. Dentro de un mismo modelo podéis escoger cuánto esfuerzo de razonamiento queréis que dedique. Un nivel bajo resulta más rápido para tareas acotadas. Los niveles medio o alto encajan mejor con cambios complejos y depuración. Y el esfuerzo extra alto puede reservarse para trabajos largos, muy exigentes o especialmente agentivos. La nomenclatura puede cambiar en otros agentes, pero el principio es el mismo: modelo y esfuerzo no tienen que estar siempre al máximo. Podéis empezar con una configuración ágil para hablar y concretar el encargo, y aumentar la capacidad o el razonamiento cuando llegue el momento de implementar la parte difícil. Así pues, la combinación de hoy queda muy clara. Utilizad /status para saber dónde estáis, /model para escoger la capacidad adecuada y /reasoning para ajustar cuánto debe esforzarse ese modelo. Si os acostumbráis a revisar estas tres decisiones, entenderéis mejor qué tipos de trabajo consumen más, evitaréis gastar recursos en tareas triviales y conseguiréis que vuestros límites duren mucho más. Y el viernes os compartiré una skill que todavía aprieta más las tuercas al ahorro de tokens. :) Como siempre, muchas gracias a todos por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, suscribiros a los cursos para emprendedores y por estar ahí, al otro lado. Como siempre digo, sin vosotros, esto no sería lo que es. Sin vosotros esto simplemente, no sería. Nos escuchamos mañana jueves con más marketing online veraniego. Como siempre, a las 07:07. Hasta entonces... ¡Muy buenos días!

Hosts & Guests

4.9
out of 5
67 Ratings

About

Todo lo que siempre has querido saber y nunca te has atrevido a preguntar sobre Marketing Online.

More From Marketing Online

You Might Also Like