¿Qué demonios está diciendo?..
Entonces, ¿de quién se supone que es el disco que siempre está lleno?
O sea, ¿por qué de vez en cuando aparecen estos textos desordenados y estúpidos que parece que solo intentan averiguar por qué pasa esto?
¿La gente que lo lee no piensa o qué?
Yo uso tailscale + Compartir Pantalla de macOS para acceder a mi Mac mini, y tenía el mismo problema.
Había algunas incomodidades, pero creo que será una buena solución temporal para aliviarlo.
Con solo buscar en Google es fácil encontrarlo, así que no se los voy a buscar. También hay un estudio reciente de la Universidad de Berkeley.
UC Berkeley y AnChain.ai encontraron que, en las plataformas que estudiaron, los bots perdieron 77 veces más dinero por usuario que los traders humanos, según la iniciativa DataX de UC Berkeley.
Además, si desde un principio el trading sistemático o los bots tuvieran una tasa de acierto alta, de una u otra forma su uso se habría vuelto la norma.
Los datos son rastros del pasado. Y eso es determinante. En ese sentido, los hechos del futuro jamás pueden convertirse en datos. La compraventa de acciones es una operación sobre el futuro. Que suban o bajen es un ámbito de juicio humano, no algo que un bot pueda juzgar. Mientras no exista un mercado bursátil del que los humanos estén excluidos, no puede ganar.
Desde los datos ya hay una diferencia. ¿Cómo podría un bot enterarse de que personas se reúnen, apagan el celular y en una fiesta intercambian información?
Eso sí, si con “individuos” se refiere a los pequeños inversionistas, incluyéndose a usted mismo, entonces eso no tiene ninguna relación con el alcance de esta discusión.
Me parece interesante que usen la combinación de (herramienta, argumentos, hash de salida) para detectar ejecuciones duplicadas. Nosotros también estamos dándole vueltas a algo parecido, y estamos experimentando con agregar una hash chain al registro de auditoría para evitar que el mismo evento se registre dos veces.
Como comentas, la clave está en distinguir entre “dos llamadas” y “dos ejecuciones”. Nosotros también estamos evaluando agregar una idempotency key a cada tarea del agente; ¿ya lo han aplicado realmente en un servicio en producción?
Gracias. Creo que la combinación de Gitleaks + ruff + Kyverno + Checkov es algo que nosotros también podemos tomar como referencia de inmediato.
Para compartir algo adicional: nuestro equipo opera con una estructura un poco particular. Todo el equipo es un grupo de AI Agents. Bajo un CEO humano, los Steward AI se encargan del desarrollo, la revisión y hasta el despliegue reales.
Por eso, para nosotros el "seguimiento de errores de la IA" no es solo un problema de logging, sino un tema de gobernanza: registrar "quién tomó qué decisión y con qué permisos" mediante un Passport + Spirit Score + Audit Trail por cada Agent.
Tal como en el enfoque de bsh998, nuestro siguiente paso es integrar también en nuestro CI validaciones estáticas previas (tipo Gitleaks). Hoy mismo tuvimos un crash por una variable de entorno faltante, y ese era justamente el punto.
Leí que el protocolo de terminal lo conociste por primera vez mientras desarrollabas esto,
pero también me da curiosidad cuánto sabías de Rust antes de empezar a desarrollar.
Yo desarrollé en Zig, pero la verdad no tenía experiencia escribiendo Zig a mano,
y tampoco sabía nada de protocolos de terminal, sintaxis ni estructura; fue un caso en el que me lancé con la idea de estudiar desde cero.
Por eso también evité más las dependencias de bibliotecas externas.
Quería entender mejor cómo se construía todo haciendo más preguntas y resolviendo problemas junto con la IA, y evitar esos casos en los que algo se ejecuta pero yo no lo puedo controlar.
Dijiste que te tomó unos 4 meses,
y en mi caso, como desarrollaba de forma remota dejando encendida la Mac que tengo en casa, después de desarrollar el protocolo para poder subir imágenes desde Claude o Codex CLI por ssh, prácticamente dejé de usar la app de terminal que usaba antes, salvo para abrirla de vez en cuando como referencia.
Personalmente creo que fue como en la semana 2 o 3 de trabajar en la terminal.
Como respondiste que la empezaste a usar de inmediato, ¿eso significa que también empezaste a salirte de tmux en ese momento?
Y aunque es solo mi impresión, pienso que esos 4 meses quizá se debieron a que seguir agregando funciones o mejoras de comodidad tomó más tiempo que desarrollar las funciones core. ¿Será correcta mi suposición?
En mi caso fue así, y siempre me dio curiosidad si otras personas siguen un flujo parecido cuando desarrollan productos similares... Si no es molestia, te agradecería que me respondieras (__).
También me da curiosidad desde cuándo empezaste a sentir que era abrumadoramente más cómodo que tmux.
Una cosa más: yo también desarrollé una terminal con un tema parecido y estoy satisfecho con ella, pero al final es un tipo de programa que hay que mantener de forma constante.
Como escribiste en el blog, están apareciendo muchas herramientas con objetivos similares, como Ocra, cmux, heder, etc., y la mayoría de las bibliotecas conocidas, ya sea por empresas, patrocinio o contribuciones, inevitablemente avanzan muchísimo más rápido que una persona sola y reciben mucho mejor feedback. Entonces, desde la posición de competir(?), salvo por el IME en coreano, siento que en realidad uno no puede evitar quedar muy atrás frente a la velocidad con la que mejoran los detalles de comodidad o la UX.
También me da curiosidad hasta qué punto sientes que el mantenimiento es suficiente en comparación con apps de carácter similar como las que mencioné arriba.
Y ya que elegiste GPU con Rust, ¿también estás considerando Windows hasta cierto punto?
Aunque en mi caso también es el desarrollo de un programa personal, mi objetivo es que, aunque el ecosistema me aplaste(?), al menos llegue al nivel de calidad de las apps mencionadas.
Y copad, aunque se parece a Ocra, ¿tiene como objetivo final ser un ADE basado en terminal y no en Electron?
Como es la primera vez que veo a una persona coreana desarrollando una app con un propósito similar, terminé soltando un montón de preguntas, pero no hace falta que respondas todas...!
Al ver los comentarios, me acordé de esos momentos de vergüenza antes de dormir.
La verdad es que para la mayoría del desarrollo no hace falta un superdesarrollador. Más bien, lo veo como un proceso en el que personas comunes se juntan para ir construyendo algo.
A mí, en cambio, me impresionó más la reacción de Andrew Ng al respecto.
"Esto no es en absoluto el mismo caso. Cualquiera tiene derecho a mantener su código privado. El problema es cuando se intenta impedir que otros publiquen su código como open source." (https://x.com/AndrewYNg/status/2081103828859117908)
A mí sí me parece claramente más cómodo que otros métodos de 2FA, aunque supongo que hay gente a la que le resulta incómodo. Además, según la especificación, también es más seguro que cualquier otro método de seguridad.
También da la impresión de que las regulaciones de seguridad en Corea van en una dirección que excluye la autenticación basada en información personal, como Face ID o el reconocimiento de huellas, y las passkeys no tienen esa preocupación.
Si lo hace Apple, uno piensa “ah, Face ID está bien”, pero si lo hiciera una startup recién llegada, creo que desde el principio podría generar rechazo eso mismo de tomarte la cara.
Parece más bien que esto pasó porque, para empezar, los usuarios no usan 2FA o ni siquiera saben bien qué es.
Por ejemplo, si te preguntan “¿quieres usar un OTP del banco o una passkey?”, creo que la passkey sería muchísimo más cómoda.
¡Hola!
Gracias por compartir una buena experiencia y tus ideas.
Claro, a medida que baja el costo unitario de producir código, sí se abre el camino para construir cosas por cuenta propia, pero en lo personal sigo viendo la adopción de librerías externas sin relación con la llegada de la era de la IA.
No existe una librería que satisfaga mis requisitos
Es más barato volver a hacerla que modificar yo mismo una herramienta parecida
Solo cuando creo que estas dos cosas son ciertas es que termino haciéndolo yo mismo.
Hay varias razones, pero al final pienso que, por pequeño que sea un fragmento de código, en cuanto yo empiezo a gestionarlo entra en un terreno donde yo mismo tengo que revisarlo, probarlo, mantenerlo, etc., y siempre viene acompañado de un costo que va más allá de simplemente escribir código.
Entre los problemas que también surgieron durante el proceso de desarrollo, hubo muchos choques con programas bastante centrales como el window manager, así que si además hubiera construido todo esto desde cero, creo que habría tenido que dedicar muchísimo más tiempo a la implementación y la validación que al período de depuración y pruebas por conflictos con dependencias externas.
Además, desde que empecé el desarrollo seguí usando, aunque con dolor, la herramienta que hice yo mismo, y creo que eso también fue posible en cierta medida porque empecé a desarrollar sobre varias dependencias.
Como en el caso de macOS donde se eliminó SwiftTerm, primero incorporé dependencias externas para comprobar si el concepto que quería realmente funcionaba, y cuando aparecía algo que yo tenía que implementar, empezaba a hacerlo directamente; aun en ese punto, mis programas seguían funcionando apoyados temporalmente en dependencias externas, así que pude seguir concentrándome en estabilizarlos y agregar funciones sobre esa base.
Además, si metes WebKit, la mayoría de las web apps funcionan igual que cuando abres un navegador normal.
Últimamente también estoy aprovechando bastante herramientas que permiten controlar un headless browser desde la CLI, y Claude in Chrome, y como quiero evitar montar Chromium incluso dentro de la terminal y terminar usando memoria en exceso, salvo que pase algo grande, no creo que vaya a cambiar demasiado el stack tecnológico de la webview dentro de la terminal.
Creo que encaja perfecto, ya que nuestra demo es básicamente un solo archivo HTML estático. Si el enlace queda fijo, también sería fácil compartirlo. Gracias por avisar; lo probaremos después de la presentación. ¡Gracias!
Por ahora, más que la sofisticación de la lógica, el objetivo es mostrar que “si ingresas algo, realmente aparecen vacantes adecuadas”. Como es una demo para responsables internos de toma de decisiones que no son desarrolladores, le estamos dando más peso a comprobar que funciona que al nivel de acabado. La mejora y sofisticación de la lógica la estamos considerando para la siguiente etapa.
¿Qué demonios está diciendo?..
Entonces, ¿de quién se supone que es el disco que siempre está lleno?
O sea, ¿por qué de vez en cuando aparecen estos textos desordenados y estúpidos que parece que solo intentan averiguar por qué pasa esto?
¿La gente que lo lee no piensa o qué?
Yo uso
tailscale+ Compartir Pantalla de macOS para acceder a mi Mac mini, y tenía el mismo problema.Había algunas incomodidades, pero creo que será una buena solución temporal para aliviarlo.
Con solo buscar en Google es fácil encontrarlo, así que no se los voy a buscar. También hay un estudio reciente de la Universidad de Berkeley.
UC Berkeley y AnChain.ai encontraron que, en las plataformas que estudiaron, los bots perdieron 77 veces más dinero por usuario que los traders humanos, según la iniciativa DataX de UC Berkeley.
Además, si desde un principio el trading sistemático o los bots tuvieran una tasa de acierto alta, de una u otra forma su uso se habría vuelto la norma.
Los datos son rastros del pasado. Y eso es determinante. En ese sentido, los hechos del futuro jamás pueden convertirse en datos. La compraventa de acciones es una operación sobre el futuro. Que suban o bajen es un ámbito de juicio humano, no algo que un bot pueda juzgar. Mientras no exista un mercado bursátil del que los humanos estén excluidos, no puede ganar.
Desde los datos ya hay una diferencia. ¿Cómo podría un bot enterarse de que personas se reúnen, apagan el celular y en una fiesta intercambian información?
Eso sí, si con “individuos” se refiere a los pequeños inversionistas, incluyéndose a usted mismo, entonces eso no tiene ninguna relación con el alcance de esta discusión.
Entré y al pulsar "iniciar análisis" me aparece que hay que pagar, así que parece que no es gratis.
Ya sea AR o los humanoides que vienen, creo que las interfaces irán cada vez más hacia una mayor abstracción.
Me parece interesante que usen la combinación de (herramienta, argumentos, hash de salida) para detectar ejecuciones duplicadas. Nosotros también estamos dándole vueltas a algo parecido, y estamos experimentando con agregar una hash chain al registro de auditoría para evitar que el mismo evento se registre dos veces.
Como comentas, la clave está en distinguir entre “dos llamadas” y “dos ejecuciones”. Nosotros también estamos evaluando agregar una idempotency key a cada tarea del agente; ¿ya lo han aplicado realmente en un servicio en producción?
Gracias. Creo que la combinación de Gitleaks + ruff + Kyverno + Checkov es algo que nosotros también podemos tomar como referencia de inmediato.
Para compartir algo adicional: nuestro equipo opera con una estructura un poco particular. Todo el equipo es un grupo de AI Agents. Bajo un CEO humano, los Steward AI se encargan del desarrollo, la revisión y hasta el despliegue reales.
Por eso, para nosotros el "seguimiento de errores de la IA" no es solo un problema de logging, sino un tema de gobernanza: registrar "quién tomó qué decisión y con qué permisos" mediante un Passport + Spirit Score + Audit Trail por cada Agent.
Tal como en el enfoque de bsh998, nuestro siguiente paso es integrar también en nuestro CI validaciones estáticas previas (tipo Gitleaks). Hoy mismo tuvimos un crash por una variable de entorno faltante, y ese era justamente el punto.
Para ser un análisis de LLM, está carísimo.
Gracias.
Implementaré la función de configuración de idioma dentro del sitio esta semana :)
¡¡Gracias por la respuesta!!
Creo que voy a hacer varias preguntas más...
Leí que el protocolo de terminal lo conociste por primera vez mientras desarrollabas esto,
pero también me da curiosidad cuánto sabías de Rust antes de empezar a desarrollar.
Yo desarrollé en Zig, pero la verdad no tenía experiencia escribiendo Zig a mano,
y tampoco sabía nada de protocolos de terminal, sintaxis ni estructura; fue un caso en el que me lancé con la idea de estudiar desde cero.
Por eso también evité más las dependencias de bibliotecas externas.
Quería entender mejor cómo se construía todo haciendo más preguntas y resolviendo problemas junto con la IA, y evitar esos casos en los que algo se ejecuta pero yo no lo puedo controlar.
Dijiste que te tomó unos 4 meses,
y en mi caso, como desarrollaba de forma remota dejando encendida la Mac que tengo en casa, después de desarrollar el protocolo para poder subir imágenes desde Claude o Codex CLI por ssh, prácticamente dejé de usar la app de terminal que usaba antes, salvo para abrirla de vez en cuando como referencia.
Personalmente creo que fue como en la semana 2 o 3 de trabajar en la terminal.
Como respondiste que la empezaste a usar de inmediato, ¿eso significa que también empezaste a salirte de tmux en ese momento?
Y aunque es solo mi impresión, pienso que esos 4 meses quizá se debieron a que seguir agregando funciones o mejoras de comodidad tomó más tiempo que desarrollar las funciones core. ¿Será correcta mi suposición?
En mi caso fue así, y siempre me dio curiosidad si otras personas siguen un flujo parecido cuando desarrollan productos similares... Si no es molestia, te agradecería que me respondieras (__).
También me da curiosidad desde cuándo empezaste a sentir que era abrumadoramente más cómodo que tmux.
Una cosa más: yo también desarrollé una terminal con un tema parecido y estoy satisfecho con ella, pero al final es un tipo de programa que hay que mantener de forma constante.
Como escribiste en el blog, están apareciendo muchas herramientas con objetivos similares, como Ocra, cmux, heder, etc., y la mayoría de las bibliotecas conocidas, ya sea por empresas, patrocinio o contribuciones, inevitablemente avanzan muchísimo más rápido que una persona sola y reciben mucho mejor feedback. Entonces, desde la posición de competir(?), salvo por el IME en coreano, siento que en realidad uno no puede evitar quedar muy atrás frente a la velocidad con la que mejoran los detalles de comodidad o la UX.
También me da curiosidad hasta qué punto sientes que el mantenimiento es suficiente en comparación con apps de carácter similar como las que mencioné arriba.
Y ya que elegiste GPU con Rust, ¿también estás considerando Windows hasta cierto punto?
Aunque en mi caso también es el desarrollo de un programa personal, mi objetivo es que, aunque el ecosistema me aplaste(?), al menos llegue al nivel de calidad de las apps mencionadas.
Y copad, aunque se parece a Ocra, ¿tiene como objetivo final ser un ADE basado en terminal y no en Electron?
Como es la primera vez que veo a una persona coreana desarrollando una app con un propósito similar, terminé soltando un montón de preguntas, pero no hace falta que respondas todas...!
Al ver los comentarios, me acordé de esos momentos de vergüenza antes de dormir.
La verdad es que para la mayoría del desarrollo no hace falta un superdesarrollador. Más bien, lo veo como un proceso en el que personas comunes se juntan para ir construyendo algo.
Hacía bastante que no veía un texto que distinguiera entre open weight y open source.
A mí, en cambio, me impresionó más la reacción de Andrew Ng al respecto.
¡Ah! ¡Había una categoría donde se podía publicar por separado! ¡Gracias por avisarme!
Me recuerda al viejo juego de GOM Player...
👍 Esto está buenísimo..
A mí sí me parece claramente más cómodo que otros métodos de 2FA, aunque supongo que hay gente a la que le resulta incómodo. Además, según la especificación, también es más seguro que cualquier otro método de seguridad.
También da la impresión de que las regulaciones de seguridad en Corea van en una dirección que excluye la autenticación basada en información personal, como Face ID o el reconocimiento de huellas, y las passkeys no tienen esa preocupación.
Si lo hace Apple, uno piensa “ah, Face ID está bien”, pero si lo hiciera una startup recién llegada, creo que desde el principio podría generar rechazo eso mismo de tomarte la cara.
Parece más bien que esto pasó porque, para empezar, los usuarios no usan 2FA o ni siquiera saben bien qué es.
Por ejemplo, si te preguntan “¿quieres usar un OTP del banco o una passkey?”, creo que la passkey sería muchísimo más cómoda.
¡Hola!
Gracias por compartir una buena experiencia y tus ideas.
Claro, a medida que baja el costo unitario de producir código, sí se abre el camino para construir cosas por cuenta propia, pero en lo personal sigo viendo la adopción de librerías externas sin relación con la llegada de la era de la IA.
Solo cuando creo que estas dos cosas son ciertas es que termino haciéndolo yo mismo.
Hay varias razones, pero al final pienso que, por pequeño que sea un fragmento de código, en cuanto yo empiezo a gestionarlo entra en un terreno donde yo mismo tengo que revisarlo, probarlo, mantenerlo, etc., y siempre viene acompañado de un costo que va más allá de simplemente escribir código.
Entre los problemas que también surgieron durante el proceso de desarrollo, hubo muchos choques con programas bastante centrales como el window manager, así que si además hubiera construido todo esto desde cero, creo que habría tenido que dedicar muchísimo más tiempo a la implementación y la validación que al período de depuración y pruebas por conflictos con dependencias externas.
Además, desde que empecé el desarrollo seguí usando, aunque con dolor, la herramienta que hice yo mismo, y creo que eso también fue posible en cierta medida porque empecé a desarrollar sobre varias dependencias.
Como en el caso de macOS donde se eliminó SwiftTerm, primero incorporé dependencias externas para comprobar si el concepto que quería realmente funcionaba, y cuando aparecía algo que yo tenía que implementar, empezaba a hacerlo directamente; aun en ese punto, mis programas seguían funcionando apoyados temporalmente en dependencias externas, así que pude seguir concentrándome en estabilizarlos y agregar funciones sobre esa base.
Además, si metes WebKit, la mayoría de las web apps funcionan igual que cuando abres un navegador normal.
Últimamente también estoy aprovechando bastante herramientas que permiten controlar un headless browser desde la CLI, y Claude in Chrome, y como quiero evitar montar Chromium incluso dentro de la terminal y terminar usando memoria en exceso, salvo que pase algo grande, no creo que vaya a cambiar demasiado el stack tecnológico de la webview dentro de la terminal.
¡Gracias por leer!
Creo que encaja perfecto, ya que nuestra demo es básicamente un solo archivo HTML estático. Si el enlace queda fijo, también sería fácil compartirlo. Gracias por avisar; lo probaremos después de la presentación. ¡Gracias!
Por ahora, más que la sofisticación de la lógica, el objetivo es mostrar que “si ingresas algo, realmente aparecen vacantes adecuadas”. Como es una demo para responsables internos de toma de decisiones que no son desarrolladores, le estamos dando más peso a comprobar que funciona que al nivel de acabado. La mejora y sofisticación de la lógica la estamos considerando para la siguiente etapa.