jfawcett

This is another accidental discovery, but it seems to me like something profound that just feels right.

Consider this. We are now in a world where we can think of the network itself as the computer, leveraging the power of the various machines across the network in the same way a programmer would leverage cores, and using shared network RAM in the same way a programmer would use RAM on a local machine. That is FrogNet.

The living network as a computing substrate for a global computer, and I mean it. I can demonstrate it.

In FrogNet, I inverted and just plain rejected many of the tenets of modern network discovery, management, and use. The network forms as members come on-line. It splits and merges seamlessly, and presents a stable, portable substrate for the implementation of what I can only call network-level RAM. Seriously.

To use it, you don't make REST calls. Well, actually, you do, but it's a single API that talks to the network RAM layer in much the same manner as a program accesses memory on a physical computer (put, get), and it works. It may not operate at blazing speeds, but it can span the entire world.

To prove it, I built a network monitor that discovers and reports on new machines without ever contacting a remote server, except the RAM. That was pretty cool, so I went for the brass ring and built a video phone that went from NYC to Seattle at 720p, using TCP. I was able to drop the bandwidth on that all the way down below 150Kbps and back up, adjusting the resolution and frame rate as it went, automatically, and without dropping.

I know this sounds like another wild marketing claim, but it's not. Clone the repo, check the code, and tell me I'm on crack if you want, but having the ability to access shared RAM without writing any special servers or coordination systems really does change how I write distributed code, and in a good way. No unnecessary coordination. No bloated messaging. Just programming.

http://fawcettinnovations.com

I follow traditional software engineering practices. There are unit tests and integration tests that happen before it sees any sort of check-in, and the code itself has sufficient logging to ensure that I am able to reconstruct whatever it was that happened. This is critical.

I write code extensively with the AI, but I make sure that it knows that it must pass all gates before being checked in. I also leave sufficient documentation on the disk and in the code that the intent is clear and the implementation precise.

In other words, don't let them hallucinate and have ways to tell immediately when they have. If you work within their limitations, they can be of great help, but if you assume more than they are capable of delivering, you will be disappointed.

When bugs are discovered, they must be gated by an oracle. The oracle must be red before application of the patch, and green thereafter.