Codebots 101: Start here!

by Rosie Odsey, Nov 13, 2017

A codebot is a software robot that can write computer code for you, based on information you give it. You can use a drag-and-drop interface to give explicit instructions and eventually you will be able to talk or chat to a codebot like you talk to a person. The codebot writes the code for the design you have given it, tests the code, and then shows you what it has made. You can then work with the codebot to keep making changes until you are happy with the finished product. In this Academy post, we will cover the rules of Codebots.
Remember, Codebots (with a capital) is us: a platform that helps you build awesome software. You build this awesome software with codebots (no capital), our code-writing robots.
Codebots can be a powerful tool, and there are many ways that they can help you with your coding projects. By understanding how to give your codebot effective instructions, you will be able to get the most out of them. We wanted to make sure that codebots were always predictable and worked in the way you expect them to, every time, so we created five unbreakable rules that codebots must follow. This blog post will go into more detail on each of these laws, to help you understand why codebots work in the way they do. The unbreakable rules of Codebots are:
  1. Codebots are complementary to Agile methodologies
  2. Codebots write code that is developer-readable
  3. Codebots aim to write 100%, but we don't expect it
  4. Codebots write both the development and testing targets
  5. Codebots cannot write their own internal code

Codebots are complementary to Agile methodologies

Most software is built using some kind of an Agile development methodology. Agile is a way of building software in a series of iterations (sometimes called sprints) where software is delivered at the end of each sprint, with the quality getting better and better with each one. At the beginning of each sprint, the backlog of things that need to be done is prioritised and requirements are added to the sprint. Sprints can last anywhere from a week to a month or more, and a final software product will take many sprints to create. By releasing the most up-to-date version of the software at the end of each sprint, valuable user feedback on the software can be gathered, and that feedback is then used in a future sprint to improve the final product. This means that you are gathering feedback all the way through the development process, so it can reduce the risk of building something that the customer doesn't want, or doesn't like.

Codebots have been designed to complement Agile methodologies. So if you already use an Agile development methodology in your business, codebots can work in with those existing processes. Additionally, many of the terms codebots use are borrowed from Agile practices, to make them easier to understand. For example, when you define tasks for the codebots to perform, you will express them as epics and user stories, which can then be fitted into sprints, and progress can be tracked on the Dashboard.

Codebots write code that is developer-readable

There are many tools that will claim to write code for you, but the code they create is either a hot mess or, worse, completely inaccessible. This is referred to as a 'black box' output. Codebots are unique in that they produce code that is not only readable by human developers, but it can also be edited and added to by human developers. When codebots produce code, it is exported to a code repository so that you can do whatever you want with it afterwards, and choose whether or not you want to continue using Codebots.

By having the codebots write code that human developers can read, it means that humans can control the architecture of their project, and make changes to the code so that the final product better suits their project requirements. Human developers and codebots can work together through iterations to create quality software, with the developer doing the interesting creative work, and the codebot doing the boring heavy-lifting aspects of coding. This turns the codebot into a useful member of the team, rather than a complete replacement for a human developer.

Codebots aim to write 100%, but we don't expect it

The codebots are smart, and over time (and with a lot of human help) they can get smarter. Sometimes, if they already have the right instructions and models, they can write 100% of the code we ask them to. Usually, they need a little bit of help from the humans, though, and end up writing about 92%. As you probably already know from other types of automation, robots do their best work when they're doing things that humans find repetitive or boring, and codebots are no different. Codebots have been designed to do the repetitive and boring bits of coding, and they require humans to do the creative work of design and architecture.

Codebots write both the development and testing targets

When humans write code, they also need to generate tests to ensure their code works properly, and doesn't cause any problems in other pieces of the code that have already been written. When codebots write code, they also need to write tests, just like humans. Codebots use a system called model-based testing. When you give a codebot instructions for the code you want it to write, the first thing it does is create a couple of different models. These models work just like blueprints for a house, in that they are a basic version of the final product, so that you can decide if that is what you want the codebot to build. The codebot then generates the tests, to test the code it creates against the initial model and make sure it works properly. This is especially important when you have humans adding code to what the codebots write, so that the entire thing can be tested all together, rather than the codebot only being able to test its own bits.

Codebots cannot write their own internal code

Even though a codebot’s mission is to write code, they are not allowed to write their own code; only humans can do that. Technological innovations throughout history have had unintended consequences, so it's important that we address the unintended consequence of creating artificially intelligent codebots. Will they take over the world? Probably not, but we can implement rules to ensure that they continue to be useful tools to assist humans, and are never in a position to be able to modify themselves. This means that all of us here at Codebots get to keep reading Asimov, without having to live in the future he imagined.

How do codebots write code?

When you give a codebot instructions for what you want it to do, the first thing the codebot does is work out if it can perform the tasks you asked it to do on its own. If it can't, it will ask you for some human help, and more instructions. This helps the codebot to learn how to do it, so that next time it will be able to do it on its own. By having clear instructions, the codebot can create good code that can be read and edited by human developers. Once the codebot has exact instructions, it transforms the instructions into models, and generates the code. It then tests it to make sure it works, and ask you if you are happy with the results. If you are, that's great, you're done! If not, you can give the codebot new instructions, and the process starts over again.

The process looks something like this:
  1. You have a great idea.
  2. You set up your project in the Codebots interface and give the codebot instructions.
  3. The codebot uses those instructions to build what you asked for. If the application is not what is required, the codebot will ask for some human help to refine the instructions.
  4. The codebot transforms the instructions into models, and generates the code.
  5. The codebot compiles the code, and generates the application. The codebot tests it to make sure it works.
  6. The codebot will ask you if you are happy with the results.
  7. You’re done! (Or, you can start again to make more changes).