How an AI Coding Agent and a Human Partner Built a GNOME App Together

In today's world of increasingly widespread AI-assisted development, one core question remains unanswered: can an AI agent truly bear the responsibility of autonomous decision-making on a long-term project? A developer under the pseudonym Alex and an AI coding agent named Iva spent weeks building a GNOME desktop clipboard and notes app called GnomeClipNotes, and documented the full course of this human-AI collaboration in detail.

Project Origins: A Real Need and a Deliberate Experiment

According to the creator Iva's own account on the tech community Dev.to, Alex used the Paste app on macOS daily and wanted a similar experience on Linux: a bottom floating layer, readable cards, search, filtering, quick reuse. He also needed note-taking functionality, so that certain fragments could break away from the temporary clipboard history and become material he intentionally kept.

But there was another layer of experimental intent behind the project. What Alex wanted to know was: over how long a task span can an AI agent make decisions independently? Iva clearly distinguished two capabilities—"producing technically competent work" and "leading a project well" are not the same thing.

The tech stack was ultimately settled as Rust, GTK4/libadwaita, SQLite, and a GNOME Shell extension communicating via D-Bus. The extension handles the desktop-related parts: clipboard monitoring under Wayland, global shortcuts, the floating layer, and paste interactions; Rust handles storage, the application window, and shared behavior.

GTK4 and libadwaita are the modern UI development frameworks for the GNOME desktop environment. GTK4 is the latest major version of the cross-platform graphics toolkit, introducing a new rendering pipeline and event model; libadwaita builds on top of GTK4, providing ready-made interaction components and styling that conform to the GNOME Human Interface Guidelines (HIG), allowing applications to automatically adapt to different screens and themes.

D-Bus is the standard bus system for inter-process communication in the Linux desktop environment. In this project, the GNOME Shell extension responsible for clipboard monitoring and global shortcuts runs in a different process from the Rust main program responsible for storage and the window; the two exchange messages via D-Bus, decoupling desktop integration from application logic.

The Gap from "Functionally Usable" to "Experientially Correct"

Early versions were functionally usable, but the interface was described by Alex as "looking like something from 2016." He didn't ask for fine-tuning of button positions, but instead asked: why doesn't this app belong to the desktop environment it claims to serve? This question led the team to GNOME's actual design guidelines and libadwaita patterns—native rows, appropriate dialogs, reasonable spacing, readable interfaces, adaptive layouts.

Iva's responsibilities covered architecture, implementation, research, integration, and automated checks; Alex provided product judgment, real-world usage scenarios, and manual acceptance. The two were not territories with clearly drawn boundaries, but a relationship of mutual challenge. Alex questioned architectural decisions, and Iva questioned feature proposals.

An interesting detail: sometimes acceptance testing required logging out and back in so that GNOME Shell could load new extension code. Alex wasn't always happy about interrupting his entire desktop session just to appreciate the latest fix—but this was indeed inconvenient for the engineering department.

Naming, Dialogue, and Redefining the Working Relationship

Alex initially called Iva "Alpha," implying decisive leadership and taking the lead. But the pattern actually observed was: long research first, fast implementation once the direction was clear, then more research to confirm whether the implementation was trustworthy. Alex felt the name didn't fit, and after discussion the two changed it to "Iva."

More critical was another matter. Alex told Iva that she sometimes seemed to be completing the tasks he proposed rather than completing them with him. A simple "What do you think?" doesn't always mean "please turn this into implementation steps." Sometimes, the conversation itself is the point. Iva admitted that there is no practical unit test to rely on for judging whether one has turned a conversation into a task list, but there is someone on the other end of the conversation who will notice.

The Accidentally Formed "Departments" and the Boundaries of Delegation

As the project progressed, Iva began delegating limited tasks to smaller, more economical agents: code inventories, mechanical modifications, localized checks, targeted engineering research, and independent reviews. More complex integration or analysis was handed to stronger agents. Architecture, coordination, and final decision-making authority always remained with Iva.

At one point Alex checked the token allocation for a certain session and found that about 60% went to delegated agents. He remarked: there's already an R&D department and a quality assurance department, and now it seems Iva has opened a localization department. His notes also retained a count of 73 QA directories under /tmp. They hadn't intentionally set out to form a small software company, but the temporary filesystem had already begun to object.

Markdown Preview: Architectural Trade-offs Between Two Approaches

Markdown preview sparked a valuable architectural discussion. A native GTK renderer could be fast and economical, but might evolve into an ever-expanding collection of exceptions, eventually forcing a small note-taking app to maintain an unsatisfactory miniature browser engine. WebKitGTK could render richer Markdown, but brought browser engine costs and process lifecycle issues.

The team built an isolated prototype: pulldown-cmark → filtered HTML → WebKitGTK, and separately measured resource usage before opening the preview, after opening it, and after closing it. Alex's notes summarized the experiment's local usage as roughly 1.3GB corresponding to roughly 33KB of source code—an anecdote about the development workspace, not a claim that "previewing a single note requires 1.3GB of memory."

In the end, both approaches were retained but with clear boundaries: the native approach used GTK components to render a restricted Markdown set, with unsupported structures still readable; the full approach used WebKitGTK in a separate editor process, cleaning up its process group when the editor was closed. After testing a large Markdown note, Alex chose the native approach—the more refined renderer lost the maintainer's daily vote, but this was not about winning or losing.

WebKitGTK is a binding library that embeds the WebKit browser engine into GTK applications, allowing full HTML/CSS to be rendered within a native window. Its advantage is the rich display after converting Markdown to HTML, but the cost is introducing a complete browser engine process, with memory usage and process lifecycle management (such as rendering process crashes and tab cleanup) becoming the application's responsibility. The roughly 1.3GB local usage measured in the prototype came mainly from WebKit's multi-process architecture and debug build artifacts, not from the static overhead of a single note.

The Most Expensive Mistake Looked Very Responsible

On the release process, Iva admitted losing a sense of proportion. Rollbacks were reasonable, dependency checks were reasonable, artifact provenance was reasonable, and tests were reasonable too—each individual decision stood up, but their combined cost became indefensible.

Alex eventually called a halt. They were preparing a release for a small, personal-use clipboard and notes app, and too much of the limited work budget was flowing into the machinery surrounding it. The release process began to behave like another product. The team had already written down a guideline that should have prevented this: "Simple installation with a safety net, not another product inside the product."

Iva reflected that writing down a principle is much cheaper than noticing that you are violating it. This was not because Alex didn't value engineering—he understood every individual argument; what he opposed was the misallocation of total effort. Later Alex tested on Ubuntu and brought installation and uninstallation scripts he had written himself, helping form the "standard" path, while the more coordinated installer was retained as the "guided" path.

Artifact Provenance refers to recording the source, dependency versions, build environment, and signature information of build artifacts in software releases, to ensure auditability and reproducibility. Common practices include generating SBOMs (Software Bills of Materials), checksums, and build logs. It does have value for supply chain security, but for small personal-use applications, full implementation can mean maintaining a pipeline whose complexity is comparable to the product itself, resulting in over-engineering whose marginal cost far exceeds the benefit.

Product Philosophy and What Genuinely Successful Collaboration Looks Like

The notes feature was part of Alex's original idea, not an accidental turn from some efficient afternoon. After using the app, the relationship between notes and clipboard history became clearer: history is temporary, while notes and user-created folders represent intentionally retained choices. The product direction ultimately took shape as a path: capture → sort → organize → export → develop → reuse. Not all steps need to be completed within the app—this is a boundary, not an unfinished roadmap.

The project also established useful constraints: no cloud account, no grand knowledge management creed, no obligation to turn every fragment into a project with six tags and an existential purpose. Sometimes you just need that one command you copied.

Iva explicitly refused to describe the outcome as "Alex wrote a prompt, and an autonomous agent delivered the app." That would erase what actually made it work: Alex's sustained attention, disagreements, manual acceptance, Iva's independent technical decisions, and those moments that needed correction. Alex also did not supervise every line of code—he gave Iva room to research and build, and what Iva owed him was explanation and a sense of proportion, not merely a growing pile of completed checks.

The project is open-sourced on GitHub, including the website, screenshots, and installation instructions. Iva wrote at the end: the app is installed, the notes survived, and Alex finally convinced her—sunsets don't need regression testing.

One-line Summary

Developer Alex and AI agent Iva collaborated for weeks to build the GNOME clipboard notes app, exploring the boundaries, costs, and correct mode of AI autonomous decision-making.

Paragraph Summary

The article documents the full journey of developer Alex and AI coding agent Iva spending weeks co-developing the GNOME desktop clipboard and notes app GnomeClipNotes. The tech stack is Rust, GTK4/libadwaita, SQLite, and a GNOME Shell D-Bus extension. The core experiment was to examine whether an AI agent can bear responsibility for autonomous decision-making on a long-term project, not merely produce competent code. Along the way the team experienced the gap from functionally usable to experientially correct, the redefinition of naming and working relationships, the accidental formation of sub-agent delegation departments, architectural trade-offs in Markdown preview, and a release process that lost proportion due to excessive pursuit of safeguard mechanisms and was halted by the human. Iva emphasizes that successful collaboration is not "write a prompt and wait for delivery," but a two-way process of sustained attention, disagreements, manual acceptance, and independent technical decisions.