Como había demasiados errores, parece que terminaron publicando un aviso a las apuradas.
Pero también me hace pensar que no fue demasiado tarde...
Ya había tantos errores que todos estaban diciendo que la gente se estaba yendo, snif.
La gente dice cosas como que no se puede confiar en ello porque es hecho en China, pero yo de verdad agradezco que DeepSeek investigue y publique de forma abierta, y sobre todo que incluso haga públicos sus procesos de prueba y error.
Nosotros terminamos estableciéndonos en usar ambos.
Metemos una fase de revisión cruzada con Codex dentro del flujo de comandos slash (dentro de /ship, en el orden planificación → implementación → verificación → revisión con Codex → reporte) y, al mismo tiempo, colgamos esa misma revisión en el pre-push hook. Si dejas solo los comandos slash, cuando hay prisa alguien simplemente hace push y la revisión se salta; si dejas solo el hook, el resultado recién aparece justo antes del push y ya es tarde.
En ambos caminos no llamamos directamente al Codex CLI, sino que desde los dos lados invocamos exactamente el mismo script de bash envuelto una vez (codex-review.sh). Ese script resuelve en un solo lugar el timeout, la verificación de autenticación, la revisión de secretos y el formato de salida, así que tanto en comandos slash como en hooks el lado que lo invoca queda limpio.
La clave es que jamás bloqueamos en función del resultado de la revisión de Codex. Aunque el CLI se caiga o salga un CRITICAL, el push igual pasa y solo se imprime el resultado. Si aunque sea una vez lo conviertes en bloqueo, cuando Codex marque por error código que en realidad no tiene problemas, el usuario va a terminar usando la opción para saltarse el hook al hacer push (git push --no-verify), y si eso se vuelve costumbre, tener el hook puesto pasa a ser prácticamente lo mismo que no ejecutarlo nunca. Por eso, las verificaciones que sí necesitan bloqueo (lint, tipos, tests, push de archivos secretos) las separamos en gates aparte, y dejamos la opinión del modelo solo como referencia.
El script, los comandos slash y el cuerpo del hook están tal cual en los capítulos 4 a 6 de Track, por si te sirve revisarlos.
Dicen que hay gente que lo hace así, y me da curiosidad saber de qué manera lo implementan.
No sé si el desarrollador invoca cada herramienta directamente cuando la necesita, sin agruparlas como agentes separados,
o si lo resuelven con una configuración para que Codex haga la revisión automáticamente al ejecutar un Git Hook.
Últimamente Meta parecía un poco menos repugnante, pero vengo a recargar mi enojo contra Meta.
Es un tema algo distinto, pero también se ha dicho últimamente que los bloqueos de los sistemas operativos fueron algo por lo que Meta hizo lobby... Desde la historia de cómo fundaron la empresa hasta cada uno de sus movimientos, de verdad parece que se cambiaron la ética por nada.
Los proveedores de LLM suelen recopilar y usar para entrenar y mejorar sus modelos los datos de los "servicios para consumidores" que los usuarios comunes usan gratis o mediante suscripción. En cambio, los datos de las API o de los servicios empresariales que usan empresas o desarrolladores pagando normalmente quedan protegidos por contrato para que no se utilicen en el entrenamiento.
Aquí hay un punto importante que debemos señalar. Es la pregunta de fondo: "¿De verdad un producto de pago no usa mis datos para entrenar en absoluto?"
En los servicios empresariales de OpenAI se indica por contrato que los datos no se usan para entrenamiento, pero ¿cómo se puede verificar técnicamente esa "promesa" y cómo se puede garantizar legal o institucionalmente? Por ahora, como no podemos vigilar directamente el pipeline de entrenamiento de OpenAI, este es un terreno que inevitablemente depende por completo de la ética del proveedor y del contrato.
La misma pregunta, "¿No existe el riesgo de que mis datos se integren al conocimiento del modelo?", no es un problema exclusivo de DeepSeek, y seguimos teniendo como tarea pendiente que no existe una solución perfecta salvo "comprar" condiciones contractuales más seguras según el presupuesto y la necesidad (por ejemplo: API, plan empresarial), o alojar el modelo por cuenta propia para lograr mayor integridad técnica.
Decir que "como es un LLM chino automáticamente roba datos personales" es una expresión exagerada, y el riesgo estructural sobre el uso de datos no es muy distinto en los LLM de Estados Unidos. Lo importante es revisar con cuidado el tipo de servicio y las condiciones del contrato, y elegir pagar para proteger nuestros datos o bien optar por una alternativa técnica (como el self-hosting).
Yo también pedí el reembolso...
Además, ni siquiera hacen rollover de los créditos de IA... y eso de aplicar el uso de tokens y el tiempo de uso (la parte que consume cuando está en Think) sin criterios claros...
Entonces que lo cobren por consumo...
Si de verdad lo van a medir como tarifa de uso, al menos deberían poner un período de vigencia y permitir el rollover...
Si va a ser así, entonces no hay motivo para usarlo...
¿Y cuál sería la razón para usarlo en vez de ChatGPT, Claude o Gemini...?
Yo lo usaba con plan anual y, aunque no era mi herramienta principal, sí lo usaba de vez en cuando... se siente como una puñalada por la espalda enorme. Para los usuarios anuales, al menos deberían mantener el precio anterior hasta que termine ese período de vigencia; pero si de repente suben el precio y encima endurecen más los límites de uso...
Parece que se olvidaron del sentido de pagar anual...
Te cobran por adelantado de una vez, a cambio de darte un poco más de promoción y captar clientes durante ese período...
Sale cada trimestre.
Definitivamente, incluso en YC's Requests for Startups - Summer 2025 ya había mucho de IA,
pero este año parece que su aplicación se ha acercado más al lado vertical y empresarial.
Como había demasiados errores, parece que terminaron publicando un aviso a las apuradas.
Pero también me hace pensar que no fue demasiado tarde...
Ya había tantos errores que todos estaban diciendo que la gente se estaba yendo, snif.
La gente dice cosas como que no se puede confiar en ello porque es hecho en China, pero yo de verdad agradezco que DeepSeek investigue y publique de forma abierta, y sobre todo que incluso haga públicos sus procesos de prueba y error.
Se ve útil para cuando le encargas el frontend a una IA, gracias por compartir.
Nosotros terminamos estableciéndonos en usar ambos.
Metemos una fase de revisión cruzada con Codex dentro del flujo de comandos slash (dentro de
/ship, en el orden planificación → implementación → verificación → revisión con Codex → reporte) y, al mismo tiempo, colgamos esa misma revisión en elpre-push hook. Si dejas solo los comandos slash, cuando hay prisa alguien simplemente hace push y la revisión se salta; si dejas solo el hook, el resultado recién aparece justo antes del push y ya es tarde.En ambos caminos no llamamos directamente al Codex CLI, sino que desde los dos lados invocamos exactamente el mismo script de bash envuelto una vez (
codex-review.sh). Ese script resuelve en un solo lugar el timeout, la verificación de autenticación, la revisión de secretos y el formato de salida, así que tanto en comandos slash como en hooks el lado que lo invoca queda limpio.La clave es que jamás bloqueamos en función del resultado de la revisión de Codex. Aunque el CLI se caiga o salga un
CRITICAL, el push igual pasa y solo se imprime el resultado. Si aunque sea una vez lo conviertes en bloqueo, cuando Codex marque por error código que en realidad no tiene problemas, el usuario va a terminar usando la opción para saltarse el hook al hacer push (git push --no-verify), y si eso se vuelve costumbre, tener el hook puesto pasa a ser prácticamente lo mismo que no ejecutarlo nunca. Por eso, las verificaciones que sí necesitan bloqueo (lint, tipos, tests, push de archivos secretos) las separamos en gates aparte, y dejamos la opinión del modelo solo como referencia.El script, los comandos slash y el cuerpo del hook están tal cual en los capítulos 4 a 6 de Track, por si te sirve revisarlos.
Dicen que hay gente que lo hace así, y me da curiosidad saber de qué manera lo implementan.
No sé si el desarrollador invoca cada herramienta directamente cuando la necesita, sin agruparlas como agentes separados,
o si lo resuelven con una configuración para que Codex haga la revisión automáticamente al ejecutar un Git Hook.
Ay, Dios mío...
Últimamente Meta parecía un poco menos repugnante, pero vengo a recargar mi enojo contra Meta.
Es un tema algo distinto, pero también se ha dicho últimamente que los bloqueos de los sistemas operativos fueron algo por lo que Meta hizo lobby... Desde la historia de cómo fundaron la empresa hasta cada uno de sus movimientos, de verdad parece que se cambiaron la ética por nada.
Los proveedores de LLM suelen recopilar y usar para entrenar y mejorar sus modelos los datos de los "servicios para consumidores" que los usuarios comunes usan gratis o mediante suscripción. En cambio, los datos de las API o de los servicios empresariales que usan empresas o desarrolladores pagando normalmente quedan protegidos por contrato para que no se utilicen en el entrenamiento.
Aquí hay un punto importante que debemos señalar. Es la pregunta de fondo: "¿De verdad un producto de pago no usa mis datos para entrenar en absoluto?"
En los servicios empresariales de OpenAI se indica por contrato que los datos no se usan para entrenamiento, pero ¿cómo se puede verificar técnicamente esa "promesa" y cómo se puede garantizar legal o institucionalmente? Por ahora, como no podemos vigilar directamente el pipeline de entrenamiento de OpenAI, este es un terreno que inevitablemente depende por completo de la ética del proveedor y del contrato.
La misma pregunta, "¿No existe el riesgo de que mis datos se integren al conocimiento del modelo?", no es un problema exclusivo de DeepSeek, y seguimos teniendo como tarea pendiente que no existe una solución perfecta salvo "comprar" condiciones contractuales más seguras según el presupuesto y la necesidad (por ejemplo: API, plan empresarial), o alojar el modelo por cuenta propia para lograr mayor integridad técnica.
Decir que "como es un LLM chino automáticamente roba datos personales" es una expresión exagerada, y el riesgo estructural sobre el uso de datos no es muy distinto en los LLM de Estados Unidos. Lo importante es revisar con cuidado el tipo de servicio y las condiciones del contrato, y elegir pagar para proteger nuestros datos o bien optar por una alternativa técnica (como el self-hosting).
GitHub tiene muchos problemas últimamente.
Está incluido.
¿Se puede considerar que el código es objeto de protección?
Es una lástima que no sea compatible con
fallback font, así que la salida en coreano deja mucho que desear.Yo también pedí el reembolso...
Además, ni siquiera hacen rollover de los créditos de IA... y eso de aplicar el uso de tokens y el tiempo de uso (la parte que consume cuando está en
Think) sin criterios claros...Entonces que lo cobren por consumo...
Si de verdad lo van a medir como tarifa de uso, al menos deberían poner un período de vigencia y permitir el rollover...
Si va a ser así, entonces no hay motivo para usarlo...
¿Y cuál sería la razón para usarlo en vez de ChatGPT, Claude o Gemini...?
Yo lo usaba con plan anual y, aunque no era mi herramienta principal, sí lo usaba de vez en cuando... se siente como una puñalada por la espalda enorme. Para los usuarios anuales, al menos deberían mantener el precio anterior hasta que termine ese período de vigencia; pero si de repente suben el precio y encima endurecen más los límites de uso...
Parece que se olvidaron del sentido de pagar anual...
Te cobran por adelantado de una vez, a cambio de darte un poco más de promoción y captar clientes durante ese período...
Está bueno, pero al intentar usarlo después de usar una terminal común, se siente demasiado trabado y termino dejando de usarlo.
Si el modelo es bueno, también se reduce la carga del diseño de arneses.
Sale cada trimestre. Definitivamente, incluso en YC's Requests for Startups - Summer 2025 ya había mucho de IA, pero este año parece que su aplicación se ha acercado más al lado vertical y empresarial.
Quienes ya se mudaron a otro lado (como Codeberg) probablemente, al ver esta situación, estén aún más convencidos de que hicieron bien en irse.
Ya lo corregí.
Gracias. Habría que corregirlo.
El señor Noh Seong-hun → es el señor Kim Seong-hyeon.