Primero lee bien los datos; después, calcula bien

Pize es un asistente de programación con IA para computación científica y análisis estadístico. Funciona en Pize Code y Positron, y también se ofrece como SDK.

La mayoría de los agentes de programación dedican sus esfuerzos a escribir más código. Los errores en estadística e investigación suelen producirse antes: si los datos se leen mal, cada prueba, modelo e inferencia posterior hereda el error sin que se note. Pize se concentra en ese punto: primero hace que el modelo conozca con precisión la forma, los tipos y los valores ausentes de los datos; después escribe y ejecuta código, interpreta gráficos y corrige resultados en la sesión de R / Python que usted ya utiliza.

Pize también es un agente de programación completo: ediciones en varios archivos, terminal, planificación y ejecución, reglas del proyecto, elección de modelos y MCP para acceder a herramientas que ya existen en un laboratorio o sistema interno. Úselo en Pize Code, Positron, mediante la CLI o a través del SDK.

• Qué es. Un agente de programación optimizado para computación matemática y análisis estadístico. La lectura, el cálculo y las pruebas se realizan en una sesión activa. Los resultados se pueden volver a calcular.
• Qué no es. No es un autocompletador genérico con otra apariencia ni un sustituto de Cursor que escriba un poco de todo. El objetivo no es completar código, sino leer bien los datos y obtener cálculos fiables.
• Dónde funciona. En Pize Code, Positron, mediante la CLI y el SDK.
• Qué recibe el modelo. La estructura, los tipos, los valores ausentes y resúmenes; no la tabla entera insertada en el contexto. Las observaciones sin procesar permanecen en la sesión.

El mismo agente de programación lee archivos, escribe código, ejecuta comandos y puede controlar un navegador. Cada cambio y cada comando requiere tu aprobación. Puedes usarlo en Pize Code, Positron, la CLI o mediante el SDK.

Opciones de uso disponibles

• Pize Code. Un complemento en la barra lateral del editor. Edición entre archivos, terminal, planificación y ejecución, y diffs que se pueden revisar.
• Positron. El mismo agente, más un puente a la sesión de R o Python que ya tienes en foco.
• SDK. El mismo agente integrado en un programa que ya utilizas, también disponible mediante la CLI.

Cómo se paga el uso de los modelos

El uso de autoservicio se paga con créditos prepagados. Un crédito equivale a un centavo de dólar estadounidense. Compra un paquete en la página de precios; Stripe procesa el pago. Las condiciones empresariales se acuerdan por contacto.

Empresas

Los laboratorios y las condiciones a medida no tienen un precio publicado. Se acuerdan por contacto.

También es un agente de programación completo

La lectura de datos y el puente con la sesión son la capa adicional que aporta Pize. A continuación se presentan las capacidades del agente de programación completo que también ofrece; sin ellas, el ciclo estadístico no puede completarse.

Un SDK (Software Development Kit o kit de desarrollo de software) agrupa API, tipos y ejemplos para que otro programa pueda invocar una capacidad sin tener que implementarla de nuevo.

Sin un SDK, cada integración escribe sus propias llamadas HTTP y trata de adivinar los campos. Con un SDK, el programa que llama recibe nombres de funciones estables, tipos y un ejemplo que realmente funciona. Esta es la capa que permite integrar un modelo en un programa de adquisición de laboratorio o en una plataforma interna de análisis.

• Qué proporciona. Interfaces invocables, tipos y el ejemplo funcional más pequeño. El programa que llama no tiene que reinventar la lectura de datos ni la sesión.
• Qué no proporciona. No sustituye la interfaz de su producto ni elige el método estadístico. El modelo sigue proponiendo el método y usted lo confirma.
• En qué se diferencia del plugin. El plugin se abre en el editor. El SDK integra el mismo agente en un programa que usted ya utiliza, sin añadir otra barra lateral.

MCP (Model Context Protocol) es un protocolo abierto: permite que un modelo acceda durante la ejecución a herramientas, datos y prompts externos, sin crear una conexión privada para cada fuente.

Un modelo solo razona. No puede ver su base de datos ni manipular parámetros dentro del software de un instrumento. MCP define tres elementos: herramientas (acciones que puede invocar), recursos (datos que puede leer) y prompts (instrucciones que puede reutilizar). El modelo puede usar de la misma forma cualquier sistema que implemente ese contrato.

• Qué problema resuelve. El modelo y el sistema externo ya no tienen que inventar cada uno una conexión privada. Se puede acceder a bases de datos, bases de conocimiento y pasarelas internas mediante un solo protocolo.
• Qué no es. No es un modelo ni un SDK. No decide cómo integrar el agente en su propio programa; solo establece cómo se conecta al exterior el agente que está en ejecución.
• Dentro de Pize. Pize actúa como cliente de otros servidores MCP. El límite de seguridad sigue siendo su aprobación: solo lectura de forma predeterminada; las acciones esperan su confirmación.

Para que un sistema de IA obtenga resultados correctos en investigación, rara vez falta «un modelo más grande». Lo decisivo es si el modelo puede ver datos reales, utilizar herramientas reales y funcionar dentro del software que usted ya usa.

Pize mantiene separadas estas tres capas y, al mismo tiempo, las conecta. El modelo elige un método y escribe código. El SDK coloca ese agente dentro de sus herramientas. MCP le permite acceder durante la ejecución a bibliotecas, software de instrumentos y sistemas internos. La lectura sigue siendo el primer paso: si los datos son incorrectos, las otras dos capas solo propagan el error.

Los errores estadísticos casi nunca aparecen como un fallo del programa. Un delimitador incorrecto desplaza todas las columnas; tomar la primera fila como cabecera elimina la primera observación; tratar NA y NULL como 0 altera la media y la varianza; y una columna numérica leída como texto se trata como factor en un modelo de regresión. Nada de eso detiene el programa. Este devuelve en silencio un número erróneo pero verosímil y, como el error se produjo durante la lectura, todas las pruebas, modelos e inferencias posteriores lo heredan.

Por eso Pize no está optimizado para que el modelo escriba más código. Primero le permite conocer la forma de los datos, el tipo de cada columna, el número de valores ausentes y la cantidad aproximada de filas. Después escribe el código de cálculo y modelado y lo ejecuta en tu sesión real para que puedas ver los resultados.

La detección del formato examina el contenido, no la extensión del archivo: en los datos de investigación, un archivo .txt suele contener una tabla, mientras que un .csv puede constar de solo tres líneas de configuración. Cada decisión que sigue influye directamente en los resultados posteriores.

• Detección del delimitador. Se elige entre tabulador, coma, punto y coma y barra vertical (|). El número de columnas debe ser estable entre filas y los campos deben parecer celdas, para evitar que un texto con una coma en cada frase se interprete como una tabla de dos columnas.
• Cabecera o datos. Si la primera fila contiene dígitos en las posiciones correspondientes a columnas numéricas, se trata de una observación, no de nombres de columna. Interpretar la primera observación como cabecera es una causa clásica de perder una muestra.
• Los valores ausentes no intervienen en la inferencia de tipos. Las cadenas vacías, NA, NaN y NULL se reconocen por separado; de lo contrario, una columna completamente vacía puede clasificarse como numérica y llevar al modelo a resumir números que no existen.
• Inferencia de tipo por columna. Numérico / texto / vacío, columna a columna. Este paso decide si una columna puede entrar en una media, una varianza o una regresión.
• Se retiran comentarios y metadatos. Los bloques iniciales que empiezan por #, ! o @XX salen primero. VCF esconde los nombres de columna en la última línea de comentario; se recuperan para que las columnas tengan nombre.
• Las tablas comprimidas se leen de forma transparente. .gz se descomprime solo; el tamaño se juzga después de descomprimir: un archivo de 1 MB puede guardar una tabla de 20 MB.
• Estimación de filas. El total se estima por la fracción de bytes del prefijo ya leído y se etiqueta como estimación, no como hecho.
• Los archivos que superan el presupuesto reciben una ficha de datos, no un error. Si se supera el presupuesto de contexto, Pize devuelve el tamaño, el delimitador, el número estimado de filas, los nombres de columna con sus tipos inferidos y las dos primeras filas. Con esa ficha, el modelo escribe el código de lectura correcto sin que una tabla de un millón de filas agote el contexto.

Primero se leen los datos y después se calcula. Pize no inventa métodos estadísticos por ti; garantiza que el modelo trabaje con tus datos reales y que puedas ver cada paso.

• Elegir el método según la distribución real. El modelo recibe el número de filas y columnas, los tipos, el recuento de valores ausentes y los resúmenes estadísticos. Con esa información decide entre métodos paramétricos y no paramétricos, si debe transformar los datos y cómo tratar los valores ausentes.
• Escribirlo y ejecutarlo. El R o Python generado corre en la sesión actual tras tu confirmación. Lo que vuelve es salida real, no un resultado imaginado.
• Diagnosticar con gráficos. Se puede recuperar el último gráfico: QQ, residuos, distribuciones que solo se juzgan mirando. El modelo puede participar en ese juicio.
• Iteración cerrada. Ejecutar, leer, corregir, en la misma sesión. Las variables intermedias no se pierden porque arranque otro proceso.
• Solo agregados, nunca filas crudas. Los resúmenes de tabla devuelven estructura y estadísticos. Las observaciones crudas se quedan en la sesión.

La verdad de un análisis no está en el archivo, está en la memoria. El puente lee, por la API pública de extensiones de Positron, la sesión de R o Python que tienes enfocada. Nunca crea ni cambia un runtime. Solo usa el que ya usas.

• Pruebas de regresión con corpus generados. Se generan muestras etiquetadas para 31 formas de archivo, en lotes de diez mil, y se pasan por el detector. La primera ejecución falló en 458 casos y reveló cuatro clases de defectos que se corrigieron una a una. La semilla aleatoria es fija, de modo que las mismas entradas permiten comprobar que los defectos corregidos no reaparecen.
• Pruebas centinela en cada punto de integración. Cada punto de integración con el código upstream tiene una prueba. Si una fusión elimina una sola línea de conexión, la prueba falla de inmediato: la función no puede dejar de operar en silencio mientras la suite de pruebas permanece en verde.
• La lista de comprobación completa en cada fusión. Se ejecutan miles de pruebas unitarias, dos comprobadores de tipos y el lint de todo el repositorio; después de empaquetar, se desempaqueta el artefacto para confirmar que el comportamiento está realmente incluido.
• Autocomprobación de un clic. La comprobación del puente en la paleta de comandos lee de verdad una sesión. Un aprobado significa que las herramientas alcanzaron datos reales.
• Convive con la versión oficial. Se publica con un id de extensión propio, instalable junto al complemento de origen sin sobrescribirlo.

La arquitectura sigue una regla constante: el comportamiento nuevo siempre se implementa en archivos nuevos; los archivos upstream solo se modifican en los puntos de llamada necesarios. Por eso una fusión que incorpora diez commits upstream puede producir un conflicto de una sola línea. Así, el proyecto puede seguir la evolución upstream en lugar de publicarse una vez y quedar estancado.