u/EastMove5163

Environment variable handling in AI-generated Next.js projects has a predictable set of issues. Hardcoded values that should be env vars. Mix of `process.env.KEY` and direct string literals for the same service in different parts of the codebase. And most critically, `NEXT_PUBLIC_` prefixes on variables that should be server-side only.

The `NEXT_PUBLIC_` issue is the one worth flagging in every review. That prefix causes the variable to be inlined into the client bundle at build time. There's no runtime override. If a secret ends up there, rotating the key and redeploying is the only fix, and any version of the bundle with the old key is already in CDN caches and browser caches.

Standard checks I run: grep for `NEXT_PUBLIC_` and verify each one is intentionally public. Check that `.env` is in `.gitignore` with a committed `.env.example`. Confirm prod has different key values from dev.

What does your env var review process look like for new projects?

AI tools are great at building for the happy path. User signs up, logs in, uses the feature, logs out. That flow works fine. The problems come from the paths the AI didn't think about.

The consistent gaps I've seen: login endpoints with no rate limiting (brute force is a real thing). Logout that clears the cookie client-side but leaves the session valid server-side. API routes that skip server-side validation because the frontend already validated. Database writes that accept raw input. CORS settings copied from Stack Overflow that allow every origin.

These aren't edge cases. They're the basics. And because the app works fine during development, they're easy to miss before launch.

If you've shipped an AI-assisted SaaS, how did you handle the security review before going live?

I've been running multiple Claude Code agents in parallel on the same codebase using git worktrees. Each agent gets its own branch and its own working directory on disk, so there's no file conflict between them. Both can read and write simultaneously without stepping on each other.

The actual workflow: create a worktree for each branch, open a Claude Code session in each directory, let them run. I've had one agent fixing a bug while another drafted a feature and neither one knew the other existed. When both finish I merge the branches like normal.

The speed improvement is real for work that can be parallelized. Not every task splits cleanly, but anything where two concerns are genuinely independent benefits from this. Bug fix plus new feature. Refactor plus test coverage. Two unrelated features.

Has anyone found this reliable for longer-running tasks, or do merge conflicts become a problem at scale?

Building a basic Claude agent is simpler than most tutorials make it look. The pattern: write Python functions for the things you want the agent to be able to do (search the web, read a file, call an API), register them as tools, give the agent a task, run it. The agent reasons about which tools to call and in what order to complete the task.

The part that most beginner tutorials skip: what happens when a tool fails. If your "search" function returns no results, what should the agent do? Try a different query? Tell the user it couldn't find anything? The agent can only make that decision if your tool communicates failure in a way the agent can understand. Raising an exception usually stops the whole thing. Returning structured output with an error flag gives the agent something to work with.

Getting comfortable with the failure cases is what takes a toy agent to a useful one. The happy path is easy. The edge cases are where you learn.

What failure cases have you hit in early agent projects that you wish you'd been warned about?

The Claude Agent SDK follows a clean pattern in Python: define tool functions, decorate or register them, pass them to the agent along with a task, run the agent. The core loop is not complicated. What gets you in practice is what happens when your tools fail.

Most example code shows tools that always succeed. In real use, tools fail: the API returns a 429, the file doesn't exist, the query returns zero results. If your tool raises a Python exception, the agent's behavior depends on how the SDK handles it and you may not get the recovery behavior you want.

The pattern that works better: return structured responses from your tools that include an error field. If the tool failed, return why it failed as data rather than raising an exception. The agent can read that response and decide how to handle it, whether to retry with different parameters, skip the step, or surface the problem. This keeps the agent in control of the flow.

What's your approach to tool error handling in agent code? Exceptions, structured error returns, something else?

The Claude Agent SDK follows a clean pattern in Python: define tool functions, decorate or register them, pass them to the agent along with a task, run the agent. The core loop is not complicated. What gets you in practice is what happens when your tools fail.

Most example code shows tools that always succeed. In real use, tools fail: the API returns a 429, the file doesn't exist, the query returns zero results. If your tool raises a Python exception, the agent's behavior depends on how the SDK handles it and you may not get the recovery behavior you want.

The pattern that works better: return structured responses from your tools that include an error field. If the tool failed, return why it failed as data rather than raising an exception. The agent can read that response and decide how to handle it, whether to retry with different parameters, skip the step, or surface the problem. This keeps the agent in control of the flow.

What's your approach to tool error handling in agent code? Exceptions, structured error returns, something else?

There's a lot of content about people's AI coding workflows and I've noticed a consistent pattern: they show you the part that works and skip the part that's hard. You see the impressive demo. You don't see what happens when the AI makes an edit you didn't want and you need to figure out how to undo it or redirect the session.

The harder skills in AI-assisted coding are not about getting better outputs on the easy tasks. They're about setting appropriate boundaries, catching bad edits before they compound, and recovering when a session goes wrong. Those skills don't make for satisfying YouTube thumbnails but they're what separates people who use these tools effectively from people who get frustrated and give up.

I think the content ecosystem around AI coding tools is in the same place as "productivity system" content: lots of people sharing what works for them on a good day, not enough sharing how they handle the messy cases.

What would you most want covered in honest AI coding workflow content that you're not seeing right now?