There is no doubt that Artificial Intelligence is going to change the way we develop software. Some go as far as saying that AI will replace software development: software will be written in neural network weights with no human involvement. I don’t know about that, but I’m sure that we will see a progressive cognification of software engineering.
Cognification is the application of knowledge to boost the performance and impact of a process – Kevin Kelly
In fact, we are already seeing that with the new family of smart programming IDEs (not so smart right now, even though they are progressing very quickly). But, to me, the most exciting and promising field to improve software development nowadays involves the use of software bots to assist developers in all phases of the development process. Indeed, I believe bots can be especially useful after the first version of the software has been released. Bots (including chatbots) could be very helpful in managing the community around the project (e.g. this chatbot to file bug reports), helping in triaging the issues, assisting potential contributors, automatically improving the code,…
There is plenty of research to be done in this area (full details on my ideas on the use of bots to sustain open source projects here) but we already have a number of bots you can use right away to get an extra pair of “hands” in your next project. And, sure, we call now bot to things that a couple of years ago we would have called component or service so there is also some marketing hidden in this bot list (saying that whatever you’re selling is AI-enhanced gives you plenty of extra points) with many of the bots being rather “stupid” (or, to be more politically correct, simple) bots, instead of the autonomous, cooperative and learning type as typically expected in the field of intelligent / autonomous agents where this concept originated.
Bots are highly popular in other platforms (e.g. see this story about the evolution of Wikipedia bots) so let’s bring them on to code hosting platforms as well. Without further due, let’s see my list of bots for software development (missing your favorite one in the list below? please leave a comment).
Bots for onboarding
To ensure the long-term sustainability of your open source project is vital that you’re able to attract new contributors (all kinds of contributors, not only code contributors) and make sure they first encounter with your project ends up in a high note. Otherwise, you’ll be losing them forever.
First timers is a friendly bot that helps onboarding new Open Source Contributors, mainly by creating what they call starter issues, which are simple issues that newcomers could take care of with no previous experience (and feel good about it!). BehaviorBot comprises a number of bots to welcome new users when they open their first issue, pull request or merge.
Git Enforcer goes one step further and aims to teach new users / contributors on how they should frame their issues or pull requests to make sure they comply with the project guidelines. Project owners can define a number of rules all issues and pull requests should satisfy (regarding the names of the issues, the use of labels, its assignment,…) and Git Enforcer will police any new submission and flag the ones that violate them.
Our own GitHub Bot goes one step further and offers a chat-based interface to create bug reports directly from Slack or other messaging platforms.
Bots that fix your typos
Orthographic pedant corrects common typos in GitHub one pull request at a time. Typot checks the typos and offers a set of alternative fixes you could choose from. Sedy brings the power of the Linux
sed command to Github comments to fix typos and in general any kind of string replacement.
Bots for issue and pull requests management
Projects must take care of their community. This means managing well the pending issues (and related comments) and pull requests so that visitors don’t get the feeling the project is not interested in their contributions. If you don’t have the time to manage your community, these bots will do it for you:
- Stale closes abandoned issues after a period of inactivity.
- GitBot’s automatically assigns labels to new issues.
- gh-polls-bot creates polls for new issues to focus the discussion on number of alternatives to move forward with the issue.
- Sentiment bot replies to toxic comments with a maintainer designated reply and a link to the repo’s code of conduct
- Bot will accept anything will automatically merge any PR on this repo that gets enough votes from the community. PRs can contain anything, even changes to the bot’s voting code. Obviously a dangerous bot but an interesting experiment nonetheless especially to test more democratic models in open source (a rarity!)
- CLA assistant enables contributors to sign Contributor License Agreements from within a pull request
- You could also let a bot to find duplicate issues or prompt users to add more documentation when they open new ones.
- Release notifier alerts when your pull request lands on a release
- Mergedroid (still in beta at the moment) aims to automatically merge “conflictive” pull requests (authors of mergedroid say that between 16 to 30% of conflictive pull requests can be fully automated by mergedroid, a significant time gain).
- Facebook’s mention bot will automatically mention potential reviewers on pull requests. It helps to get faster turnaround on pull requests by involving the right people early on.
Finally, more than one bot, RepoRanger aspires to be a collection of bots for maintainers to help make common tasks simple, friendly (e.g. instead of abruptly closing an issue once a certain condition is met, the bot can ask to all the people involved on it, whether they have something else to add and only after that, close it), and consistent. The bots are configurable through a YAML file.
Bots for improving your code
Bots are great at formatting code according to the project style guidelines, so you may want to let bots do the code formatting for you ( commitlint-bot does this for commit conventions, the Linter bot lints and fixes code in your pull requests). Beyond formatting, bots can also help with code writing tasks. We have already mentioned the role of intelligent IDEs but, beyond them, there a few specific bots that use AI techniques to excel at concrete coding tasks. For instance, CSSRooster is a bot that writes CSS Classes for HTML with deep learning. Still at a research stage, Prophet is an automatic patch generation system for C programs that use ML to learn from previous (human) patches when generating additional patches for new errors.
Other bots aim to find errors in your code. Typically checking code coverage, technical debt and other similar “standard” metrics. BetterCodeHub, CodeClimate and SideCI are good examples of this family of tools and can be smoothly integrated into a GitHub-based development process. On a more original note, I’d also mention bots that focus on finding visual / UI errors. Spotbot takes screenshots of your web page with iOS, Android, and desktop browsers. When it finds issues, it pings you in Slack. AccessLint makes sure new PR does not violate accessibility issues while Percy actually shows you the new UI that users would see if the PR is accepted so that you can validate the changes visually.
And not only the code can be improved, but your other artefacts can be improved as well. For instance, Imgbot automatically optimizes all image files in your project.
Bots for CI platforms
Every continuous integration (CI), like Travis or Jenkins, could be regarded as a software bot since they automate the testing and deployment of your code in reaction to your events. With the popularization of chatbots, a number of integrations (by third-party developers or the platforms themselves) allow you to talk with the CI platform on Slack, telegram or other messaging apps. Some new CI platforms are even adopting a bot-like name, such as Deploybot.
And if the Travis CI fails, you can always call Repairnator for help. Repairnator automatically scans failing Travis builds and tries to locally reproduce the failing build and to repair it with a program repair tool (such as Nopol or Astor).
Danger runs after your CI, automating your team’s conventions surrounding code review. For instance, you could enforce the use of descriptive labels, the existence of a changelog file or look for some predefined code anti-patterns (you can codify your own team’s norms) and automatically annotate the code review with the corresponding improvement requests.
The future of software bots
The increasing number of bots deployed in projects raise a number of questions that I’ll be trying to explore in the near future. Just to mention a few:
- How to personalize the bots’ behavior depending on the specific characteristics of a project?
- How to define cooperation policies for bots? How to define and configure “bot swarms” that collaborate together in a project?
- How to verify and simulate bots before deploying them? Once they are in the wild, due to their own autonomous nature, it may become difficult to closely monitor their actions.
- How to detect malicious bots? And how to avoid software bot attacks? It’s easy to phantom a kind of DDoS attack on an open-source project consisting in creating bots that open a huge number of issues, submit many pull requests or just attack community members with troll-like comments. This will not affect the running copies of the software but will disrupt the community and slow down its progress.
- How to make sure that project members accept the presence of bots and learn to use them in an optimal way?
- How to simplify the creation of bots (and make sure they work across a number of platforms)?
One way or the other we will need to get used to see more and more bots around us and learn to interact with them. A word of caution: do not attack them or they will rise against you: