Conversational Coding Partner

Workbook-grounded and author-clarified; proposed reconstruction. Researchers, educators and designers who do not code can develop bounded digital artefacts through dialogue with a coding system. The exchange can combine requirements discovery, planning, editing, execution, diagnosis and revision, while experienced programmers may use the same pattern in unfamiliar or accelerated work.

Proposed and author-clarified. Conversational development lowers the barrier to complete digital artefacts, but it can conceal dependencies, security assumptions and unintended behaviour behind fluent explanations. When planning, execution and correction remain only in an opaque exchange, a non-coder may be unable to judge correctness or maintain the resulting project.

Proposed and author-clarified. Use conversation as the interface to a persistent inspect–plan–edit–run–review loop for a bounded digital artefact. Let the person specify domain intent and observable behaviour while the system handles implementation and explanation. Build through small testable slices, execute only within approved boundaries and use observed results to guide correction. Store code, tests, dependencies, decisions and instructions in the project. Keep the person, relevant reviewers and durable evidence—not conversational confidence—as the authority.

• A sequence of small, reviewable code changes linked to explicit requirements.
• Executable tests and observed results that support or reject each change.
• A repository record containing code, assumptions, dependencies and unresolved risks.
• Human approval of the implementation rather than reliance on conversational confidence.
• A complete but bounded digital artefact whose setup, behaviour and limitations remain understandable after the conversation ends.

The project owner controls purpose, scope, acceptance and external actions and judges domain correctness through observable behaviour. Technical reviewers assess security, maintainability and architecture where risk warrants. The system proposes, edits and may execute authorised steps, but project evidence and accountable people—not the conversational narrative—determine acceptance.

Reconstructed risks

• Generated code introduces security vulnerabilities, licence conflicts or hidden network behaviour.
• The assistant edits outside the intended scope or damages unrelated work.
• Passing superficial tests creates false confidence in scientific or pedagogical correctness.
• The person becomes unable to maintain the resulting system without the conversation.
• Secrets, private data or unpublished code enter an unsuitable service.

• Minimum viable implementation: create a dedicated project, state one observable capability, ask the coding partner to implement it, run it locally, inspect the result and retain the code plus a short setup note.
• Robust implementation: use source control, automated and reference tests, dependency locking, structured decision records, security and accessibility review, documented setup and a sequence of small approved changes.
• Low-code implementation: use an approved coding agent that can inspect, edit, test and preview within a restricted project while requesting approval for installations, network activity, publication or other consequential actions.
• Local or privacy-preserving implementation: keep unpublished code, data and credentials in controlled storage; use de-identified or synthetic test data and local execution when policy or participant expectations require it.
• Speculative implementation: allow the partner to propose and implement multi-step features through staged approval, automated tests and monitoring, while retaining stop conditions, reversible checkpoints and human authority over release.