Getting Started

Getting Started with WriteIt.ai

Add Repository

On your dashboard page, click the "Add Repository" button.

photos

You will then be presented with the following screen where you add your repository name.

Github Integration

You will then be asked to give WriteIt.ai permissions to access your repository. The integration is done in the form of Github Oauth app, where WriteIt.ai requests a personal access token with the scope "repo".

Security

The token is treated as a secret on every level of the application.

The app will use it to pull your repository source code, your issues, and to make pull requests. It will never make any operations outside of this scope.

Access to Organization Repositories

If you are part of an organization, you will need to press the "Request" button to let the organization's admin know that you would like to grant WriteIt.ai permission to access its repositories. The admin must approve such request.

Revoking Github Access

You can revoke the granted access token at any time. It can be done on Github as described here.

Repository Ingestion

Once the Github permissions are granted, WriteIt.ai pulls your repository, and begins the analysis.

It goes through the entire tree of your project - it:

  • identifies the applications within (e.g. front-end and back-end applications)
  • where the dependency definitions are (e.g. pyproject.toml or requirements.txt)
  • it identifies all the functions, classes, and variables, and tries to determine their function and meaning
  • it stores all those metadata to databases

Then there is only one step remaining - the Dockerfile setup

Dockerfile Setup

AI Agents are based on the capabilities of large language models (LLMs). Even the best of them make mistakes. In order to mitigate those, it is important that they have access to validating their outputs.

That is why they must be able to execute the code in the form of unit tests, and run formatting and linting checks.

In order to do that, you must make sure that you have a Dockerfile that is able to run those commands.

Dockerfile naming conventions

If you already have a Dockerfile in your application, WriteIt.ai will try to use it.

However, you can also make a dedicated file called for_agents.Dockerfile that will take precedence.

The precedence is following:

  • for_agents.Dockerfile
  • Dockerfile.for_agents
  • ci.Dockerfile
  • Dockerfile.ci
  • dev.Dockerfile
  • Dockerfile.dev
  • Dockerfile

Docker Compose

Oftentimes, the unit tests can't be run without supporting docker containers (e.g. Postgres) These are usually defined in docker compose files.

WriteIt.ai uses them if they are available.

The precedence is following:

  • for_agents.compose.yml
  • for_agents.docker-compose.yml
  • compose.for_agents.yml
  • docker-compose.for_agents.yml
  • ci.compose.yml
  • ci.docker-compose.yml
  • compose.ci.yml
  • docker-compose.ci.yml
  • dev.compose.yml
  • dev.docker-compose.yml
  • compose.dev.yml
  • docker-compose.dev.yml
  • compose.yml
  • docker-compose.yml

Example Dockerfile setup

An example of a Dockerfile setup could be following:

Hatch
# Use a Debian base image with apt-get
FROM python:3.11.9-slim-bookworm

# Install hatch
RUN pip install --no-cache-dir hatch

WORKDIR /app

COPY ./pyproject.toml ./

RUN hatch dep show requirements > ./requirements.txt && \
    pip install --no-cache-dir -r /app/requirements.txt

# Copy the application code into the container
COPY ./src ./src

Pip
# Use alpine image for smallest size
FROM python:3.11-alpine

WORKDIR /app

# Copy and install requirements first (for better caching)
COPY requirements.txt .
RUN pip install -r requirements.txt uvicorn

# Copy only src directory
COPY ./src .

# Run with uvicorn
CMD ["uvicorn", "project.asgi:application"]