CRUD
Create, read, update, delete: the four operations behind almost every screen and API. Say 'CRUD' and you have asked for all four.
See it
What it is
CRUD names the minimum set of things you can do to a record: create, read, update, delete. It lines up with SQL (INSERT, SELECT, UPDATE, DELETE) and with HTTP in a REST API (POST, GET, PUT or PATCH, DELETE). That is why the word carries so much: 'give me CRUD endpoints for projects' is a full spec in four letters, and every framework and AI tool knows exactly what to generate.
Reach for it when scaffolding the boring, necessary parts: admin panels, internal dashboards, resource endpoints, the settings screen nobody wants to design. In practice 'read' splits in two: fetch one record by id, and list many with filters, sorting, and pagination. Ask for both or you will get a list endpoint that returns everything forever.
Gotcha: real products are rarely pure CRUD. 'Publish', 'refund', 'invite teammate', 'cancel subscription' are not row edits, they are events with side effects, permissions, and their own audit trail. Squashing them into PATCH /order with { status: 'refunded' } hides the business rules and lets anyone with edit access trigger a refund. Also prefer soft delete (a deletedAt column) so the D in CRUD is undoable.
Ask AI for it
Scaffold full CRUD for a 'Project' resource. REST API: POST /projects (create), GET /projects (list with pagination, search, and sort), GET /projects/:id (read one), PATCH /projects/:id (partial update), DELETE /projects/:id (soft delete by setting deletedAt). Validate every request body against a schema, return 201 with the created record, 404 for a missing id, and a structured error body of { code, message, details }. Then generate the matching admin UI: a data table for the list, a shared create/edit form, and a confirmation dialog on delete.