DCI the secret source for AI based software development?

[Lund Soltoft]

When reading Matt's recent post it dawned on me that I'd made a recent DCI related experiment and forgotten to share about it here.

Around new years ANthropic released an article about skills and there was something about how the LLM uses skills to find potential tools that made me think of how an AI could choose role players for a context. Initially I thought of a LLM backed VM but after using Cope as part of rubber ducking the idea (thanks for taking the time Cope) I realised that DCI might be the secret source I needed for LLM assisted coding. One of the things LLMs are bad at is architecture and I thought what if I used DCI concepts to structure specifications. 

Initially I had just data specifications and contexts and when I made the data immutable I also had better results from the generated code. Even LLMs find it easier to "reason" about a system if data doesn't suddenly change value. I also realised that I could wirft a draft for the specification and through a conversation with the model end up with an enabling specification. So fairly early in the progress I incidentally validated to practices that I've been using in my work previously. 

I had a hard time getting the agents to accept another concept I've been proposing. Immutable contexts. It turned out that I was better off having two flavours of the DCI "context" one I ended up calling a projection, they are immutable but otherwise just like a context and one where I just stuck to "context" only contexts can use contexts as role players.

My first example was of course the money transfer, that I wrote up in plain English with the data and contexts that I've used in other versions of the same example. Once that compiled I created a terminal based snake game and for both the rules was, I had to treat the generated code as an intermediate step, like an AST it's important but only for the compiler not for me. So I never read the code (not entirely true, I read it when I was debugging the pipeline)

After completing those experiments I wanted to do something more complex. Not so much to test the DCI idea (which can be seen in the specifications) but to test the "executable specifications". So I started building a netbank by only specifying the system, including the integration to an Open Banking API.

you can see the results on 

https://obi.fly.dev 

and since it's meant to showcase "executable specifications" the specifications can be see on the site (if you click the small icon in the upper right corner)

After several months of various experimentations I've come to believe that with the DCI it requires to build the specifications as a set of data and contexts (in two flavours) you can create entire applications even if you can only express the requirements in English and not in code, and by structuring the requirements this way that it's possible to maintain the application and debug the application (though I still have not been able to create a single step debugger for the prose, though I have done some work on traceability from the requirement to the actual code but that's mainly a token budget optimization)