Forem: Jordi Cabot

None of the top 10 projects in GitHub is actually a software project 🤯

Jordi Cabot — Sat, 10 May 2025 18:28:33 +0000

As part of our ongoing research, we periodically monitor GitHub to understand what is gaining traction and popularity within the community, using stars as a proxy. In May 2022, our analysis of the top 25 starred repositories revealed some surprising trends, particularly the prominence of non-software development projects. We analyzed the projects following the previously identified six main categories according to the project's content: software, awesome list, books, study plan, algorithm collection and style guide. You can refer to our previous post for a description of the categories.

We have now repeated the analysis, using the same categories. And we have observed some interesting shifts. The following figure shows the distribution of these categories for the top 25 starred repositories in GitHub:

The list of repositories can be found here.

Our surprise was that while software development projects continue to hold a significant presence, their prominence has diminished compared to the remarkable growth of awesome lists and study plans. Awesome lists and study plans often focused on documentation and educational resources, which highlight GitHub's evolving role as a hub for collaborative knowledge sharing.

Some other highlights, comparing them with our last analysis are:

We see an addition to the AI community with AutoGPT. Along with Tensorflow they represent the AI community in the software category, which is getting relevant (2 out of 8). We can expect in the future to have new AI projects in the top 25 such as Transformers or Ollama (currently top 34 and 36, respectively).
There is no software project in the top 10 projects. These are awesome lists (5), study plans (4), and one books project. Thus, we see how important is the social role of GitHub beyond coding. These kinds of projects are maintained by the community with the addition or removal of items from a list of items.
Chinese projects are still the only non-English projects we see in the top 25, such as CyC2018/CS-Notes, maintaining its importance in the platform. There is also a project not related to code nor books or guides, but to the labor of coding. This is 996.ICU, used to track companies that still apply this abusive work schedule called 996 (9 a.m.–9 p.m., 6 days per week). So we can even see GitHub being used as a community building platform, where people share their concerns on practices related to developing software.

From this review, we can see that our conclusions from last post still stand:

GitHub's transformation into a social platform for collaborative efforts beyond coding is evident. Reviewing our previous conclusions:

From this review, it is clear that the presence of non-software projects on GitHub continues to grow. This trend may significantly affect the efforts of the mining-software community, which relies on massive data analysis, or representative samples, to extract meaningful insights. As non-software repositories become more prevalent, researchers must take extra precautions to filter out irrelevant projects to ensure the accuracy and relevance of their findings.
We see some projects that can financially survive (via sponsor or external infrastructure such as open collective or patreon), favoring the long-term sustainability. Thus, we keep our stand on promoting a transparent governance model to state where the investment will be managed and who can benefit from it, especially when knowing that non-technical users have an increasing key role in these communities.

As GitHub continues to evolve, we will keep a close eye on these trends to provide ongoing insights into the platform's direction. Our research will adapt to these changes, ensuring that we remain at the forefront of understanding GitHub's role in the broader tech ecosystem.

Beyond Vibe Coding: Welcome to Vibe Modeling

Jordi Cabot — Thu, 01 May 2025 14:38:40 +0000

Everybody talks about vibe coding, where you develop software by talking to an LLM tuned for coding. And keep asking it to create what you need until you get something that (apparently) works. And the "apparently" is key here. Even Andrej Karpathy, who coined the term, said it was great for throwaway weekend projects where people, even if they had no coding expertise, could quickly explore and build artefacts that mostly work.

Despite all the hype, vibe coding should never be used for more than this, as getting the result of a vibe coding session ready for production would require:

coding expertise and
as much time to test and fix the code as if you started the project from scratch with a "traditional" process.

But what if we could keep the magic of AI-assisted development without the unpredictability of LLM-generated code? That’s where vibe modeling comes in.

What is vibe modeling?

Vibe modeling is the process of building software through conversational interaction with an LLM trained for modeling, not coding. And then following a model-based / low-code approach to generate deterministic code from those "vibed models". Think of vibe modeling as a model-driven vibe coding approach.

Indeed, in vibe modeling, the LLM does not aim to generate code but models. And the model-to-code step is performed with "classical" code-generation templates (or any other type of precise and semantically equivalent executable modeling techniques).

This has two major advantages over vibe coding:

Understandable output. A user is able to validate the quality of the LLM modeling output even if he has no coding expertise. Models are more abstract and closer to the domain and, therefore, a user should be able to understand them with limited effort. True, some basic modeling knowledge may still be required but for sure it's much easier to validate a model (e.g. a graphical class diagram) than a bunch of lines of code
Reliable code-generation. The generation process is deterministic. If the model is good, we know the code is good and there is no need to check it.

And vibe modeling is just one of the possible low-modeling strategies and could be combined with them. For instance, you could upload to the LLM (as context for the prompt) any document already describing the domain you want to model (interviews, manuals, tutorials, ....) and then have a chat with the LLM to improve / adapt this first partial model.

Is there any vibe modeling tool?

Not quite. Low-code tools (like BESSER or Mendix) offer more and more AI features. But right now, mostly focusing on some kind of smart autocomplete for models. Not so much offering a kind of an integrated chatbot you can use for vibe modeling. We do have implemented a tree-of-thoughts approach for domain modeling and now are working in integrating a chatbot in the BESSER web modeling editor to go from this one-shot model to an iterative, conversation-based, model refinement. But you'll need to wait a little bit more for that.

In the meantime, we’d love to hear from you: 👉 What features would you want in an ideal vibe modeling experience?

Three laws of software agents by Isaac Asimov (kind of)

Jordi Cabot — Thu, 03 Apr 2025 23:35:47 +0000

What would Isaac Asimov think about the software agents taking the world by storm and, more and more, taking care of building the applications of the future? Would he had reframed his three laws of robotics?

We will never know, but I'd like to propose my own interpretation, keeping the original spirit of the rules (if you need a reminder, read the original rules at the end).

The three laws of software agents

An agent should not introduce bugs in a software, or through inaction, allow a human to do so
An agent must obey orders to modify the software given by human beings except when such orders would conflict with the First law
An agent must protect its own contributions to the software as long as such protection does not conflict with the First or Second Law

What do you think? Do you have an alternative proposal (if so, happy to read it, leave it a comment!)

The original rules

In case any of you needs a reminder, here are the original three laws of robotics which were to be followed by robots in several of his stories. The rules were introduced in his 1942

A robot may not injure a human being or, through inaction, allow a human being to come to harm.
A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

Other rule variations

I'm obviously not the only one versioning the rules. For instance, I found these other three rules for software development:

A developer must write code that creates value.
A developer must expend effort making their code easy to maintain, except where such expenditure will conflict with the first law.
A developer must reduce their code to the smallest size possible, as long as such reduction does not conflict with the first two laws.

or these other three laws of informatics

Programs must be correct.
Programs must be maintainable, except where it would conflict with the First Law.
Programs must be efficient, except where it would conflict with the First or Second Law.

that also make sense to me. Have you seen other examples?

On the rewards of programming by Donald E Knuth

Jordi Cabot — Sun, 24 Nov 2024 18:17:24 +0000

If Donald E Knuth says it, who are we to disagree?:

"Computer programs are fun to write, and well-written computer programs are fun to read. One of life's greatest pleasures can be the composition of a computer program that you know will be a pleasure for other people to read, and for yourself to read.

Computer programs can also do useful work. One of life's greatest sources of satisfaction is the knowledge that something you have created is contributing to the progress of welfare of society.

Some people even get paid for writing computer programs! Programming can therefore be triply rewarding ---on aesthetic, humanitarian, and economic grounds"

Taken from his book on Literate Programming

Dashboard of open source low-code tools

Jordi Cabot — Sun, 24 Nov 2024 13:59:25 +0000

I've created a dashboard listing open-source low-code tools available as public repositories in GitHub.

The selection method is based on the following inclusion criteria:

Repositories that declare themselves as low-code projects
Repositories with more than 50 stars
Active repositories (last commit is no more than 1 year ago
Tool aims to generate any component of a software application, including AI components, dashboards, or full applications

and exclusion criteria:

Repositories with no information in English
Repositories that were just created to host the source code of a published article
Repositories that are awesome lists or collection of resources

The final list is the intersection of the above criteria. The final list has also been manually curated to remove projects that use low-code in a different sense of what we mean by low-code in software development.

An initial search with the above inclusion resulted in a surprising total of 301 candidates. But a couple of years ago (February 2022) I had written a post complaining about the lack of open source low-code tools. Was I wrong? Has the situation changed drastically over the last two years? What's going on?

Real number of real low-code tools

While it's true that there were 301 tools satisfying the inclusion criteria, the dashboard only lists 151, once we remove those not complying with the exclusion criteria.

But 151 is still quite a lot compared with what I covered in the previous post. So I decided to see how many of these low-code tools were model-based. Or just mentioned the word models (or derivatives). It turns out, only 9 of the 151 low-code tools claim to use any type of model. Not even 9 if we remove a couple that only target AI components and merge the three repos of the same platform. Of course, BESSER is one of the few exceptions 😇.

And to me, this minimal number is the one that matters. As you know, my vision of low-code is linked to that of model-based approaches so tools called low-code where there is zero control on how such code is generated are not what I'd really call low-code. So in this sense, I still believe there is a lack of open source low-code tools, as I understand them.

A fragmented community

Keep in mind that I'm not saying there are no other model-driven tools or code-generators in GitHub beyond the tools in the dashboard.

In fact, there are a few. For instance, Telosys (that we also covered here). But Telosys defines itself as a "lightweight and pragmatic code generator", not as a low-code tool. Once again, the diverse terminology in our area makes a small domain even smaller and hides useful tools from potential users that are using the "wrong" keywords. To read mode about the relationship between the low-code and model-driven communities, take a look at our work on a Metascience Study of the Adoption of Low-Code terminology in Modeling Publications, which we are now updating and extending as I still believe it's an important discussion to have in our community.

Other interesting aspects

A significant number of low-code tools are Chinese and targeting only Chinese users (as there is zero effort in having any type of English documentation, not even in the readme). As I don't speak Chinese I can't really dig deeper in the characteristics of these tools but it does seem low-code has a strong presence in China. Given the exclusion criteria, these tools are not part of the dashboard but it was indeed one of the most used exclusion criteria when going down from 301 to 151.
There are very few low-code tools in Python (see the end of the dashboard for some global stats like this one). Most of the existing ones are low-code tools targeting specific AI components, not low-code platforms for a full application development. Once again BESSER is one of the few exceptions, but in a world becoming more and more AI-driven, I'd like to see more low-code tools embracing Python, and thus, facilitating the interaction with machine learning and AI libraries.
If you look at the distribution of tools per year of creation, you'll see that some tools were created before the low-code term was coined. This means that such tools saw the marketing wave of low-code and decided to rebrand themselves to gain visibility.
The dashboard itself was built with the help of Cursor. As usual, I was faster than if I had done it alone but I still suffer some hallucinations (Cursos suggested to use a Cell Renderer that made a lot of sense but that, unfortunatley, didn't exist and for a couple of bugs I had to go the "old way" and find myself the solution in StackOverflow and the Streamlit forums)

Check out the dashboard

Check out the dashboard, play with it and let me know what you think. Here or in the dashboard GitHub repository.

A wishlist and (potential) architecture for a low-code platform for smart software development

Jordi Cabot — Fri, 13 Jan 2023 12:38:42 +0000

Smart software, also called "AI-enhanced" or "ML-enabled"give rise to unique software engineering challenge as these systems are harder to specify, verify and test. Additional complexity arises from all the potential interactions between the AI components and the “traditional” ones (since we need to specify how they collaborate, test that they behave consistently and analyze their interdependencies).

In this post we offer a “wishlist” that outlines what developers need to watch for in low-code tools for smart software. Also, we present work on an architecture (see featured image) that is one way to satisfy items on that wish list.

Low-code for smart software wishlist

We believe a developer working on smart soft-ware would be interested in a low-code platform capable of:

Managing concerns for both AI components and traditional software components in a consistent and integrated way including their interdependencies (e.g., an AI component trained using the data entered via a regular component).
Supporting the complete lifecycle of the required AI components (training, validation, deployment and monitoring), as well as tracking the decisions behind their architecture and evolution.
Operating with a technology-independent and platform-agnostic specification while supporting a transparent deployment to different AI service providers.
Enabling the integration of AI components in both the front-end (e.g., chatbots) and back-end (e.g., prediction tasks) of our system.
Defining high-level goals or quality concerns (e.g., fairness) that can be automatically tested and/or monitored after deployment.
Being used without intricate knowledge of the underlying AI techniques, offering mechanisms to automatically select a suitable method and (hyper)parameters for a particular usage scenario.
Supporting a variety of AI tasks, beyond text or image classification.

A low-code architecture for smart software

To provide the features identified in the previous wishlist, we envision the following architecture

This architecture is based around the following components:

Model editor. Developers provide the description of the software system using a unified notation, a smart software model, which includes both traditional and smart elements:
- A description of the application domain and the architecture of the software system, i.e., components and the relationships between them.
- A high-level description of the tasks to be performed by the AI components, the target quality metrics as well as concerns (e.g., ethical issues, resource budget for training or deployment) that should be considered.
- A description of the input data sources storing to be used for the training of AI components, with emphasis on the identification of information relevant from the point of view of fairness.
Code generator. The information provided in the model drives the generation of code implementing the different processes within the low-code tool. Who knows? LLMs (large language models) could also play a role here!
Training. The code generator emits code to train a ML model, preparing training and validation datasets from the input data sources according to the resource budget. After training, the target quality metrics are measured and any ethical constraint is checked.
Deployment. The trained model is deployed on a particular AI platform, which can be either a cloud service from a variety of providers or a local AI package.
Traditional software components. Software modules that do not integrate AI features are generated in the usual way. These modules interact with AI components through a dedicated API.
Monitoring and feedback. Finally, the AI components should be continuously monitored and tested after deployment in order to provide continuous feedback to the developer. This feedback should include explanations regarding the decisions made by AI components, linking back to the input data sources or tracing back to requirements in the input model.

All components in this architecture are feasible and partially already exist as separate elements in other low-code, AI or monitoring plat-forms. But bringing them all together in a unified framework could be a force multiplier and a significant next step in lowering the barrier to entry for the next generation of smart software developers.

To read more

This post is a summary of a reflection we published in this column, co-authored by myself and Robert Clarisó for IEEE Software on the promises and challenges of low-code platforms to accelerate the development of smart software.

The full tech stack to run a chatbot — behind the scenes of an open source bot platform

Jordi Cabot — Tue, 12 Jul 2022 12:46:39 +0000

We always aim to "educate" aspiring chatbot developers about the software challenges of building and running a good chatbot. Today we want to go a bit further and give you a behind-the-scenes look at all the languages, libraries and frameworks that must play together to run a chatbot.

As the full stack depends on the specific chatbot (especially regarding the communication channels where it will be deployed), we will use our ecommerce chatbot as an example.

1. The core chatbot logic

The core elements of the ecommerce bot (the intents, training sentences and business logic to execute for every matched intent) are implemented with our Java Fluent API that wraps a set of EMF-based core classes modeling our chatbot specification primitives and the help of Lombok to simplify the writing of the bot specification.

As the bot is automatically adapted to the data of the eCommerce shop hosting the bot, the bot logic communicates with the WooCommerce API and stores some shop data into a SQL PostgreSQL database.

2. The NLP Engine

To determine which chatbot intent is the best match for the user textual input, we rely on nlp.js (in JS) though we are in the process of moving to our new Python NLP server for better optimization of the needs of eCommerce conversations. A preprocessor language model is also used to improve the chances of a matching.

3. The front-end

The eCommerce chatbot is implemented as a WordPress plugin in PHP whose mission is to simply embed in the proper PHP WP pages the Xatkit widget displaying the bot. The widget itself is a react component that talks with the server component managing the core chatbot logic via a websocket.

4. The configuration and monitoring component

Any non-trivial bot comes with a dashboard to configure the bot (e.g. removing some predefined conversations, adding new ones, ...) and monitor its results, showing, for instance, the user questions the bot was unable to understand.

Our eCommerce dashboard is a Spring application relying on Thymeleaf as server-side Java template engine and foundation as responsive front-end framework.

All in all, chatbots are indeed a complex piece of engineering

Take a look at all the links above. We have 5 major programming languages (together with their package managers: maven, npm,...). 7 if we count HTML and CSS. Plus a myriad of auxiliary libraries and frameworks that require specialized knowledge, e.g. knowing Java doesn't mean you can master Spring in a breeze. Or even less that you would be able to create Java Fluent APIs.

If you don't have the luxury of having a large team with specialized profiles, maybe it's time to start testing all these intelligent code assistants. And I'm only half-joking.

Definitely, I feel we need better software engineering tools that help manage the complexity of these type of multi-language projects and their dependencies. For instance, we have (a few) tools for reverse engineering large codebases written in one language and help you understand and evolve it. But I don't know any that can do the same with a number of different repositories (we have over 80, including private ones, in Xatkit !) in a mix of languages where the dependencies between the components are not as "easy" as looking for imports or references in the package manager definition.

While we wait for these tools to pop up, any tech question on the internals of Xatkit you'd like to know? And if you want to read more about the technologies we have listed above, this twitter thread gives some pointers to good tutorials for them:

// Detect dark theme var iframe = document.getElementById('tweet-1545179026666438657-764'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1545179026666438657&theme=dark" }

How to build your own chatbot NLP engine

Jordi Cabot — Mon, 28 Mar 2022 09:23:57 +0000

This post goes over our new NLU chatbot intent classifier engine for chatbots to show how you can use it to:

(obviously) Create your own chatbots (pairing it up with Xatkit or any other chatbot platform for all the front-end and behaviour processing components)
Learn about natural language processing by playing with the code and executing it with different parameter combinations
Demystify the complexity of building a NLU engine (thanks to the myriad of wonderful open-source libraries and frameworks available) and provide you with a starting point you can use to build your own.

Ready for some NLP fun? We'll first give some context about the project and then we'll take a deep dive into the NLU engine code.

What is an intent classifier?

An intent or intention is a user question / request a chatbot should be able to recognize. For instance, the questions in a FAQ-like chatbot. To be able to answer the user input request (called user utterance) the bot needs to first understands what the user is asking about.

An intent classifier (also known as intent recognition, intent matching, intent detector,...) is then the function that, given a set of intents the bot can understand and an utterance from the user, returns the probability that the user is asking about a certain intent.

Nowadays, intent classifiers are typically implemented as multi-class classifier neural network.

Does the world really needs yet another NLU chatbot engine?

Probably not. In fact, in Xatkit we aim to be a chatbot orchestration platform exactly to avoid reinventing the wheel and the non-invented here syndrome. So, in most cases, other existing platform (like DialogFlow or nlp.js) will work just fine. But we have also realized that there are always some particularly tricky bots for which you really need to be able to customize your engine to the specific chatbot semantics to get the results you want.

And this is sometimes impossible (for platforms where the source code is not available, which, by the way, is the norm) or difficult (e.g. if you're not ready to invest lots of time trying to understand how the platform works or if the platform is not created in a way to easily allow for customizations.

And of course, if your goal is to learn natural language processing techniques, there is nothing better to write some NLP code :-). Ours is simple enough to give you a kick-start.

What makes our NLU engine different?

Xatkit's NLU Engine is (or better said, it will be, as what we're releasing now is still an alpha version with limited functionality, which is good to play with and to learn, not so much to use it on production ;-) ) a flexible and pragmatic chatbot engine. A couple of examples of this flexible and pragmatic approach.

Xatkit lets you configure almost everything

So that the data processing, the training of the network, the behaviour of the classifier itself, etc can be configured. Every time we make a design decision we create a parameter for it so that you can choose whether to follow our strategy or not.

Xatkit creates a separate neural network for each bot context

We see bots as having different conversation contexts (e.g. as part of a bot state machine). When in a given context, only the intents that make sense in that context should be evaluated when considering possible matches.

A Xatkit bot is composed of contexts where each context may include a number of intents (see the dsl package). During the training phase, a NLP model is trained on those intents' training sentences and attached to the context for future predictions).

Xatkit understands that a neural network is not always the ideal solution for intent matching

What if the user input text is full of words the NN has never seen before? It's safe to assume that we can directly determine there is no matching and trigger a bot move to the a default fallback state.

Or what if the input text is a perfect literal match to one of the training sentences? Shouldn't we assume that's the intent to be returned with maximum confidence?

This type of pragmatic decisions are at the core of Xatkit to make it a really useful chatbot-specific intent matching project.

Show me code!

At the core of the intent classifier we have a Keras / Tensorflow model. But before training the network and using it for prediction we need to make sure we process the training data (the pairs in this case). And to make the NLP Engine useful we expose it through an easy-to-use REST API that makes it easy to integrate it in external platforms or libraries.

So, overall, the project structure is the following:

Main.py holds the API definition (thanks to the FastAPI framework). The dsl package has the internal data structures storing the bot definition. The dto is a simplified version of the dsl classes to facilitate the API calls. Finally, the core package includes the configuration options and the core prediction and training functions.

Core Neural Network definition

At the core of the Xatkit NLU engine we have a Keras/Tensorflow model.

The layers and parameters are rather standard for a classifier network. Two aspects worth mentioning:

The number of classes depends on the value of len(context.intents). We have as many classes as intents are defined in a given bot context.
We use sigmoid function in the last layer as the intents are not always mutually exclusive so we want to get the probabilities for each of them independently

Preparing the data for the training

Before training the chatbot using the above ML model, we need to prepare the data for training.

Keep in mind that bots are defined as a set of context where for each context we have a number of intents and for each intent a number of training sentences.

To get the training started, we take the training sentences and link them with their corresponding intents to create the labeled data for the bot.

Some details on the code listing above:

We assign a numeric value to each intent and we use that number when populating the total_labels_training_sentences list
We use a tokenizer to create a word index for the words in the training sentences by calling fit_on_texts. This word index is then used (texts_to_sequences to transform words into their index value. At this point training sentences are a set of numeric values, which we call training_sequences
Padding ensures that all sequences have the same length. This length, as always, is part of the NLP configuration.
The model is finally trained by calling the fit

Predicting the best intent matches

Once the ML model has been trained, prediction is straightforward. The only important thing to keep in mind is to process the user utterance with the same process we prepared the training data. Note that we also implement one of the optimizations discussed above to directly return a zero match prediction for sentences where all tokens have never seen before by the model.

Exposing the chatbot intent classifier as a REST API

The main.py module is in charge of exposing our FastAPI methods. As an example, this is the method for training a bot. It relies on Pydantic to facilitate the processing of the JSON input and output parameters. Parameter types are the dto version of the dsl classes.

Ready to give it a try?

Great. Go over to https://github.com/xatkit-bot-platform/xatkit-nlu-server and follow the installation instructions. Even better if you watch/star it to follow our new developments. And even, even better if you decide to contribute to the project in any way, shape or form you can!

How to program a chatbot that reads all your website and answers questions based on its content

Jordi Cabot — Mon, 27 Dec 2021 07:24:49 +0000

I'm sure you often get questions from your visitors and think "but this is already on the website!". You then added a chatbot to your site to filter out the most common questions. But what about all the rest. Adding more and more questions to the bot it takes time. So, is there an easy way to let the chatbot find the answer by itself for those questions that are already answered somewhere in the (hundreds? thousands?) pages, posts or other online documents you've already published?

YES!. The key is to plug Haystack to your chatbot. We have several pretrained language models fine-tuned for Question Answering that can be used to find an answer in a text but they only work when the text length is really small. Here it is where Haystack comes into play. Haystack architecture (see the featured image above) proposes a two-phase process:

A Retriever selects a set of candidate documents from all the available information. Among other options, we can rely on ElasticSearch to index the documents and return those that most likely contain the answer to the question
A Reader applies state-of-the-art QA models to try to infer an answer from each candidate

Now we just need to return these inferred solutions together with additional information (context, confidence level,...) to help our users understand why we think this is the answer they were looking for. All thanks to a completely free and open source NLP framework!

Let's see how we can benefit from Haystack by creating a chatbot able to answer software design questions for the WordPress website modeling-languages.com. Haystack website is full of useful examples, so we'll adapt them in our scenario.

Creating the chatbot, the "front-end"

The easiest part is to create the chatbot. We'll obviously use Xatkit for this. The bot can have as many intents as you wish. The only part that we care about here is the default fallback state. Here, instead of saying something useless, e.g. "sorry I didn't get your question, can you rephrase it and try again?", we will ask Haystack to find us a solution.

Here we have all the pieces locally deployed but obviously each of them could be in a different server.

Loading the information to ElasticSearch

Before we can find an answer, we need to first power up ElasticSearch with the documents we want to use as information source for the bot. In this example, the documents will be all posts published in modeling-languages. We assume we have direct access to the WordPress database but otherwise we could write something similar using the WordPress REST API instead. Note that we split each post in different paragraphs to avoid chunks of text that could be too much for the QA models.

I deployed a Flask server to facilitate calling all the endpoints on-demand, especially needed for those that the bot needs to interact with.

Finding the answer

The Retriever component will look for the most promising documents in ElasticSearch (by default, using the BM25 algorithm but there are other options). The Reader will look into each candidate and try to find the right answer in it. Thanks to the predefined Pipelines provided by Haystack, putting everything together is really easy:

Once we have the answer, we create the response object that will be sent back to the chatbot. As a final step the chatbot will print this response to the user together with the URL of the post the answer comes from. This way, even if the answer is not perfect the user will have the option to go to the suggested URL.

But, does it work?

We've seen it's feasible to add the Haystack infrastructure to a chatbot. But what about the quality of the answers? Are they good enough?

The answer is that it does work reasonably well. The modeling-languages website was not the easiest one to try with. It's rather large (over 1000 posts that translate into around 8000 documents) with significant overlappings. And there are still some "legay" posts in Spanish that add to the confusion.

Let's see a couple of examples. In the first one I ask on how can I add a business rule (i.e. constraint) to a software design model. The first answer is technically correct (indeed, constraints are written on top of models) but rather useless. The next two are exactly what I was hoping to see an answer as they suggest me to use the Object Constraint Language to specify my constraints.

The second question is more concrete but it has a more open answer. Note that all answers are taken from the same document (the only one that realy talks about this Temporal EMF tool). All answers are reasonable but the third one really nails it. And keep in mind that we're using an extractive QA model, meaning that the model aims to return a subset of the text containing the answer. Instead, a generative QA model (also available in Haystack) would be able to "build" the answer from partial answers, potentially spread out in more than document.

In terms of performance, results were very satisfactory. The whole process took just a few seconds (once the initial model loading) but this is on my poor laptop. With proper configuration and tuning, the user should not notice a major delay. Haystack itself can also be deployed as a REST API which should optimize even more the whole process. And of course, you could always let the bot designer to configure whether to use Haystack in the default fallback or not, depending on a number of factors.

Choosing Java as your language for a Machine Learning project - Are we crazy???

Jordi Cabot — Thu, 04 Nov 2021 11:13:26 +0000

Most people are stunned when they realize that the Xatkit bot engine is written in Java.

True, the vast majority of AI / Machine Learning projects are written in Python. But this doesn't mean that you should go with Python when starting your own project. And don't worry, this is not a post about language wars. I don't pretend to say that Java is better than Python (nor the other way round, for that matter). I'm just explaining our language choice. And suggesting that you should take into account many aspects when choosing the base language for your next project.

Let's see why Java is a good choice for Machine Learning projects, or at least as good as a choice as many others:

Machine Learning is only a small part of your project. Most of your code will NOT be about ML tasks but about data input/output, user interface, interaction with external services,... so the language needs to be good at all these things as well. This is especially true in the case of chatbots that, to begin with, need to interact with different user input platforms.
There are ML libraries available for every language. So there is always a way to execute/train your neural networks outside the python world. For instance, in Xatkit, we reuse Stanfords' Core NLP models in some of our language processors. And, if needed, there is always the option to wrap the ML models code in a Python server (I like the simplicity of Flask for this) and consume them via API calls to this server.
Java is heavily used in the enterprise world. So while core ML fans may frown at our language choice, enterprise users may see Java as a benefit as they already know how to manage and deploy Java-based applications but they could not have the same experience with Python or other languages.
We are Java "experts". We are much more productive coding in Java than with any other language. Of course, we could become proficient in Python if we put the time but time is precious and it made sense to stick to the language we were already using in other projects
Xatkit is a model-based tool. By model, I refer here to software design models, not ML ones. An in the modeling ecosystem, Java is still the boss. In particular, Xatkit reuses some EMF libraries, mostly to do some reflection on the bot definition at runtime. For sure, there are other ways to accomplish the same goal, but you can see this as a legacy decision before Xatkit embraced Fluent APIs for the bot definition.

As you can see, maybe Java should not be your first option when getting started in AI technologies if there is really no constraint at all on your language choice. Otherwise, the choice of a language is more of a social/team/organization decision that should take into account many other aspects (team knowledge, organization architecture, integration needs,...). We see developers arguing non-stop about why language A is better than language B but for most projects, even those including some kind of intelligent component, any major language will work and that choice will NOT be the core element in the project success at all.

So, forgive me if we continue developing bots in Java :-)

Beyond no-code: no-learn and no-work development

Jordi Cabot — Sun, 18 Apr 2021 06:29:59 +0000

No-code solutions aim to empower non-technical people to create their own software solutions with zero need to code anything at all. The term no-code is sometimes used as a slight variation of low-code. In fact, we can often see tools defining themselves as no-code/low-code tools. All big companies are buying into it.

I discussed before the difference between the low-code and no-concepts. Long story short, no-code really means no code at all, which limits the variety of applications you can build. We are basically looking at template-based frameworks or the creation of workflows mixing predefined connectors to external applications where the designers, at most, decide when and how certain actions should be triggered. This is a reasonable trade-off if you don't want/have the time to learn to code. And the number of different applications you could create is still huge with an increasing number of no-code solutions ready to help, no matter the type of applications you have in mind. But no-code doesn't mean that you'll be able to create your dreamed application in no time.

I want to highlight two subcategories of no-code applications: no-learn and no-work development tools. The following image describes the relationship between each category.

No-Learn software development

No-learn development tools correspond to the set of no-code frameworks that let the users employ their own tools to define the software to be built. Instead of the user having to learn to use the no-code tool and the (graphical) language behind it, the no-code tool is able to read and import the software definition from Word, Excel or whatever other tool users in that domain typically use.

An example would be our Excel to chatbot service. Instead of forcing users to learn a new interface and language to define chatbots, we offer them an Excel template that lets them define bots in a tool they already know. No matter how great is our no-code tool, if it's a new tool the user will need to invest time learning it. Better to eliminate this barrier to entry.

A no-learn tool can still have the same expressiveness as a general no-code one. We're not limiting what users can do with it, just changing the language in which that no-code project will be defined.

No-Work software development

No-work is an extreme case of no-code development where the user does nothing. Users do not code but neither do they define the application to be built. Not within the no-code tool interface, nor with their own tool (no-learn category above). They do nothing. Instead, the no-code tool takes whatever information is already available in the company (in documents, files or databases) to automatically derive a software application from them.

Continuing with our chatbot definition example. In a no-work setting, we would not even ask the user to fill our Excel template to specify the bot behaviour, we would just take its FAQ website, existing Excel file (e.g. with some list of questions they prepared to homogenize their client support team) or list of products in a database and generate the chatbot from there. In our interviews with potential chatbot clients, they often tell us a variation of the sentence "we already have an Excel file we use internally, we just want to give you that and get a bot that is able to answer the questions in our file".

This completely eliminates all barriers to entry. As a trade-off, no-work approaches do restrict even more the diversity of applications to be built as the no-code tool needs to largely depend on convention over configuration strategies in order to be able to derive a valid application from the client's input files.

Still, this approach is less radical than it seems. Just think about all the CRUD generators available on any modern programming framework. Any of them is able to connect to a relational database and immediately generate all the forms required to access and manipulate the database data.

No-code categories are not exclusive

Each of the categories above targets a different type of user/scenario. Depending on how much the user wants to learn/work, you can offer him a specific type of tool, each one with its trade-offs.

But this doesn't mean your no-code tool needs to stick to one specific category. As we do in Xatkit, you can offer different interfaces/importers on top of the same engine. You can even offer a low-code version for advanced users willing to use your tool's API to complement the result of the no-code approach.

“Hello World”, chatbot version – Complete example

Jordi Cabot — Mon, 23 Nov 2020 10:48:51 +0000

The Hello World program is the typical first example you see when learning any programming language since it was first used in a tutorial to learn B (predecessor of the C language) in 1973. It is often the first program written by people learning to code. Its success resides in its simplicity. Writing its code is very simple in most programming languages. It's also used as a sanity test to make sure the editor, compiler,... is properly installed and configured. For these same reasons, it makes sense to have a "Hello World" version for chatbots. Such bot could be defined as follows:

A Hello World chatbot is a chatbot that replies "Hello World" every time the user greets the bot

So something as this:

While this chatbot is indeed simple (compared with any other chatbot), it's much more deceitful than its Hello World counterparts for programming languages. That's because of the essential complexity of chatbot development. Even the simplest chatbot is a complex system that needs to interact with communication channels (on the "front-end") and the Text Processing / NLP engine (in the "backend"), among, potentially, other external services. Clearly, creating and deploying a Hello World chatbot is not exactly your typical Hello World exercise.

Chatbots are complex systems

But don't be scared, let me show you how to build your first chatbot with our open-source platform Xatkit. Our Fluent API will help you to create and assemble the different parts of the chatbot. Let's see the chatbot code you need to write.

Recognizing when the user says "Hi"

The chatbot needs to detect when the user is greeting it. This is the only intention we need to care about. So it's enough to define a single Intent with a few training sentences. Any NLP Provider (e.g. DialogFlow or nlp.js) would do a good job with this simple intent.

Replying Hello World

To process the user greetings text, we need at least one state that replies by printing the "Hello World" text. But to keep the bot in a loop (who knows, maybe many users want to say Hi!), we'll use a couple of them.

Configuring the chatbot

As we mentioned above, chatbots come with some inherent essential complexity. At the very least, they need to wait and listen to the user on some channel and then reply to the same channel. In Xatkit, we use the concept of Platform for this. In the code below, we indicate that the bot is displayed as a widget on a webpage and that it will get both events (e.g. the page loaded event) and user utterances via this platform.

And this is basically all you need for your Hello World chatbot!. Feel free to clone our Xatkit bot template to get a Greetings Bot ready to use and play with.

Of course, this is a very simple Hello World chatbot (e.g. what about if the user does not say Hi but something else?) but I think it's the closer we can get to the Hello World equivalent you're so used to see for other languages. Remember you can head to our main GitHub Repo for more details on Xatkit or check some of our other bot examples.