LM Studio Bionic Ya - Proyectos de código, búsqueda, edición y terminal

Objetivo del tema

Conectar Bionic con una carpeta de trabajo, comprender qué aporta la indexación, investigar un repositorio mediante búsquedas, realizar cambios con alcance preciso y ejecutar comandos de terminal sin perder el control del proyecto.

Idea central: antes de editar, el agente necesita construir un mapa del repositorio. La velocidad no proviene de saltarse la inspección, sino de buscar los archivos, símbolos y pruebas que realmente gobiernan el comportamiento.

13.1 Qué habilita el modo de código

Al asociar un directorio y permitir capacidades de código, Bionic puede buscar en el repositorio, leer y editar archivos, utilizar Git y ejecutar comandos de shell en el directorio de trabajo. Esto permite tareas como:

Explicar cómo está implementada una funcionalidad.
Localizar la causa de un error.
Modificar o refactorizar varios archivos.
Agregar funcionalidades y pruebas.
Actualizar documentación técnica.
Revisar cambios que afectan varias capas.

Estas capacidades amplían el impacto del agente: ya no trabaja sólo en un sandbox documental, sino sobre la carpeta local seleccionada.

13.2 Crear o configurar el proyecto

Crea un proyecto y asigna un nombre que identifique el repositorio.
Activa Allow coding cuando aparezca en la creación o en la configuración de la sesión.
Selecciona Choose a folder y elige la raíz correcta del código.
Crea o abre una sesión con capacidades de código.
Espera la indexación inicial y comprueba la carpeta en el panel derecho.

Diferencias de versión: la guía oficial muestra Allow coding durante la creación. Desde Bionic 1.1.0 los proyectos de trabajo y código se unificaron y las capacidades de código pueden habilitarse por sesión. Busca el mismo concepto aunque el control aparezca en otro paso.

13.3 Elegir correctamente la carpeta raíz

La carpeta elegida define el espacio que Bionic indexa y donde opera. Selecciona el nivel que contiene la configuración principal del proyecto, no una subcarpeta aislada ni un directorio demasiado amplio.

Ejemplos de alcance
Selección	Consecuencia	Recomendación
`mi-api/` con código, pruebas y configuración	El agente puede relacionar implementación y tests.	Adecuada para un repositorio único.
`mi-api/src/`	Puede perder pruebas, manifiestos y documentación de la raíz.	Sube un nivel salvo que quieras limitar el alcance deliberadamente.
Una carpeta con muchos proyectos no relacionados	La búsqueda se vuelve ruidosa y aumenta el riesgo de tocar otro proyecto.	Crea proyectos separados.
Raíz de un monorepo	Comparte configuración y paquetes, pero el alcance es grande.	Indica paquete, aplicaciones afectadas y comandos enfocados.

No selecciones tu carpeta personal ni una unidad completa: concede un alcance innecesario y dificulta distinguir qué archivos pertenecen a la tarea.

13.4 Qué hace la indexación

Bionic indexa la carpeta seleccionada para poder localizar archivos y buscar el código pertinente. La indexación es un mapa de búsqueda; no significa que todo el repositorio se incluya simultáneamente en cada prompt.

Durante una tarea, el agente consulta ese mapa, abre archivos relevantes y lleva al contexto los fragmentos necesarios. Por eso un repositorio puede ser mayor que la ventana de contexto del modelo, aunque una tarea excesivamente amplia siga requiriendo dividirse.

Cuando agregas, renombras o generas muchos archivos, concede tiempo para que la vista del proyecto se actualice. Si una búsqueda no encuentra un elemento recién creado, abre el archivo directamente o inicia una nueva consulta con la ruta exacta.

13.5 Panel Files, repositorio y rama

Si la carpeta es un repositorio Git, el panel de archivos muestra también el repositorio y la rama actual. Antes de trabajar, comprueba:

La ruta absoluta o el nombre de la carpeta seleccionada.
La rama activa.
Los cambios locales ya existentes.
La presencia de archivos de configuración y pruebas.

Bionic 1.1.1 corrigió casos en los que los detalles de la rama quedaban desactualizados tras cambios en el repositorio. Aun con una versión reciente, confirma con git status y git branch --show-current antes de una operación importante.

13.6 Construir un inventario inicial

El primer prompt no tiene que pedir modificaciones. Solicita una radiografía breve y basada en archivos:

Inspecciona este repositorio sin modificar archivos ni instalar dependencias. Informa: 1. lenguaje, framework y gestor de paquetes; 2. puntos de entrada; 3. estructura de carpetas relevante; 4. comandos documentados para ejecutar, probar y verificar estilo; 5. ubicación de las pruebas; 6. estado de Git y rama actual; 7. archivos de instrucciones para colaboradores o agentes. Cita la ruta que respalda cada dato. Si algo no puede determinarse, indícalo.

Revisa el inventario contra los manifiestos, el README y los archivos de automatización. Una detección incorrecta del gestor de paquetes puede producir instalaciones o archivos de bloqueo no deseados.

13.7 Estrategias de búsqueda

Por nombreLocaliza archivos, carpetas, componentes o pruebas conocidos.

Por textoBusca mensajes de error, rutas HTTP, claves de configuración o etiquetas visibles.

Por símboloSigue funciones, clases, variables, importaciones y llamadas.

Por comportamientoParte de una prueba, pantalla o endpoint y recorre el flujo.

Por historialUsa Git para saber cuándo y por qué cambió una línea.

Por convencionesConsulta manifiestos, CI, linters y archivos de instrucciones.

Una buena investigación combina varias estrategias. Encontrar una cadena no demuestra que ese archivo controle el comportamiento; sigue importaciones y llamadas hasta reconstruir el recorrido.

13.8 Prompts de búsqueda eficaces

Del pedido ambiguo a la investigación concreta
Pedido débil	Pedido útil
«¿Dónde está el login?»	«Localiza el flujo de inicio de sesión desde la ruta HTTP hasta la validación de credenciales y la creación de sesión. Enumera archivos y funciones en orden.»
«Busca el error.»	«Busca el mensaje exacto “Token expired”, identifica quién lo genera y quién lo transforma en respuesta HTTP. No cambies archivos.»
«Explica este proyecto.»	«Explica sólo cómo se crea un pedido, incluyendo controlador, servicio, persistencia y pruebas relacionadas.»

13.9 Referencias exactas y chips de archivo

Escribe @ para seleccionar un archivo en la paleta de referencias. Si una respuesta incluye un chip con ruta y líneas, ábrelo para revisar el fragmento. Desde Bionic 1.0.7 los rangos con estilo de GitHub pueden mostrarse como referencias cliqueables.

Revisa @src/auth/session.ts y sus llamadas. Concéntrate en la función refreshSession y en las pruebas que cubren expiración. No analices proveedores OAuth ni cambies el código. Devuelve rutas y rangos de líneas para cada conclusión.

Los números de línea pueden cambiar después de una edición; la ruta y el nombre del símbolo son referencias más estables para un seguimiento posterior.

13.10 Leer antes de proponer

Para comprender una funcionalidad, el agente debería revisar como mínimo:

El punto de entrada o consumidor.
Las funciones y tipos directamente implicados.
Configuración y variables relevantes.
Pruebas existentes y datos de prueba.
Convenciones e instrucciones del repositorio.

Pide que separe hechos observados de hipótesis. Una explicación basada sólo en nombres de archivo puede sonar convincente y ser incorrecta.

13.11 Definir el alcance de una edición

Una instrucción de cambio debe contener comportamiento actual, resultado esperado, límites y verificación:

Corrige la normalización del código de producto en buscarPorCodigo. Comportamiento esperado: debe ignorar espacios al inicio y al final y comparar sin distinguir mayúsculas. No modifiques la forma almacenada del código ni la API pública. Alcance: src/catalogo.js y sus pruebas directas. No agregues dependencias ni reformatees archivos no relacionados. Verificación: agrega casos para " a-01 " y "A-01", ejecuta la prueba enfocada y resume los archivos cambiados.

Para cambios grandes, pide primero una lista de archivos y un plan. El tema siguiente profundiza el ciclo inspeccionar, cambiar, probar y revisar diffs.

13.12 Herramientas de edición

El agente puede crear, reemplazar o modificar fragmentos de archivos. Tras cada edición, comprueba:

Que no haya cambios fuera del alcance acordado.
Que se conserven codificación y finales de línea.
Que imports, tipos y referencias sigan siendo válidos.
Que no aparezcan secretos, archivos temporales o artefactos generados.
Que la modificación sea mínima pero completa.

Trabajo local existente: informa al agente si hay cambios tuyos sin confirmar. Nunca autorices a limpiar, restablecer o sobrescribir el repositorio sin identificar exactamente qué se perdería.

13.13 Uso de la terminal

Con capacidades de código, Bionic puede ejecutar comandos en el directorio seleccionado. La terminal permite inspeccionar el entorno, instalar dependencias, generar archivos, ejecutar la aplicación y correr pruebas.

Clasificar antes de ejecutar
Tipo	Ejemplos	Riesgo habitual
Lectura	Estado de Git, listar scripts, consultar versión.	Bajo, aunque puede exponer información sensible en la salida.
Verificación	Tests, linter, comprobación de tipos, compilación.	Puede crear cachés o artefactos y consumir recursos.
Modificación	Instalar paquetes, formatear, migrar o generar código.	Cambia archivos, lockfiles, datos o entorno.
Destructivo o externo	Eliminar, resetear, publicar, desplegar o enviar datos.	Pérdida de información o impacto fuera del equipo.

Revisa el comando completo, su directorio y sus argumentos. Los modos de aprobación y Auto Review se estudiarán en el tema 19.

13.14 Dependencias, scripts y archivos generados

Antes de instalar o ejecutar, pide al agente que identifique el gestor y los scripts existentes. No mezcles npm, pnpm o yarn, ni diferentes gestores de Python, sin una razón explícita.

Conserva el archivo de bloqueo utilizado por el repositorio.
No actualices todas las dependencias para resolver un cambio menor.
Distingue código fuente de archivos generados.
Comprueba si una compilación modifica archivos versionados.
No ejecutes scripts descargados sin revisar su origen y contenido.

13.15 Cambiar el directorio de trabajo

Si elegiste una carpeta incorrecta o el proyecto se movió, abre el panel derecho, localiza las opciones del directorio y selecciona Change working directory.... Después:

Confirma la nueva ruta.
Espera la indexación.
Comprueba repositorio y rama.
Abre una sesión nueva si el objetivo ya no comparte contexto con la anterior.

No continúes ciegamente un plan elaborado para la carpeta anterior.

13.16 Modelo, contexto y privacidad del código

Para programar, el modelo debe seguir herramientas y mantener coherencia entre varios archivos. Elige uno con capacidad agéntica adecuada y contexto suficiente para la tarea.

Indexar una carpeta no significa que todo el repositorio se envíe de una vez. Sin embargo, los fragmentos leídos para una solicitud se procesan donde se ejecuta el modelo elegido: localmente, mediante LM Link o en Secure Cloud. Excluye secretos de la tarea y confirma el destino de inferencia antes de trabajar con código confidencial.

13.17 Práctica: explorar y corregir un repositorio mínimo

Crea una carpeta llamada inventario-demo con esta estructura:

inventario-demo/ |-- package.json |-- src/ | `-- catalogo.js `-- test/ `-- catalogo.test.js

`package.json`

{ "name": "inventario-demo", "private": true, "type": "module", "scripts": { "test": "node --test" } }

`src/catalogo.js`

export function buscarPorCodigo(productos, codigo) { return productos.find((producto) => producto.codigo === codigo); }

`test/catalogo.test.js`

import test from 'node:test'; import assert from 'node:assert/strict'; import { buscarPorCodigo } from '../src/catalogo.js'; const productos = [ { codigo: 'A-01', nombre: 'Teclado' }, { codigo: 'B-02', nombre: 'Mouse' } ]; test('encuentra un producto por codigo exacto', () => { assert.equal(buscarPorCodigo(productos, 'A-01')?.nombre, 'Teclado'); });

Primera etapa: inspeccionar

Abre la carpeta como directorio de trabajo con capacidades de código.
Confirma que los tres archivos aparecen y termina la indexación.
Selecciona un modelo capaz de usar herramientas.
Envía el siguiente prompt sin autorizar cambios todavía.

Inspecciona este repositorio sin modificarlo. Explica el recorrido desde la prueba hasta buscarPorCodigo, identifica por qué una consulta " a-01 " no encuentra el producto y propone el cambio mínimo. Indica archivos, símbolos y comando de prueba.

Segunda etapa: cambiar y ejecutar

Implementa el cambio propuesto. La búsqueda debe ignorar espacios exteriores y diferencias entre mayúsculas y minúsculas, sin modificar los objetos almacenados. Agrega pruebas para " a-01 " y "b-02". No agregues dependencias ni cambies la API exportada. Ejecuta npm test y resume los archivos editados.

Revisa que la función normalice ambos operandos al comparar y que productos permanezca intacto. Ejecuta también npm test manualmente si Node.js está instalado.

Resultado esperado: pasan tres casos, la función encuentra Teclado con " a-01 " y Mouse con "b-02", no hay dependencias nuevas y sólo cambian el archivo de implementación y su prueba.

13.18 Diagnóstico de problemas

Problemas frecuentes al trabajar con código
Problema	Comprobación o solución
No aparecen herramientas de código.	Confirma que la sesión tenga Allow coding y un directorio asociado.
Faltan archivos en la búsqueda.	Verifica la carpeta raíz, espera la indexación y menciona la ruta exacta.
El agente analiza otro paquete.	Indica la subcarpeta y limita expresamente los archivos permitidos.
El comando falla.	Revisa directorio, shell, dependencias, variables y el comando documentado por el proyecto.
Aparecen muchos archivos modificados.	Detén la tarea, revisa Git y determina si un formateador o generador excedió el alcance.
La rama mostrada no coincide.	Actualiza Bionic y confirma con `git branch --show-current`.
El modelo describe archivos inexistentes.	Pide rutas y fragmentos verificables; abre los chips antes de aceptar la conclusión.

13.19 Resumen

Las capacidades de código conceden búsqueda, edición, Git y terminal sobre una carpeta local.
La carpeta raíz define el alcance y debe elegirse con precisión.
La indexación facilita buscar; no introduce todo el repositorio en cada prompt.
La investigación combina nombres, texto, símbolos, comportamiento e historial.
Las referencias con @ y los chips de archivo ayudan a comprobar la evidencia.
Una edición segura define comportamiento, límites y verificación.
Todo comando debe revisarse junto con su directorio y efectos.
El código consultado se procesa donde se ejecute el modelo seleccionado.

En el próximo tema profundizaremos el flujo seguro de inspeccionar, cambiar, probar y revisar diffs antes de conservar una modificación.

Fuentes oficiales consultadas: guía de proyectos de código, creación del proyecto y Allow coding, proyectos, sesiones y directorios compartidos, trabajo agéntico con repositorios extensos, flujos de código con modelos locales y cambios actuales de proyectos, búsqueda y Git.

Retornar

13. Proyectos de código: indexación, búsqueda, edición y terminal