What My Four-Hour Cursor and Go Experiment Proved

What Building a Go App With Cursor in Four Hours Actually Proved

In October 2024, Cursor helped me reach a working local demonstration in an unfamiliar language faster than I believed I could on my own. The same experiment also showed how quickly that feeling of progress falls apart when the agent and the developer are looking at different files.

That is the honest result of Venture Step E037. It was a useful learning session, not a controlled productivity study and not evidence that the prototype was ready for anyone else to use.

flowchart LR
    A["Four-hour learning goal"] --> B["Go backend and Java command-line client"]
    B --> C["Working local task flow"]
    C --> D["Duplicate project paths"]
    D --> E["Wrong file remains in context"]
    E --> F["Repository identity becomes uncertain"]
    F --> G["Tests, review, and Git must provide proof"]

The project was deliberately small

The transcript records a task application with a Go backend, a Java command-line client, a REST connection, and a JSON file for persistence. I ran the backend locally, used the client to view tasks, and toggled a task as complete.

I was new to Go. Part of the four hours went to installing tools, creating directories, arranging files, and learning how to run the two sides of the application. Cursor helped generate and explain code while I worked.

That matters because the useful claim is personal and bounded. I got from unfamiliar tooling to a visible local behavior in one session. The source does not establish how long the same work would take an experienced Go developer, another beginner, or me without the setup work.

The official Go getting-started tutorial is a better current source for basic modules, dependencies, files, and commands than my quick language summary in the episode. E037 should be read as a dated experiment, not as a language benchmark.

Context removed friction

The compelling part of the editor was not merely text generation. Cursor could work with selected project context.

Instead of repeatedly copying code into a separate chat, I could ask questions near the files, request a change, and inspect a proposed result. The editor also produced a project explanation and documentation intended for a hypothetical new hire.

Cursor's current guide to coding with agents describes a much broader 2026 workflow involving plans, repository search, rules, tools, tests, diff review, worktrees, and cloud agents. Those current capabilities are not part of the October 2024 proof. They do reinforce the underlying point that an agent works through instructions, selected context, tools, and verification rather than through complete understanding.

The speed felt real because the loop became shorter. I could ask, see a change, run the program, and ask another question without rebuilding the entire context by hand.

The path failure was the most valuable result

I had created related project files in more than one location. Some were in a directory created from the terminal, while others remained in an earlier Documents location.

I believed I had closed or moved past an unwanted file. Cursor continued using it as context. Because I could not immediately see the full path clearly enough, I spent time changing or discussing the wrong copy.

This was not a small interface annoyance. It broke the identity chain between request, file, diff, and running behavior.

If an agent edits main.go, the reviewer needs to know which main.go, under which repository root, on which branch, at which revision. A plausible code change is not useful when the team cannot connect it to the intended artifact.

The lesson also corrects one of my original conclusions. I described codebase context as if the editor simply knew the project. In practice, the system works from selected and retrieved context. It can include irrelevant state, miss necessary state, or follow an unwanted path. The developer still owns the repository map.

A running demo did not prove quality

The local task flow showed that some path through the application worked. It did not establish security, maintainability, error handling, idiomatic code, dependency safety, test coverage, performance, deployment readiness, or accessibility.

The generated documentation looked useful. Without checking every described route, field, and command against the code, it remained a proposal.

The refactor looked fast. Without a full diff, tests, performance evidence, and review, speed did not establish improvement. A refactor can preserve the visible happy path while breaking failure behavior or making future changes harder.

NIST's Secure Software Development Framework describes secure development as a set of practices integrated into the software lifecycle. The episode contained no record that those practices had been applied to the prototype.

The repository has to become the proof system

The agent can propose. The repository has to preserve what was accepted and why.

Cursor's product checkpoints may help undo agent edits, but Pro Git remains the stable foundation for durable version history. The commit should represent a coherent state that another person can inspect and restore.

This is why the duplicate-path mistake deserves equal weight with the working demo. It exposed the difference between generating code and knowing which code the project now depends on.

What E037 still gets right

AI-assisted development can lower the activation energy for a learning project. It can explain unfamiliar syntax, locate examples, draft a small slice, run checks, and keep a learner engaged long enough to see a system work.

That value disappears when output replaces understanding. A strong learning session ends with the learner explaining the data flow, making a manual change, identifying the exact files involved, and reproducing the behavior from a clean state.

The four-hour experiment did not prove that Cursor could build production software for me. It proved that context-aware assistance could shorten my path to a prototype and that context mistakes could just as quickly undermine the result.

The next useful step is [[How to Review AI Generated Code Before Accepting It]]. Readers who want to try the same kind of bounded experiment can use [[How to Build a Small App With an AI Coding Agent]].

This story was developed with AI assistance from the immutable E037 transcript, current Cursor first-party material, official Go and Git documentation, NIST SSDF, and the linked historical boundary record. Dalton Anderson remains the author. Transcript, technical, current-source, and founder review are mandatory before publication. Publication is not authorized.