From htop to Git: A Useful Test Case
hjr265 recently published a post about building GitTop, a terminal TUI tool that shows git repository activity the way htop shows process activity, using a fully agentic coding workflow. The author let an LLM agent handle the implementation end to end. No line-by-line review during construction, no copilot-style autocomplete. The agent planned, wrote, and revised the code while the human observed and directed at a higher level.
This is a genuinely interesting test case, not because the tool is especially complex, but because TUI development in Go has just enough structure to stress-test what agents are good at. You need a framework, a layout model, real-time data, and keyboard input handling, all wired together correctly before anything useful appears on screen. It is not a CRUD app, but it is also not distributed systems. The scope is bounded in a way that makes outcomes legible.
What “Fully Agentic” Actually Means
The term gets used loosely, so it is worth being precise. There is a spectrum.
At one end: AI-assisted coding, where the model autocompletes lines, suggests refactors, or answers questions. The human drives; the model advises. Tools like GitHub Copilot and Cursor in its default mode sit here. Context is narrow, the human reviews every change, and the model does not take actions autonomously.
At the other end: fully agentic coding, where the model operates in a read/write/run loop with minimal interruption. It reads files, writes code, runs build commands, reads compiler errors, revises, and iterates. The human provides a goal and reviews the result; the model handles the implementation path. Claude Code and Aider support this mode, and Claude Code in particular is designed around it: it has access to shell execution, file system tools, and a persistent project context.
The intermediate mode, where the human reviews and approves each step, is where most teams actually land. Fully agentic means accepting that intermediate layer of approval as optional.
GitTop appears to be a genuine attempt at the far end of that spectrum. The agent did the implementation work, and the author evaluated the output rather than the process.
How an Agent Approaches a TUI From Scratch
For Go TUI work, the obvious choice is bubbletea, the Elm-architecture-inspired framework from Charm. The model/view/update pattern maps well to agentic code generation because the structure is explicit and compositional. An agent building with bubbletea has a clear skeleton to fill in:
type Model struct {
// data fields
}
func (m Model) Init() tea.Cmd {
return tea.Tick(time.Second, func(t time.Time) tea.Msg {
return tickMsg(t)
})
}
func (m Model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
// handle input and data updates
}
func (m Model) View() string {
// render to string
}This is a good target for agentic generation. The framework is well-documented, has clear seams between concerns, and the agent can find numerous examples in its training data. The Init, Update, and View split makes it hard to produce structurally incoherent code even in a long generation loop.
The git data layer is similarly tractable. Running git log, git diff --stat, or parsing git shortlog output is shell invocation plus string parsing, the kind of code agents produce reliably because the output formats are stable and well-represented in training corpora.
The harder pieces tend to be the integration points: threading real-time tick updates through the bubbletea message loop without introducing data races, handling terminal resize events correctly, making layout calculations that work at different terminal widths. These require the agent to hold multiple concerns in tension, and that is where agentic loops tend to accumulate revisions.
Where the Workflow Earns Its Place
The case for fully agentic coding in a project like GitTop comes down to a few concrete things.
Scaffolding speed. The first working prototype, something that runs, renders, and does not crash, takes far less time when you are directing rather than typing. An agent can produce a bubbletea skeleton with data loading and basic rendering in a single loop without the developer looking up API signatures or consulting documentation. The iteration to get from blank file to visible output is compressed.
Staying in the problem space. When you are thinking about what a tool should do, having to simultaneously think about how to wire up event handlers and layout calculations is context-switching. The agentic model lets you stay at the product level, what data should be visible, how it should be sorted, what the keyboard shortcuts should do, while the implementation details are handled below.
Mechanical correctness. Boilerplate, error handling on command execution, string formatting, and flag parsing are things agents get right reliably. For a tool like GitTop, a meaningful portion of the codebase is this kind of mechanical work. Delegating it saves real time with low risk.
Where It Still Has Rough Edges
The limitations are also visible in a project like this.
TUI layout is sensitive to terminal behavior in ways that are hard to test in a loop. Line wrapping, ANSI sequence handling, color code support detection, and cursor positioning all interact with the specific terminal emulator. An agent cannot run the code visually; it can only read the output of go build and go test. The feedback loop for visual correctness is broken, which means the human has to close it by running the tool and describing what looks wrong.
This is not a deficiency unique to agentic coding, but it is more pronounced here than in web or backend development, where test harnesses can verify output faithfully. The correction loop for TUI visual bugs is inherently slower.
The other rough edge is architectural judgment under ambiguity. When the requirements have gaps, whether to refresh data every second or on demand, how to handle a repository with no recent commits, what to do when git commands fail because the working directory is not a repository, the agent has to make choices. Some of those choices will be wrong in ways that only surface in specific conditions. In a human-driven project, these edge cases get caught in design review or casual conversation before they become bugs. In a fully agentic project, they surface as defects to fix after the fact.
This is where the “fully” in fully agentic becomes a trade-off rather than a benefit. The agent ships more of the decision surface, and some of that surface will need revisiting.
The Verification Problem
The structural challenge in agentic development at the systems level is that verification is harder than generation. Writing a bubbletea application is straightforward enough that an agent can do it. Verifying that the result is correct across different terminal emulators, with different git repository states, under different data volumes, requires test infrastructure that is often harder to set up than the code itself.
This shifts the developer’s job toward test design and acceptance criteria. In a fully agentic workflow, the clarity of your acceptance criteria directly determines the quality of the output. Vague success conditions produce working-but-wrong code that passes all available automated checks. Precise success conditions give the agent a feedback signal that actually guides revision.
For GitTop, “show git activity like htop shows processes” is clear enough directionally but leaves most specifics unresolved. The agent will fill those specifics with reasonable defaults, and the human will accept or revise them. That is the actual workflow, and it works reasonably well for personal tools where the developer is also the primary user.
What This Signals for Go Tooling Projects
Go is a reasonable target for agentic coding in general. The language is explicit, the stdlib is large and consistent, and the ecosystem of well-documented libraries like bubbletea makes agent-friendliness higher than average. The agent does not have to navigate a complex dependency graph or reconcile conflicting community conventions.
For terminal tooling specifically, the sweet spot seems to be projects where the data model is clear, the output format is familiar enough that the agent has good priors, and the scope is bounded. GitTop fits that description. A tool that requires novel algorithms, unusual concurrency patterns, or tight performance constraints would stress-test the workflow more severely.
The broader point that hjr265’s experiment illustrates: fully agentic is not an all-or-nothing claim about quality. It is a claim about where the human’s time is spent. The output requires the same careful evaluation as any code. What changes is when and how the developer engages with it. That shift in engagement mode is genuinely new, and for certain classes of projects, it is productive. GitTop is evidence of that, as long as you read the evidence with appropriate nuance.