The code is AI-written. The decisions weren't outsourced.

First constraint: student accounts, not an agent platform

I didn't begin with an expensive autonomous coding service or a fleet of agents sharing a commercial orchestration system. I had limited student access to different AI providers. Those models were capable of doing useful work, but not of maintaining a long, continuous project context together. Accounts, context windows and session availability became engineering constraints.

So the experiment was also about the development process. A task might be planned with one model, implemented through another, reviewed with a third and revisited in a later session without access to the earlier conversation. I had to find a way for a new agent to recover what mattered without trusting whatever story the previous agent happened to tell.

My responsibility was the product direction, architecture, decisions, coordination and acceptance. AI produced the current code. In practice, much of my time went into recovering context, challenging plausible-looking solutions and redirecting work that had wandered away from the intention. Counting generated lines or closed issues would badly misrepresent that work.

Git became the shared project memory

Git was already where the code lived. I started using the repository as the durable state that independent AI sessions could inspect: product definition, explanatory context, development principles, current mission, decisions, Issues, branches, PRs and verification evidence. An agent arriving without yesterday's chat should be able to work out what AAAAT is supposed to be, what it is doing now, and which decisions have been rejected.

But a pile of Markdown isn't automatically memory. Early versions let old plans, tests and implementation choices quietly become new requirements. Once an idea had been merged, later agents treated it as unquestionable truth—even when it was only a development hypothesis. More documentation sometimes made that worse.

The correction was an explicit order of authority: current owner direction → Product Definition → derived specification and current mission → tests → implementation. Context and history can explain a decision, but they don't get to overrule it. A single current mission tells a new agent what is active; Git retains earlier, including wrong, development states without forcing the product to support them.

The repository shows that approach being formalized in PR #240. It also shows how fragile it can be: PR #325 had to repair the master-plan state after mechanisms were recorded as completed user capabilities. Git provides a reviewable trail of decisions and corrections, not a complete transcript of every model's private reasoning or every unrecorded session.

This is one of the things I would carry into another project: agent continuity doesn't have to come from one provider remembering everything. It can come from a small, inspectable body of repository state—as long as that state is allowed to be corrected.

The recurring problem was not bad code. It was the wrong problem.

Models often write code confidently. They also have strong habits about what a respectable software project is supposed to contain. AAAAT repeatedly drifted into familiar patterns that sound safe and professional: an application-status pipeline, additional configuration layers, provider-routing machinery, compatibility migrations for disposable development databases, elaborate setup paths, or tests protecting whichever implementation had just been generated.

None of those things is inherently wrong in every project. They were wrong here when they solved no current AAAAT need, displaced a simpler user interaction or contradicted an explicit decision. That's a more difficult failure to catch than a compiler error: the code may build, the PR may be tidy, and every test may pass.

For example, PR #315 recovered the product definition after AAAAT's application model acquired concepts and workflows that did not match how people were supposed to use it. PR #443 later removed synthetic AI capability certification, per-operation model routing and schema fingerprint machinery. The application needed one user-selected AI connection and ordinary local data integrity—not an AI-provider certification platform or a development-era compatibility programme.

Installation produced another example. PR #442 was left unmerged because removing a few Linux installation obstacles would not repair the larger mistake: AAAAT was trying to own package repositories, signing keys and package updates instead of delegating to the computer's native TeX installer or software manager. The accepted correction in #443 reduced that responsibility. #441 also removed unjustified restrictions on operating systems and build tools.

The recurring engineering work was deciding what AAAAT actually owns, finding where an apparently reasonable implementation crossed that boundary, and deleting or replacing it. Sometimes the best contribution from an AI agent was the code it stopped adding.

Who is the software supposed to protect—and from whom?

The most stubborn disagreements concerned user ownership. AAAAT is free, open-source software running on someone's own computer. If that person wants to change the effective instruction for an AI action, point the app to their own model, inspect the information in a request, or edit the script that starts their local runtime, I don't want the application to fight them.

Some agent proposals treated shipped prompts like untouchable policy or introduced additional approval and security machinery around things the user was intentionally doing on their own machine. My principle is simpler: the software should protect information and operations it actually owns, not invent authority over the person running it.

This doesn't mean there are no security boundaries. AAAAT still needs typed validation, renderer/process isolation, narrow mutations and honest rules about what can leave the local workspace. An external assistant doesn't get arbitrary filesystem, database or shell access just because it's called an agent. A remote model may need a credential, but AAAAT doesn't need to turn into a general authentication or AI-security platform to support that connection. The boundary is discussed explicitly in PR #153.

For the person using AAAAT, the useful distinction is between information stored locally, information shown prominently, and information allowed into a particular AI request. These are different decisions. A field may remain visible in the workspace without its value being sent for inference. Users can inspect and edit prepared context and, for supported actions, change the default AI instructions. The disclosure choice also matters when the configured model runs locally; it describes what the task may use, not just which company receives it.

Optional local startup is deliberately editable too. The owner of the computer can change it, disable it or restore the installed default. AAAAT must not confuse a user-controlled configuration script with permission for a connected AI to execute arbitrary commands. That's freedom with a real boundary, not a security theatre dashboard.

A small model changes the engineering problem

Another useful result is that AAAAT can do meaningful optional inference using the lightweight IBM Granite 4.1 3B Q4_K_M model through llama.cpp on a CPU. The product does not assume everyone has a premium model or a paid subscription, and its essential manual work needs neither.

Working with a small model shifts effort from impressive prompts to well-bounded tasks. Asking one model invocation to extract arbitrary fields, invent new fields, classify Tags and write polished advice is tempting. It's also harder to validate, slower to recover from and easier for a limited model to get wrong. AAAAT's application assistance was split into narrower field-value and conservative Tag tasks, with local validation and results that the user can inspect or correct. The same philosophy applies to working on one CV field or drafting a letter from explicitly selected context.

Evaluation became part of that search. PR #410 added repeated local trials against real model endpoints; #411 widened them to different in-app, copy-paste and connected-agent journeys. #416 corrected an evaluator that launched a second llama.cpp process and depended on experimental server-side MCP support, rather than testing the user's already-running model and AAAAT's actual tool boundary.

That distinction matters: a mock response doesn't demonstrate model usefulness, a packaged MCP server doesn't demonstrate a real external host can use it, and one successful run doesn't establish reliability. The repo contains actual local-host evidence alongside explicitly marked limitations. I consider the lightweight-model outcome useful and encouraging, not a universal benchmark or proof that every model and machine will behave the same way.

And yes, the interface is still a compromise

The UI has been one of the hardest parts to get right. This is where models most often replaced the intended human experience with the structure of the implementation: separate screens for what should be one action, too many explanatory panels, unnecessary AI ceremonies, technical vocabulary and controls that took space away from the work itself.

It wasn't fixed by asking for nicer CSS. On 11 October, the desktop experience was explicitly blocked from release because the problem involved navigation, editing state, document ownership, disclosure and visual composition together. The original diagnosis and corrections are in Issue #428; the integration that followed is documented in PR #435.

The current version is the most acceptable result of those iterations, not my ideal interface. It can be used and it is public, but that doesn't mean the visual and interaction design has reached the standard I'd eventually like. I would rather say that plainly than present a green verification check or a polished screenshot as proof of good UX.

This taught me something awkward: correcting an agent's misunderstanding of a product interaction can take longer than implementing the underlying service. Getting the right architecture is important, but it doesn't automatically give someone a usable screen.

What shipping AAAAT demonstrates—and what it doesn't

AAAAT shows that a final-year student with constrained access to several AI providers can coordinate an end-to-end, AI-coded open-source desktop project, including local information ownership, real document generation, optional lightweight inference and native releases. I haven't manually authored the implementation code at this stage. That is the experiment I set out to try.

It does not establish that an agent can be trusted to decide the product, that a passing suite proves user experience, or that this architecture is the answer for every team. Nor is Git a substitute for engineering judgment: it makes the decisions and mistakes inspectable enough to be challenged, and sometimes proves how often they needed challenging.

The biggest practical lesson for me has been to challenge the premise of a generated solution before debating its implementation. If an agent wants an extra framework, migration, permission layer or workflow, ask which real user problem needs it. If a test passes, ask what that test really exercised. If an AI provider or model changes, the product's meaning shouldn't change with it.

Most of my effort has gone into that kind of direction and correction rather than typing code. The full project history includes false starts, rejected PRs, superseded plans and honest gaps in acceptance evidence. I think that record is more interesting—and more useful to other engineers—than a frictionless story about AI building an application automatically.

This remains a personal experiment, not a finished theory of agentic software engineering. You're welcome to inspect it, disagree with the decisions, try AAAAT, or contribute improvements. The Product Definition says what the app is supposed to be; the Development Principles say how I try to keep the engineering honest; and the pull requests show where reality argued back.

Feedback is welcome

This is an open-source side project, not a managed recruitment service. If you find a problem or see a better way to express one of these principles, open an Issue or propose a change. Use fictional examples when discussing career data publicly.