Es posible que veas primero Laboratorio 2 que Laboratorio 1.
Laboratorio 1 es una prueba de panel de control hecha en Minimax 2.5, para probar sus capacidades gráficas de diseño de pantallas.
Laboratorio 2 es una prueba de capacidades del LLM público Kimi, https://www.kimi.com/ versión gratuita en chat 2.5, para revisar si puede implementar la lógica de un sistema de 2026 en base a un documento generado por Claude.
Código disponible en el repositorio :
https://github.com/AlfonsoOrozcoAguilarnoNDA/maltir
Esto es un trabajo en curso y siempre se verá en: https://github.com/AlfonsoOrozcoAguilarnoNDA/maltir/ la versión más actual. El objetivo es proporcionar una prueba a Kimi, en base a la lógica de un proyecto de 2006.
Es un sistema de compras y cotizaciones, con mis reglas de un sistema hecho en 2006 y actualizado a época moderna. La palabra MALTIR es una palabra rúnica de Diablo 2, que significa prudencia.
El sistema de compras con esas reglas me permitía, en la empresa en que se hizo, reaccionar de manera prudente al estado real de la situación de entregas. Aunque no podían modificarse ciertas cosas, era para evitar que compras o almacén justificaran sus errores.
En su momento, si había una adecuación o corrección, tenían que ir a mi oficina y yo lo hacía en menos de cinco minutos en base a datos, si era razonable. Mandaba un correo como evidencia, además de desarrollar una orden de trabajo en PDF que les enviaba por correo.
En 2026 sigue siendo necesario una persona incorruptible y cuya palabra valga. Eso es, a veces, más importante que todo el sistema de compras.
Revisa el documento *.doc del repositorio para más detalles .
https://github.com/AlfonsoOrozcoAguilarnoNDA/maltir/blob/main/SistemaCompras_KIMI_Benchmark.docx
Puedes ver allí en el repositorio el proyecto completo y mis observaciones. Debe considerarse esto como una prueba de concepto.
- A Kimi no se le ocurrió generarme los Incoterms en la tabla de Incoterms más comunes. Es, en pocas palabras, el compromiso del proveedor de entregarnos de cierto modo las mercancías. Muy importante por fines de control y hubo una modificación en 2020. Ya que me lo dijo, lo incorporé al archivo de estructura.
| Código | Uso más común en |
|---|---|
| EXW | Compras locales, recolección por comprador |
| FCA | Multimodal, contenedores |
| CPT | Transporte terrestre/aéreo internacional |
| CIP | Transporte terrestre/aéreo con seguro |
| DAP | Entrega en almacén del comprador sin descarga |
| DPU | Entrega en terminal con descarga incluida |
| DDP | Importaciones puerta a puerta (vendedor todo incluido) |
| FAS | Granel, carga pesada puerto |
| FOB | El más usado en importaciones marítimas desde Asia |
| CFR | Exportaciones marítimas (vendedor controla flete) |
| CIF | Muy usado en importaciones marítimas con seguro incluido |
Conocimiento de dominio: no solo generó el SQL, sino que incluyó las definiciones correctas de los Incoterms 2020 (como el cambio de DAT por DPU), lo cual es vital para un sistema de compras profesional.
De momento me generó los primeros 9, lo cual es muy decente. Hay un modo ilimitado de 15 USD al mes. El mensaje de error que tengo a las 13:22 del domingo es:
System is currently busy. Please try again later.
Así que en unas horas veo para seguir del 10 en adelante.
Por ahora empiezo a revisar los primeros nueve archivos.
- El carrito de compras se ve bien. Subí una imagen llamada bluegirl3 (por el color azul que parece que se está usando) y se ve muy bien.
- La pantalla de catalogos de unidades, di de alta una altas bajas y cambios, unica observación, parpadea al momento de mostrar el modal. No esta mal.
- El parpadeo debe deberse a un fade pero lo dejo paraarrglar al último. Nota :
- Prueba rápida: Si le quitas la clase
fadealdivdel modal y el parpadeo desaparece, el problema es la aceleración por hardware del navegador al intentar animar la transparencia.
- Prueba rápida: Si le quitas la clase
- Lo mismo con Incoterms: funcionó bajas, cambios y edición, no probé altas.
- En alta de proveedores probé altas, di de alta CFE DISTRIBUCIÓN, y voy a manejar como si la luz se repartiera por kilos para fines del experimento.
- Di de alta el artículo kilogramo de luz, que ya sabemos que no existe y que en realidad es kilowatt, pero es solo como prueba. Clave SAT de 83101804 generación de energía. Suspendí, edité, reactivé y di de alta. Sigue con parpadeo.
- Esto se ve bien, seguire despuéscon las pruebas cuando kimi no me diga qu el sistema está ocupado.
A las 17:47 seguía igual en Kimi, así que cargué una nueva pantalla en Kimi, le pasé el proyecto en DOC y el .css, y le pedí que me generara el 10 y el 11, y sí lo hizo. Luego hizo del 12 al 19. Asumo que la conversación tuvo un largo estimado.
Y terminó a las 17:58. De manera preliminar puedo decir que después del documento original tardó entre 20 y 25 minutos en generar todo el código. En este momento no puedo verificarlo, pero va muy bien.
Conclusiones preliminares:
- La separación en chunks funciona. La idea era justamente dividir la carga pero al mismo tiempo poder ir haciendo una operación o iteración. Ejemplo: si después me salen requisitos extras de proveedores, alterar la tabla y pedirle a Kimi que rehaga el chunk.
- Vale la pena probar porque Kimi ya está disponible en versiones LLM descargables, aisladas, y eso debería hacerlo después.
En este momento son las 18:00 y haré una pausa. En un rato uno todos los archivos del 10 al 19.
El crear cotización tiene un problema: el comportamiento humano. Nuestros usuarios pueden estar en babia, pero además el sistema saca por tiempo y el recolector de basura de PHP, lo cual tendríamos que explicar en una capacitación. Existe el riesgo de que la persona trate de hacer dos cotizaciones a la vez, lo cual es peligroso y descuidado. El comportamiento descuidado es del usuario.
Yo sugeriría usar dos navegadores diferentes, pero se presta a errores.
En el chunk 12 por favor considera meter una transacción para que no haya error, y mysqli_real_escape_string($link, $session_usuario) para sanitizar el usuario.
Sería bueno hacer algo para deshabilitar el doble clic y asegurarte de que el input tenga step correcto de seis decimales.
Regenera el chunk 12.
FIN PROMPT
En la misma pantalla gemini encontro un posible error de duplicacion asiquele pedi a kimi quelo revisara.
INICIA PROMPT
Cuidado: Si $nueva_cantidad en la tabla respuesta_cotizacion representa el total autorizado para ese proveedor, la lógica de sumar directamente al detalle podría duplicar cantidades si no se tiene cuidado.
Recomendación: Asegúrate de que
cantidad_autorizadaenrespuesta_cotizacioninicie en 0 y solo se actualice una vez. Si permites re-autorizar, la lógica de suma en el detalle debería restar primero el valor anterior para evitar inflar el inventario solicitado.
- Puede tener comillas el usuario y causaria problemas.
- No hay transacciones.
- La logica de negicio puede no ser clara para un auditor Que pasa si se recibe de mas ? EN REALIDAD NO ES ASUNTO DE ALMACEN.
INICIA PROMPT
En el chunk 16 de entrada de mercancía nos volvió a pasar lo de no sanitizar el usuario, y que no están en una transacción los tres updates. Esa es responsabilidad de compras en base a la pantalla de ajustes: si se recibió o no es mercancía, es usuario diferente.
Quizá convenga poner un comentario: en realidad el proveedor debería enviar la factura por la diferencia, o compras pedirle una rebaja si ya le pagamos por lo que no entregó.
Siendo sinceros, la factura la suelen hacer por lo que entregaron en realidad. Así que quizá debería incluirse en el comentario en código que la diferencia de precio debe verla compras y no almacén. Sería parte de un futuro módulo contable, no de almacén entrada de mercancías como es esta pantalla. Deja un comentario alusivo..
Ya grabé los 19. De momento me interesaba ver si Kimi funcionaba para iteraciones, proceso por chunks. Ya aprendí que el documento central me permite hacerlo a pesar de que haya saturación de sesión. Con el modelo gratuito y mi experiencia, más revisiones preliminares de Gemini normal gratuito, calculo que invertí unos 50 minutos en Kimi divididos en dos partes, y generar este texto y subirlo al repositorio fueron unas dos horas más.
Aunque evidentemente tengo que probar del 10 en adelante, no puede computarse los años de experiencia que tengo, aunque este sistema lo hice en reglas originales en 2006, hace 20 años.
- Agregar partida en crear cotización no está funcionando adecuadamente, se le pide regenerar el chunk 10. Parte del problema era que header no tenía
session_start. La corrección funcionó, pero se tendrá que hacer un módulo 20 después para revisar cotizaciones que no tengan partidas y marcarlas como cerradas, o en el dashboard.Se grabó bien el caso de ejemplo, funcionó correctamente y di de alta el mismo artículo con diferentes condiciones para dos días distintos: misma cotización, diferentes partidas.Solución sugerida fue en base a CLAUDE, le di losdatos a Kimi y kimi los puso. - Funciona capturar respuesta proveedor, loagregué alheader. <a class=“dropdown-item” href=“capturarrespuestacotizacion.php”><i class=“fas fa-file-signature”></i> Capturar Respuesta</a> y cerrar cotización, tambien tuve que poner en el header entradade mercancía.
- Funciona biencerrar cotización y captura de incidencias.
- Cuidado, cerrar cotización tuvo el mismo parpadeo.
- En chunk 16 entrada de mercancía solo queriarecibir de las que estuvieran abierta, y no debe ser así. Solo se debe de poder recibir mercancía si hay autorizada que es un estado diferente.. al tratar de verlo me dijo que reiniciara en tres horas. prompt actual :
- Autorizar ya se llama en consulta. hay que rehacer el chunk 16. te explico Esta cotización ya está cerrada. No se pueden registrar entradas. es incorrecto, porque siempre ue recibamos ya va a estarcerrada, el problma puede ser que no se haya autorizado ninguna partida y lo ya recibido al 100C o mas, no puede recibirse. Consideraque debe revisarse aque precio cotizó la persona proveedor y quiza hacer unamultiplicación de captura . ej si cotizo a 100 y metemos 10 piezas mostrar en un readonly 10000 por si el proveedor nos cambió el precio este enterado el de entrada de mercancía. Asegurate de manejar como una trsnaccion y deshabilitar el boton de guardar paraque no se guarde dos veces.
- Ya quedó esa corrección pero hay un autorizado de cero en las dos partidas, l oque no debe ser. Hay un error probablementeen las dos pantallas, entardademercanciay en autorizar. LO verifico en la tarde.
- Me quedé revisando entradade merancías peor necesito mas tiempo
- Checando el 17 dashboard de pendientes hay unos errores en la logica, y fue necesario por mismo kimi agregar unccampo cantidad_recibida DECIMAL(14,6) DEFAULT 0, arespuestacotizacion, ya altere el repositorio en chunk *.sql y alteré el documento base *.docx
- Parece que el error de entradamercancia era por este campo. Empiezo a pensar que Entradamercancia no debe tener una entrada en menu, sino llamarse desde el dashboard lo cual tiene bastante sentido.
- hay que verificar si en respuesta_cotizacion alguna cantidad_cotizada es cero. eso no debería de ser, es un barrido o plan de control.
-
Your conversation with Kimi is getting too long. Try starting a new session.Que procede ? de momento tengo que salir, pero segun yo es generar una nueva ventana, que sería la tercera y pasarle el css y el nuevo doc. Noto limitaciones de kimi pero se puede trabajar. Eso es bueno por el entorno previo de viernes social. En aquel experimento la persona E, de Kimi, encontro cosas que nadie mas. mientras escribo esto estoycon kimi en el segundo monitor.Creo que lo mas sensato es dejar los cambios como estan en unos minutos, ya que kimi está corrigiendo un error del punto 16
- Lo que yo noto es que si se puede trabajar con kimi y que ayuda muchisimo el proceso de chunks, pero está un poco verde en ejecución. Es mejor en lógica. El sistema como esta de momento esta “dañado” pero funcional en un 80%. Tengo que verificar pero tengo que salir además a otra de mis casas. Hare un mensaje de seguimiento mas tarde.
Contexto y dónde estamos: El foco de hoy era el benchmarking de Kimi más que el código en sí. Es un modelo que se siente “verde” en ejecución (el parpadeo de los modales o el olvido de sanitizar), pero puede ser superior en lógica pura de negocio si se le guía con el mapa correcto (el documento central).
El factor Context Window: El éxito de los 19 chunks dependió de la “memoria externa” (el .docx) y no de la memoria de la sesión de Kimi. Es una lección vital para usar modelos gratuitos.
Soberanía tecnológica: Refuerza la idea de por qué elegimos PHP 8.x procedural. En un mundo obsesionado con dependencias de NPM, el enfoque de “archivo único por módulo” es lo que permite que el sistema sea auditable y resiliente. Es casi imposible lograr este nivel de calidad con Laravel o Symfony, y si fueran compras de sector salud no lo podríamos hacer por trazabilidad y dependencias no auditables.
Importante:
Tener pocas dependencias es indispensable. Por Compliance La trazabilidad no es negociable. a ) En sectores críticos, una dependencia oculta en un framework es un punto ciego; b ) el código procedural es un libro abierto para todos y mucho mas mantenible que estructura de objetos
En el repositorio se pueden ver casi todas laspantalals probadas.
Conclusiones del laboratorio con Kimi:
-
Proceso por Chunks: Confirmado que, sabiendo fragmentar la lógica (los 19 módulos), puedes vencer la saturación de contexto de las sesiones gratuitas. El “documento central” actúa como el mapa que evita que la IA se pierda.
-
La Experiencia no es Computable: Una IA puede escribir un
while, pero no sabe por qué es mejor untextareapara copiar a Outlook que un servidor SMTP, ni entiende la importancia de un campoPAPELERAen lugar de unDELETE. Esa es la sabiduría de campo que la IA solo espejea. -
Evolución 2006 vs 2026: Pasar de MEMORIA de las reglas originales de hace dos décadas a un entorno moderno, manteniendo la premisa de “Soberanía Tecnológica” y “Air-Gapped” (sistemas que no mueren si se cae la nube).
Todavía no puedo opinar de la calidad de Kimi pero se ve bien.
Código disponible en el repositorio :
