Add a failure-and-repair record to your AI portfolio

Use an actual defect and name your contribution

In an October 11, 2026 account, Brandon R Galang describes an earlier take-home project in which an endpoint returned ordinary JSON while the interface expected a stream. He also describes a handoff with file uploads working and chat still broken. These are his reports of earlier work. The article's publication date does not make the defects new, and this guide has not independently reproduced them.^[1]

Select a defect from your own work that you can explain with a small, shareable record. Identify your contribution: what you inspected, which decisions you made, and where a coding agent or colleague helped. Use material you have permission to publish. For this proposed record, remove credentials, personal information and confidential employer content before sharing it. Galang's account provides the debugging context; this selection and sharing checklist is editorial advice.^[1]

Record the observations before the explanation

Start with the action that exposed the problem and the result you expected. Then state the result you observed. If a page looked correct while data failed to save, say which save check failed. If a response had the wrong format, name the expected and actual formats. Galang describes investigating what the interface sent, what the endpoint returned, whether the agent initialized and whether the workflow reached its final step.^[1]

Use this original record structure: Action and expected result; observed failure; project version and relevant environment; layers inspected; evidence for the cause; change made; same check after the change; remaining limits. Add causes you ruled out only when a check supports that conclusion. Keep a suspected cause labeled as a hypothesis until you test it. The headings organize the work Galang recommends recording; they are not his exact wording.^[1]

Retest the behavior that failed

A change to a file does not show that the original behavior now works. In this proposed format, repeat the action that exposed the defect and record the result against the same expectation. Name the checks you actually ran. If you checked only a mocked component or a local build, state that scope. Galang describes asking a coding agent whether it had tested locally before pushing a change after production failed.^[1]

When you can share them safely, attach the relevant change, a small test and the actual output from the retest. A before-and-after record must come from real execution. A diagram can explain how you investigated the issue, with a caption that identifies it as conceptual. Do not turn a blank template into a completed incident or add plausible logs to fill a gap. These are editorial evidence rules for presenting the checks discussed in the source.^[1]

Keep unresolved work visible

If the repair is partial, list what works, what still fails and the next check you would run. Keep that proposed check separate from completed tests. Galang recommends a short record of what you wanted, what broke, what you changed and what you still cannot explain. His account also says he was rejected in some interviews despite having working apps. A useful debugging record cannot promise an offer.^[1]