## https://sploitus.com/exploit?id=FC7A6C9A-3171-59C6-9828-21470DFE1CF9
# ccdd-poc — ¿Dónde está el límite de un solucionador de issues con modelo chico?
Serie de POCs que **miden** (no opinan) la viabilidad de la arquitectura de dos niveles para
desarrollo asistido por IA: **un modelo grande entiende al usuario y escribe la spec (historias +
tests); un modelo chico ejecuta y valida contra esos tests.** Aplica la disciplina de
[CCDD](https://github.com/MauricioPerera/ccdd): *lo que no se corre contra la realidad no está
verificado.* Cada POC aísla **un confound** y produce un número sobre tareas reales, con un harness
reutilizable (Ollama + `unittest`, sin dependencias).
## El mapa de límites (medido)
| POC | Pregunta | Hallazgo | Modelo chico |
| :--- | :--- | :--- | :--- |
| **[#1](README_POC1.md)** | ¿el ejecutor converge contra un oráculo de tests real? | Sí, en el caso limpio | gemma4 **100%** · qwen2.5:1.5b 75% |
| **[#2](poc2/README.md)** | ¿localiza + edita sin romper, en un codebase? | Sí (retrieval fácil) | gemma4 **100%** · 1.5b **0%** (colapsa editando) |
| **[#2b](poc2b/README.md)** | ¿dónde rompe la localización? | En la **localización**, no el ejecutor | recall@1 66% **techa** la convergencia |
| **[#3](README_POC3.md)** | ¿el techo es la calidad de la spec? | **Sí**: tests generados por par tiran 100%→**62%** | tests rotos / contradictorios |
## El veredicto
- **El ejecutor (~12B) es el eslabón sólido.** Convierte specs claras en código correcto; localiza y
edita sin romper cuando recibe el archivo correcto. Un 1.5b está **debajo del piso** (colapsa al
editar). No gastes en hacer el ejecutor más grande.
- **Los dos riesgos reales viven en la capa de spec**, no en el ejecutor:
1. **Localización** (qué archivo/función) — keyword retrieval rompe temprano; en un pipeline dirigido
por tests, el import del test **localiza gratis**, y la localización difícil es trabajo del modelo
grande (al escribir el test) con retrieval semántico/LSP.
2. **Calidad de los tests** — un modelo del mismo nivel escribiendo los tests **degrada el sistema**
(rotos, contradictorios). Poné tu **modelo más fuerte en la spec** y que el **humano revise los
tests** (barato: lee assertions, no código).
- **La mala spec se paga en cómputo.** Specs rotas/insatisfacibles hacen **thrashear** el loop (4
reintentos por nada). Detectá la no-convergencia rápido y **escalá**.
En una frase: **el modelo chico no es el cuello de botella — la spec lo es.** Por eso el humano y el
modelo fuerte van *arriba* (revisando historias y tests), y el chico *abajo* (grindeando contra un
oráculo determinista).
## Correr
```bash
# requiere Ollama con el modelo; Python 3 (solo stdlib)
POC_MODEL=gemma4:latest python run_poc.py # #1
cd poc2 && POC_MODEL=gemma4:latest python run_poc2.py # #2
cd poc2b && POC_K=1 POC_MODEL=gemma4:latest python run_poc2b.py # #2b (límite localización)
POC_GEN_MODEL=gemma4:latest POC_EXEC_MODEL=gemma4:latest python run_poc3.py # #3 (techo de spec)
```
## Estructura
- `run_poc.py`, `contract.py`, `ollama_client.py`, `tasks.py` — POC #1 (motor + harness reutilizable).
- `poc2/` — localización + edición sin regresión (codebase con bugs plantados + retrieval).
- `poc2b/` — el límite de la localización (codebase grande + síntoma + barrido recall@K).
- `run_poc3.py` — el techo de la spec (tests generados vs referencia oculta).
- `work*/`, `report*.json` — artefactos por corrida (para auditar gaming/soluciones).
> Alcance honesto: tareas acotadas, modelos locales, oráculos chicos. Los números valen como **señal
> sobre estas tareas con estos modelos**, no como benchmark universal. El valor es el **harness**:
> cambiás el modelo o metés tus issues y obtenés tu propio número de go/no-go.