Lewis Westbury

Video calls are a powerful tool for connecting people remotely.

During my time at the Centre for Collective Intelligence, I lead the development of Zeitgeist - a tool to run deliberative workshops, both remotely and in-person. We designed an interface that allowed participants to deliberate together and interact with workshop content.

In this topic, we’ll explore how small group video call experiences can offer a comfortable, natural, experience - and guide the development of an open source library that lowers the risk and effort to integrate video calls into applications.

Vendor lock-in

Building Zeitgeist, we faced a difficult architectural choice: Which video call provider to integrate? We did not have the resources to develop, host, or maintain our own.

There are plenty of video call service vendors to choose between. From those that offered the features we needed, we selected Amazon Chime SDK, primarily because it offered easy integration with our product. In Feburary 2026, Amazon sunset Chime. The SDK, whilst still available, is in maintenance mode: No new features or major changes are planned. Sooner or later, support will end, and Zeitgeist will need to migrate.

When you build an application that uses a video call service, you must use a video calling client library that can interact with the provider. These client libraries are created by the service providers, and they are not incentivised to support other providers. Most use their own terminology, and none have a common interface. This is vendor lock-in, and it represents a bit of risk for you:

• What if they increase their prices?

• What if they remove support for your region?

• What if they adopt unethical practices?

• What if another provider offers a feature you need?

It’s often a significant effort to replace a library like this, as you are likely to have heavily integrated it into your user interface.

An opportunity for OSS

At time of writing, there’s no open source, vendor neutral, video calling client library. (There are a few open source video calling services, but they require that you also host or work with a basic WebRTC provider.) There’s a niche for a library that can bridge the divide:

• Unified terminology for common video calling concepts

• Supports any number of vendors with a plugin architecture

• Supports any number of application/UI frameworks by publishing multiple libraries

• Provides an abstraction layer: import the library, build your UI, and connect to any vendor

• Easily switch between vendors with small configuration changes

• Easily extensible

I’ll be working on the beginnings of this, as an open source React library, over the coming year. Work we do on this topic will directly feed into the development of this library. Collaborators are welcome.

With the reach of generative AI, the term “slop” has risen in prominence. It represents a rejection of thoughtless content, often perceived to be low in quality or creativity.

Developers have always taken a view about the amount of effort they put in to a task - with a direct effect on the quality of code they deliver. This is a calculation based on deadlines, availability, resources, reputation, and plenty of other factors.

Opinion is strongly divided about AI-assisted coding. Some argue it supports increased productivity. Others cite poor quality outputs and unexpectedly high cost.

What does poor quality code look like?

I have been exploring the outputs from some generative AI coding tools. Some traits are pretty clear:

• Use of obscure and made-up terms

• Code mingled with narrative comments

• Spaghetti code

• Long or difficult to read functions

• Inflexible, hard-coded assumptions

• Dependencies on old libraries, difficult to upgrade

These issues are also referred to as technical debt.

Does it even matter?

Arguably, if code is only ever to be written by one person (or agent), then idiosyncrasies don't matter. Provided the developer knows where everything is, who cares if nobody else can figure it out? This may well be a naive position...

• Do you trust your coding agent to get everything right?
• What happens when you run out of credit?
• Do you want to be able to maintain it yourself?
• Are you sure nobody else will look at the code?

What can we do about it?

Over time, technical debt builds up in every project and the solution is to refactor the code - a sense-making process in which developers rewrite the offending parts. Solo developers and small teams working in isolation are particularly vulnerable to technical debt, but all teams experience it.

Running code reviews and writing code that any person can quickly understand is a good preventative measure. Some examples of established practices:

• Clear and meaningful variable names

• Use of well established design patterns

• Use of existing frameworks, rather than re-inventing the wheel

• DRY (Don’t Repeat Yourself)

• KISS (Keep It Simple Stupid)

• YAGNI (You Ain’t Gonna Need It)

• SOLID (principles for object oriented development)

• Separation of concerns (a precursor to the Single Responsibility Principle)

• Clean Code (and opinionated superset of principles and approaches)

How are coding agents any different?

Coding assistants work alone. They aren't trained to expect code review nor do they have code quality metrics. As they work, they develop personal shorthand and assumptions, which then shapes and styles the code they produce.

I have been collating a set of guidance, skills, and scripts for coding assistants, to raise the quality of their outputs. It's available here: instantiator/dev-qual

For this topic, we’ll discuss factors that contribute to code quality, and how they can be measured and applied - both to AI-assisted and human developed coding. With some metrics in hand, I’ll support you to compose rules for your language or framework of choice, or enhance those already found in dev-qual.

Software development is necessarily social.

Developers need to communicate well for plenty of reasons:

• to share an understanding of common goals and desirable outcomes

• to share standards for quality

• to share contracts and interfaces for interoperability

• to share patterns for efficiency and readability

• to share learnings to avoid common pitfalls

• to write clear code that’s easy to review

Over the past few decades a variety of ways of working and digital tools have been developed to support this. The agile manifesto and agile software development offers principles and ways of working for teams, and  lean software development goes further, applying lessons from manufacturing to support larger organisations and optimise cross-team communication. Tools like Jira, Trello, Asana, GitHub Projects (and plenty of others) offer easily recognised interfaces to manage this communication.

Open source software is an ecosystem of interoperable tools including operating systems, command line tools, browsers, coding languages and libraries. Many interconnected systems are linked together by APIs running common protocols, with common data standards.

AI assisted coding is becoming prevalent, and may alter the way we work together. Developers can create far more complex projects in much smaller teams, or in isolation. Are shared contracts, open APIs, common data types, and interoperability at risk? What are good outcomes, and how can we incentivise them?

For this topic, we’ll discuss and test principles that could contribute to a manifesto for assisted coding. We’ll be thinking about this, and exploring a variety of ways of working. All ideas welcome!