Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why does generating service-layer business logic typically require providing significantly more context than generating a simple route handler?
💻 Code Challenge | +75 XP
Write a prompt for generating an OrderService.cancelOrder() method that explicitly states the business rule (only pending/processing orders can be cancelled), requires constructor-injected dependencies, and wraps the cancellation and inventory restoration in a single transaction.
AI-generated order-cancellation logic allowed cancelling already-shipped orders, and a related inventory bug left stock counts inconsistent after a failed cancellation attempt. Reorder the steps to fix both issues.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Generating service-layer code without stating the actual domain-specific business rule it needs to enforce
// Vague: the model has no way to know YOUR specific business rule
"Generate cancelOrder()"
// Explicit: states the actual rule to enforce
"Generate cancelOrder() — only allowed if status is pending or processing"The Solution //
Generic validation logic (is this a valid email format?) is well-represented in training data and generally reliable, but a domain-specific business rule (which order statuses allow cancellation) is entirely specific to your application and won't be correctly inferred without being explicitly stated in the prompt.
The Error //
Generating a service method with multiple related database writes but no transaction wrapping them together
// Wrong: unprotected, inconsistent state possible on partial failure
await orderRepo.save(data);
await inventoryRepo.decrement(data.items);
// Correct: both succeed or both roll back together
await db.transaction(async (tx) => {
await orderRepo.save(data, tx);
await inventoryRepo.decrement(data.items, tx);
});The Solution //
If related writes (like creating an order and decrementing inventory) aren't wrapped in a single transaction, a failure partway through can leave the database in an inconsistent state — inventory decremented without a corresponding order actually existing, for example.