Today I've been working on creating a presentation to better communicate my goal of creating a computer that measure my emotions, the problem it's trying to solve, the high-level inputs and outputs the computer might need to output a list of emotions, and the many questions I have about the process, applications, and learnings.

A big part of the "computer" I will create will be AI. Specifically training AI to transform a set of inputs into emotional data.

I started reading The Age Of AI: And Our Human Future by Henry A. Kissinger, Eric Schmidt, and Daniel Huttenlocher. The purpose of the book is to explain what AI is (historical context, how it differs from traditional algorithms, the different learning methods) and start a discussion about the implications of AI's existence in our day-to-day and in the future.

It's a great book and is easy to follow. It's not very technical and what I'm enjoying about reading this book is that it gives me a little more background on the technology I use every day at work and for my personal projects.

And as I continue to draft my presentation (which I'll share soon in a future post!) I wanted to share a very important learning I had today while having fun building an animated counter.

What I learned was that if AI is struggling to code or achieve the desired outcome I'm trying to communicate to it, that means I'm likely not being specific enough about what I need. And, for programming web applications, I can't be more specific than reading the code it outputted and giving it specific instructions (code instructions) on what to change to achieve the desired outcome.

For example, I was asking Cursor (the AI-code-editor I use) to design an animated counter. Where each digit in the counter animates up toward the end value.

That is how I started prompting AI. And over the course of the next hour, I started to refine my approach. And the key to refining my approach was to simplify my ask and to be more specific about my ask.

To achieve the exact animation I was looking for, I had to first decompose it and understand myself. And then, once I broke down the animation into a smaller sub-component / process, I was able to build that one component. And then, I used that smaller component to build the larger hole.

To be more specific, instead of tasking AI to build an animation for a digit of N numbers, I broke down the problem by defining how to animate a single digit. Then, once I had that animation nailed down, I was able to reuse that single-digit-animation and scale it to N digits.

It was very satisfying to see how breaking down a problem into smaller sub-units and solving each sub-problem on their own can help abstract logic to then simplify higher-level tasks.

I share this here because I think this is an important learning that I will have to continue applying as I try to solve more complex problems to create a computer to output my emotions in real-time.

I'm going to buy the most affordable starter kit from OpenBCI. I had a great conversation with a close friend and they helped me realize how I should try to build a prototype (input > computer > output) as quickly as possible to validate my idea. If I can do that and can make progress on creating quality emotional outputs from a brain activity. Then I can start to dive deeper into customizing different parts of the prototype.

Let's start simple. Thank you DYZ.