> For the complete documentation index, see [llms.txt](https://handbook.sixpivot.com.au/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.sixpivot.com.au/how-we-work/policies/responsible-use-of-ai/ai-assisted-software-development.md). # AI-Assisted Software Development AI has become part of how we build software at SixPivot. It can help us explore unfamiliar code, investigate problems, implement features, refactor systems, write tests and review our work. Modern coding agents can often take on substantial pieces of development work. That's useful, but producing code faster isn't the goal. Our Consulting Manifesto talks about **Quality Code over Speed of Delivery**. AI should help us reach good solutions faster, not simply help us produce more software. > **AI-generated code is still our code.** If we ship it, we're responsible for understanding, supporting and maintaining it. This guidance assumes you've already considered the appropriate use of AI under our [Responsible Use of AI](/how-we-work/policies/responsible-use-of-ai.md) policy. ## Understand what you're shipping You don't need to have personally typed every line of code, but you should understand the solution you're delivering, the change it brings and the effect it would have on the software. Before accepting significant AI-generated changes, make sure you understand: * the approach being taken; * the assumptions being made; * how it fits into the existing system; and * why it's an appropriate solution to the problem. AI can produce convincing implementations that are subtly wrong, unnecessarily complicated or simply don't fit the architecture around them. Use the same engineering judgement you would apply to code written by anyone else. ## Review according to risk Not every generated change needs the same level of scrutiny. A small mapping change is very different from a database migration, authentication change or production infrastructure update. But that small mapping change can have a significant effect. Apply greater scrutiny where mistakes have greater consequences, particularly around: * security and authentication; * data access and persistence; * database migrations; * infrastructure and deployment; * concurrency and distributed systems; and * destructive or difficult-to-reverse operations. AI can also be useful as an additional reviewer, but having another AI review AI-generated code isn't necessarily independent verification. It can over-engineer, over-estimate and not grasp the wider picture. Normal project and code review practices still apply. ## Test the requirement, not the implementation AI is very good at generating both an implementation and the tests for it. This creates an easy trap: if the AI misunderstands the requirement, it can encode the same misunderstanding into both. Everything passes, but the software is still wrong. Tests should validate the expected behaviour and requirements of the system, not simply confirm that the generated implementation behaves as written. Use AI to help find edge cases and generate tests, but apply independent thought to what actually needs to be proven. Ensure that tests generated are high-value and not testing irrelevant or unncessary things. ## Be deliberate about dependencies and architecture AI can introduce libraries, abstractions and architectural patterns very quickly. That doesn't mean we need them, keep a tight control on dependencies. Before accepting a new dependency or significant architectural change, consider whether: * the project already has an established way of solving the problem; * the additional abstraction is actually useful; * the dependency is necessary and appropriate; * the library, API or version being suggested actually exists; and * the change makes the system easier or harder to maintain. Don't let an agent redesign the application simply because it found a different way to solve the task. ## Keep changes reviewable Coding agents can produce a lot of code very quickly. Large generated changes can be difficult to understand, review and recover from, particularly when they combine implementation, refactoring, dependencies and unrelated cleanup into one change. Prefer coherent changes with a clear purpose. A simpler, smaller PR is easier to review than a huge one. If an agent starts changing substantially more than expected, understand why before accepting the work. A large diff isn't necessarily a sign of progress. ## Build software humans can maintain The AI conversation that produced a solution won't always be available to the next person maintaining it. The code needs to stand on its own. Prefer straightforward implementations that fit the existing codebase over clever solutions that only make sense with the context that generated them. Documentation and comments should explain things that genuinely need explanation, not attempt to preserve an AI conversation inside the codebase. The same maintainability standards apply whether the code was written by a Pivot, generated by an AI or produced collaboratively between the two. Ensure comments written are concise and relevant. ## Keep engineering AI is particularly valuable for exploring options, challenging assumptions, understanding unfamiliar systems and working through difficult problems. Use it for those things. Don't let every engineering problem become a prompt followed by accepting the first plausible answer. For important decisions, understand the problem, challenge the proposed solution and consider alternatives. AI should increase what we can accomplish while preserving the engineering judgement that makes the result good. ## In short **AI-generated code is our code.** Understand and own what we ship. **Quality over quantity.** Generating more code faster isn't the objective. **Review according to risk.** Apply more scrutiny where mistakes have greater consequences. **Test what should happen.** Don't let the same incorrect assumption define both the implementation and its tests. **Keep changes understandable.** Build software that the rest of the team can review, support and maintain. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.sixpivot.com.au/how-we-work/policies/responsible-use-of-ai/ai-assisted-software-development.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.