What happened
In an article published on November 1, 2026, Engadget writer Kate Irwin sets out five safety practices for people building applications with AI coding tools. The article describes vibe coding as generating code by instructing an AI model, sometimes while accepting code the user does not fully understand or review. It cites application-security firm Apiiro, which says its examination of Fortune 50 companies found that vibe coding made engineers four times more productive but led to ten times as many security issues. Engadget does not provide Apiiro’s sample size, methodology, or definition of a security issue.
The first practice is specificity. The article warns against assuming a model will infer privacy constraints, security practices, or checks by itself. Instead, a builder should state privacy specifications, access restrictions, encryption requirements, and other guardrails in the request. It suggests asking a model to refer to OWASP’s vulnerability guidance, and keeping persistent project rules in a Markdown file or in a platform’s continuing context feature. The examples named are Lovable’s Knowledge section and Replit’s Memory section. Engadget also recommends tools with audit logs so a builder can trace changes to a project.
The second practice is keeping API keys and passwords out of prompts and source code. The article points beginners to password managers and to built-in secrets or environment-variable features in Replit, Lovable, and Vercel. If the selected tool lacks such a feature, it recommends using a backend .env file, excluding that file through .gitignore, and ensuring it never appears in a public frontend. Engadget names TruffleHog as a way to check code for accidentally exposed sensitive information.
For applications that handle data, the article recommends parameterized SQL queries, input sanitization, server-side actions for critical operations, and row-level security policies where they apply. It adds that models can hallucinate packages that do not exist or accidentally introduce malicious packages, so builders should verify dependencies and use current library versions. The fourth practice is rate limiting. Limits on password attempts can help against brute-force and credential-stuffing attempts; limits on a chatbot or other model-powered feature can also constrain token use. The guide advises limiting by account ID before IP address when possible, and lists authentication flows and CAPTCHA as additional measures.
Finally, Engadget recommends reviewing and testing AI-generated work before release and monitoring it after release. It suggests asking the model to assess its own output against OWASP Top 10 risks, then using other models as additional reviewers rather than relying on one system. The article lists Claude Code Security, Codex Security, Stackhawk’s Wingman, CheckVibe, SafeToShip, and Vibe App Scanner as tools that can evaluate vibe-coded projects. The source presents these as options, not as independently tested or equivalent products.
What the archive adds
This is a new practical explainer rather than a newly disclosed incident or product release. Developing Gemini 4 Argon responsibly and safely argued that agent safety depends on runtime controls and observable behavior, not model-level refusal training alone. Engadget addresses application building rather than model development, but its emphasis on restricted access, logs, testing, and monitoring is consistent with that distinction.
Trend signal
The guide supports Verification bandwidth is the scarce engineering resource. AI can increase the volume of code a team produces before automated tests, security checks, and human review can establish whether that code is reliable enough to ship. Engadget’s suggestions—independent checking, auditability, and continuing monitoring—are operational responses to that imbalance, although the article does not measure their effectiveness.
Why now
Engadget frames vibe coding as a now-common way to build, particularly for people who can move rapidly from an instruction to a working application without a conventional engineering review process. The timing is tied to that broader adoption pattern, not to a disclosed vulnerability, a new platform capability, or a regulatory decision.
Connections to other events
An earlier archive Telegram post summarized SonarSource research in which many developers reported incomplete trust in AI-generated code and said it can look correct while behaving unreliably. That evidence concerns developer confidence and verification. Engadget adds an app-security checklist: protect secrets, limit access and usage, review generated work, and observe the system after deployment. The two sources cover different populations and measures, so they are not directly comparable.
Why it matters
For a builder, an application that runs is not necessarily an application that is safe to expose. Generated code can place credentials in the wrong location, process untrusted input insecurely, provide broader data access than intended, or permit costly numbers of model calls. Those risks are especially easy to miss when a user evaluates an AI-built app primarily by whether its visible feature works.
The value of the guide is that it translates broad security concerns into choices a non-specialist can make during a build. A persistent rules file can specify constraints; a secret store can prevent a credential from reaching a repository; rate limits can bound both abuse and spend; and a separate review can challenge the output of the model that wrote the code. These controls address different failure modes. None is a substitute for qualified security work where the application’s exposure or data sensitivity warrants it.
Limits and uncertainty
Engadget’s piece is a practical checklist, not a controlled evaluation of the practices or tools it names. It does not compare the listed security products, establish which are available to all builders, or show that asking a model to check itself materially reduces vulnerabilities. Apiiro’s productivity and security-issue figures are reported without methodology, sample size, or definitions in the supplied source. Implementation also varies by stack: row-level security, server-side actions, authentication, and rate limits are not interchangeable configurations. Following the checklist cannot establish that an AI-built application is secure, nor does the article claim that it replaces ongoing engineering review or incident response.
Skill to build now
Add a short security requirements file to one AI-built project this week. State which data is sensitive, who may access it, where secrets must live, and which input, database, and rate-limit protections are required. Then scan for exposed keys and manually review one critical route that accepts user input. Use the file as both recurring context for the coding tool and a checklist for your own review; do not treat its presence as proof that the generated code followed it.
Reader takeaway
AI can make an application quicker to produce, but it does not make its security choices on the builder’s behalf. Keep secrets out of chats and public code, explicitly define access and data protections, and verify the result with checks that go beyond the model that generated it.