Engineering Collaboration
Human experience. AI assistance. Better engineering.
Every piece of software begins with a human thought.
Sometimes it is an observation. Sometimes it is a problem that needs solving. Sometimes it is simply the feeling that something could be better.
Engineering Collaboration is the methodology I use to transform those ideas into reliable, well-tested software by combining human experience with artificial intelligence.
AI is not used to replace engineering judgement. It is used as an engineering assistant throughout an iterative design, development and testing process in which every significant architectural decision remains under human control.
Every project starts with a conversation
Traditional software projects often begin with a written specification. My projects rarely do.
Most begin with a discussion: an observation made while using software, a real-world problem, or a conversation about how users actually experience a feature.
Often the first challenge is not writing code. It is understanding the problem well enough to describe the solution.
I often explain the idea through similes, metaphors or abstract concepts. The role of the collaboration is to translate that vision into something technically possible, testable and maintainable.
AI provides an effective environment for exploring ideas, challenging assumptions and gradually refining abstract concepts into practical engineering requirements.
Keeping ideas grounded
The process does not rely on AI alone to determine what is possible.
The AI contributes research, analysis, feasibility checks and implementation knowledge. I contribute current technical information, domain experience, live observations and specialist sources that may not appear in a general search.
- the latest ESO API documentation;
- existing addon code and library behaviour;
- platform-specific limits discovered through live testing;
- outlier examples that reveal a different solution;
- creative references that define tone or character;
- first-hand experience of how users actually behave.
For example, the design of Nan in Tea & Toast was not formed from a generic request for a funny companion. It developed through discussion of lived memories, behaviour, speech patterns and the emotional influence of Maggie Smith in The Lady in the Van.
Likewise, Suga's Test Zone changed direction when I explained that it should not be thought of as an addon, but as a development server, public test environment, QA zone and safety net around live software.
From vision to implementation
Once the problem is understood, the collaboration becomes increasingly structured.
Rather than asking AI to simply write software, I define:
- the desired behaviour;
- the intended user experience;
- design constraints;
- failure conditions;
- accessibility requirements;
- long-term maintainability;
- release and rollback strategy.
AI then assists by transforming those agreed requirements into working implementations, documentation and reusable components.
The collaboration lifecycle
Problem or Observation
|
v
Human proposes an idea
|
v
Discussion and exploration
|
v
AI evaluates feasibility
|
v
Human supplies current APIs,
domain knowledge and outlier evidence
|
v
Shared functional design
|
v
Implementation
|
v
Test plan
|
v
Human UAT
|
v
Human observations
|
v
Refinement
|
v
Repeat
|
v
Production release
Real-world testing matters
Working code is only the beginning.
Every feature undergoes User Acceptance Testing using real-world scenarios. Rather than simply confirming whether something technically works, I observe how it behaves.
- Does this feel intuitive?
- Would a new user understand it?
- Is the timing natural?
- Is accessibility improved?
- Does it solve the original problem?
- Does it behave correctly outside the planned test steps?
The value of observation
Some of the most important changes do not begin with a failed test. They begin with an observation.
Tamriel Races
The compass marker was technically accurate, but the way it behaved near the destination could still cause players to spin in circles.
That observation led to changes in waypoint presentation, distance behaviour and how the addon yields to the user's own map marker.
Tea & Toast
Nan is not trying to be funny. She is genuinely worried.
That changed the entire dialogue model. Concern became the source of every line, while humour became a natural result of how she expresses that concern.
Suga's Test Zone
Do not think of it as an addon. Think of it as my development server.
That single metaphor changed the architecture from a temporary host addon into a reusable development, public-test, QA and rollback environment.
VCAP2
Different message types need different tags.
That observation expanded the system from identifying an addon to allowing users to control distinct categories of narration from the same addon.
Human expertise remains central
Throughout every project, I remain responsible for:
- identifying problems worth solving;
- defining the vision and intended user experience;
- providing domain knowledge and specialist resources;
- supplying current API documentation and project assets;
- validating that proposed solutions remain aligned with the original intent;
- performing User Acceptance Testing;
- reporting expected behaviour, unexpected behaviour and qualitative observations;
- approving or rejecting design decisions;
- determining when software is suitable for release.
The AI engineering contribution
The AI engineering assistant supports the project by:
- exploring possible technical approaches;
- keeping proposed solutions grounded within known technical limitations;
- researching APIs, documentation and implementation options;
- identifying architectural opportunities and risks;
- transforming agreed requirements into working code;
- producing reusable templates and documentation;
- generating changelogs, test guidance and release notes;
- assisting with debugging based on UAT feedback;
- refining implementations through iterative development.
The AI assists the engineering process, but it does not replace project ownership, domain judgement or final approval.
Engineering through iteration
Each development cycle improves more than the software itself. It also improves the architecture, documentation, testing procedures, accessibility model, release process, rollback strategy and standards used by future projects.
This is why earlier entries in the archive may be less structured than later ones. The archive system itself was also developed collaboratively, implemented, tested and refined across multiple iterations.
Engineering Collaboration Records
Each suitable archive release can include an Engineering Collaboration Record.
These records do not repeat the full methodology described on this page. Instead, each one documents how a particular feature or version came to exist.
- the original problem or observation;
- the proposed theoretical solution;
- technical limitations discovered during research;
- specialist information supplied by the project owner;
- the agreed functional design;
- implementation decisions;
- test parameters;
- UAT results and observations;
- corrections and refinements;
- the final outcome.
This creates a traceable record of both contributions: the human vision, judgement and testing, alongside the AI research, implementation and documentation support.
Continuous improvement and traceability
Every version of every project is archived, not simply as a backup, but as evidence of the engineering journey.
- release notes;
- changelogs;
- User Acceptance Testing records;
- Engineering Collaboration Records;
- rollback builds;
- design documentation.
This creates a fully traceable history showing how each project evolved through structured collaboration, testing and continuous refinement.
The result
Engineering Collaboration is not about asking AI to write software.
It is about combining human creativity, systems thinking, real-world experience and structured testing with AI-assisted research and implementation to produce software that is robust, maintainable and genuinely useful.
Every project reflects that philosophy, not simply because it works, but because every decision can be traced, understood, tested and improved.
The best software is rarely written in a single sitting. It is shaped through observation, collaboration and continuous refinement.
Explore the software archive and discover how this methodology is applied in every project.