I've been using AI - Claude - to code and it seems apparent to me that programming in the way we are doing it at the moment will be obsolete within a year for the most part. At the moment you would still need an understanding of programming and design skills to prompt AI and to refine the results. I'm sure that will become less necessary in time.
However, there are some caveats to using AI.
Any complex system is made up of interrelated modules that perform certain functions: logging to, or retrieving data from, a database; monitoring sensors; A gui to interact with users; the list is varied as any systems designer would be aware. So there are two issues: one is how do we integrate Ai written modules with existing systems, and that's for another post, and the other I want to address here.
If we are designing a completely new system we could, conceivably, give the complete specification to AI and let it build the project. Except, of course, that we can't design a complete system from scratch and expect it to work. We could go through an iterative process that will eventually get us to where we need to be by going, as it were, in ever decreasing circles. Using agile design, prototyping and other methods. These presume that the system can be broken down into modules that can be defined, demonstrated and tested stand-alone. For instance, we have to be able to show a gui to a user without the working system the provides the data for the gui.
Even if we could specify the project to the point where we could simply tell an AI system to go ahead and code, the resultant system would be extremely difficult even for an experienced programmer to understand. And why should anyone take the trouble to understand it? In one sense it defeats the purpose of getting AI to build it. So here lies a problem: if something goes wrong you are dependant on AI fixing it. Modules may be so integrated that making a small change to one module could result in unforeseen effects elsewhere.
The solution is to break any complex system into easily definable and testable modules. UMM (Universal Message Manager) is a publish and subscribe system that connects modules - called agents. An agent receives messages of a certain type, performs certain actions, and (usually) sends messages of a certain type. These messages can be sent from tools supplied with the system so any agent can be easily specified, monitored and tested. Even a complex system can be easily maintained and understood.
Unlike client / server where the client and the server must be built together and are inherently conjoined, publish and subscribe works on the basis that the receiver of a message doesn't know the sender and the sender doesn't know the receiver or receivers. In UMM not only are the senders and receivers separated but also the messages are self-describing so the data in the message is not dependant on a receiving agent expecting data in a particular format.
Of course a client / server modal can be built on top of the UMM infrastructure but even here the usual dependancies disappear. For instance all messages between client and serve can be logged and a server can be replaced mid-session with no loss of data.
If this is of interest, take a look at UMM. We welcome any comments.
Top comments (0)