AI Context:
Why One Boolean Wasn’t Enough
AI-assisted software development can help trace this: A boolean is rarely just a boolean once it crosses the stack.
In one recent product feature, a document used to have a single isMainManual flag. That flag answered two completely different questions: should this document be used as context for the AI, and should the user be able to see it?
That worked while there was only one “main manual.” It became a problem as soon as products needed multiple documents with different purposes.
The solution was not simply adding more documents. It was separating two concepts that had been coupled together: useForAI and isVisibleToUser.
The product decision became a technical decision
Consider a product with three documents:
- A public user manual
- A warranty document
- An internal troubleshooting guide
The AI might need the troubleshooting guide and the manual to answer questions accurately. But the end user may only need access to the manual and warranty.
The old model could not express that.
The new model can:
That distinction sounds obvious when written this way. But implementing it meant changing much more than a database column.
The backend schema had to change. Existing data had to be migrated. The API contract had to evolve. The code selecting documents for the LLM had to change. The frontend needed two controls instead of one. The public product page needed a different document-selection experience.
The system also had to remain compatible with existing clients throughout. So… AI-assisted software development, yes or no?
The tech stack tells the story
This is where the feature gets interesting from an engineering perspective.
The backend used Node.js, Express, Prisma, and PostgreSQL. Prisma handled the schema and migrations, including two hand-written SQL migrations for the transition.
The AI layer used the OpenAI Node SDK in Azure OpenAI mode, with pdf-parse extracting text from PDFs before assembling the selected documents into the LLM prompt.
On the frontend, the feature touched TypeScript, Next.js, React, TanStack Query, and Radix UI. The admin interface gained two document toggles, while the public product experience gained a document picker when multiple documents were visible.
That stack is worth looking at as a system, not a list of technologies.
A change to a boolean in PostgreSQL eventually changes what gets extracted from a PDF, what gets concatenated into an LLM prompt, what the API exposes, what React renders, and what a user can select.
That is the real cost of coupling concepts together.
Migration is where the old model meets reality
Changing the data model was not just a matter of renaming isMainManual.
The implementation used an expand-and-contract approach.
First, we added the new useForAI and isVisibleToUser fields. Existing isMainManual = true records were backfilled into useForAI = true. Only then did we remove the old column.
An important engineering principle is hiding here: changing the model and migrating the meaning of existing data are two different problems.
The new schema tells you what the system should look like.
The backfill tells you what the old system meant.
Those are not always the same question.
In this case, the migration preserved the old AI behavior for existing main manuals, while the new model established a more explicit relationship between documents and AI context. It was still AI-assisted software development.
The AI behavior changed too
The most interesting part of the change may actually be inside the AI layer.
Previously, if a product had no main manual, the AI could fall back to using all documents.
After the change, it includes only documents explicitly marked useForAI. If there are none, the prompt says:
“No manuals available.”
That is more than a refactor. It changes the AI system’s semantics.
It also creates a new consideration that becomes increasingly important as AI applications grow: context is part of the product architecture.
Which documents the model can access is not merely an implementation detail. It affects relevance, token consumption, response quality, and potentially what information reaches the model in the first place.
The implementation currently concatenates all AI-enabled documents into the prompt without a size cap, so adding more AI-enabled documents can also increase prompt size and token usage. Whether that trade-off was explicitly considered is not documented in the available evidence.
Then there is the API
The old isMainManual field was removed from the public response, but mainManual was retained as null so older clients would not crash.
That is a small compatibility decision with a very practical consequence.
A backend can evolve without forcing every consumer to upgrade at exactly the same moment.
The public document list was also filtered server-side using isVisibleToUser, rather than relying on the client to hide documents.
This is another example of how a seemingly simple product distinction becomes an architectural boundary: visibility is enforced where data leaves the system, not just where the UI renders it.
The frontend had to reflect the new mental model
The admin interface changed from updating a document immediately when a toggle was changed to queueing document changes and flushing them when the product was saved.
That introduced a different consistency trade-off: document updates are sent before the product update and are not wrapped in a single transaction. If the product save fails, those document changes can remain applied.
The model also changed for users.
If there is one visible document, it opens directly. If there are several, the interface presents a picker built against the design prototype.
The UI is therefore not simply exposing the database model. It is expressing the product decision that multiple documents can now coexist for different audiences.
Where AI fits in is actually unknown
This is an important part of the case.
There is no direct evidence that AI was used to implement this particular feature. The work happened in May 2026, while the available local AI session logs begin in September. No AI co-author trailers or feature-specific session records exist.
So assigning an AI-assisted software development percentage to this feature would mean inventing evidence that does not exist.
What is documented is human review. The backend and frontend PRs were each approved by another engineer.
That makes this case useful for a different reason.
It shows that the interesting question is not always “How much of the code did AI write?”
Sometimes the better question is:
“What decisions had to be made to make the code mean the right thing?”
The part AI cannot infer from the codebase
The repository can show us that two flags exist.
It cannot, by itself, tell us why a warranty document should be visible but excluded from AI context, or why an internal troubleshooting guide should work the other way around.
Those decisions depend on the actual content, the users, the product, and the consequences of exposing or withholding information.
The same applies to the migration.
The code can tell us that former main manuals became AI-enabled documents. It cannot tell us whether that was the right interpretation of every existing product.
The implementation also introduced an invariant requiring every product to have at least one AI document, but that invariant is enforced at the product level and can still be broken through certain individual document endpoints. That is not simply a coding detail. It is an architectural trade-off about where the system should enforce its rules.
The bigger engineering lesson
The feature took about one working day to author and three calendar days to merge both backend and frontend. The result removed the one-document limitation and separated AI context from user visibility.
But the interesting part is not the speed.
It is what the speed depended on.
A small change in product semantics propagated through PostgreSQL, Prisma, Express, the OpenAI SDK, PDF parsing, Next.js, React, TanStack Query, and Radix UI.
That is what modern software development increasingly looks like.
AI-assisted software development can help generate, refactor, explain, and connect pieces of that stack. But the hard part is often deciding what those pieces should mean together.
In this case, the key architectural move was not adding AI.
It was deciding exactly what AI should be allowed to see. Not all about AI-assisted software development.
Diving deep into AI-assisted software development.
