Open source has long been attractive to schools for sensible reasons. It can reduce lock-in, support local control, lower costs and make it easier to inspect how a tool works. Yet the debate sparked by the “Vibe Coding Kills Open Source” paper suggests that a familiar label may no longer tell the whole story. If AI-assisted coding makes it easier to produce more code, more quickly, schools may soon face a harder question: is the software they rely on actually healthy, or simply busy-looking?
For education leaders, this is not just a developer argument about coding culture. It is a procurement and due-diligence issue. If your school uses open-source platforms directly, or buys products built on top of them, weak project health can lead to outages, patching delays, confusing documentation and hidden security risks. If you want a broader picture of how AI-built tools are changing school technology decisions, it helps to read vibe coding explained for teachers alongside this procurement lens.
The paper matters because schools rarely buy software in a vacuum. A timetable tool, safeguarding dashboard, learning platform plugin or reporting workflow may depend on dozens of open-source libraries behind the scenes. Some are mature and carefully maintained. Others may now be receiving large volumes of AI-generated contributions that look productive on the surface but create extra maintenance work underneath.
That matters beyond developer culture because schools depend on stability. A classroom teacher does not care whether a bug came from a human or an AI assistant. They care that the register opens, the assignment syncs, the export works and the data stays secure. Procurement teams should think in the same way. The key question is not whether AI was used, but whether its use has made the software harder to trust over time.
Many school leaders hear “open source” and think of a single app they installed themselves. In reality, the ecosystem is much wider. A school may use open-source content management systems on its website, open-source databases in MIS integrations, open-source libraries in parent communication tools, and open-source machine learning components in newer AI features.
This layered dependence means that risk can sit far below the visible product. A supplier may present a polished interface and a reassuring licence statement, while relying on under-maintained components deeper in the stack. That is one reason due diligence should connect with wider governance work, including AI policy planning and privacy audits. Technical quality, governance and data protection often fail together rather than separately.
AI-assisted coding can be genuinely useful. It can speed up boilerplate work, help developers write tests, explain unfamiliar code and support smaller teams. The concern raised by the paper is not that AI always harms software. It is that fast code generation can encourage shallow review, duplicated logic and a growing pile of changes that no one fully understands.
In schools, reliability problems often appear first as everyday friction. A staff-facing behaviour tool starts timing out after updates. A student revision app produces inconsistent results across devices. A plugin that once worked with your learning platform begins breaking after each release. If maintainers are overwhelmed by a flood of AI-assisted pull requests, small faults can linger and simple fixes can become risky.
Security can also become harder to judge. AI tools may generate code that appears plausible while introducing unsafe dependencies, weak validation or poor error handling. Open source still offers transparency in principle, but transparency is only useful if someone is actively reviewing what is there. A public repository full of code is not the same thing as a well-governed project.
Schools should resist a lazy shortcut: assuming “open source” means safe, ethical or well-maintained. The licence tells you about permissions, not quality. It may allow inspection, modification and redistribution, but it does not guarantee active stewardship, secure defaults or clear accountability.
The reverse is also true. Schools should not panic and abandon open source altogether. Many open-source projects remain among the most dependable tools in education and IT more broadly. The point is to assess project health with more care. This is similar to the wider shift in AI procurement, where leaders increasingly need evidence of governance rather than marketing claims. Our piece on the EU AI Act and school procurement governance explores that broader mindset.
When evaluating open-source software for school use, IT teams should look for signs of sustained stewardship. Healthy projects usually show regular but sensible releases, active issue triage, clear documentation, named maintainers, transparent security processes and evidence that bugs are closed with explanation rather than silence.
It is also worth checking whether the project can say no. A repository full of merged AI-assisted contributions may look lively, but a healthy project often shows disciplined review standards. Look for contribution guidelines, coding standards, test requirements and a visible process for rejecting poor submissions. Good maintenance leaves traces.
Another useful signal is whether the project explains its dependencies. If a tool relies heavily on dozens of barely maintained packages, your risk is higher even if the top-level application appears active. For school leaders already reviewing AI use in teaching and administration, this is part of the same due-diligence habit discussed in what actually changed in school AI practice.
If a supplier uses AI-assisted development, procurement staff do not need to ban that practice. They do need to ask better questions. Useful questions include how AI-generated code is reviewed, whether security scanning is mandatory, how dependency risk is monitored, and who remains accountable for code quality.
Ask suppliers whether they contribute fixes upstream or merely consume open-source components. Ask how quickly they can patch a critical vulnerability in a dependency they do not control. Ask whether they maintain an internal software bill of materials. Ask what happens if a key open-source project becomes effectively unmaintained. Strong suppliers should be able to answer plainly.
For student-facing products, also ask how the supplier checks that AI-assisted changes do not create inconsistent behaviour for younger users or accessibility barriers for pupils with additional needs. For staff-facing tools, ask how updates are tested against real school workflows such as attendance, report writing and safeguarding notes. These practical checks often reveal more than technical jargon.
Ready to Revolutionise Your Teaching Experience?
Discover the power of Automated Education by joining out community of educators who are reclaiming their time whilst enriching their classrooms. With our intuitive platform, you can automate administrative tasks, personalise student learning, and engage with your class like never before.
Don’t let administrative tasks overshadow your passion for teaching. Sign up today and transform your educational environment with Automated Education.
Computing leads and digital learning leads should monitor both classroom and back-office tools. Student-facing platforms need close attention where bugs could affect submissions, revision records or access arrangements. Staff-facing systems need scrutiny where errors could affect reporting, communication or data exports.
There is also a curriculum angle. As AI-assisted coding becomes normal, pupils need to understand why readable code, testing and verification still matter. If you are thinking about how this changes computing education, see the curriculum response on code reading and debugging. The procurement lesson and the curriculum lesson are linked: more generated code increases the value of human judgement.
A simple red-amber-green approach can help schools make consistent decisions.
A green project has active maintainers, recent releases, clear documentation, open security reporting, meaningful tests, transparent dependency management and evidence of careful review. A supplier using it can explain how updates are validated in school contexts.
An amber project may still be usable, but it needs caution. Documentation may be patchy, maintainers may be few, issue response may be slow or dependencies may be sprawling. In these cases, schools should ask for mitigation plans, support arrangements and rollback options.
A red project shows warning signs that should pause procurement. These include long-unanswered security issues, abandoned documentation, unexplained bursts of code, no visible testing, unclear ownership, broken release processes or supplier evasiveness about AI-assisted development practices.
The sensible response is not to abandon open source. It is to procure more intelligently. Open source still offers flexibility, transparency and resilience when projects are genuinely healthy. Schools should update due-diligence processes so that project stewardship, dependency risk and review discipline sit alongside licensing and price.
This may also mean reviewing existing tools, not just new purchases. A lightweight annual check can be enough to spot drift before it becomes a crisis. If you are refreshing governance more broadly, connect this work with your acceptable use policy review so expectations around AI-assisted development and supplier transparency are written down.
Over the next year, expect more suppliers to mention AI-assisted development openly, and more open-source projects to publish policies on how generated code is handled. Expect security questions about dependencies to become more common in tenders. Expect schools to need clearer evidence, not broader promises.
The strongest organisations will not be those that reject AI-assisted coding outright. They will be the ones that can show disciplined review, responsible maintenance and honest communication about risk. In education, that matters because software is never just software. It shapes teaching time, staff workload and pupil experience.
May your next software review be clearer, calmer and far more evidence-based. The Automated Education Team
Microsoft Build 2026 brought a fresh wave of Copilot announcements, but …
Summer term is often the last realistic window for school leaders and AI …
Schools do not need a whole-school AI rollout to learn what works. In many …
Once the papers are marked, many departments want feedback that is sharper …
Primary assessment week can feel intense, especially when SATs and spring …
Exam week often creates pressure to do more, faster, with less time to …
Many school AI rules still rely on vague disclosures such as “I only used …
AI voice tools for modern foreign languages have improved sharply by 2026, …
Spring assessment season puts pressure on teachers, pupils and families to …
Uus arutelulaine artikli “Vibe Coding Kills Open Source” ümber tõstatab koolide jaoks praktilise …
En ny våg av diskussion kring rapporten ”Vibe Coding Kills Open Source” väcker en praktisk fråga för …
Uusi keskusteluaalto “Vibe Coding Kills Open Source” -paperin ympärillä nostaa esiin käytännöllisen …