Show HN: Sideko – Hybrid deterministic/LLM generator for API SDKs and docs

5 comments

·August 26, 2025

Hi HN, I’m Patrick. Elias, Kevin, and I are building Sideko (https://sideko.dev), a new type of code generator for building and maintaining API client SDKs from OpenAPI specs.

Traditional SDK generators rely on static templates that produce rigid, machine-generated code. When the API changes, these generators completely overwrite the SDK, destroying any custom modifications developers have made. The result is brittle code that looks artificial and requires constant manual rework.

Our approach uses structured pattern matching queries instead of templates. These queries analyze the existing codebase to understand its structure and intent, then make small updates while preserving custom changes. When we regenerate code, the system recognizes what developers have modified and works around those changes rather than overwriting them. The pattern matching enables our hybrid workflow where deterministic codegen establishes the foundation, LLMs enhance specific components, and the system maintains both the automatically generated and the human-modified code.

Our Hybrid SDK Generation Approach

Workflow: Our system starts with deterministic codegen that generates the base SDK structure, then uses LLMs to enhance specific components where adaptability adds measurable value, while agent rules enforce consistency through type checking and integration tests against mock servers.

Summary: The key advantage is that LLM edits are retained across code regenerations while the deterministic code stays automatically synced with API changes. Language-specific rules for Python and TypeScript guide both LLM modifications and testing to ensure quality and consistency throughout the development cycle.

You can quickly try it out from your terminal:

  Install: npm install -g @sideko/cli

  Login: sideko login

  Initialize: sideko sdk init

  Prompt: “Add a new function that…”

Repo is here: https://github.com/Sideko-Inc/sideko

We’d love to hear your thoughts!

Visit

souperdeluxe

We're doing something similar at our company. We're fine tuning small LLMs and using them as isolated components of a larger deterministic system. When we tried using LLMs for larger components of the system we ended up writing a lot of pseudo-code into the prompt. That was better off as just code. Now we can quickly find tune our business logic based on client preferences, without having to dig into the prompt. This also means we build trust in our prompts over time, because they change less often.

pmkelly4444

Interesting, are you using LLM rules files?

eliasposen

Hi all! My name is Elias, co-founder at Sideko. Excited to share this new release with you all, try it out and join our Slack channel to share your generations or chat with us about customizations, enhancements, and more!

dlahoda

we have openapi.

one of openapi methods inputs pk signed binary protobuf message and handles inner result which may be custom error code(after unwrapping http code).

some other openapi method is ws upgrade. data over ws has json schema for messages, but no any api generated. we could have sse and have similar problem.

other teams writes solana contact and generates its client(called anchor).

so we have rust, and generate a lot of ts.

after, somebody glues manually all these parts.

and after somebody supposely adapts these to react.

so out problem not docs, but a lot of manula glue to maintain. which in theory could be ai generated.

pmkelly4444

And you're stuck maintaining the glue by hand because no generator understands the relationships between all these different systems.