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)

[Matthew Browne]

Hi Rune (do you still go by Rune?),
I think the expression you were going for is "secret sauce", not "secret source" :-)

The idea of "executable specifications" has been around a long time of course, but it's very interesting and clearly AI makes it much more feasible. I would be interested to see what your original prompts were (did you speak to it in terms of roles?) that generated the more detailed / executable specs.

This also reminds me of this project:
https://codespeak.dev/

CodeSpeak (which is still in development) was founded by Andrey Breslav, the creator of Kotlin. There's an interview with him that's just generally interesting where he talks about how Kotlin came to be and what goes into designing a language, and at the end he talks briefly about AI and his ideas for CodeSpeak:
https://www.youtube.com/watch?v=ZggUn2mNqMU&t=2674s

A good general point he makes is that there's value in committing your specs to version control, especially when much of your code is AI-generated.

(And this is unrelated, but while I'm sharing interviews with language creators, I also thought this recent interview with Bjarne Stroustrup was great.)

Lastly, I have a question about immutability...years ago, you described a philosophy on immutability that mirrored the real world, e.g. making Address objects immutable since the address itself doesn't change, whereas a homeAddress or workAddress property of a User object would be mutable since a person can move to a new location (and I assume in this approach that properties like 'name' and 'email' would also be mutable, since it's still the same person with the same identity if those change). Is this the approach you're taking with LLMs, or are you going fully immutable so that you would just create a new User object (to continue with that example) anytime one if its properties changes?

—

Matt Browne (he/him)

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAGLi4WjH7bfwHCyMJoU21bOU53rtLpWAVtY8VLGC6F4eNEdqUQ%40mail.gmail.com.

[Raoul Duke]

ja wohl, un/fortunately, i for one €0.02 personally do expect AI embracement is a prisoner's dilemma arms race -- more adoption is most likely to "win" out over less. 

https://docs.google.com/document/d/1f5YL2ftdgMEYunM3LaHk6Ffm4zyCtP36VbfZLrQHClw/edit?usp=drivesdk

[Lund Soltoft]

Yeah the Lupa focused more on a different aspect than the structure of the specifications. for a better example of what the structure of the DCI inspired files look like see this:

https://github.com/ITU-Yggdrasil/reen/blob/main/tests/snake/drafts/contexts/game_loop.md

To view this discussion visit https://groups.google.com/d/msgid/object-composition/76c53194-1e49-4cf6-a691-2476e18df5aa%40gmail.com.

[Lund Soltoft]

Lastly, I have a question about immutability...years ago, you described a philosophy on immutability that mirrored the real world, e.g. making Address objects immutable since the address itself doesn't change, whereas a homeAddress or workAddress property of a User object would be mutable since a person can move to a new location (and I assume in this approach that properties like 'name' and 'email' would also be mutable, since it's still the same person with the same identity if those change). Is this the approach you're taking with LLMs, or are you going fully immutable so that you would just create a new User object (to continue with that example) anytime one if its properties changes?

Actually in that scenario the homeAddress is a role just as the email is. Neither are intrinsic to being a person nor to the person's identity. I ended up not doing it entirely like that but instead create two different flavours of a context. One I call a projection (which is immutable, and could be used as the Person in the above example) Contexts are mutable and would generally work with I/O or similar that are mutable. The snake game I liked to in the other answer was actually what caused this because it buffers keystrokes as they come in. Had it been mutable then I would need to update the reference to the buffer for each keystroke but these are inherently asynchronous which would make it rather hard to reason about compared to accepting mutability.

 

[Matthew Browne]

I checked this out a bit more and it seems to be potentially very useful and role-based, but I'm wondering if it's quite DCI...I'm sort of missing the role-playing *object* part; I guess it might or might not actually be DCI depending on how the agent decides to implement the spec? i.e. the spec itself doesn't seem to specify a notion of objects playing roles.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAGLi4Wh68QO9wE5BSaME%3Dm8kK3yT0AH4xV6TAL1msjJbPQjLaQ%40mail.gmail.com.

[Lund Soltoft]

You are right. The code is not DCI. I have thought about reviving my rust DCI crate and have the LLM use that. The big issue there is that the LLM has a strong biased towards not doing DCI so getting it to do it on a code level is a fairly big task and presently I don’t think the most valuable one. 

I’m more interested in whether the DCI mindset on how to divide a system into contexts is valuable when doing AI (assisted) coding and so far I’ve had no negative effects of it but significant positive ones

Having blurred the lines somewhat with the latter I believe that loosening the constraint might be possible with out tangible cost but I would consider that dangerous territory because with a less strict model there’s going to be more surprises and surprises in LLM land is spelled hallucinations

Mvh

Rune

Den 18. maj 2026 kl. 03.39 skrev Matthew Browne <mbro...@gmail.com>:



To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAJA9FQ-TuG%3Du4uBW2GdeVmsPmfrf1_z7wUyfKq_VJ%2BEnx44WpQ%40mail.gmail.com.

[Matthew Browne]

Although it would be ideal for the generated code to be DCI since it arguably makes the code nicer to review (and debug if needed), I consider the generated code to be analogous to a compiler target in this case, so the details of the generated code are less important. But in the snake game example, I don't even see anything in the spec that would necessarily indicate some group of data or instance methods playing each role, although I suppose the role methods that mention state changes imply it.

I don't mean this as a criticism; after all, this is a new innovation for a new type of programming, and there are different considerations compared to hand-writing code. I'm just not sure if it's really DCI or something new that's DCI-like.

To view this discussion visit https://groups.google.com/d/msgid/object-composition/F22FDCB3-82D0-4F58-8BE9-447DB75EB86C%40gmail.com.

[Lund Soltoft]

I think I agree at least for some definitions of DCI. There’s a mental model and a representation in a coding environment. For the latter this experiment is not DCI and I don’t think it would benefit from it either. The code is meant as an AST. I want to get to a point where that is not review nor needed for debugging. 

From the architectural perspective I think DCI can still be used even when there’s no code. The idea of representing a use case as a context still holds including that the participants gets certain super-powers while playing a role in the context. 

Mvh

Rune

Den 19. maj 2026 kl. 04.06 skrev Matthew Browne <mbro...@gmail.com>:



To view this discussion visit https://groups.google.com/d/msgid/object-composition/CAJA9FQ_hAzaD1oP927nsLPt47KJtk%2BS_RmVwwgALRReUSxzB_A%40mail.gmail.com.