Automating the Overhead: Building a Multi-Tool Developer Assistant with Python and Gemini

Software development isn't only about writing code.

A significant part of a developer's day can be spent writing status updates, preparing pull requests, creating commit messages, investigating errors, analyzing support tickets, preparing deployment checklists, and documenting technical work.

These tasks are important, but they are also repetitive.

As part of my journey through the Google Cloud Gen AI Academy APAC – Meet the Builders initiative, I wanted to explore a practical question:

What if a developer had a single AI-powered workspace that could handle some of this repetitive overhead?

That idea became AI Developer Productivity Assistant — a Python and Streamlit application powered by Gemini 2.5 Flash, with SQLite-based history and Docker-based deployment.

In this article, I'll walk through the problem, the solution, architecture, Gemini integration, prompt engineering, deployment approach, challenges, and lessons I learned while building it.

---

The Problem: The Coding Tax

When we think about developer productivity, we usually focus on writing code faster.

But there is another part of development that is easy to overlook: the work surrounding the code.

A developer may need to:

• Write a daily status update
• Analyze a support ticket
• Create a pull request description
• Write a meaningful Git commit message
• Understand a programming error
• Prepare a deployment checklist
• Create technical documentation
• Convert rough technical notes into professional communication

None of these tasks necessarily requires complex programming, but they consume time and mental context.

For example, a developer might have notes like:

worked on payment validation
checked failed payment tickets
updated reconciliation handling
improved logging

The Solution: AI Developer Productivity Assistant

The solution I built is a web-based application called:

AI Developer Productivity Assistant

The idea is simple:

Instead of using separate tools for different small developer tasks, the application provides multiple AI-powered utilities through a single interface.

The developer selects a task, provides the relevant technical context, and Gemini generates a structured response.

The overall workflow looks like this:

Developer
|
v
Streamlit UI
|
v
Select Productivity Task
|
v
Enter Technical Context
|
v
Application Logic
|
v
Gemini 2.5 Flash
|
v
Structured AI Response
|
v
Developer Review
|
v
Copy / Download / Use

The goal is not to replace the developer.

The goal is to reduce repetitive work and allow developers to spend more time focusing on actual engineering problems.

Technology Stack

The application was built using:

Technology Purpose
Python Application development
Streamlit Web interface
Gemini 2.5 Flash Generative AI
Google Gen AI SDK Gemini integration
SQLite Lightweight history storage
Docker Application containerization
Google Cloud Run Cloud deployment

The application is intentionally lightweight. The focus was on building a practical Gen AI application rather than introducing unnecessary infrastructure.

Architecture

The high-level architecture is:

                +---------------------+
                |      Developer      |
                +----------+----------+
                           |
                           v
                +---------------------+
                |    Streamlit UI     |
                +----------+----------+
                           |
                           v
                +---------------------+
                |  Application Logic  |
                +----------+----------+
                           |
             +-------------+-------------+
             |                           |
             v                           v
    +----------------+          +----------------+
    | Gemini 2.5     |          |    SQLite      |
    | Flash          |          |    History     |
    +----------------+          +----------------+
             |
             v
    +---------------------+
    | Structured AI       |
    | Response            |
    +---------------------+

For deployment, the application is packaged into a Docker container and deployed to Google Cloud Run.

Source Code
|
v
Docker Image
|
v
Artifact Registry
|
v
Google Cloud Run
|
v
Running Application
What Can the Assistant Do?

The application currently provides several developer-focused AI utilities.

1. Daily Status Generator

The Daily Status Generator converts rough developer notes into a structured and professional daily status update.

Example input
Worked on payment validation.
Investigated failed payment support tickets.
Updated reconciliation handling.
Improved logging.

The assistant can transform this into a structured format such as:

Completed

• Worked on payment validation.
• Investigated failed payment support tickets.
• Updated reconciliation handling.
• Improved logging.

Ongoing

...

Issues / Blockers

...

Next Steps

...

The important part is that the AI should preserve the developer's original meaning rather than inventing additional work.

This makes the tool useful when the developer has the technical details but doesn't want to spend additional time formatting them.

1. Support Ticket Analyzer

The Support Ticket Analyzer is designed to help developers understand and organize technical support issues.

The developer can provide information such as:

Ticket title
Customer or user issue
Error message
Relevant logs
Additional context

The assistant generates a structured analysis containing:

Issue Summary
Possible Cause
Impact
Priority
Recommended Investigation
Recommended Resolution
Customer Response
Technical Notes

One important design decision was to avoid presenting assumptions as confirmed facts.

For example, if the available information is insufficient to determine the exact root cause, the assistant should say:

Likely Cause

or:

Possible Cause

rather than confidently claiming an exact root cause.

This is particularly important when using AI for technical troubleshooting.

1. Pull Request Description Generator

Writing a good pull request description is another task that can become repetitive.

The Pull Request Generator accepts information such as:

Branch name
PR title
Problem statement
Changes made
Components changed
Testing performed
Known limitations

It generates a structured PR description containing sections such as:

Summary

Problem

Changes Made

Technical Details

Testing

Impact

Known Limitations

Deployment Notes

This provides a consistent structure while allowing the developer to review and modify the generated content before submitting the PR.

1. Git Commit Message Generator

Meaningful commit messages are important for maintaining a readable project history.

The Git Commit Message Generator allows the developer to enter a simple description such as:

fixed payment reconciliation
updated payment validation
improved logging

The assistant can generate suggestions such as:

fix: improve payment reconciliation handling

or:

fix: update payment validation and reconciliation logging

The application can also suggest different commit types where appropriate:

feat:
fix:
refactor:
docs:
test:
chore:

This is a small feature, but it is a good example of how generative AI can remove repetitive decision-making from everyday development tasks.

1. Programming Error Explainer

Debugging often starts with understanding what an error actually means.

The Error Explainer allows a developer to provide:

Programming language
Framework
Error message
Stack trace
Relevant code
What they were trying to accomplish

The assistant produces a structured explanation:

Error Summary

What This Means

Likely Cause

Step-by-Step Diagnosis

Recommended Fix

Example Corrected Code

Prevention Tips

The purpose isn't simply to generate a replacement piece of code.

The assistant should also explain the error so that the developer understands what went wrong.

This makes the feature useful as a debugging companion rather than simply a code generator.

1. Deployment Checklist Generator

Deployment involves many small checks, and missing one of them can lead to unnecessary problems.

The Deployment Checklist Generator accepts information such as:

Application type
Technology stack
Environment
Deployment platform
Database
Environment variables
Additional requirements

It can then generate a checklist covering areas such as:

Pre-Deployment
|
+-- Dependencies
+-- Configuration
+-- Tests
+-- Environment Variables

Container
|
+-- Dockerfile
+-- Image Build
+-- Image Tagging
+-- Image Push

Cloud Deployment
|
+-- Service Configuration
+-- Environment Variables
+-- IAM
+-- Health Checks
+-- Logs

Post-Deployment
|
+-- API Testing
+-- Application Testing
+-- Database Connectivity
+-- Monitoring
+-- Rollback Plan

The checklist can be adapted based on the technology and deployment environment supplied by the developer.

1. Technical Documentation Generator

Documentation is another area where developers often have the information but don't necessarily want to spend a large amount of time formatting it.

The Documentation Generator accepts project information such as:

Project name
Project description
Technology stack
Architecture
API endpoints
Important components
Setup instructions
Environment variables
Deployment details

It can generate documentation with sections such as:

Project Name

Overview

Features

Architecture

Technology Stack

Installation

Configuration

Environment Variables

Running Locally

API Documentation

Deployment

Troubleshooting

Future Improvements

This provides a starting point that the developer can review and customize.

Using Gemini as the AI Engine

Gemini is the core intelligence behind the application.

I used the official Google Gen AI Python SDK to interact with the Gemini API.

A simplified version of the integration looks like this:

from google import genai

client = genai.Client(
api_key=settings.GEMINI_API_KEY
)

response = client.models.generate_content(
model="gemini-2.5-flash",
contents=prompt
)

return response.text

The Gemini API key is stored as an environment variable rather than being hardcoded in the application.

For local development, the application can use an environment configuration such as:

GEMINI_API_KEY=your_api_key

The same principle is followed during deployment by providing the configuration through the deployment environment.

Designing Better Prompts

One of the biggest lessons from building this application was that an AI application is not simply:

User Input
|
v
LLM
|
v
Response

The quality of the prompt has a significant impact on the usefulness of the response.

For the different developer tools, I structured prompts around:

Role
+
Context
+
Task
+
Constraints
+
Output Format

For example, a simplified prompt for the Daily Status Generator could look like:

You are a senior software engineering assistant.

Your task is to convert rough developer notes
into a professional daily status update.

Rules:

• Do not invent completed work.
• Preserve the original technical meaning.
• Separate completed and ongoing work.
• Use professional language.
• Do not assume information that was not provided.

Developer notes:

{input}

Return the response using:

Completed

Ongoing

Issues / Blockers

Next Steps

This approach makes the expected output much more predictable.

Different tools use different prompts because a support ticket analysis requires a different response structure from a Git commit message.

Why Context Matters

A generic prompt such as:

Make this professional.

doesn't provide enough context.

A better prompt explains:

Who the AI should act as
What the input represents
What task needs to be performed
What the AI should avoid
What format the output should follow

This was one of the most important lessons I took away from building the application.

The AI model is important, but the surrounding application design and prompt engineering are equally important.

Keeping Track of Requests with SQLite

For the MVP, I implemented SQLite-based history tracking.

The application stores information such as:

Request
|
+-- Feature
+-- Input
+-- Generated Output
+-- Timestamp

This allows users to view recent requests and generated responses.

SQLite was selected because it keeps the MVP simple and doesn't require an additional database service during development.

The history functionality is intentionally lightweight.

For a larger multi-user production deployment, I would move this layer to a managed database rather than relying on local SQLite storage.

Error Handling and Validation

AI applications need to handle more than successful responses.

The application also considers cases such as:

Missing Gemini API key
Invalid API configuration
Gemini API errors
Network failures
Empty user input
Database errors
Unexpected AI responses

Instead of exposing technical stack traces to normal users, the application provides a more user-friendly message.

For example:

Unable to generate the response right now.

Please verify the AI configuration and try again.

Technical errors can still be logged for debugging purposes.

Security Considerations

Since the application interacts with an external AI API, credential management is important.

The application does not hardcode the Gemini API key.

Instead, it reads the key from an environment variable:

GEMINI_API_KEY

The .env file should also be excluded from source control.

A simplified .gitignore configuration includes:

.env
pycache/
*.pyc

Another important consideration is the information provided to the AI.

Developers should avoid sending sensitive customer information, credentials, API keys, or confidential company data unless the application's deployment and data-handling policies are appropriate for that information.

Containerizing the Application with Docker