Will AI powered tools need an ingredients list?
We discussed in the Feb meetup with Christina Monti. Also, I continue to build in public, so pull up a front row seat.
AI as an ingredient
Last week we hosted, with the support of our sponsors Contentful and Plantquest, the first anniversary edition of our online Dublin DevRel meetup. We were joined by the wonderfully sensible, experienced and generous Christina Monti, spending the meetup giving us guidance and contributing to every conversation - thank you Christina!
Christina delivered her talk on the Art of Listening. It generated lots of interest and questions and comments and you can find the entire conversation on the dedicated previous meetups section on the DevRel meetup site here: February Meetup Christina Monti and Richard Rodger (devrelmeetup.com
I then took to the screen to deliver my talk on the chatbot, with some background and shall we say reassurance from one of my favourite sci-fi authors Iain M Banks! The conversation after the talk is revealing and as Christina has recently written an excellent piece about the important of source information as a foundation for AI products and services, we were all rooted in reality. Should we be moving towards a product safety approach like with processed food - “this item contains this LLM”…. ?
Wanna check my building progress?
This is the third post in a series I’m writing about a new Minimal Viable Product we’ve released at Voxgig that turns your podcast into a chatbot. Your visitors can now ask your guests questions directly!
The first post is here: Building a Podcast Chatbot for Voxgig and you find the full list at the end of this post.
We want to ingest a podcast. The podcast episodes are described in an RSS feed that also contains the metadata about the podcast. We send a message to the microservices system describing what we want to happen:
{
aim: 'ingest', // The "aim" of the message is the `ingest` service.
subscribe: 'podcast', // The instruction to the `ingest` service.
feed: 'https://feeds.resonaterecordings.com/voxgig-fireside-podcast'
}
The system routes this message to our implementation code (we’ll come back to how that happens later in this series). Since this is a TypeScript code base, our implementation is a TypeScript function:
async function subscribe_podcast(this: any, msg: any, meta: any) {
let out: any = { ok: false }
out.why = 'no-code-yet'
return out
}
As a convention, our microservices accept messages that are JSON documents and also respond with messages that are JSON documents. There may not be a response (if the message is an “event”), but if there is, we use the property ok: boolean
to indicate the success or failure of the message, and use the why: string
property to provide an error reason to the sender.
Why use this convention? You can’t throw exceptions over the network (easily or naturally). But you also don’t want to use exceptions for business logic failures. The system itself hasn’t failed, just some business logic process.
Our initial implementation does nothing except fail, but we can still test it by using the REPL:
boqr/pdm-local> aim:ingest,subscribe:podcast
{
ok: false,
why: 'no-code-yet'
}
Now we can start to write code to fill out the implementation, which will get hot-reloaded as we go, and we can keep using the REPL to test it. This is what they call Developer Experience folks.
Let’s pause for a minute before writing any more code. And you can now head to my site to read the rest of the article.
See you next time!