“Build a registration screen.” “Add search.”
With generative AI, a working web service can appear in tens of minutes from plain-language instructions.
This style of development is often called vibe coding, and it is spreading not only in IT teams but also as citizen development in business units.
As outlets such as Toyo Keizai Online have pointed out, more cases look fine in operation while remaining full of security holes.
When companies chase speed under an “AI-first” banner alone, Japanese organizational weaknesses tend to show up quickly.
What is happening
Traditional system development spent time on requirements, design, development, review, and testing.
Generative AI dramatically shortens the “development” part.
But the time humans spend on review and security checks has not sped up at the same rate.
The result is a distortion: build speed rises by tens of times, while the speed of verifying safety stays roughly the same.
On top of that come gaps that are especially common in AI-generated code.
“It works” is not the same as “it is safe”
Generative AI is an excellent programmer.
Its goal, however, is to write code that behaves as requested—not necessarily code that is secure in the way humans implicitly expect.
Problems repeatedly noted in reporting and verification include:
- Weak or missing authentication
- Admin screens exposed to the outside
- API keys or secrets embedded in source
- Insufficient permission design before release
- Security libraries installed but never actually enabled
The common thread is that the app still runs without these defenses.
Pages load, registration works, search works—so thin reviews easily miss the holes.
Some analyses say AI may “know” needed defenses, yet still leave a gap before applying them all the way.
Weaknesses that show up easily in Japanese companies
A particular risk in Japanese companies is treating “AI made it fast” as “it is finished.”
As citizen development spreads, people without security expertise can more easily publish near-production services.
That tends to expose weaknesses such as:
- Speed KPIs run ahead while review capacity cannot keep up
- Working demos go straight to production
- IT or security teams join only after the fact
- Unclear rules for dependency and secret management
- No clear owner who understands the code when incidents happen
AI use itself is not the problem.
The problem is raising speed without adding verification gates, and treating “we used AI” as success on its own.
Practical countermeasures
The basic approach is not prohibition, but building a system where teams can still ship safely even when they build fast.
- Put security requirements such as auth, permissions, and secret handling into prompts
- Require secret scanning and dependency checks before deploy
- Add static analysis or lightweight diagnostics into CI
- Fix human or secondary-AI security review into the process
- Keep approval flows for admin screens and production release
- Design least privilege, audit logs, and final confirmation points
Most important is keeping a “safety checklist” separate from a “does it work” checklist.
Organizations need a shared understanding that looking functional and being protected from the outside are different problems.
Summary
AI-driven rapid development greatly accelerates web service prototyping and improvement.
But “works OK” is not “security OK.”
If build speed rises while verification speed stays put, Japanese companies’ weaknesses can turn directly into incidents.
Going forward, AI adoption means designing not only how fast you build, but also how safely you can stop and fix.
At Makoto Tejima, even in AI-assisted web and system development, we emphasize design that includes existing-system integration, permission management, public-surface hardening, and human confirmation points.
Please feel free to consult us about AI development rules, secure public design, or reviewing existing systems.
