Recommended resources
The freely available resources this lesson will direct you to.
Hello. Your booking service now has two repeatable HTTP checks: create-and-get, and one failure response. In the last lesson, you were asked to record what you wrote unaided and which exact APIs you looked up. Today you will use that record to distinguish API reference, conceptual guidance, and outsourced implementation.
The aim is not to stop looking things up. Exact Go APIs are worth checking. The aim is to notice when a lookup has quietly moved from supplying information to doing the implementation thinking you want to strengthen. Allow about 40 minutes, with most of that time spent auditing your own booking-service work.
Classify the help you used, not just the website you visited
Start with your notes, browser history, or editor history from the baseline service and its tests. Spend five minutes listing external lookups you remember, without judging them yet. Include documentation, videos, search results, AI chats, and accepted editor suggestions. A test run or compiler diagnostic is evidence from your tools, but it is not an external lookup for this audit.
The unit you will classify is the particular question and material you used, not an entire source. A page of Go documentation can give you a function signature in one visit and a worked implementation pattern in another. Likewise, an AI chat can begin with an explanation and end with a patch. Record those as separate uses if they supplied different kinds of help.
The Diátaxis map offers a useful starting distinction: some material helps you learn or understand; other material supplies facts or directions while you work.
Read the short primer to put precise meanings behind those four quadrants.
Start here - Diátaxis in five minutes - Diátaxis
Diátaxis distinguishes documentation by the need it serves. Read it to sharpen your judgment about whether a lookup supplied a fact, understanding, or directions you followed.
In “The four kinds of documentation,” begin with the paragraph introducing the four kinds. Read four purposes through the subsections “Tutorials,” “How-to guides,” “Reference,” and “Explanation.” Stop in “Explanation” after the paragraph beginning “Like reference, explanation belongs”; you can leave the following paragraph about overloaded tutorials for another time. Notice especially the difference between reference facts and a how-to guide's directions for accomplishing a goal.
Our audit uses three labels, not the four Diátaxis categories. They serve a different purpose:
| Label | What you obtained for your booking work | Typical use |
|---|---|---|
| API reference | A specific, checkable fact about an API or tool | The signature or behavior of httptest.NewRecorder, or the required shape of a Go test function |
| Conceptual guidance | An explanation or technique that helped you decide and implement | Why testing through the assembled router catches errors a direct handler call can miss |
| Outsourced implementation | Task-specific code, assertions, design choices, or a solution path supplied for you to adopt | A generated create-and-get test, or a proposed repair to your failing booking handler |
A how-to guide or tutorial does not automatically mean outsourced implementation. You might study a testing technique in a video, close it, and design your own booking test. That use is conceptual guidance. If you carry over its completed test structure and substitute your booking field names, the part you carried over is outsourced implementation. The label follows what crossed into your work, not the format or reputation of the source.
Locate the boundary where help becomes implementation
For this baseline mission, use a strict but practical boundary: if an external source supplied a task-specific answer that you incorporated instead of deriving it, mark that use as outsourced implementation. “Answer” includes more than compilable code. It can include which cases to assert, where to put repository responsibilities, or exactly how to repair a broken path-ID lookup. A suggestion need not be bad to count as outsourced.
Consider the lookups from the preceding lesson. Checking the official httptest documentation to confirm how NewRequest, NewRecorder, or Result behaves is API reference. Watching a demonstration to understand the request-and-recorder testing technique is conceptual guidance if you then decide how to apply it to your own router and contract. Asking an assistant to write your booking create-and-get test and accepting its assertions is outsourced implementation, even if you subsequently read and understand every line.
Small examples require judgment. Copying a minimal call that demonstrates an API signature need not hand over your design; using a complete example as your booking test skeleton does. If a lookup did both, split your record: note the API fact you checked and the implementation you adopted. Do not force a mixed interaction into a flattering single label.
Editor suggestions count too, particularly when they arrive without an explicit search. GitHub's documentation describes inline suggestions as capable of completing or changing code and generating tests. Skim the relevant parts so you can recognize that accepting a suggestion is a use of external help, even when it feels like ordinary typing.
Application card: GitHub Copilot inline suggestions - GitHub Docs
GitHub Docs describes what inline suggestions may contribute and why generated code still needs review. Read this to classify accepted suggestions by their contribution rather than by how little effort it took to accept them.
In “4. Intended uses,” read the first three uses: accelerating code authoring, generating unit tests, and generating code from comments. Then go to “7. Limitations,” find the “Inaccurate code” bullet, and read its caution. Focus on the difference between receiving a suggestion and establishing that it matches your contract and codebase.
Verification is a separate dimension from classification. A generated test does not become “API reference” because it passes. It remains outsourced implementation that you verified to some degree. Conversely, an answer about an exact Go method can be sought as API reference but still be wrong; check the method against authoritative documentation. Keeping these dimensions separate prevents a green test run from obscuring who made the implementation decisions.
For example, if an assistant tells you which status your unknown-booking endpoint should return, that is not a fact about the Go API. Compare it with your recorded contract. If the assistant instead tells you what ResponseRecorder.Result returns, verify that API claim and record the lookup as API reference.
Produce an honest lookup ledger
Now spend about 15 minutes classifying the lookups you listed at the start. Use a compact ledger beside your baseline notes; it need not be committed to the repository. One row per distinct use is enough.
| Lookup and obstacle | Material actually used | Class | Decision you retained or delegated | Check or evidence |
|---|---|---|---|---|
| Needed to capture a handler response | Confirmed recorder method behavior | API reference | Chose my own status and body assertions | Checked official docs; test runs |
| Unsure what boundary an HTTP test should cover | Learned why to call the assembled handler | Conceptual guidance | Selected routes and cases from my contract | Test fails on a deliberate mismatch |
| Example: asked for a booking test and adopted its assertions | Booking-specific test code and expected values | Outsourced implementation | Delegated test design; must revisit independently | Compare assertions with contract |
Those rows illustrate the level of detail, not a desired answer for your own history. In particular, do not claim the third event happened if it did not. If you cannot reconstruct a lookup reliably, mark it uncertain rather than inventing a clean account.
For each row, make the “decision” column concrete. “I understood it” is hard to evaluate; “I chose to send both requests through the same router and derived the expected fields from my contract” identifies work you actually did. When you find an outsourced portion, identify its smallest useful boundary. Perhaps the assistant supplied only an assertion, not the entire test. That distinction tells you what to rebuild later.
Finish by marking one outsourced or uncertain portion, if you have one, for a later close-the-assistant reproduction. If none appears, retain the ledger anyway: a history of API lookups and independently made decisions is useful evidence. Do not rewrite the baseline service merely to improve the labels. The purpose here is to measure the development process accurately, not to make it look purer than it was.
The three labels answer different questions: API reference supplies a checkable tool fact; conceptual guidance improves your understanding while you retain the implementation decisions; outsourced implementation supplies task-specific work you adopt. Classify the use, split mixed uses, and record verification separately. That gives you a more meaningful account of independent implementation fluency than either “used AI” or “did not use AI.”
Next, you will turn evidence from the baseline code and this ledger into a 0–5 implementation scorecard with green, yellow, or red ratings. The lookup record will help distinguish a feature you can reproduce from one you can currently only recognize.