Ahora que lo pienso después de dejar un comentario, me da curiosidad cómo verifican la edad si en un café sin personal hay máquinas expendedoras. ¿Las máquinas expendedoras también tienen alguna función para reconocer la identificación?
Yo tampoco fumo, así que no lo sabía, pero hace poco me di cuenta al ver una máquina expendedora de cigarrillos electrónicos desechables en un café sin personal que abrió hace poco en mi barrio. Parece que la mitad de los comentarios de Hacker News de abajo también tratan sobre el absurdo desperdicio de recursos. Jaja
Me trae recuerdos (?) de cuando, a fines de los 2000, trabajaba en una empresa de software de navegación para vehículos desarrollando un módulo de búsqueda de rutas.
Dijkstra es demasiado lento para la búsqueda de rutas en navegación, así que no se usa; en su lugar se usa la búsqueda A* (A Star), una versión mejorada con heurística. Revisando, veo que A* no es un algoritmo SSSP sino SPSP (Single-Pair Shortest Path).
markitdown es conveniente para convertir entre formatos, pero con PDF no debería usarse nunca. D
Ya hay muchos métodos de extracción de documentos que usan LLM multimodales como Gemini, y en los benchmarks también muestran resultados bastante buenos. El problema, claro, es el costo.
Más que de bajo nivel... para implementar formularios, algo que podría resolverse usando solo la etiqueta input de HTML termina exigiendo saber demasiadas cosas innecesarias como state, JSX y componentes controlados/no controlados, además de generar mucho código; supongo que eso pudo haber sido una de las motivaciones del texto principal.
Parece como si estuvieran diciendo que, solo porque apareció una nueva alternativa, el método existente ya murió.
¿De verdad ya no se puede usar el método anterior y ahora necesariamente hay que usar el nuevo?
Estoy muy de acuerdo con el concepto, así que hice algunas pruebas este fin de semana en un proyecto nuevo, pero no funcionó tan bien como esperaba. Creo que todavía necesita muchas mejoras. Por ahora, el flujo general parece ser más o menos el siguiente, como ya se ha explicado varias veces:
redactar la constitución → redactar la especificación → redactar las tareas → implementar
El problema es que
el archivo constitution.md es una guía clave sobre "cómo desarrollar", pero no contiene "en qué se convertirá finalmente esta app"
spec.md es un documento que describe una sola funcionalidad
no existe un documento maestro sobre "qué es esta app"
leyendo las discusiones en GitHub, parece que la chain of specs terminará siendo la source of truth. Me deja con dudas, pero más o menos lo pude entender.
mediante los comandos /specify y /tasaks se generan muchos documentos como entregables (que era lo que quería), pero por eso mismo consume contexto rápidamente (estoy usando Claude Code)
una vez que entro en la implementación, me alejo un poco de Spec Kit y termino completándola como siempre, conversando con Claude Code
cuando se consume todo el contexto y se hace compaction o se inicia una sesión nueva, se olvida de la existencia de los documentos generados por Spec Kit
mientras avanzo con las tareas definidas en tasks.md, a veces termino sobrescribiendo cosas que antes había hecho bien, y en el proceso de corregir bugs también acabo creando nuevas funcionalidades, así que cada vez se aleja más de tasks.md. No entiendo qué sentido tiene conservar tasks.md de forma permanente.
Por ahora, mi conclusión es la siguiente
aunque el resultado termine siendo distinto de lo que pensé al principio, primero hay que cerrar la especificación y luego crear una nueva para ir corrigiendo poco a poco
la especificación inicial inevitablemente crecerá, así que para las funcionalidades de la app quizá sea mejor no explicarlas en absoluto y limitarse a crear solo el boilerplate
para algo hecho a nivel PoC, es mejor no usar Spec Kit
Estoy muy de acuerdo. Por muy bien que lo haga, que interfiera resulta incómodo. Lo ideal es que esté ahí como si no estuviera, y que aparezca para ayudar justo cuando se necesita; creo que la clave será qué tan adecuado sea su juicio de la situación. También entre las personas hay quienes lo hacen bien y quienes no, así que si la inteligencia artificial logra superar eso, parece que ocurrirá una revolución.
Para ser precisos con respecto a Vulkan, lo correcto sería decir que “la API de Vulkan compatible con la iGPU del Pi 5 todavía no es compatible con llama.cpp”. También me da curiosidad saber qué rendimiento habría dado si eso hubiera sido compatible.
> Se niegan a contratar talento mejor que ellos mismos
Lo he visto mucho, no solo en fundadores, sino también en puestos de liderazgo.
Por experiencia, suelo identificarme mucho con el punto 3.
El peor formato: PDF
Ahora que lo pienso después de dejar un comentario, me da curiosidad cómo verifican la edad si en un café sin personal hay máquinas expendedoras. ¿Las máquinas expendedoras también tienen alguna función para reconocer la identificación?
Yo tampoco fumo, así que no lo sabía, pero hace poco me di cuenta al ver una máquina expendedora de cigarrillos electrónicos desechables en un café sin personal que abrió hace poco en mi barrio. Parece que la mitad de los comentarios de Hacker News de abajo también tratan sobre el absurdo desperdicio de recursos. Jaja
Me trae recuerdos (?) de cuando, a fines de los 2000, trabajaba en una empresa de software de navegación para vehículos desarrollando un módulo de búsqueda de rutas.
Dijkstra es demasiado lento para la búsqueda de rutas en navegación, así que no se usa; en su lugar se usa la búsqueda A* (A Star), una versión mejorada con heurística. Revisando, veo que A* no es un algoritmo SSSP sino SPSP (Single-Pair Shortest Path).
Hablo desde la experiencia de haber hecho esto: para la personalización se necesita mucha información, incluso más de 2 gigabytes.
markitdownes conveniente para convertir entre formatos, pero con PDF no debería usarse nunca. DYa hay muchos métodos de extracción de documentos que usan LLM multimodales como Gemini, y en los benchmarks también muestran resultados bastante buenos. El problema, claro, es el costo.
Algo como
doclingtambién está bien.La funcionalidad o el enfoque se ven iguales a los de Atlas: https://atlasgo.io/
Me identifico mucho con esas tres trampas principales. Con que haya un solo gatekeeper ya empiezan a aparecer varios efectos negativos.
Más que de bajo nivel... para implementar formularios, algo que podría resolverse usando solo la etiqueta
inputde HTML termina exigiendo saber demasiadas cosas innecesarias comostate, JSX y componentes controlados/no controlados, además de generar mucho código; supongo que eso pudo haber sido una de las motivaciones del texto principal.Como no fumo, no entendía de qué iba, pero entonces se refiere a que, para ser desechables, usan demasiados recursos.
La majestuosidad de un karma de -47 jajaja
Parece como si estuvieran diciendo que, solo porque apareció una nueva alternativa, el método existente ya murió.
¿De verdad ya no se puede usar el método anterior y ahora necesariamente hay que usar el nuevo?
Estoy muy de acuerdo con el concepto, así que hice algunas pruebas este fin de semana en un proyecto nuevo, pero no funcionó tan bien como esperaba. Creo que todavía necesita muchas mejoras. Por ahora, el flujo general parece ser más o menos el siguiente, como ya se ha explicado varias veces:
redactar la constitución → redactar la especificación → redactar las tareas → implementar
El problema es que
/specifyy/tasaksse generan muchos documentos como entregables (que era lo que quería), pero por eso mismo consume contexto rápidamente (estoy usando Claude Code)Por ahora, mi conclusión es la siguiente
jajajajajajaja
Estoy muy de acuerdo. Por muy bien que lo haga, que interfiera resulta incómodo. Lo ideal es que esté ahí como si no estuviera, y que aparezca para ayudar justo cuando se necesita; creo que la clave será qué tan adecuado sea su juicio de la situación. También entre las personas hay quienes lo hacen bien y quienes no, así que si la inteligencia artificial logra superar eso, parece que ocurrirá una revolución.
Para ser precisos con respecto a Vulkan, lo correcto sería decir que “la API de Vulkan compatible con la iGPU del Pi 5 todavía no es compatible con
llama.cpp”. También me da curiosidad saber qué rendimiento habría dado si eso hubiera sido compatible.docling también está bueno
¡Guau! ¡Un cortador ultrasónico!