Software: Interfaces All the Way Down
The way we write software is changing faster than ever before. In just the past year, LLM-driven tools have advanced so rapidly that developers now often ship complex features without writing a single line of code by hand. Like it or not, software as an industry, profession, and process, is in the midst of a revolution.
For all the change, however, some things remain the same. One of these constants is that software is fundamentally made of interfaces – developing software is all about describing contracts between two or more parties, verifying that these contracts are fulfilled, and managing changes over their lifecycles.
"User Interfaces" allow (human) users to interact with a system in a reliable and intuitive way. These often call "Application Programming Interfaces" (APIs) which expose reliable and deterministic sets of server behaviors. These servers may then interface with other services through other APIs, RPCs, etc., passing around DTOs or "events" that each component must honor. Peer inside one of these services and you'll see it made up of functions (or objects, methods, etc.), describing a format to the caller and an expectation of behavior and/or returned data — more interfaces! And underneath the code running on silicon? Another interface describing how compiled code interacts with the hardware. Software is interfaces all the way down.
As development becomes more "agentic", the application developer's focus is shifting towards higher levels of abstraction. More time is spent designing API endpoints, or thinking about which data schemas to pass between services, than is spent writing functions line-by-line. This shift can lead to faster feature development, but the old concerns apply: interfaces need to communicate their intent clearly (to both humans and machines), be carefully versioned to avoid breaking their contract, and have their implementation proven through extensive test coverage.
Great improvements in how we define high-level software interfaces have been made in recent decades. OpenAPI and JSON Schema are just two of the more popular formats for describing interfaces; gRPC/Protobuf, GraphQL, and others have also found extensive use. Each has spawned whole ecosystems of useful tooling: testing, release management, service orchestration, documentation, code generation, and other crucial aspects of application development are all made easier and more reliable by having well-defined interface specifications. To date, however, no tool has arisen as a comprehensive way to manage the SDLC primarily through these high-level interfaces. Teams are stuck cobbling together solutions in an ad-hoc way, wasting time that could be spent on the product, and settling for workflows that don't take full advantage of the power of interface definitions.
Enter Interface 7
Think of Interface 7 as the semantic layer and collaboration point for your software interfaces. Where Git stores generic text and line-by-line diffs, ifc7 tracks and understands the contracts that expose your application to users, agents, and other applications. Starting with OpenAPI and JSON Schema as the first supported specifications, it can be used to manage schema versioning, enforce style guides, and detect breaking changes. It provides human-readable documentation and access-controlled URLs for interface documents so they can be exposed to other users and processes on a least-privilege basis. Soon, it will be able to drive automated code generation (both deterministic and LLM-based), intelligently manage CI/CD and release management, and keep track of test coverage and common client workflows. It is not meant to be a replacement for Git or other existing development tools, but a hub — an interface, if you will — where they are all brought together. This will allow teams to focus on the parts of software that matter the most: where they interact with other systems and the outside world.
The API or data schema sits at the ideal layer of abstraction for communicating between product and engineering teams. It is the natural point for coordination between engineers working on different systems that need to interact. It is also perfect for driving interactions with LLM-based workflows because it allows for structured communication and deterministic validation of outputs. Interface 7 aims to be the point at which all these players interact.
Imagine a product team collaborating with engineering on changes to an existing API. A draft of this API change generates documentation, mocks, and libraries which a frontend developer can quickly access to begin building features off of. An LLM agent opens automated Git PRs to implement changes for a developer to review, and gaps in API test coverage are immediately surfaced. When the team is ready to release, semantic understanding of API changes can ensure that interdependencies aren't broken. This is where Interface 7 is headed.
Principles
To get there, we need to follow a few principles.
1. Build on a strong foundation
A reliable and feature-rich interface collaboration tool depends on a solid low-level platform to build from. To this end, we have started by building:
- a core interface revisioning and versioning system,
- a plugin architecture for implementing language-specific features,
- webhooks for driving external processes, and
- a CLI tool with Git-like syntax for scripting and managing interfaces.
More powerful features are being built on top of this platform. On the UI side, we have started with a user-friendly way to view interface documentation, see revision history, manage versioned releases, and control team access.
2. Be as open as possible, but be sustainable
To be a truly world-class development tool, there needs to be a certain amount of ubiquity. A collaboration tool is only good if many people are familiar with it and can use it easily, if there is continuous feedback with the development community, if bugs are surfaced and resolved quickly, etc. Making software free and open source is a great way to achieve this.
At the same time, it takes money to support and grow a complex software project. This is why we are committed to being "as open as possible"™ - releasing useful FOSS tools to the dev community and contributing back to the open projects we depend on, while still maintaining some proprietary software as IP to help with revenue generation.
Being as open as possible also means maintaining interoperability with the many other platforms and standards that development teams use regularly.
3. Focus on the users
Initially we had two types of users in mind when conceiving of Interface 7: engineers and product designers. Now there is a third: LLM agents. We aim to treat each user type as a first-class citizen of the platform, providing just the right level of access to information and capabilities, while handling privacy and security appropriately.
4. Don't reinvent the wheel
There are a ton of good tools and standards out there. Our main goal is not to develop new ones, but to bring existing ones together in an intuitive, automated, and enjoyable-to-use way. We all know what tends to happen when a new "better" standard is introduced. In an era of massive disruption of the software industry, we want to make the transition to interface-centric development as smooth as possible by building off of what is tried-and-true.
What's Next
We are still at the very early MVP stage, but there is a lot of potential and a lot to come. Stay tuned, sign up to the hub, use the CLI, and let us know your thoughts. Software development is going to look very different in just a few years, and we hope to be a part of it.