DEV Community: Ramón Chancay 👨🏻‍💻

Chatbot vs agente de IA: diferencias, ventajas y cuál necesita tu negocio

Ramón Chancay 👨🏻‍💻 — Sun, 27 Sep 2026 20:26:43 +0000

Un chatbot responde; un agente de IA hace. Esa es la diferencia entre chatbot y agente en una línea: el chatbot recibe una pregunta y devuelve un texto, mientras que el agente recibe un objetivo, consulta y modifica tus sistemas (el calendario, el inventario, el CRM) y termina con una tarea completada, no con una explicación de cómo completarla. He construido los dos: chatbots para clientes que responden desde los documentos de una empresa o redactan cartas listas para enviar, un agente autónomo que publica noticias cada tres horas y un agente de voz, hecho como prueba de concepto para un cliente, que termina la llamada con una cita creada en el calendario. La forma más rápida de saber cuál necesitas es mirar qué pasa cuando termina la conversación: si alguien de tu equipo copia datos a otro sistema, ese trabajo es el que haría un agente.

TL;DR

Un chatbot entrega información: responde preguntas desde tus documentos. Un agente entrega resultados: usa herramientas conectadas a tus sistemas para agendar, registrar o actualizar algo.

El chatbot es más barato, más rápido de construir y su peor error es una respuesta equivocada. El agente ahorra trabajo real, pero su peor error es una acción equivocada, y eso exige confirmaciones, permisos acotados y registro de todo lo que hace.

Si la conversación termina con una persona de tu equipo copiando datos a otro sistema, lo que necesitas es un agente. Si termina cuando el cliente tiene su respuesta, un chatbot alcanza.

Qué es un chatbot y qué es un agente de IA

Un chatbot con IA es un programa que conversa: recibe un mensaje, un modelo de lenguaje genera una respuesta y la devuelve. Los buenos no responden de memoria. Buscan primero en los documentos de tu empresa (manuales, políticas, catálogo, preguntas frecuentes) y responden a partir de lo que encontraron; esa técnica se llama RAG, generación aumentada por recuperación. Lo que sale de un chatbot, siempre, es texto: una respuesta, un resumen, un borrador. Es lo que muchas empresas llaman asistente virtual, y puede vivir en tu web o en WhatsApp.

Un agente de IA también conversa, pero además tiene herramientas. Una herramienta es una función que el modelo puede pedir que se ejecute: consultar los horarios libres, crear una reserva, buscar un pedido por número, registrar un contacto en el CRM. El agente decide qué herramienta usar, lee el resultado y decide el siguiente paso, en un ciclo que se repite hasta que la tarea está hecha o hasta que necesita que alguien le confirme algo. Ese ciclo es lo que en la parte técnica se llama agent loop.

La diferencia práctica está en lo que queda cuando termina la conversación. Con un chatbot, el cliente sabe algo que antes no sabía. Con un agente, algo cambió en tus sistemas: hay una cita en el calendario, un ticket abierto, un pedido actualizado.

Diferencia entre chatbot y agente de IA, en una tabla

	Chatbot con IA	Agente de IA
Qué entrega	Una respuesta o un texto	Una tarea completada
Con qué trabaja	Tus documentos y el historial de la conversación	Tus documentos más herramientas conectadas a tus sistemas
Quién hace el paso final	Una persona, con la información que le dio el chatbot	El propio agente, dentro de los límites que le pusiste
Peor error posible	Una respuesta equivocada	Una acción equivocada: una reserva duplicada, un dato mal registrado
Integraciones	Pocas o ninguna	Una por cada sistema que toca
Llamadas al modelo por conversación	Normalmente una por mensaje	Varias por mensaje, una por cada paso del ciclo
Cómo se mide si funciona	Porcentaje de respuestas correctas y de preguntas que no supo responder	Porcentaje de tareas completadas sin intervención humana y errores en acciones

La fila del peor error es la que más pesa al decidir. Un chatbot que se equivoca da una mala respuesta, que se corrige con otra. Un agente que se equivoca deja un efecto en tus sistemas que alguien tiene que detectar y deshacer.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/chatbot-vs-agente-de-ia.

Chatbot vs AI agent: differences, benefits and which one your business needs

Ramón Chancay 👨🏻‍💻 — Sun, 27 Sep 2026 20:26:39 +0000

A chatbot answers; an AI agent acts. That's the difference between a chatbot and an AI agent in a single line: the chatbot takes a question and returns text, while the agent takes a goal, reads and changes your systems (the calendar, the inventory, the CRM) and ends with a finished task, not with an explanation of how to finish it. I have built both: chatbots for clients that answer from a company's documents or draft letters ready to send, an autonomous agent that publishes news every three hours, and a voice agent, built as a proof of concept for a client, that ends the call with an appointment created in the calendar. The quickest way to know which one you need is to look at what happens when the conversation ends: if someone on your team copies data into another system, that work is what an agent would do.

TL;DR

A chatbot delivers information: it answers questions from your documents. An agent delivers outcomes: it uses tools connected to your systems to book, record or update something.

A chatbot is cheaper, faster to build, and its worst mistake is a wrong answer. An agent saves real work, but its worst mistake is a wrong action, which calls for confirmations, narrow permissions and a log of everything it does.

If the conversation ends with someone on your team copying data into another system, you need an agent. If it ends when the customer has their answer, a chatbot is enough.

What is a chatbot and what is an AI agent

An AI chatbot is a program that converses: it receives a message, a language model generates a reply, and it sends it back. Good ones don't answer from memory. They first search your company's documents (manuals, policies, catalog, FAQs) and answer from what they found; that technique is called RAG, retrieval-augmented generation. What comes out of a chatbot is always text: an answer, a summary, a draft. It is what many companies call a virtual assistant or AI assistant, and it can live on your website or on WhatsApp.

An AI agent also converses, but it has tools as well. A tool is a function the model can ask to run: check open time slots, create a booking, look up an order by number, add a contact to the CRM. The agent decides which tool to use, reads the result and decides the next step, in a cycle that repeats until the task is done or until it needs someone to confirm something. On the technical side, that cycle is called an agent loop.

The practical difference is what remains when the conversation ends. With a chatbot, the customer knows something they didn't know before. With an agent, something changed in your systems: there is an appointment in the calendar, an open ticket, an updated order.

Chatbot vs AI agent: the difference in a table

	AI chatbot	AI agent
What it delivers	An answer or a piece of text	A completed task
What it works with	Your documents and the conversation history	Your documents plus tools connected to your systems
Who takes the final step	A person, with the information the chatbot gave them	The agent itself, within the limits you set
Worst possible mistake	A wrong answer	A wrong action: a duplicate booking, a wrongly recorded field
Integrations	Few or none	One for every system it touches
Model calls per conversation	Usually one per message	Several per message, one for each step of the cycle
How you measure it	Share of correct answers and of questions it couldn't answer	Share of tasks completed without human help, and errors in actions

The worst-mistake row is the one that weighs most when deciding. A chatbot that gets it wrong gives a bad answer, which the next answer can correct. An agent that gets it wrong leaves an effect in your systems that someone has to spot and undo.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/chatbot-vs-ai-agent.

Cuánto cuesta desarrollar una app y por qué cotizo precio fijo

Ramón Chancay 👨🏻‍💻 — Sat, 26 Sep 2026 22:10:39 +0000

Cuánto cuesta desarrollar una app, una plataforma web o un chatbot con IA es la primera pregunta que recibe cualquier persona que construye productos digitales, y la que peor se responde. Aquí no vas a encontrar un monto, porque no existe antes de definir qué se construye; vas a encontrar lo que sí se puede saber antes: de qué depende, cuántas semanas suele tomar y cómo leer una cotización. La respuesta honesta es "depende del alcance", que suena a evasiva hasta que entiendes de qué depende exactamente. En este artículo explico las variables que mueven el precio, por qué no doy un número antes de definir qué se va a construir, y cómo funciona mi cotización: un precio fijo por escrito para la primera versión, por hora para el trabajo que no se puede acotar. La idea es que puedas leer cualquier cotización, la mía o la de otro, y saber qué te están vendiendo.

TL;DR

El precio de un producto digital depende de cuántos flujos tiene, qué backend necesita, con qué servicios se integra, si se publica en tiendas y si incluye IA. No de la tecnología con que se escribe.

Un número dado antes de definir el alcance es una adivinanza. Por eso el primer paso es una llamada de 30 minutos y una propuesta escrita, sin costo si decides no avanzar.

Cotizo precio fijo para la primera versión porque el alcance ya se definió y el riesgo de equivocarme al estimar es mío. La auditoría y el mantenimiento van por hora, porque ahí el alcance no se puede cerrar de antemano.

Cuánto cuesta desarrollar una app: de qué depende el precio

El precio de un producto digital es, en su mayor parte, tiempo de una persona con criterio. Lo que hace que ese tiempo crezca es la cantidad de cosas distintas que el producto tiene que hacer bien. Estas son las variables que miro antes de cotizar cualquier proyecto, y que explican casi toda la diferencia entre una cotización y otra:

Variable	Qué la hace crecer	Ejemplo
Flujos y pantallas	Cada recorrido completo que un usuario puede hacer	Registrarse, buscar, reservar y pagar son cuatro flujos, no una app
Backend y datos	Si hace falta un servidor propio, una base de datos y reglas de negocio	Un catálogo que se lee es barato; un inventario que varias personas editan a la vez no
Integraciones	Cada servicio externo con el que hay que hablar	Pagos, notificaciones push, mapas, correo, facturación, un sistema que ya tienes
Publicación	Si el producto va a las tiendas de aplicaciones	Cuentas, revisión de Apple y Google, firma, y volver a pasar por ahí en cada versión
IA	Si un modelo de lenguaje responde a usuarios reales	Hay que evaluarlo antes de exponerlo, y decidir qué hace cuando se equivoca
Diseño	Si existe un diseño en Figma o hay que definir la interfaz	Construir sobre un diseño cerrado es más rápido que decidirlo mientras se programa
Lo que ya existe	Si se parte de cero o de un producto en uso	Un producto heredado se cotiza después de leerlo, no antes

Dos de esas filas suelen sorprender. La primera es la publicación en tiendas: la revisión de Apple y Google es un trabajo con sus propios tiempos y rechazos, y se repite con cada versión. La segunda es la IA: un chatbot que responde bien en la demo y mal frente a un cliente real es peor que no tener chatbot, y evitar eso cuesta tiempo de evaluación que no se ve en la interfaz.

Lo que no mueve el precio, o lo mueve mucho menos de lo que se cree, es la lista de tecnologías. Que la app se escriba en React Native o en Swift cambia decisiones importantes, pero no cambia que registrarse, buscar, reservar y pagar son cuatro flujos que hay que construir y probar.

Lo que sí puedo decir antes de la llamada son los rangos que salen de mi propio trabajo. Una primera versión enfocada de una app móvil o una plataforma web, con un flujo principal, datos reales y una interfaz cuidada, suele tomar entre 4 y 8 semanas de trabajo a tiempo completo. Una funcionalidad de IA sobre un producto que ya existe, como un chatbot con RAG o un flujo de generación, suele salir en 2 a 5 semanas. Productos más grandes, como una plataforma de streaming o de salud, se planifican por fases y cada fase se cotiza por separado. Esas semanas son lo que se cotiza: el precio de la propuesta es ese tiempo, cerrado por escrito, y con cualquier tarifa de mercado que conozcas puedes sacar un orden de magnitud antes de escribirme.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/cuanto-cuesta-un-proyecto-precio-fijo.

How much does it cost to build an app, and why I quote a fixed price

Ramón Chancay 👨🏻‍💻 — Sat, 26 Sep 2026 22:10:35 +0000

How much it costs to build an app, a web platform or an AI chatbot is the first question anyone who builds digital products gets asked, and the one that gets the worst answers. You will not find a dollar figure here, because it does not exist before we define what gets built; you will find what can be known beforehand: what the price depends on, how many weeks it usually takes, and how to read a quote. The honest answer is "it depends on the scope", which sounds evasive until you understand exactly what it depends on. In this article I explain the variables that move the price, why I do not give a number before defining what will be built, and how I quote: a fixed price in writing for the first version, and hourly for the work that cannot be bounded. The goal is for you to be able to read any quote, mine or someone else's, and know what you are being sold.

TL;DR

The price of a digital product depends on how many flows it has, what backend it needs, which services it integrates with, whether it ships to the app stores and whether it includes AI. Not on the technology it is written in.

A number given before the scope is defined is a guess. That is why the first step is a 30-minute call and a written proposal, at no cost if you decide not to go ahead.

I quote a fixed price for the first version because the scope has already been defined and the risk of estimating wrong is mine. The audit and the maintenance are hourly, because there the scope cannot be pinned down in advance.

How much does it cost to build an app: what drives the price

The price of a digital product is, for the most part, the time of one person with judgment. What makes that time grow is the number of different things the product has to do well. These are the variables I look at before quoting any project, and they explain almost all of the difference between one quote and another:

Variable	What makes it grow	Example
Flows and screens	Every complete journey a user can take	Sign up, search, book and pay are four flows, not one app
Backend and data	Whether it needs its own server, a database and business rules	A read-only catalog is cheap; an inventory several people edit at once is not
Integrations	Every external service the product has to talk to	Payments, push notifications, maps, email, invoicing, a system you already have
Publishing	Whether the product goes to the app stores	Accounts, Apple and Google review, signing, and going through it again with every release
AI	Whether a language model answers real users	It has to be evaluated before it goes in front of real users, and you have to decide what it does when it is wrong
Design	Whether a Figma design exists or the interface still has to be defined	Building on a finished design is faster than deciding it while coding
What already exists	Whether you start from zero or from a product in use	An inherited product is quoted after I have read it, not before

Two of those rows tend to surprise people. The first is publishing to the stores: Apple and Google review is work with its own timelines and rejections, and it repeats with every version. The second is AI: a chatbot that answers well in the demo and badly in front of a real customer is worse than no chatbot, and avoiding that costs evaluation time you never see in the interface.

What does not move the price, or moves it far less than people think, is the list of technologies. Whether the app is written in React Native or in Swift changes important decisions, but it does not change the fact that sign up, search, book and pay are four flows that have to be built and tested.

What I can say before the call are the ranges that come out of my own work. A focused first version of a mobile app or a web platform, with one core flow, real data and a polished interface, usually takes 4 to 8 weeks of full-time work. An AI feature on top of a product that already exists, such as a RAG chatbot or a generation flow, usually ships in 2 to 5 weeks. Larger products, such as a streaming or healthcare platform, are planned in phases and each phase is quoted separately. Those weeks are what gets quoted: the price in the proposal is that time, locked in writing, and with any market rate you know you can work out an order of magnitude before you write to me.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/how-much-does-it-cost-to-build-an-app-fixed-price.

Por qué contratarme por Upwork: pagos protegidos, reputación verificable y arbitraje

Ramón Chancay 👨🏻‍💻 — Wed, 23 Sep 2026 23:47:25 +0000

Contratar por Upwork significa que el contrato, los pagos y el registro de lo que se entregó pasan por una plataforma que no controla ninguna de las dos partes. Es la forma en que prefiero trabajar con un cliente nuevo, y la recomiendo incluso a quienes me encontraron por LinkedIn o por un referido. Lo recomiendo porque resuelve los tres riesgos que asumes cuando contratas a alguien que no conoces, en otro país, para construir algo que todavía no existe. Tu dinero queda en custodia hasta que apruebas cada entrega, lo que hago queda registrado, y si no nos ponemos de acuerdo hay un tercero que decide. Escribo esto para explicar cómo funciona cada una de esas tres cosas, qué cuesta y qué no resuelve.

TL;DR

En Upwork, tu dinero no me llega hasta que apruebas la entrega. En precio fijo queda en custodia (escrow) por cada hito; por horas, cada hora lleva registro y el límite semanal lo fijas tú.

Mi reputación en Upwork (Top Rated, 100 % Job Success) la escribieron mis clientes al cerrar cada contrato. Yo no puedo editarla ni borrarla, y puedes leerla antes de escribirme.

Si algo sale mal, hay un camino definido que no depende de mi buena voluntad: primero media Upwork y, si no alcanza, decide un arbitraje.

Qué cambia al contratar por Upwork

Al contratar por Upwork, el contrato, el dinero y la evidencia dejan de depender de la confianza entre las dos partes y pasan a tres mecanismos de la plataforma: custodia del dinero, registro de lo que pasó y un tercero que decide.

Sin plataforma, el acuerdo se sostiene en la confianza y en un contrato que, si se rompe, tendrías que hacer valer en el país del otro. Para un founder que contrata desde Estados Unidos, Europa o cualquier parte de Latinoamérica a alguien en Ecuador, esa segunda parte es casi teórica. Nadie va a litigar un proyecto de unos miles de dólares en otra jurisdicción.

Los tres mecanismos, en concreto:

Custodia del dinero. En contratos de precio fijo, tú depositas el monto de cada hito antes de que yo empiece, y Upwork lo retiene hasta que apruebas la entrega. En contratos por horas, cada hora facturada tiene un registro que puedes revisar antes de pagarla.
Registro de lo que pasó. Los mensajes, las entregas, las horas y las aprobaciones quedan en el contrato. Si hay una discusión sobre qué se pidió y qué se entregó, la evidencia ya existe y ninguno de los dos la puede editar.
Un tercero que decide. Si no llegamos a un acuerdo, Upwork media entre las partes. Si la mediación no alcanza, el caso pasa a un arbitraje cuya decisión es vinculante para los dos.

Nada de esto sustituye elegir bien a la persona. Reduce el costo de equivocarse: si el trabajo no aparece o no sirve, tu pérdida se limita al hito que estaba en revisión, no al proyecto entero. Por eso conviene que los hitos sean cortos, de una o dos semanas de trabajo cada uno.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/por-que-contratar-por-upwork.

Why hire me through Upwork: protected payments, a verifiable track record and arbitration

Ramón Chancay 👨🏻‍💻 — Wed, 23 Sep 2026 23:47:19 +0000

Hiring through Upwork means the contract, the payments and the record of what was delivered run through a platform that neither side controls. It is how I prefer to work with a new client, and I recommend it even to people who found me on LinkedIn or through a referral. I recommend it because it covers the three risks you take on when you hire someone you don't know, in another country, to build something that doesn't exist yet. Your money stays in escrow until you approve each delivery, what I do is on record, and if we can't agree there is a third party who decides. This post explains how each of those three things works, what it costs and what it doesn't solve.

TL;DR

On Upwork, your money doesn't reach me until you approve the delivery. On fixed-price contracts it sits in escrow per milestone; on hourly ones every hour is logged and you set the weekly cap.

My Upwork track record (Top Rated, 100% Job Success) was written by my clients when each contract closed. I can't edit or delete it, and you can read it before you message me.

If something goes wrong, there is a defined path that doesn't depend on my goodwill: Upwork mediates first and, if that isn't enough, an arbitrator decides.

What changes when you hire through Upwork

When you hire through Upwork, the contract, the money and the evidence stop depending on trust between the two sides and move to three platform mechanisms: escrow for the money, a record of what happened, and a third party who decides.

Without a platform, the agreement rests on trust and on a contract that, if broken, you would have to enforce in the other person's country. For a founder hiring from the United States, Europe or anywhere in Latin America someone based in Ecuador, that second part is close to theoretical. Nobody litigates a project worth a few thousand dollars in a foreign jurisdiction.

The three mechanisms, concretely:

Escrow for the money. On fixed-price contracts, you fund each milestone before I start, and Upwork holds the money until you approve the delivery. On hourly contracts, every billed hour has a log you can review before paying it.
A record of what happened. Messages, deliveries, hours and approvals stay in the contract. If there is a dispute over what was asked for and what was delivered, the evidence already exists and neither of us can edit it.
A third party who decides. If we can't reach an agreement, Upwork mediates. If mediation isn't enough, the case goes to arbitration, and the decision binds both sides.

None of this replaces choosing the right person. It lowers the cost of getting it wrong: if the work doesn't show up or doesn't work, your loss is limited to the milestone under review, not the whole project. That is why milestones should be short, one or two weeks of work each.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/why-hire-through-upwork.

Qué es Jev: el modelo de TypeSafe AI que decide en vez de escribir

Ramón Chancay 👨🏻‍💻 — Wed, 23 Sep 2026 05:11:22 +0000

Jev es el primer "modelo System One" de TypeSafe AI: un modelo que no genera texto, sino que recibe un estado y una lista de preguntas tipadas y devuelve valores tipados —un sí o no, una opción de una lista, una puntuación— con probabilidades calibradas. Salió en early access el 15 de septiembre de 2026 y en una semana se volvió el tema de conversación entre quienes construimos sistemas con LLMs. Revisé la documentación y los primeros análisis independientes para responder lo que importa en la práctica: qué es, cómo se llama, cuánto cuesta y en qué parte de un sistema real tiene sentido meterlo.

TL;DR

Jev no escribe: responde preguntas de tipo choice, score o noul (sí/no) con un valor, sus probabilidades y un nivel de confianza que tu código puede usar directamente.

Cuesta 0.042 USD por millón de tokens de entrada, la salida es gratis y la latencia publicada va de 70 a 500 ms. Sirve para clasificar, enrutar, priorizar y evaluar, no para redactar ni razonar.

Úsalo como capa de decisión rápida delante de un LLM: si la confianza es alta actúas, si es baja escalas al modelo grande. Los benchmarks todavía no los ha reproducido nadie independiente.

Qué es Jev y en qué se diferencia de un LLM

Un LLM genera texto token por token. Cuando lo usas para decidir algo —¿este ticket es urgente?, ¿a qué departamento va?— le pides una respuesta en JSON, la parseas y la validas por si el modelo cambió de formato. Buena parte del código que rodea a un LLM en producción existe solo para convertir prosa en un valor que el programa pueda usar.

Jev elimina ese paso. Le mandas un state (el contexto: un mensaje, un documento, el historial de un agente) y un mapa de preguntas, cada una con un tipo declarado. Lo que vuelve no es texto, sino el valor del tipo que pediste más una distribución de probabilidades. No hay nada que parsear y el modelo no puede inventar una categoría que no existe, porque solo puede elegir entre las que definiste.

TypeSafe AI lo llama "System One" por la distinción entre pensamiento rápido e intuitivo (sistema 1) y lento y deliberado (sistema 2). La idea es que los LLMs actuales cubren el sistema 2 y que una gran parte de las decisiones de un software no necesita deliberación, sino un juicio rápido y medible. La empresa tiene sede en San Francisco, la fundó Diogo Almeida —ex investigador de OpenAI y uno de los coautores de RLHF— y anunció junto al lanzamiento una ronda semilla de 40 millones de USD liderada por DCVC. La demo que más circuló fue Jev jugando Doom: recibe un frame y devuelve el siguiente movimiento, sin comentario de por medio.

Los tres tipos de pregunta: choice, score y noul

Toda la API se reduce a tres primitivas. Cada pregunta que le haces a Jev es de uno de estos tipos:

Tipo	Qué responde	Qué devuelve	Ejemplo
`choice`	Una opción de una lista cerrada	La opción elegida, su confianza y la probabilidad de cada opción	¿A qué departamento va este ticket?
`score`	Un nivel en una escala ordenada de 2 a 10 niveles	La puntuación, su confianza y la distribución por nivel	¿Qué tan frustrado está el cliente, de 1 a 5?
`noul`	Sí o no	La probabilidad de que la afirmación sea verdadera, entre 0 y 1	¿El mensaje pide una devolución?

La diferencia entre la respuesta y la confianza es lo más útil del diseño. La respuesta dice qué eligió el modelo; la confianza, calculada a partir de la forma de la distribución, dice si conviene actuar. Si la probabilidad se concentra en una opción, la confianza es alta. Si está repartida entre dos o tres, es baja, aunque la opción ganadora sea la misma. Con un LLM esa señal no existe de forma nativa: te devuelve una categoría con la misma seguridad aparente cuando acierta que cuando duda.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/que-es-jev-typesafe-ai.

What is Jev: TypeSafe AI's model that decides instead of writing

Ramón Chancay 👨🏻‍💻 — Wed, 23 Sep 2026 05:11:18 +0000

Jev is TypeSafe AI's first "System One model": a model that doesn't generate text. It takes a state and a list of typed questions and returns typed values—a yes or no, an option from a list, a score—with calibrated probabilities. It launched in early access on September 15, 2026, and within a week it became the main topic among those of us building systems with LLMs. I went through the documentation and the first independent analyses to answer what matters in practice: what it is, how to call it, what it costs and where in a real system it makes sense to use it.

TL;DR

Jev doesn't write: it answers choice, score or noul (yes/no) questions with a value, its probabilities and a confidence level your code can use directly.

It costs 0.042 USD per million input tokens, output is free and the published latency is 70 to 500 ms. It's for classifying, routing, prioritizing and evaluating, not for writing or reasoning.

Use it as a fast decision layer in front of an LLM: if confidence is high you act, if it's low you escalate to the large model. No one has independently reproduced the benchmarks yet.

What is Jev and how is it different from an LLM

An LLM generates text token by token. When you use it to decide something—is this ticket urgent? which department does it go to?—you ask for a JSON answer, parse it and validate it in case the model changed the format. A good part of the code around an LLM in production exists only to turn prose into a value the program can use.

Jev removes that step. You send it a state (the context: a message, a document, an agent's history) and a map of questions, each with a declared type. What comes back isn't text, but a value of the type you asked for plus a probability distribution. There's nothing to parse, and the model can't invent a category that doesn't exist, because it can only choose among the ones you defined.

TypeSafe AI calls it "System One" after the distinction between fast, intuitive thinking (system 1) and slow, deliberate thinking (system 2). The idea is that current LLMs cover system 2, and that a large share of the decisions a piece of software makes don't need deliberation, just a fast and measurable judgment. The company is based in San Francisco, was founded by Diogo Almeida—a former OpenAI researcher and one of the co-authors of RLHF—and announced a 40 million USD seed round led by DCVC alongside the launch. The demo that spread the most was Jev playing Doom: it receives a frame and returns the next move, with no commentary.

The three question types: choice, score and noul

The whole API comes down to three primitives. Every question you ask Jev is one of these types:

Type	What it answers	What it returns	Example
`choice`	One option from a closed list	The chosen option, its confidence and the probability of each option	Which department does this ticket go to?
`score`	A level on an ordered scale of 2 to 10 levels	The score, its confidence and the distribution per level	How frustrated is the customer, from 1 to 5?
`noul`	Yes or no	The probability that the statement is true, between 0 and 1	Is the message asking for a refund?

The difference between the answer and the confidence is the most useful part of the design. The answer says what the model chose; the confidence, computed from the shape of the distribution, says whether you should act on it. If the probability is concentrated on one option, confidence is high. If it's spread across two or three, it's low, even when the winning option is the same. An LLM has no native equivalent of that signal: it returns a category with the same apparent certainty whether it's right or unsure.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/what-is-jev-typesafe-ai.

Heredaste un producto: la auditoría de código antes de seguir

Ramón Chancay 👨🏻‍💻 — Sun, 20 Sep 2026 00:50:40 +0000

Heredar un producto es quedarte a cargo de un software que construyó otra persona: el desarrollador se fue, la agencia terminó el contrato, o el código pasó por tantas manos que ya nadie sabe con certeza qué hace. Tienes un producto que funciona —o que funciona a medias— y ninguna forma confiable de saber qué tan sano está por dentro. Una auditoría de código es la respuesta a esa pregunta antes de gastar el primer dólar en cambios: alguien lee lo que hay, lo contrasta con lo que tu negocio necesita y te entrega un veredicto escrito sobre qué conservar, qué reparar y qué reescribir. Escribo esto porque es la mitad de mi trabajo y porque la decisión que se toma sin auditoría casi siempre es la cara.

TL;DR

Antes de pedir funcionalidades nuevas sobre un producto heredado, necesitas saber qué tienes. Eso se responde con una auditoría del código y la arquitectura que termina en un documento, no en una conversación.

La auditoría no revisa solo el código: revisa quién es dueño de las cuentas, qué tan caro es sostener el producto y qué riesgos ya están activos. Varios de los hallazgos más urgentes nunca son técnicos.

"Reescribir todo desde cero" es la recomendación más frecuente de quien llega nuevo y la más cara para ti. Casi siempre hay un núcleo que se conserva y tres cosas concretas que se reparan.

Qué significa heredar un producto

Los casos llegan casi siempre en una de estas formas:

El desarrollador se fue. Trabajaba solo, tenía todo en la cabeza y dejó un repositorio sin documentación. A veces sigue respondiendo mensajes por un tiempo; a veces no.
La agencia terminó y desapareció. Entregó una versión que funcionaba el día de la entrega. Seis meses después nadie contesta y el contrato no dice qué pasa con las cuentas.
El código se desordenó con los años. Nadie se fue: el producto acumuló cambios pequeños y urgentes hasta que cada modificación nueva rompe algo viejo y ya nadie se atreve a tocar ciertas partes.
Compraste el producto. Adquiriste una empresa o una aplicación y el software vino incluido, sin que nadie de tu lado lo haya revisado nunca.

En los cuatro el punto de partida es el mismo: existe un producto que tus usuarios usan y tu equipo no puede responder preguntas básicas sobre él. Cuánto cuesta mantenerlo al mes. Qué pasa si se cae un martes a las nueve de la noche. Si los datos de tus usuarios están donde deberían. Cuánto trabajo real hay detrás de la funcionalidad que quieres agregar el mes que viene.

No saber esas respuestas no es una falla de gestión. Es el estado normal de un producto que cambió de manos sin traspaso. Lo que sí es una falla es seguir construyendo encima sin resolverlo.

Por qué lo primero no es programar

La reacción natural cuando heredas un producto es pedir lo que te hace falta: arreglar el error que reportan los usuarios, agregar la pantalla que te pidió un cliente, publicar la versión nueva. Es razonable y casi siempre sale mal, por tres motivos.

No sabes lo que estás tocando. En un código que no conoces, un cambio de veinte líneas puede ser de veinte líneas o de tres semanas. Nadie puede cotizarte de verdad sin haber leído lo que hay, y quien te dé un precio sin leerlo lo está adivinando.

No sabes qué está en riesgo ahora mismo. Las cosas que más urgen en un producto heredado rara vez son las que se ven desde afuera. Una llave de acceso publicada en el repositorio, una base de datos sin copias de respaldo o un servicio que dejó de recibir actualizaciones de seguridad no aparecen en la lista de pendientes de nadie, y cualquiera de las tres puede costarte el producto entero.

No sabes si conviene seguir con eso. A veces la respuesta honesta es que el código no vale lo que cuesta mantenerlo, y esa es una decisión de negocio que necesitas tomar con información, no después de haber invertido seis meses en mejorarlo.

Una auditoría cuesta una fracción de lo que cuesta el primer mes de desarrollo a ciegas. Ese es todo el argumento.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/auditoria-de-codigo-producto-heredado.

You inherited a product: the code audit before you continue

Ramón Chancay 👨🏻‍💻 — Sun, 20 Sep 2026 00:50:36 +0000

Inheriting a product means being left in charge of software somebody else built: the developer moved on, the agency's contract ended, or the code passed through so many hands that nobody knows for certain what it does any more. You have a product that works—or half works—and no reliable way to tell how healthy it is inside. A code audit is the answer to that question before you spend the first dollar on changes: someone reads what is there, holds it against what your business needs, and hands you a written verdict on what to keep, what to fix and what to rewrite. I am writing this because it is half of my work, and because the decision taken without an audit is almost always the expensive one.

TL;DR

Before asking for new features on an inherited product, you need to know what you have. That is answered by an audit of the code and the architecture that ends in a document, not in a conversation.

The audit does not only review code: it reviews who owns the accounts, how expensive the product is to keep running, and which risks are already live. Several of the most urgent findings are never technical.

"Rewrite everything from scratch" is the most frequent recommendation from whoever arrives new, and the most expensive one for you. There is almost always a core worth keeping and three concrete things to fix.

What inheriting a product means

The cases almost always arrive in one of these shapes:

The developer left. They worked alone, kept everything in their head, and left a repository with no documentation. Sometimes they still answer messages for a while; sometimes they don't.
The agency finished and disappeared. It delivered a version that worked on delivery day. Six months later nobody answers, and the contract says nothing about what happens to the accounts.
The code drifted over the years. Nobody left: the product piled up small, urgent changes until every new one breaks something old, and nobody dares touch certain parts.
You bought the product. You acquired a company or an app and the software came with it, without anyone on your side ever having reviewed it.

In all four the starting point is the same: there is a product your users use, and your team cannot answer basic questions about it. How much it costs to run per month. What happens if it goes down on a Tuesday at nine at night. Whether your users' data is where it should be. How much real work sits behind the feature you want to add next month.

Not knowing those answers is not a management failure. It is the normal state of a product that changed hands without a handover. What is a failure is to keep building on top without resolving it.

Why the first move is not writing code

The natural reaction when you inherit a product is to ask for what you need: fix the bug users are reporting, add the screen a client asked for, ship the new version. It is reasonable, and it almost always goes wrong, for three reasons.

You don't know what you are touching. In code you don't know, a twenty-line change can be twenty lines or three weeks. Nobody can really quote you without having read what is there, and whoever gives you a price without reading it is guessing.

You don't know what is at risk right now. The most urgent things in an inherited product are rarely the ones visible from the outside. An access key published in the repository, a database with no backups, or a service that stopped receiving security updates appear on nobody's to-do list, and any of the three can cost you the whole product.

You don't know whether it is worth continuing with it. Sometimes the honest answer is that the code is not worth what it costs to maintain, and that is a business decision you need to take with information, not after investing six months in improving it.

An audit costs a fraction of what the first month of blind development costs. That is the entire argument.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/code-audit-inherited-product.

Qué es un ingeniero de producto y en qué se diferencia de un programador

Ramón Chancay 👨🏻‍💻 — Sat, 19 Sep 2026 19:53:31 +0000

Un ingeniero de producto (product engineer, en inglés) es la persona que se hace responsable de que tu producto digital funcione y resuelva lo que tu negocio necesita, no solo de que el código que le pediste quede escrito. Decide qué debe hacer la primera versión y qué se deja para después, la construye, la publica y la mantiene funcionando. Un programador, en el sentido más común de la palabra, recibe una tarea definida por otro y la ejecuta bien. Los dos roles son legítimos y los dos escriben código; la diferencia está en quién toma las decisiones y quién responde por el resultado. Escribo esto porque es lo que más me preguntan los founders antes de contratar, y porque elegir mal el rol sale más caro que elegir mal la tecnología.

TL;DR

Un programador ejecuta tareas que otro definió. Un ingeniero de producto define qué se construye, lo construye, lo publica y responde por el resultado.

Si en tu empresa nadie decide qué va en la primera versión y qué no, ese trabajo lo terminarás haciendo tú, sin experiencia, o no lo hará nadie. Ahí es donde un ingeniero de producto paga.

Si ya tienes un CTO o un líder técnico que decide, lo que necesitas es un buen programador. Contratar de más también es un error.

Qué hace un ingeniero de producto

La forma más corta de explicarlo: un ingeniero de producto responde por el producto, no por los tickets. Cuando un cliente me entrega su app móvil, su sitio o plataforma web, o su chatbot con IA, lo que recibe a cambio es una sola persona responsable de que eso exista, funcione y siga funcionando. Eso incluye cosas que normalmente se reparten entre cuatro perfiles: entender el negocio, definir el alcance, diseñar cómo se resuelve, escribir el código, publicarlo y mirar qué pasa después.

Lo que define el rol no es la lista de tareas, sino dónde empieza y dónde termina la responsabilidad. Empieza antes de que exista una tarea, en la conversación donde se decide qué vale la pena construir. Y termina después de que el código está escrito, cuando el producto lleva meses en manos de usuarios reales y hay que decidir qué se arregla, qué se mide y qué viene después.

En mi caso trabajo así desde 2019, como contratista independiente, para founders y equipos que no tienen un líder técnico en casa. Antes trabajé dentro de equipos con la estructura tradicional, y esa experiencia es justamente lo que me hace valorar el rol de programador cuando la estructura existe.

Qué hace un programador, y por qué no es una crítica

Un programador recibe una especificación, una tarea o un diseño, y lo convierte en software que funciona. Es un trabajo difícil y hay programadores excelentes que no quieren ni deberían tener que decidir qué se construye. En un equipo con un product manager, un diseñador y un líder técnico, ese reparto es correcto: cada uno decide en su terreno y el programador puede concentrarse en hacer bien la parte más técnica.

El problema aparece cuando contratas a un programador y no tienes a nadie que haga el resto. Las decisiones no desaparecen; alguien las toma igual. Si no hay quien las tome con criterio, pasan una de dos cosas:

Las tomas tú, que conoces tu negocio pero no sabes qué es caro de construir, qué es frágil o qué va a doler dentro de seis meses.
Las toma el programador de forma implícita, tarea por tarea, sin ver el conjunto y sin que nadie le haya pedido que lo vea.

Ninguna de las dos es culpa del programador. Le pediste que ejecutara y ejecutó. El hueco estaba en el rol que nadie ocupó.

La diferencia en una tabla

	Programador	Ingeniero de producto
Qué recibe	Una tarea definida por otro	Un problema del negocio
Qué entrega	Código que cumple la tarea	Un producto publicado y en uso
Quién decide el alcance	Alguien más	Él, contigo
Qué pasa si la tarea estaba mal planteada	La hace igual, o pregunta	La cuestiona antes de empezar
Qué pasa cuando algo falla en producción	Depende de quién lo detecte	Es su responsabilidad detectarlo
Cómo se mide su trabajo	Tareas completadas	Resultados del producto
Quién habla contigo	A menudo un intermediario	La misma persona que escribe el código

La fila que más importa es la tercera. Definir el alcance de la primera versión es donde se gana o se pierde el dinero de un proyecto, y es precisamente la parte que un programador, por definición del rol, no hace.

Sigue leyendo

Hasta aquí la primera mitad. El recorrido completo — con el resto de la implementación, las decisiones de diseño y lo que solo aparece en producción — está en mi blog:

Lee el artículo completo en ramonchancay.me →

Publicado originalmente en www.ramonchancay.me/es/blog/que-es-un-ingeniero-de-producto.

What is a product engineer, and how is that different from a programmer?

Ramón Chancay 👨🏻‍💻 — Sat, 19 Sep 2026 19:53:27 +0000

A product engineer is the person responsible for making your digital product work and solve what your business needs, not just for writing the code you asked for. They decide what the first version should do and what can wait, build it, launch it and keep it running. A programmer, in the most common sense of the word, receives a task someone else defined and executes it well. Both roles are legitimate and both write code; the difference is who makes the decisions and who answers for the result. I am writing this because it is the question founders ask me most before hiring, and because picking the wrong role costs more than picking the wrong technology.

TL;DR

A programmer executes tasks someone else defined. A product engineer defines what gets built, builds it, launches it and answers for the result.

If nobody in your company decides what goes into the first version and what does not, you will end up doing that job yourself, without the experience, or nobody will. That is where a product engineer pays off.

If you already have a CTO or a technical lead who decides, what you need is a good programmer. Over-hiring is a mistake too.

What a product engineer does

The shortest way to put it: a product engineer answers for the product, not for the tickets. When a client hands me their mobile app, their website or platform, or their AI chatbot, what they get in return is one person responsible for making that thing exist, work and keep working. That covers work normally split across four profiles: understanding the business, defining the scope, designing how it gets solved, writing the code, launching it and watching what happens next.

What defines the role is not the list of tasks but where the responsibility starts and ends. It starts before a task exists, in the conversation where you decide what is worth building. And it ends after the code is written, when the product has been in real users' hands for months and someone has to decide what gets fixed, what gets measured and what comes next.

In my case I have worked this way since 2019, as an independent contractor, for founders and teams without a technical lead in-house. Before that I worked inside teams with the traditional structure, and that experience is exactly what makes me value the programmer role when the structure exists.

What a programmer does, and why that is not a criticism

A programmer receives a specification, a task or a design and turns it into working software. It is hard work, and there are excellent programmers who do not want to decide what gets built and should not have to. In a team with a product manager, a designer and a technical lead, that split is the right one: each person decides in their own area and the programmer can focus on doing the most technical part well.

The problem shows up when you hire a programmer and have nobody to do the rest. The decisions do not disappear; someone makes them anyway. If there is nobody to make them with judgment, one of two things happens:

You make them, and you know your business but not what is expensive to build, what is fragile or what will hurt in six months.
The programmer makes them implicitly, task by task, without seeing the whole and without anyone having asked them to.

Neither is the programmer's fault. You asked them to execute and they executed. The gap was in the role nobody filled.

The difference in one table

	Programmer	Product engineer
What they receive	A task defined by someone else	A business problem
What they deliver	Code that completes the task	A launched product in use
Who decides the scope	Someone else	They do, with you
What happens if the task was framed wrong	They build it anyway, or ask	They question it before starting
What happens when something breaks in production	Depends on who notices	Noticing it is their job
How their work is measured	Tasks completed	Product outcomes
Who talks to you	Often an intermediary	The same person writing the code

The row that matters most is the third one. Defining the scope of the first version is where a project's money is won or lost, and it is precisely the part a programmer, by definition of the role, does not do.

Keep reading

That is the first half. The full walkthrough — with the rest of the implementation, the trade-offs and the things that only show up in production — is on my blog:

Read the full post on ramonchancay.me →

Originally published at www.ramonchancay.me/blog/what-is-a-product-engineer.