Building funsize-engineer

Introduction

In the modern software landscape, the barrier between an idea and a deployable artifact is often the friction of boilerplate and configuration. This post documents the creation of funsize-engineer, a Python package designed to serve as my terminal-based “business card”. Inspired by David Neal’s npm calling card, I wanted to create a Python equivalent that could be easily distributed and run via PyPI.The goal was simple: create a distributable Python package that, when run, displays professional contact information and ASCII art in a visually appealing format. However, the method of creation was novel. Instead of writing every line of code manually, I utilized Google Antigravity, an agentic coding platform. This article demonstrates how the “Agent-First” development paradigm shifts the engineer’s role from typist to architect, focusing on task orchestration and verification rather than syntax.

Antigravity Core Functionality

Antigravity operates on a fundamental shift in the developer-tool relationship. It is not merely an autocomplete engine; it is an autonomous agent capable of executing complex, multi-step tasks.

Two core components enable this workflow:

1. 
   The Manager View: Unlike a standard chat interface, Antigravity maintains a structured “Manager View” of the project. It tracks high-level objectives, breaks them down into sub-tasks (e.g., “Scaffold Repository”, “Implement Core Logic”, “Configure CI/CD”), and maintains context across the entire development lifecycle. This allows the agent to “remember” architectural decisions made in step one while executing step ten.

This artifact allowed the developer to verify that the workflow was correctly targeting both branches and, crucially, that fetch-depth: 0 was included to ensure setuptools-scm could correctly calculate versions from git tags.

Troubleshooting and Iteration

No development process is without friction. We encountered two significant technical hurdles that required agentic problem-solving.

1. The “Dev Version” Trap

During the setup of the automated versioning, we encountered an issue where releases from the main branch were being tagged with “dev” suffixes (e.g., 0.2.11.dev0) instead of clean release versions, despite having a correct git tag (e.g., v0.2.11).

The Issue: setuptools-scm calculates versions based on the distance from the last tag. In our GitHub Actions workflow, we were creating a tag and then checking it out. However, setuptools-scm saw the commit after the tag (the one triggering the workflow) and assumed it was a “dirty” state, appending a .dev suffix. Additionally, the workflow wasn’t properly stripping the v prefix from tags before passing them to the build system.

The Resolution: The agent diagnosed the issue and implemented a robust fix:

1. 
   Explicit Versioning: Instead of relying on git state, we forced setuptools-scm to use the exact version we wanted by setting the SETUPTOOLS_SCM_PRETEND_VERSION environment variable.


2. 
   Prefix Handling: We added logic to strip the v prefix from git tags (e.g., v0.2.11 -> 0.2.11) to ensure Python package compatibility.

Final Code & Output

The result is a lightweight, installable package. The core logic resides in funsize_engineer/card.py, which orchestrates the rich components.

Final Example Code:

Conclusion

The creation of funsize-engineer highlights the power of the Agent-First methodology. By offloading the implementation details—from directory scaffolding to complex CI/CD scripting—to Antigravity, I was able to focus on the what and why of the product. The result is a professional-grade Python package built in a fraction of the time, with the agent acting not just as a coder, but as a partner in the engineering process.