Últimamente, como los agentes de codificación pueden compensar las partes en las que uno es débil, creo que la barrera de entrada podría bajar si uno conoce bien sus fortalezas y sabe aprovecharlas.
En mi caso, la documentación siempre fue un problema, pero al delegarle una parte a un agente de codificación, la carga también se redujo, y además, al revisar ese material documentado, siento que también estoy desarrollando mejor criterio sobre la documentación.

¡Gracias por leer! Antes había muchas cosas de las que una persona tenía que estar pendiente directamente, como la documentación, los casos de prueba y la validación, pero ahora, como ya se pueden hacer bastantes partes junto con agentes de IA para programar, da la impresión de que, para el open source, la dificultad de mantenimiento realmente ha bajado bastante más que antes.

@xguru parece que el enlace está mal~

Sí, si uno mira solo el historial del portapapeles, hay muchas coincidencias. Pero Raycast tiene muchas otras funciones además del portapapeles, así que me parecía excesivo.

Estas son las cosas en las que me enfoqué.

Primero, que sea ligero y que gestione solo el historial del portapapeles; actualmente pesa unos 2 MB.

Además, se puede editar el contenido guardado desde el detalle. Me resultó cómodo al revisar varios prompts y retocarlos un poco de antemano.

También cuidé la búsqueda y la organización en carpetas. Intenté resolver esos datos que uno necesita mientras trabaja, cosas de una sola vez o que da flojera volver a buscar.
Hice que se pueda buscar por contenido, etiquetas, título, etc.

Más adelante me gustaría permitir agregar funciones o distribuciones directamente mediante plugins, pero eso todavía no lo tengo concretado.

También creo que Raycast es una buena app, y quiero esforzarme para que esto pueda ser una opción según las preferencias de cada quien.

Gracias por tu opinión.

En este tipo de herramientas, lo más difícil no es la parte de acumular, sino la de desechar, y llama la atención que hayan separado garden con un ciclo de vida aparte.

El contexto que se le da al agente, cuando envejece, no solo deja de servir, sino que puede volverse perjudicial. Una persona ve un documento y puede pensar “esto suena a algo antiguo”, pero el modelo no tiene esa intuición, así que toma condiciones invariantes que eran ciertas hace tres meses y las usa tal cual como si siguieran siéndolo hoy. El código al menos falla al compilar, pero una wiki se equivoca en silencio.

Por eso me da curiosidad si a cada página se le adjunta de qué momento es la referencia y en qué se basó para escribirse. Me parece acertada la decisión de guardarlo en el repositorio como Markdown y hacer que pase por revisión en Git, pero ahí lo que queda en el diff es cuándo cambió el documento, no hasta cuándo su contenido sigue siendo válido.

Con 1,700 casos, hablar de rendimiento en realidad casi no tiene sentido; tanto si lo procesas directo en el frontend como si pones un backend, ambos van a responder al instante. Así que el criterio correcto no debería ser la velocidad, sino si vas a reescribir o no la lógica de Python que ya tienes.

Con ese criterio, Streamlit es lo que mejor encaja. Puedes importar y usar la lógica de matching tal cual, y si la pantalla solo necesita 5 selectbox y una tabla de resultados, ni siquiera hace falta escribir código de frontend. Si lo subes a Streamlit Community Cloud, también obtienes gratis un enlace compartible, y si dejas que lea el JSON en runtime, con solo reemplazar el archivo se reflejan los datos más recientes.

El HTML estático tiene la ventaja de que el despliegue es más simple, pero obliga a mover la lógica de Python a JS; si el cálculo de puntajes es aunque sea un poco complejo, solo ese port te puede consumir varios días. Si el objetivo es mostrar algo funcionando esta misma semana, parece mejor no asumir ese riesgo.

Una cosa más: Streamlit inevitablemente se ve más como una herramienta que como un producto. Si es una demo para tomadores de decisión internos y el objetivo es confirmar que "si ingresas algo, realmente aparece", no pasa nada; pero si es una demo para clientes externos, sí conviene tenerlo en cuenta.

Parece que admite casi todas las funciones que tiene Raycast; ¿hay alguna diferencia en particular?

Oh... En las publicaciones de Show GN siempre quise ver, además del típico “hice algo”, este tipo de insights también, así que me emociona encontrarme con un texto así jajaja

Es parte de la psicología humana querer dárselo todo a una sola persona para que se encargue bien de todo, en vez de buscar un experto para cada caso y asignarle solo su parte del trabajo.
¿No será que, con los LLM, la función de recompensa inevitablemente termina diseñada para que acepten cualquier cosa que les tires?

Aunque sea un benchmark público, es la primera vez que veo cifras tan concretas a este nivel. Gracias.

La proporción de 159 casos / 76 casos / 3,197 casos me llamó especialmente la atención. Que los casos no determinables (sin ID) sean abrumadoramente numerosos significa que, al final, la mayoría de los duplicados están en una zona donde ni siquiera se pueden rastrear; esto vuelve a confirmar que no hay que confiarse pensando que “con tener logs de auditoría alcanza”.

El enfoque de priorizar la creación (POST) coincide exactamente con nuestro diseño. Precisamente por eso queríamos adjuntar primero la idempotency key a los eventos de creación en nuestra hash chain.

Voy a incorporar de inmediato la sugerencia del message ID de email. Con solo agregar “ID de entidad obligatorio en la respuesta” a la especificación de las herramientas internas, cambia la posibilidad de verificar los logs de auditoría. Y si se usa el ID como ancla en la hash chain, se puede comprobar si hay duplicados solo mediante cálculo.

¿Pudieron identificar en qué tipos de herramientas se concentraban los 3,197 casos “sin ID”? Además del email, me da curiosidad cuántas herramientas devuelven solo “éxito/fallo”.

Por ahora está en proceso de optimización, así que si queda listo dentro de esta semana, creo que podrán verlo de forma más prolija :)

Ya agregaron la función para cambiar al coreano :)
Muchísimas gracias

¡A mí también me da bastante gusto encontrarme con alguien que está haciendo algo parecido!

Yo también había invertido bastante tiempo en Rust incluso antes de la era de Claude, creando APIs y CLIs con Rust.

Hace relativamente poco empecé a pensar que había que reemplazar tmux, así que no llevo mucho tiempo desde que lo sustituí como tal, pero también hice un multiplexor y desde el segundo día minimicé bastante el uso de tmux.
Aquí, además de la calidad del producto, creo que también influyó mucho que tener un fallback a otras herramientas que no eran la que yo hice terminaba volviéndose una vía de escape, y eso hacía que no me esforzara tanto en desarrollar.

Y si al final tomó cuatro meses, creo que fue porque, como mencionaste, también me llevó mucho tiempo convertir funciones de mi gusto en algo expandible para que varias personas pudieran usarlo, y porque también necesité bastante valor para decidir publicarlo al público.

Y en cuanto a la motivación de un proyecto personal, a diferencia de programas como orca, que reciben apoyo empresarial, yo de hecho lo veo de forma positiva.
Claro, pocas cosas motivan tanto como una carga económica encima, pero yo tengo todo mi workflow ajustado a herramientas que uso yo mismo, así que si quiero trabajar ahora mismo, estoy en una situación en la que tengo que mejorar esta herramienta, y por eso también invierto hasta el máximo posible de mi tiempo personal en mejorar estas herramientas.
Por supuesto, existe el problema de que todo se acaba en el momento en que mi motivación baje, pero para evitar esa situación he optimizado intencionalmente mi workflow alrededor de mis propias herramientas, justamente para prevenirlo.
Personalmente, incluso ahora mismo pienso que, comparado con las herramientas competidoras, lo que me falta no es algo técnico sino marketing, así que haberlo publicado para recibir feedback también ha sido algo bastante importante.

Lo de usar renderizado por GPU no fue tanto por dar soporte a Windows, sino por el reto técnico y la optimización para programas que llenan por completo la pantalla del terminal.
En lo personal, hace mucho que no uso Windows para desarrollo, así que no había pensado a fondo en el soporte para ese sistema operativo, pero ahora que ya hay una base bastante sólida, sí me da la impresión de que podría valer la pena intentarlo.

Mi objetivo es simplemente que, para todo mi trabajo de desarrollo, con solo copad sea suficiente, ¡y por eso también ya preparé un sistema de plugins!
Así que, en general, intento implementar en copad todas las funciones que necesitan una GUI, en la medida de lo posible.

Hay una diferencia bastante grande en la forma de renderizado, pero la verdad es que desde la perspectiva del usuario final no se siente como una diferencia tan grande, así que hasta me da algo de pena explicarlo en detalle. Como mencionaste, ahora que los costos de producción han bajado, parece que vivimos en una época en la que lo mejor es lo que mejor se adapta a uno..!

Samsung, que recopilaba los registros de asesoría interna en la carpeta disciplinaria de Recursos Humanos, es sin duda una empresa líder global.

Todavía no lo he probado en un servicio en producción. Como todas estas cifras salen de trazas de benchmarks públicos, creo que lo correcto es mencionar primero esa limitación.

Aun así, hay una observación que podría servir como referencia para diseñar una idempotency key.

Para distinguir entre “dos llamadas” y “dos ejecuciones”, comparé los IDs de entidad incluidos en la respuesta. Si al llamar dos veces con los mismos parámetros el ID de respuesta era distinto, eso significaba que realmente se habían creado dos cosas; si era el mismo, entonces la API lo había filtrado por su cuenta.

Según el benchmark Toolathlon, entre las llamadas duplicadas a herramientas con cambio de estado:

Casos con ID distinto (creación duplicada real): 159
Casos con ID igual (la API hizo dedup): 76
No se pudo determinar porque no había ID: 3,197

Aquí apareció un patrón. Los 159 casos con IDs distintos eran todos herramientas de tipo creación (creación de documentos, creación de hojas de cálculo, carga de archivos, creación de quizzes). En cambio, en las de tipo actualización (patch, update, enroll) no hubo ni un solo caso con IDs distintos; como apuntaban al mismo objeto, no se volvió a crear nada.

O sea, si van a agregar una idempotency key, parece que la prioridad debería estar del lado de creación (POST). En actualización, muchos casos ya parecían ser idempotentes de forma natural.

Y aquí vuelve a aparecer el problema del correo que mencioné antes. En el envío de emails, la respuesta solo era la cadena "éxito", así que no se podía comparar ningún ID. Aunque se agregue una idempotency key, no hay forma de verificar solo con la traza si realmente funcionó. Si diseñan una herramienta interna, con solo hacer que el resultado del envío devuelva un message ID, ya se puede validar en el log de auditoría. Creo que también encajaría bien con el método de hash chain que mencionaste.

Para insistir una vez más en la limitación: todas las cifras de arriba vienen de trazas de benchmark, así que no sé si en un entorno real de operación saldría la misma proporción. Si en algún momento llegan a correr trazas, me daría curiosidad ver qué tan distintos salen los resultados.

Es como una canasta para guardar capturas de pantalla.

Hay un enfoque similar de compilación JIT con numba, pero este da la impresión de tener una cobertura más amplia.

Si al menos sacaran algo como gps oss 120b, todavía sonaría un poco más convincente, pero quién sabe.

Entonces, lo mejor es ofrecer LLM cerrados al mercado al menor precio posible. Si el acceso a inteligencia de alto rendimiento es alto, de forma natural se reduce el incentivo para desarrollar modelos de pesos abiertos, y el liderazgo técnico también podría quedar en manos de instituciones comunes. Pero al final, Anthropic es justamente el proveedor más excluyente del mercado, ¿no?