Make-believe and Pretend: The Value of Child-like Behavior in the Age of AI

Summary:

When engaging with AI in a 'no code' or 'low code' software development effort, it is important to:
- anthropomorphize the AI development 'partner' from the very start;
- engage in pretend play with the AI by creating context, assigning and assuming explicit roles implying specific accountability and expertise;
- utilize existing frameworks, rituals, and artifacts, such as those from Agile to engage in structured communication within the Agile rituals and using the Agile artifacts appropriate to the roles which have been assumed;
to transform the pretend play into a formalized activity with predictable and repeatable outcomes.

Detail:

I am on a new development journey. The goal is to build a new website for an author who is shortly going to be pitching a new book. The current website is hosted on Google. It was assembled by a 15 year old digital native and met the need of the time. There is a list of complaints to be addressed. I need to figure out how.

I recently built a very simple landing page using Cursor AI for my own personal website. I did no coding. The AI was like a golden retriever: eager to please and kind of all over the place. In the end I got what I wanted. The experience gave me ideas.

There are a lot of YouTube videos about 'Low Code/No Code' development using LLMs and AI-powered IDEs. Reddit has a lot of noise about all that as well. I spent some time ingesting, and the strategy that jelled out was not what I expected. But I am trying it, and so far it is really working.

In a nutshell, what I have learned is that successful no-code projects are essentially a series of very intentional and well-planned games of make-believe.

In this article I will explain what I mean when I say that, and how I am using that knowledge to be successful in my current project.

I'm a girl dad, and let me tell you, when you get invited to a tea party in the swankiest play room in all of the cul-de-sac, you better bring your best game. Your host will be dressed in a way that makes professional runway models weep. The etiquette of making and pouring the tea will be flawless. The culinary artistry of the little sandwiches that have no crusts will be understated, but contain coded cultural messages. The conversation will be very much reflective of your social stature and role in society. Attendees will come away with serious mutual obligations to be fulfilled.

Having done this enough to be comfortable in high society parlors all over the basement, I have more than a few questions, like 'how does a 6-year-old know about the intricacies of properly, pinky out, holding a tea cup?' Where exactly they pick these things up, I cannot tell you, but the fact they do is incredibly important.

Tea parties, both the actual very-British adult kind and the six-year-old kid version, are a form of meeting. Meetings are interesting because they transform social human encounters into intentional activities with repeatable and predictable outcomes. People in meetings represent knowledge and capability. Meeting outcomes generally involve agreements between the people on how the knowledge and capabilities will be utilized. This makes meetings a form of interface used to access resources and skills. Run a meeting well with the right people in the room, and you can get access to anything you need to accomplish your goals.

Six-year-olds hold tea parties because they are engaged in both active and unconscious learning about they world they live in and how it works. Emulating the social behaviors they observe using pretend play is how they learn to navigate that world as independent actors, access the resources needed to sustain that independence, and build social capital through the acquisition and fulfillment of mutual obligations. So tea parties, no matter who is hosting them, are serious stuff.

When we speak about interfaces in the technical world, we are often referring to visual interfaces. We shorthand this by saying 'UX', 'User Experience', to be clear about what we mean. A big debate in the UX world is the extent to which visual interfaces should be skeuomorphic. Skeuomorphic is a big word meaning that what you see on the screen looks like something you would use in the physical world. Pressing ⏯ to play music on a handheld device is using a skeuomorphic visual interface: the symbol you are pressing was first used on physical buttons on cassette tape machines in the 70s and persists today as an icon even though the physical buttons have mostly gone away.

The existence of skeuomorphic visual interfaces implies there are other types of skeuomorphic interfaces as well. A minute ago I described a tea party as a type of behavioral interface which, when properly navigated, resulted in access to resources and know-how. So it follows that in an AI-enabled electronic world there is a type of skeuomorphic behavioral interface that similarly results in access to resources and know-how.

So if you have been wondering where I am going with all of this, we have arrived at the key insight, which is that to get the most out of AI possible in a low-code/no-code type of activity, the interface you should use is an emulation of the social interfaces used by people, which are meetings. And since the AI has never actually, you know, been in a meeting, and is only factually a few years old and not actually a real person at all, it won't be a 'real' meeting, it'll be a pretend meeting. Essentially, you need to start holding tea parties.

So what is the content of these pretend meetings? What should you be doing when playing pretend with an AI to transform the activity from a random set of questions and answers into an intentional activity with repeatable and predictable outcomes?

My former Cisco colleague Liliya Lund put a very insightful post up on Linkedin which provided some pretty serious clues:

The thing that immediately clicked for me when I saw this diagram was the obvious-in-hindsight connection between the use of AI as an execution resource and the practice of Agile as an enabling ritual framework. If you read the prevailing sentiment on AI development using, say, Cursor, it is very clear that successful AI-enabled development sessions start with standups to establish context, progress to focus on well-documented and clearly described deliverables best formatted like user stories, and governed by a backlog which can be updated or reprioritized at any time based on the later discovery, or sinking realization in the moment, of the current state the AI has left your code base in.

Many are now using AI as the equivalent of a development team, and learning that the AI development team you get using current technology is inconsistent, undisciplined, and difficult to consistently communicate with effectively. Agile rituals and artifacts are ideal and existing forms which have been developed to solve these issues when communicating with real people. In the pretend world of 'tea parties with AI' they can, if appropriate effort is placed into them, function equally well as a means of structuring intentional communication with a not-entirely trustworthy and totally inhuman AI counterpart.

So what is the takeaway here? When engaging with AI in a 'no code' or 'low code' software development effort, it is important to:
- anthropomorphize the AI development 'partner' from the very start;
- engage in pretend play with the AI by creating context, assigning and assuming explicit roles implying specific accountability and expertise;
- utilize existing frameworks, rituals, and artifacts, such as those from Agile to engage in structured communication within the Agile rituals and using the Agile artifacts appropriate to the roles which have been assumed;
to transform the pretend play into a formalized activity with predictable and repeatable outcomes.

It is early days and we are learning a lot in a rapidly changing environment. Next month this all may be different, but for now this is what I have found resonates and works best for me.

About Me
I'm an experienced business architect with experience in both startup and mature organizations. I take a data-driven approach to the design, implementation, and optimization of the people, processes, and tools required for your organization to accelerate into the future. If that seems helpful to you, please reach out. I'd love to learn more about you and how I can help with the challenges you face.