Телеграм канал «Full Stack Camp»

CI/CD is a set of automated practices that help teams build, test, and release software safely and quickly. CI (Continuous Integration) means every time a developer pushes code or opens a pull request, an automated system checks that the code builds and passes tests. CD (Continuous Delivery/Deployment) means code that passes those checks can be automatically prepared for release or deployed to an environment like staging or production.

Here is how it works in practice: you create a small config file, usually a .yml file (for example, .github/workflows/ci.yml for GitHub Actions), and inside it you define when the pipeline should run and which commands it should execute, such as npm ci, npm run lint, npm test, and npm run build. You can set it to run on pull requests, for example with on: pull_request, so when a developer creates or updates a PR, the CI system automatically starts a machine, installs dependencies, and runs those lint/test/build commands. The PR then shows a green check if everything passes or a red X if something fails.

This helps because problems are caught early before merging, every PR gets the same checks instead of relying on people to remember, reviewers save time, and the main branch stays safer and more stable. After merge, CD can continue the same idea by automatically deploying the app to staging or production.


@CTBEsoftwareengineers

Here is the full checklist.

Lesson 5: The Control Loop

An agent can call tools again and again, talk to itself, and never stop. You must build hard limits so it always stops, even in the worst case.

Checklist

□ Set a max number of turns (steps) the agent can take. Stop it hard when it reaches this number.

□ Set a max number of tool calls, separate from turn count if needed.

□ Detect repeated identical tool calls (same tool, same input, again and again). Stop the loop if this happens.

□ Detect repeated failed tool calls. Do not let the AI retry a broken tool forever.

□ Add a total time limit for the whole run, not just per-call timeouts.

□ If a budget is used up, tell the user clearly: "stopped because of turn limit" or "stopped because of repeat calls."

□ Keep a full history/trace of what happened in the run, so you can debug it later even after it stops.

□ Track cost or token usage if you are using a paid API, so a stuck loop does not cost you real money.

□ Test your control loop on purpose: force a fake infinite loop and check that your code really stops it.

@fullstackCampp

#AI #Safety #lesson5

Lesson 4: Safe Tools & Blast Radius

"Blast radius" means: if the AI does something wrong, how much damage can it do? When you give an AI real tools (write files, run commands, call APIs), you must lock the tool down so the worst case is small and safe.

Checklist

□ Lock file writes to ONE folder only. Do not allow writing anywhere else.

□ Do not check folder safety with simple text matching (like startswith). Use a real "is this path inside that folder" check, because text matching can be tricked.

□ Block filenames that contain path separators (/ or \) or "go up a folder" patterns (..).

□ Only allow specific file types (example: only .md files, not .py, .exe, .env).

□ Set a max size limit for anything written (file content, data saved).

□ For running commands: use an allow-list of exact commands. Never allow "any command."

□ Never build a command by joining raw text together. This can lead to command injection.

□ Give tools clear, narrow jobs. A "write markdown report" tool should not be able to write any file type.

□ Log every tool call: what tool, what input, what result. You need this to check later what happened.

□ Treat every tool result as untrusted data when it goes back to the AI. Do not treat it as a command.

□ Test what happens if the AI tries to call a tool that does not exist. Your code must catch this, not crash.

□ Test what happens if the AI sends wrong or missing arguments to a tool.

@fullstackCampp

#AI #Safety #lesson4

Docker cheatsheet
@shu_codes

Lesson 2: Harness Engineering
A harness is your safety net. The AI call can fail in many ways: slow network, server down, wrong model name, bad answer. Your code must catch all of these and never crash. Instead of crashing, return a clear result that says "it worked" or "it failed, and here is why."

Checklist
Set a timeout on every network call. Do not wait forever (a few seconds to under a minute, not minutes and minutes).
Catch "timeout" errors on their own.
Catch "connection error" (server not running, wrong URL) on their own.
Catch "HTTP error" (404 model not found, 401 bad key, 500 server crash) on their own.
Add one last catch-all for any error you did not expect.
Check if the required API key or config exists BEFORE you call the network, not after.
Check that user input is not empty, blank, or the wrong type, before sending it anywhere.
Every result should be a clear structure, like {"success": true/false, "content": ..., "error": ...}.
Add an error_type label (like NETWORK_TIMEOUT, CONFIG_ERROR) so your code can react differently to different failures.
Check the AI response shape carefully. Real answers can be missing pieces (empty list, missing field) even when the network call "worked."
Handle the case where the AI response is blocked by a safety filter (empty result, special "block reason" field).
Handle the case where the AI stopped early (hit a length limit) and the answer is cut off or empty.



@fullstackCampp

#AI #Safety #lesson2