Skip to content

Document the Value of Writing a Specification for an Existing Service #33

Description

Summary

Add documentation explaining why writing a specification remains valuable even after a service has already been implemented, particularly for mature and legacy systems.

Motivation

A specification is not only a design artifact for new systems—it is also a powerful tool for understanding, validating, and evolving existing implementations. As services grow and change over time, a formal specification captures the behavioral contract independently of the implementation, making it easier to verify correctness and safely evolve the system.

The documentation should cover several key benefits:

  • Specifications improve testing and regression detection.

    • A specification can be used to systematically increase test coverage by validating the implementation against the intended behavior.
    • It provides a stable behavioral oracle that helps detect regressions as new features and fixes are introduced.
  • Specifications enable safe refactoring.

    • They capture the externally observable contract that clients depend on, independent of implementation details.
    • This is especially valuable during major internal changes, such as replacing the storage backend, changing communication protocols, or performing large-scale refactorings.
    • The specification provides confidence that the new implementation preserves the same client-visible behavior.
  • Specifications improve the developer experience for clients.

    • A formal model provides a precise behavioral description that clients can program against, complementing traditional API documentation.
    • Specifications are closely related to mocks (though they are not the same, and there is separate documentation explaining the distinction).
    • Once a model exists, generating high-fidelity mocks becomes straightforward, making it easier for client teams to develop and test integrations independently and build more resilient applications.
  • AI can reverse engineer specifications from existing implementations.

    • AI is effective at inferring behavioral models from running systems, source code, and observed interactions.
    • This is particularly valuable for legacy services where the service contract is undocumented or exists only as tribal knowledge.
    • AI can treat the implementation as a black box, formulate hypotheses about its behavior, perform experiments to validate those hypotheses, and incrementally construct a machine-checkable specification.
    • The documentation should describe this workflow and illustrate how AI can significantly accelerate specification and model discovery for existing systems.

Expected Outcome

Readers should understand that specifications provide long-term value throughout a service's lifecycle. Even when an implementation already exists, a specification helps teams:

  • Increase test coverage and detect regressions.
  • Perform major refactorings with greater confidence.
  • Provide clients with a precise behavioral contract and enable high-quality mocks.
  • Recover and document the behavior of legacy systems through AI-assisted specification discovery.

Activity

  1. Tomperez98 commented on Aug 13, 2026

    @Tomperez98
    ContributorAuthor

    Immad (@imnaseer) I want to start working on a PR for this but would love to align the expectations.

    I have created a skill that explains how to use the accordant model, we can add a section in the docs with the npx skill install instruction + repo with a webserver that is documented with an openapi yaml.

    I imagine we could enable the agent to reverse engineer the webserver with accordant. this webserver should be a little complex (so we can teach derived requests, asynchronous tasks, )

  2. imnaseer commented on Aug 14, 2026

    @imnaseer
    Member

    Let's connect over a short call here Tomas and we can come up with a strategy we can share with the agent. There can be different modes here: online (active) learning where the agent can play and poke around with the APIs, offline learning where the agent is just given the traces but can't actively play with the service. An orthogonal dimension is whether the agent treats the service as a black box or whether it's possible to peek in and look at the source code of the service.

    We can then package those learnings up as a skill.

    We can then even consider an automated tool that attempts to reverse engineer specs given an OpenAPI spec as well. This is a rich space.

  3. Tomperez98 commented on Aug 14, 2026

    @Tomperez98
    ContributorAuthor

    Awesome

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions