codistill – Squeeze SSOT Out of Existing Code Image: AI generated

If you want to adopt SSOT for an existing project but cannot rewrite from scratch, if you want to auto-extract OpenAPI and DDL from legacy Go/NestJS/FastAPI code – codistill squeezes specs out of existing code.

“We already have 200 endpoints”

Someone reads the yongol post and asks: “Looks good, but our project already has tens of thousands of lines. Do we need to write SSOT from scratch?”

Starting from scratch would be nice, but it is impossible in practice. No team can stop a running service and write specs from zero. You cannot tear up the foundation of a store that is open for business.

That is why codistill was built. It squeezes SSOT out of existing code.

aliases:

  • /tech/juicer/

Put code in, specs come out

codistill statically analyzes web framework source code to auto-extract declarative specs.

codist scan --openapi ./my-project

This single line produces an OpenAPI 3.0 spec from existing code. What used to take days of manual work finishes in seconds.

Zero runtime overhead. No instrumentation needed. Pure static analysis. The same direction has been validated academically – Huang et al. (2024) presented Respector at ICSE, a technique for automatically generating OpenAPI specs from source code via static analysis alone.

aliases:

  • /en/tech/juicer/

aliases:

  • /tech/juicer/

Three frameworks

FrameworkLanguageExtraction
GinGoRoutes, bindings, responses, middleware
NestJSTypeScriptDecorators, DTOs, guards, interceptors
FastAPIPythonRoutes, Pydantic models, dependencies

Go, TypeScript, Python – the three most widely used backend frameworks covered.

aliases:

  • /tech/juicer/

What it extracts

LayerOutput
RoutesHTTP method, path, handler location, middleware
RequestBody binding type + struct fields, query/form/path params, file uploads
ResponseStatus codes, body type + struct fields, json/validate tags
OpenAPIpaths, parameters, requestBody, responses, components/schemas
DDLPer-table CREATE TABLE snapshot from migration history
SQLRepository method skeletons – CRUD type, table, params, return

Decisions scattered across source code are condensed into declarative specs.

aliases:

  • /en/tech/juicer/

aliases:

  • /tech/juicer/

DDL consolidation

When 50 migration files have piled up, it is hard to tell what the current schema looks like. You have to mentally replay the accumulated ALTER TABLEs in order.

codist ddl ./migrations -o ./schema

Reads the entire migration history and outputs one clean CREATE TABLE snapshot per table. 50 files become as many .sql files as there are tables.

aliases:

  • /tech/juicer/

sqlc query scaffolding

Extracts SQL query skeletons from code written with the repository pattern.

codist sql next --repo ./repository --queries ./db/query

next – ratchet workflow. Shows the next repository method without a query, write the skeleton, move on. When all are filled, it stops.

codist sql status

Shows current progress. Not the agent declaring “I’m done,” but the machine counting the remaining methods.

aliases:

  • /en/tech/juicer/

aliases:

  • /tech/juicer/

Entry into the yongol pipeline

codistill’s output is yongol’s input.

Existing code
  ↓ codist scan --openapi
  ↓ codist ddl
  ↓ codist sql next
OpenAPI + DDL + sqlc queries
  ↓ yongol validate
  ↓ yongol generate
SSOT-based codebase

codistill reverse-extracts SSOT from existing code; yongol validates consistency and generates code. The transition from brownfield to greenfield doesn’t happen all at once but incrementally. Perry and Wolf (1992) defined architecture erosion and drift – violating the spec is erosion; becoming insensitive to the spec is drift. codistill is the tool that reverse-extracts specs from code where drift has already occurred, realigning them.

Start by feeding codistill’s OpenAPI and DDL to yongol. Run validate to expose cross-layer inconsistencies. Fix them one by one. Add SSaC. Add Rego. Add Hurl. At every step, yongol guarantees consistency.

Not foundation work but seismic retrofitting. Martin Fowler’s (2004) Strangler Fig pattern – don’t replace legacy all at once; wrap it incrementally. Reinforce the building without closing the store.

aliases:

  • /tech/juicer/

Get started

npx skills add park-jun-woo/codistill

codist scan --openapi ./my-project

Existing code is distilled into specs.

Code: github.com/park-jun-woo/codistill

aliases:

  • /en/tech/juicer/

aliases:

  • /tech/juicer/

References

  • Huang, R., Motwani, M., Martinez, I., & Orso, A. (2024). Generating REST API Specifications through Static Analysis. Proceedings of the IEEE/ACM 46th International Conference on Software Engineering (ICSE 2024). ACM
  • Lercher, A., Macho, C., Bauer, C., & Pinzger, M. (2024). Generating Accurate OpenAPI Descriptions from Java Source Code. arXiv:2410.23873. arXiv
  • Chauhan, S., Rasheed, Z., et al. (2026). OpenAI for OpenAPI: Automated generation of REST API specification via LLMs. Journal of Systems and Software. arXiv
  • Perry, D. E. & Wolf, A. L. (1992). Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes, 17(4), 40-52. ACM
  • De Silva, L. & Balasubramaniam, D. (2012). Controlling software architecture erosion: A survey. Journal of Systems and Software, 85(1), 132-151. ScienceDirect
  • Fowler, M. (2004). StranglerFigApplication. martinfowler.com/bliki. Link
  • Fritzsch, J., Bogner, J., Wagner, S., & Zimmermann, A. (2019). Microservices Migration in Industry: Intentions, Strategies, and Challenges. 2019 IEEE ICSME, pp. 481-490. arXiv
  • Curino, C. A., Moon, H. J., & Zaniolo, C. (2008). Graceful database schema evolution: the PRISM workbench. Proceedings of the VLDB Endowment, 1(1), 761-772. VLDB
  • Nghiem, D., Guo, H., & Foster, J. S. (2023). A Qualitative Study of REST API Design and Specification Practices. 2023 IEEE VL/HCC, pp. 148-156. IEEE

aliases:

  • /tech/juicer/