Vibe coding is giving teachers extraordinary new creative possibilities. It is also allowing people with little knowledge of software security to build applications that collect, store and share data. Schools need to recognise the point at which an exciting classroom experiment becomes an information system.
Yesterday I was in Singapore running a workshop for teachers on vibe coding. We began with the kinds of activities I have been enthusiastically encouraging teachers to explore: simple simulations, quizzes and interactive learning resources. These are exactly where I think vibe coding can have enormous value in education. A teacher can have an idea for a resource and turn it into something students can interact with remarkably quickly.
What struck me during the workshop was how quickly the ambitions grew. Once teachers realised that they could create a working application, the next questions naturally became about connecting it to other things. Could it save results? Could it use an API? Could it remember students? Could it write information to a spreadsheet? Could students log in?
None of these were unreasonable questions. In fact, they demonstrated just how empowering this technology has become. However, I also realised that we were crossing a boundary that was almost invisible to the people crossing it. Within a very short period of time, we had moved from creating engaging classroom resources to discussing applications capable of collecting and storing information about real students. It just became a safe guarding matter!
When a quiz becomes an information system
Consider something as apparently harmless as saving quiz results to Google Sheets. An AI coding tool can produce the necessary code very quickly, and Google Apps Script makes it possible to expose a web endpoint that receives information and writes it into a spreadsheet.
Technically, this is relatively straightforward. It can also be configured very badly.
Google’s own documentation shows that an Apps Script web application can be configured so that only the developer can access it, only people within an organisation can access it, any signed-in user can access it, or even any anonymous user can access it. A web app can also execute using the authority of the person who deployed it.
That combination is powerful. It means a teacher could create an endpoint available to anybody on the internet that nevertheless writes into a spreadsheet using the teacher’s own permissions.
The spreadsheet itself might not even be publicly visible. The security problem could instead be the public endpoint sitting in front of it. If the code does not properly authenticate users, validate requests or restrict what can be written, somebody who discovers the endpoint may be able to submit information that the teacher never intended them to submit.
Alternatively, the spreadsheet itself could accidentally be shared too widely. Google Sheets allows a file to be restricted to named users, but it can also be made available to anyone with the link, with different levels of access.
From the teacher’s perspective, both versions might appear to work perfectly. A student completes the quiz, their score appears in the spreadsheet and the teacher sees exactly what they expected to see. Functionally, the application has succeeded.
The difficulty is that functionality and security are different tests.
Vibe coding has removed some useful friction
Traditional web development has never guaranteed secure software. Professional developers make security mistakes too. However, learning to build database-backed applications traditionally exposed developers to concepts such as authentication, authorisation, HTTP requests, server-side code, database permissions, API credentials and deployment environments.
Vibe coding removes much of that friction. That is one of its great strengths, but it can also remove some of the moments at which developers would previously have been forced to think about what their application was actually doing.
A teacher can now say, “Save the student’s name and score to a database”, and an AI may create the database connection. They can say, “Let students log in”, and an authentication system may appear. They can ask the application to call an external API and receive working code without necessarily knowing what credentials are being used, whether those credentials are visible to the browser or whether the API should ever have been accessible from the client in the first place.
The application may work before its creator understands its architecture.
That is an extraordinary change in software development, and schools need to consider its implications.
Professional-looking software is no longer evidence of professional development
There is another reason this particularly concerns me in education. Teachers are excellent at sharing resources. Somebody creates something useful, posts it in a professional community and other teachers understandably want to try it.
Vibe coding means that what gets shared may no longer simply be a worksheet, presentation or quiz. It may be an entire web application.
Imagine seeing a post that says, “I have made a free student assessment dashboard. Upload your class spreadsheet and it automatically creates progress charts.”
You follow the link and find a beautiful application. It has professional typography, graphs, individual student profiles, a polished login page and perhaps even AI-generated feedback.
Twenty teachers underneath the post say how useful it is.
None of that tells you how the application stores data.
The creator could be an experienced software engineer who has carefully implemented authentication, database permissions, encryption, monitoring and data retention policies. They could equally be an excellent classroom teacher who asked an AI assistant to build the entire application and then tested only whether the buttons worked.
The visual difference between those two applications may now be almost impossible to detect.
This is why the appearance of software can no longer be treated as a useful proxy for the expertise behind it.
The security industry has a name for part of this problem
OWASP, the Open Worldwide Application Security Project, has created a Citizen Development Top 10 covering risks associated with low-code, no-code and AI-assisted application development. Its number one risk is Blind Trust.
OWASP describes blind trust as accepting output from an automated system, platform or model without independently verifying its accuracy, integrity or security. It specifically identifies a tendency among citizen developers to assume that platform-generated components or AI-generated code must be secure because they were supplied automatically.
This description closely matches what worries me about vibe coding in schools. The problem is not that a teacher deliberately decides to create an insecure application. The problem is that the teacher may have no visible reason to suspect that there is anything left to check.
The AI says the application is complete. The database works. The login works. The dashboard looks excellent. The security problem may be hidden underneath all of it.
OWASP identifies other citizen-development risks including authorisation mistakes, insecure authentication, sensitive-data leakage, vulnerable components and security misconfiguration. Particularly relevant to schools is its warning that sensitive information can be exposed through public storage, insecure APIs, incorrect permissions or AI-generated logic that sends data somewhere the creator did not expect.
These are exactly the kinds of errors that can occur when somebody connects a classroom application to a spreadsheet, database or external API without fully understanding the security model.
Even the platforms tell developers not to trust generated code blindly
This is not an argument that vibe-coding platforms are inherently insecure. Many of the major platforms are actively building security features and publishing guidance designed to help developers avoid these mistakes.
Google’s guidance for Gemini within Firebase Studio is particularly direct. It tells developers to validate Gemini’s output, warns them not to use untested generated code in production and tells them not to enter personally identifiable information or user data into the AI chat.
That is an important message for schools. One of the world’s largest technology companies is explicitly warning developers that generated code which appears plausible still requires validation before it should be trusted in production.
Lovable also provides security tooling intended to detect common problems in applications, including database access and Row Level Security issues. This is a positive development, but automated security checks do not remove the need to understand what an application is doing. A security scanner can help find known patterns of problems; it does not assume responsibility for the application or the information being placed into it.
This distinction becomes particularly important when the people represented by those records are children.
We already have evidence of what can go wrong
In February 2026, The Register reported security findings concerning an EdTech application built using Lovable. Security researcher Taimur Khan reportedly discovered vulnerabilities that exposed 18,697 user records, including 4,538 student accounts. According to the report, the flaws could potentially allow an unauthenticated attacker to access user records, delete accounts and even grade student submissions.
It would be wrong to conclude from this that applications built with Lovable are automatically insecure. The security problems were in a particular application, and insecure applications can be created using virtually any development technology.
That is precisely why the incident is useful.
The important lesson is that an application can exist online, have thousands of users, perform a genuine educational function and still contain serious security weaknesses. Usage does not prove security, and neither does the reputation of the platform on which the application happens to be hosted.
Student data changes the level of responsibility
There is a significant difference between experimenting with software and processing information about children.
If I create a physics simulation that allows students to adjust the mass of an object and observe its acceleration, very little personal information needs to be involved. If the simulation breaks, it is inconvenient rather than a data breach.
If I change the same application so that students log in, their names are recorded and their performance is stored over time, I have created something fundamentally different. I am now operating a system containing personal information.
The distinction becomes even more important when the information includes assessment results, attendance, behaviour, additional learning needs, pastoral information, photographs or other records about individual children.
The UK’s Department for Education published updated EdTech data-protection guidance in July 2026 that provides a useful illustration of the level of scrutiny schools should apply. It says that when schools begin using educational technology that processes personal information, they need to establish what information is being collected, why it is needed, where it is stored, who can access it, which subprocessors are involved, how long the information is retained and how breaches will be handled. It also says that data protection should be built in by design and by default.
For AI tools, the guidance goes further by saying schools should ensure that products align with their safeguarding and online-security policies. It recommends consulting both the Data Protection Officer and designated safeguarding lead when making decisions about relevant AI systems.
Different countries have different legislation and governance structures, but the underlying principle travels well: once an application starts processing information about children, it deserves a different level of scrutiny from an ordinary classroom resource.
The risk of other people’s code
My experience in Singapore also made me think differently about another aspect of this problem. Teachers do not have to build an insecure application themselves. They simply have to trust one that somebody else has built.
OWASP’s discussion of blind trust extends beyond AI-generated code to templates and reusable components. This matters because citizen development encourages sharing. An insecure pattern created once can easily be copied into many other applications.
Education has an especially strong culture of sharing. Normally that is something to celebrate, but software is different from many of the resources we traditionally share.
The data may travel through several services before reaching its destination. The application may use a database controlled by the creator. An API call may send information to an external company. Analytics tools may collect additional information. A badly configured endpoint may be exposed publicly. None of this is necessarily visible from the webpage itself.
This means schools need to be careful about treating teacher-created software as simply another kind of teaching resource.
Shadow IT can now be created in an afternoon
Schools have been dealing with Shadow IT for many years. A member of staff discovers a useful cloud service and starts using it without going through the normal approval process. A spreadsheet gradually becomes essential to a department even though nobody is formally responsible for maintaining it.
Vibe coding potentially accelerates this dramatically because staff no longer need to find an external service. They can create one themselves.
A teacher might build a simple application for their own class. It works well, so colleagues start using it. More features are added. A database appears. Students create accounts. Eventually hundreds of people depend on an application that started as a weekend experiment.
OWASP identifies exactly this kind of problem in its citizen-development guidance. It warns that rapidly created applications can become widely used while lacking clear ownership, monitoring, lifecycle management or plans for what happens if the original creator stops maintaining them.
For schools, that raises questions that are broader than code security. Who owns the application? Who maintains it when the teacher leaves? Who responds when a dependency becomes vulnerable? Who deletes old student records? Who investigates if suspicious activity occurs?
These are questions associated with running an information system, not simply creating a useful classroom activity.
Blocking Lovable will not solve the whole problem
I can understand why schools may consider restricting some vibe-coding platforms while policies and technical controls catch up. There is a legitimate short-term argument for preventing staff or students from casually connecting consumer development environments to sensitive school information.
However, focusing exclusively on Lovable would misunderstand the scale of the change.
The same kinds of applications can be created using Replit, Bolt, Base44, v0, Firebase and a rapidly growing number of other tools. Traditional hosting and cloud platforms can also be combined with AI coding agents to achieve the same thing.
The technology will continue changing faster than schools can maintain a list of websites to block. The more sustainable response is therefore to regulate the use of data, rather than simply the tool used to create the application.
A practical boundary for schools
I think schools should continue encouraging teachers and students to experiment with vibe coding, but introduce a clear point at which additional review becomes necessary. A useful policy could distinguish between applications that are purely educational resources and applications that process personal information.
As a practical starting point:
- Simulations, quizzes, games and teaching tools that use no identifiable personal data can normally remain in the experimentation category.
- Applications introducing persistent storage, user accounts, external APIs, uploaded files or connections to services such as Google Sheets should trigger a security and data-protection check before real information is used.
- Applications storing identifiable student information should require school approval and clear ownership.
- Sensitive information such as safeguarding, medical, pastoral or confidential behaviour records should never be placed into experimental or unapproved applications.
- Development and testing should use fictional or anonymised information wherever possible.
The exact implementation will differ between schools, but the key idea is to make the boundary visible. Teachers should know when their project has stopped being “a cool thing I made for my lesson” and has started becoming part of the school’s information infrastructure.
Digital literacy now includes questioning software
There is something slightly ironic about all of this. For years we have taught students to become critical consumers of information online. We ask them to consider who wrote something, why it was written, what evidence supports it and whether the source can be trusted.
Vibe coding means we now need similar habits when evaluating software.
A polished interface should prompt us to admire the design, not automatically trust what lies behind it. Before putting real student information into an unfamiliar application, teachers should know who created it, who operates it, where the information is being stored and whether the school has approved that use.
My experience in Singapore has not made me less enthusiastic about vibe coding. If anything, seeing how quickly teachers moved from an idea to genuinely sophisticated applications reinforced how transformative this technology is likely to be.
It did, however, change the way I think we need to teach it.
We cannot teach people only how quickly AI can make software work. We also need to teach them to recognise the moment when making it work is no longer enough.
When an application begins collecting information about children, then it becomes a major safeguarding issue!
