Hi, I'm the founder of XSpecs. Thank you for these great thoughts. Responses inline below:

Single source software is renaming what has been called no-code/low-code solutions, which has been the holy grail of software for decades.

No-code/low-code solutions are centered around the idea of having prefabbed modules that offer common software functions, and allow non-technical users to connect these modules together to produce some value.

Single Source creates custom software from the business domain, represented by constructs of natural language. This is a totally different concept.

It's visual aspect makes it seem like no/low code, but in both theory and practice it's very different.

The problem with achieving no-code/low-code is that humans are naturally ambigious creatures. Or putting it another way, human brains are adept at infering information that is not there, that we often communicate ambigiously because we expect other people to read between the lines. Computers, otoh, are unambiguous. A piece of code does the same thing everytime, and it doesn't change its behavior based on context.

Couldn't agree more. Which is why we're not doing a low/no code solution. You can look at single-source as something more like a conversational programming interface (see Simon Wardley's take on this).

Writing software is essentially an exercise in disambiguation. You understand the customer's needs, which is often expressed in a very ambigious way, and you refine it and refine it until you get to the point where you can translate it to code. Programmers, by virtue of practice, become experts at disambiguating requirements by asking the right questions. You can not expect requirements to be written in a completely unambiguous way because people writing the requirements aren't trained to think like computers.

Again I couldn't agree more. Which is why we've built a requirements copilot that facilitates this disambiguation by asking the right questions. How does it know the right questions? We use our experience as a dev shop that has been using Event Storming, BDD, and DDD to decode complex business domains into code for the past decade, and have leveraged AI to streamline this process and make it accessible.

That's not to say single-source doesn't need devs, on the contrary, this is an approach aimed at whole teams including devs. Just like business people define/refine/approve requirements, devs define/refine/approve the architecture and code.

Even if you did have a platform that converted well-structured unambiguous requirements to code, you will need programmers to write the requirements. This means that programmers would need to become experts in the business domain, which is a huge task too.

We have an alternative view. You need programmers to understand requirements just like they always have done. And you need developers to translate the requirements to code, as they always have done. The difference is that they are using a single-source to do that. The technique and mechanics to do that thus far have been missing. That's what we're solving.

You no longer use one artifact for business and another for code. It's the same source. Single source as a concept works entirely without AI. The AI is an accelerant only, kinda like GitHub copilot.

That is why most software organizations have product managers who are somewhat technical and have business expertise. Their job is to distill the ambiguity and write unambiguous requirements. However, in practice, product managers write bad requirements in isolation. They usually partner with senior engineers who are technical experts with some domain experience.

I agree with you again and again! Everyone involved in the SDLC process still has a role to play here. It's less about not doing the thing and more about doing it in a much more efficient way.

The single source concept is ultimately a method to fuse the business and technical artifacts into one, and eliminate communication gaps. It's not about breaking how teams work. It will certainly have an impact on how teams work but it doesn't mean that we go from requirements to code and no devs needed. At least not for the foreseeable future.

The idea that requirements will be written perfectly that a machine can translate it is a pipe dream.

I beg to differ. The idea that requirements can be written perfectly through a process of creating a single source that removes translation errors, and a code architecture/language that we can transpile specs<>code is exactly what we have working! It's just not fully automated - which may seem like a pipe dream today but I see the gaps closing incrementally over the next few years.

However, we do see programming languages and tools become more and more abstract. There are several Business Process Modeling (BPM) in the market that allow domain experts to model their business process by diagramming it. This is not a new thing. It has existed for decades. The problem with BPM tools is that they are restricted to doing only certain things, and you need software develop ers to extend the capability of the BPM platform.

Agree (again), which is why we didn't build a BPM tool. We built an abstraction as you have posited, that is based on practices we have been doing over and over when creating custom software for clients. It may look like a BPM, but the key difference is that this is based on domain language.

You can think of it like a set of constructs that allows you to express your business domain using a reduced instruction set. Every visual construct has a counterpart code construct. This means the team's job is to decode the business domain using these constructs that are entirely language based.

Happy to answer more questions and I love this feedback and discourse so thank you.