DEV Community

Charlie Cheng
Charlie Cheng

Posted on

From messy LLM chats to reliable specs: why I built Abstraction AI

#tooling #ai #productivity #startup

When I started using AI coding tools seriously last year, I fell into a pattern that might sound familiar:

  1. Open ChatGPT or another LLM.
  2. Talk for 50+ turns about a new idea.
  3. Paste the whole chat into a coding agent and say: > "Build the system based on all of this."

On good days, it felt magical.
On bad days, it felt like I had given a very smart intern a 20-page brainstorm doc and hoped they would “just figure it out”.

Over time, the failure modes became obvious.

The problem with throwing raw chats at coding agents

Two issues showed up again and again:

1. The context is noisy and self-contradictory.

In a long conversation, I will:

  • change my mind
  • backtrack on decisions
  • explore dead ends
  • forget to clearly mark the final choice

A coding agent that reads everything has to guess which part is the “truth”.

Sometimes it gets it right. Sometimes it confidently builds the wrong version.

2. Most of us do not naturally produce complete specs.

Even as developers, we often skip over:

  • non-functional requirements
  • edge cases and failure modes
  • data contracts and schema details
  • clear boundaries between components

When non-technical founders work with AI coding tools, this gap is even wider.

So we end up in an awkward place:

  • The coding agent is powerful enough to write a lot of code.
  • But the “instructions” we give it are closer to a brainstorm than a spec.

Treating AI coding more like training

I come from an AI/ML background, so I started to think in familiar terms:

  • The spec is the objective and the loss function.
  • The coding agent is the optimizer.
  • Logs, tests, and failures are feedback.

If the objective is fuzzy, the loss landscape is noisy.

If the objective is clear and structured, optimization can be much more stable.

The missing piece was obvious in hindsight:

I needed a deliberate step that turns “vibes” into a spec.

That is why I built Abstraction AI.

What Abstraction AI does

Abstraction AI sits between your conversations and your coding agents.

You give it:

  • long LLM chats,
  • meeting transcripts,
  • or your own unstructured project notes.

It generates a spec package that typically includes:

  • a concise product brief and key user stories
  • system architecture and the main components
  • data model and API sketches
  • constraints and non-functional requirements
  • an implementation plan broken into steps
  • ready-to-use prompts you can paste into your coding agent

The design goal is to be:

  • Newbie-friendly.

    The language is as clear as possible, with a terminology section so non-technical collaborators can follow along.

  • Agent-friendly.

    The structure is consistent enough that coding agents can follow it like a checklist instead of guessing inside a giant chat log.

A small example of the workflow

A typical flow for me now looks like this:

  1. Brainstorm with ChatGPT or another LLM about the idea until I feel there is enough raw material.
  2. Paste that raw conversation into Abstraction AI.
  3. Review the generated spec:
    • edit language,
    • remove things I do not actually want,
    • add constraints I forgot to mention.
  4. Once I am happy with the spec, I hand it to a coding agent (Claude Code, Cursor, etc.) together with the implementation plan.
  5. Let the agent iterate, but always with the spec as the single source of truth.

The difference is subtle but important:

  • I am no longer asking the coding agent to discover what I want.
  • I am asking it to satisfy a spec that I have already understood and agreed with.

Why I think this matters

There is a lot of discussion about RLHF, RLAIF, and sophisticated training pipelines for models.

But once those models land in our editors and terminals, we often go back to a very ad-hoc workflow:

  • long prompt,
  • hope for the best.

Abstraction AI is my attempt to borrow a tiny part of the discipline from training and bring it into everyday development:

  • make objectives explicit,
  • make evaluation concrete,
  • then let the optimizer (the coding agent) do what it does best.

If you are curious or have a similar workflow, the tool is live here:

👉 https://abstractai.ai-builders.space/

I would love to hear how you currently bridge the gap between “messy context” and “spec”, and what you would want from a tool like this in your own stack.

Top comments (0)