Temporarily unstable
Temporarily unstable
Compliance in Vibe Coding and AI-Assisted Software Development
Vibe coding has made it possible for one person to develop software that previously might have required a small development team. With AI tools, a freelancer can create a prototype, build user interfaces, write documentation, generate tests, find bugs and, in some cases, produce a fully functioning application in a remarkably short time.
However, this does not change responsibility for the finished product. If you release a Windows application, an Android app, a web application or an AI-based tool, the question is not simply: Does the software work?
You should also ask: Do I know what the software does, why it does it, what data it processes, which components it uses, what risks exist, and can I document that I have made a serious effort to develop it responsibly?
Compliance does not necessarily mean extensive bureaucracy. For a freelancer or solo developer, it is about establishing a proportionate and documented development practice.
AI may write code. AI must not take over the developer's responsibility.
1. Legal Compliance
Software does not exist outside the law. Which rules apply depends on the product, its users, the market and the data being processed. A simple language-learning app without user registration has a very different risk profile from a system that processes customer data, emails, health information or information about children.
☐ Have I described what the product actually does?
☐ Have I identified who the users are?
☐ Have I identified the countries in which the product is offered?
☐ Have I assessed whether GDPR applies?
☐ Do I know which personal data the product processes?
☐ Do I have a lawful basis for processing that data?
☐ Have I documented the purpose of the data processing?
☐ Do I collect only the data that is necessary?
☐ Can users have their data deleted where required?
☐ Have I defined how long data is retained?
☐ Do I know where data is physically or organisationally processed?
☐ Do I use external data processors or cloud services?
☐ Are the necessary data processing agreements in place?
☐ Does the product have an appropriate privacy policy?
☐ Does the product use cookies, analytics or tracking?
☐ Are rules concerning children relevant?
☐ Are consumer protection rules relevant?
☐ Are accessibility requirements relevant?
☐ Is EU AI regulation relevant?
☐ Have I identified areas where professional legal advice is required?
2. Privacy and Data Protection
Privacy should be part of the design. A useful approach is privacy by design combined with data minimisation: if the software does not need a particular piece of information, consider not collecting it at all. The less sensitive data a solo developer stores, the smaller both the security burden and the potential consequences of a data breach.
☐ Have I created an inventory of all data collected by the software?
☐ Do I know why each type of data is necessary?
☐ Can any data collection be eliminated?
☐ Can data be processed locally instead of in the cloud?
☐ Does the user know what information is collected?
☐ Does the user know why the information is collected?
☐ Does the user know whether data is sent to third parties?
☐ Does the software send data to AI services?
☐ Have I investigated how the AI provider processes data?
☐ Do logs contain personal data?
☐ Can logs be anonymised?
☐ Have I defined data retention periods?
☐ Can data be deleted?
☐ Can relevant data be exported?
☐ Are backups included in the deletion policy?
☐ Is test data free from unnecessary personal information?
☐ Do I avoid using production data in the development environment?
☐ Are privacy settings understandable?
☐ Have I documented the data flow?
☐ Have I completed a privacy review before release?
3. Software and Security Compliance
AI can generate code that works while still containing security vulnerabilities, particularly in authentication, file handling, databases, APIs, network communication and user input. AI-generated code must therefore be understood, reviewed and tested.
☐ Are API keys stored outside the source code?
☐ Are passwords and tokens protected?
☐ Are .env and similar files excluded from Git?
☐ Have I checked the repository for previously committed secrets?
☐ Is user input validated?
☐ Are file uploads restricted and validated?
☐ Are secure connections used?
☐ Is authentication implemented correctly?
☐ Is authorisation separated from authentication?
☐ Do users have only the permissions they need?
☐ Are errors handled without exposing sensitive information?
☐ Do logs contain passwords, tokens or other secrets?
☐ Is the database adequately protected?
☐ Is backup available where required?
☐ Has restoration from backup been tested?
☐ Are dependencies kept up to date?
☐ Are dependencies scanned for known vulnerabilities?
☐ Have debugging functions been removed from production?
☐ Have I carried out a security review before release?
☐ Do I know what to do if a security vulnerability is discovered?
4. Dependencies, Open Source and Licences
Software rarely consists solely of your own code. Even a small project may use libraries, frameworks, fonts, images, icons, databases, APIs and AI services. Vibe coding can make this less transparent because an AI assistant may install a dependency without the developer consciously evaluating it.
☐ Do I have a list of the major dependencies?
☐ Do I know why each dependency is used?
☐ Have unnecessary dependencies been removed?
☐ Do I know their licences?
☐ Are they permitted for commercial use?
☐ Do any licences require attribution?
☐ Does any licence require disclosure of source code?
☐ Have I documented third-party components?
☐ Do I know where the images come from?
☐ Do I know where the icons come from?
☐ Do I know where the fonts come from?
☐ Do I have the necessary rights to the test data?
☐ Do I have the necessary rights to training or example texts?
☐ Have I reviewed the terms of external APIs?
☐ Have I reviewed the terms of AI services?
☐ Are version numbers recorded?
☐ Can the project's dependencies be reproduced?
☐ Have I checked for known vulnerabilities?
☐ Can problematic components be replaced?
☐ Can I explain which major third-party components the product depends on?
5. A Documented Development Process
This is an important difference between experimental vibe coding and professional AI-assisted development. There is nothing inherently wrong with starting with a prototype. The problem arises when a prototype becomes production software without a point at which the project moves from experimentation to controlled development.
☐ Is there a description of the product's purpose?
☐ Are functional requirements documented?
☐ Are non-functional requirements documented?
☐ Is the project scope defined?
☐ Is the architecture documented?
☐ Are important design decisions documented?
☐ Is version control used?
☐ Are commits meaningful?
☐ Are branches used where appropriate?
☐ Can an earlier version be recreated?
☐ Are version numbers used?
☐ Are release notes or a changelog maintained?
☐ Are major changes documented?
☐ Are known limitations documented?
☐ Are significant bugs recorded?
☐ Is documentation updated together with the code?
☐ Is the build process documented?
☐ Can the project be built from a clean installation?
☐ Could another technically competent person understand the basic project structure?
☐ Are there clear criteria for determining when a version is ready for release?
6. Testing, Validation and Quality Assurance
The fact that an application starts without errors does not mean that it has been tested. Testing should determine whether the software does what its requirements say and whether it behaves appropriately when something goes wrong. AI can assist with tests, but human validation remains important.
☐ Is there a test strategy?
☐ Have critical functions been tested?
☐ Are unit tests used where appropriate?
☐ Are integration tests used where appropriate?
☐ Have user flows been tested?
☐ Has invalid input been tested?
☐ Have empty values been tested?
☐ Have boundary conditions been tested?
☐ Have failure scenarios been tested?
☐ Has loss of internet connectivity been tested where relevant?
☐ Have missing files or resources been tested?
☐ Have permissions been tested?
☐ Has installation been tested?
☐ Has upgrading from an earlier version been tested?
☐ Has uninstallation been tested where relevant?
☐ Have relevant devices or screen sizes been tested?
☐ Have regression tests been performed after major changes?
☐ Are test results documented?
☐ Have critical defects been corrected before release?
☐ Has the final packaged version been tested, rather than only the development version?
7. AI as a Development Tool
There is an important distinction between software developed with the assistance of AI and software that itself uses AI. If Codex or another AI tool helps write code, this does not in itself make the finished product an AI system. AI use should nevertheless be managed professionally.
☐ Do I know which AI tools are being used?
☐ Do I know which parts of the development process they assist with?
☐ Am I sending confidential information to AI services?
☐ Am I sending personal data to AI services?
☐ Am I sending customers' source code or documents to AI services?
☐ Do I have the right to do so?
☐ Is AI-generated code reviewed?
☐ Is AI-generated code tested?
☐ Are AI-generated dependency recommendations checked?
☐ Are suggested APIs and functions verified?
☐ Is security-critical code reviewed separately?
☐ Are major refactorings accepted only after review?
☐ Can I explain the software's core functionality without relying on AI?
☐ Are important architectural decisions documented?
☐ Is AI-generated documentation verified?
☐ Are AI-generated legal claims checked separately?
☐ Are facts verified rather than merely well written?
☐ Is human approval required before release?
☐ Can the project continue without the specific AI session?
☐ Is it clear that responsibility for the product remains with the developer?
8. When AI Is Part of the Product
If the product itself uses a language model, image model, classification model or another AI system, additional questions arise. Users should be able to understand when AI is used, what it is used for and what significant limitations may exist.
☐ Is it documented where the product uses AI?
☐ Does the user know when AI has a significant influence on the output?
☐ Is the AI function clearly described?
☐ Is the model provider known?
☐ Are relevant model versions recorded?
☐ Do I know which data is sent to the model?
☐ Is personal data protected?
☐ Can sensitive information be avoided?
☐ Has the risk of hallucinations been assessed?
☐ Is significant AI output validated?
☐ Is there human oversight where the consequences require it?
☐ Can users correct or override AI-generated results?
☐ Have automated decisions been identified?
☐ Have bias and discrimination risks been considered?
☐ Have misuse scenarios been considered?
☐ Are relevant limitations communicated?
☐ Has the relevance of the EU AI Act been assessed?
☐ Has the applicable risk classification been investigated where relevant?
☐ Can the AI functionality be disabled if necessary?
☐ Is there a procedure for incorrect or harmful AI-generated results?
9. Ethics Beyond Compliance
Legal software is not necessarily good software. Compliance often defines minimum requirements. Ethics asks: Should we do something simply because we can? This is particularly relevant to AI, surveillance, behavioural analysis, children, personalisation and large-scale data collection.
☐ Does the product solve a genuine problem?
☐ Is the real purpose of the product clear to the user?
☐ Am I collecting information simply because it is technically possible?
☐ Does the design respect the user's privacy?
☐ Are the user's choices genuinely voluntary?
☐ Do I avoid manipulative dark patterns?
☐ Is it easy to say no?
☐ Is it easy to change one's mind?
☐ Can users understand the consequences of their choices?
☐ Are children or vulnerable people involved?
☐ Could the product be used for surveillance?
☐ Could the product be misused?
☐ Have I considered unintended consequences?
☐ Could algorithms disadvantage particular groups?
☐ Are automated assessments fair?
☐ Am I presenting AI as more authoritative than it really is?
☐ Can users distinguish between facts and AI-generated assessments?
☐ Does the product respect user autonomy?
☐ Would I personally accept the same data processing as a user?
☐ Could I publicly explain and defend the product's fundamental design choices?
Transparency does not mean that all source code must be public. It means not hiding material information from users, such as data collection, AI use, external services or significant limitations.
☐ Is the developer or company identifiable?
☐ Is contact information available?
☐ Is the purpose of the product described?
☐ Are its main functions described accurately?
☐ Does marketing avoid exaggerated claims?
☐ Are significant limitations described?
☐ Is the use of AI disclosed where relevant?
☐ Is data collection explained?
☐ Is third-party data processing explained?
☐ Are users' rights explained clearly?
☐ Is a version number available?
☐ Is a change history available where appropriate?
☐ Are known serious issues documented?
☐ Can users report errors?
☐ Can users ask questions about privacy?
☐ Can users identify AI-generated content where necessary?
☐ Are automated decisions explained where required?
☐ Is the documentation written in understandable language?
☐ Are technical and legal claims accurate?
☐ Can I substantiate the main claims I make about the product?
A solo developer cannot replicate a large corporation's compliance organisation, nor should that be the objective. Compliance should be proportionate to risk. A local desktop utility with no internet access and no personal data normally requires less governance than a cloud service processing large amounts of personal data.
☐ Have I classified the project's level of risk?
☐ Do I know which areas I can handle myself?
☐ Do I know when external expertise is necessary?
☐ Have I separated the prototype from the production version?
☐ Do I have a backup of the project?
☐ Is the repository secure?
☐ Is access to development systems protected?
☐ Is customer data separated from test data?
☐ Do I have a simple release procedure?
☐ Do I have a testing checklist before release?
☐ Do I have a security checklist before release?
☐ Do I have a privacy checklist before release?
☐ Do I have a licence checklist before release?
☐ Have I documented significant AI tools?
☐ Do I have an overview of subscriptions and external services on which the product depends?
☐ Do I know what happens to users if I discontinue the product?
☐ Can data be exported or handed over where necessary?
☐ Do I have a procedure for serious defects?
☐ Do I have a procedure for security incidents?
☐ Can I document why I considered the product safe and responsible enough to release?
A small project does not need a thousand-page quality management system. A practical solution is a /docs directory containing, for example, README.md, REQUIREMENTS.md, ARCHITECTURE.md, DATA-FLOW.md, PRIVACY.md, SECURITY.md, DEPENDENCIES.md, AI-USAGE.md, TESTING.md, RELEASE-CHECKLIST.md and CHANGELOG.md.
Ten short, maintained documents are more valuable than a 200-page compliance system that nobody keeps up to date.
☐ The requirements for this version are defined.
☐ The correct code has been committed.
☐ The repository is clean.
☐ The correct version has been tagged or otherwise identified.
☐ The project can be built reproducibly.
☐ Automated tests pass.
☐ Critical user flows have been manually tested.
☐ The final installer, APK or package has been tested.
☐ Known critical bugs have been resolved.
☐ Dependencies have been checked.
☐ Licences have been checked.
☐ Secrets have been checked.
☐ Security has been reviewed.
☐ Privacy has been reviewed.
☐ AI functionality has been reviewed.
☐ Ethical risks have been assessed.
☐ Documentation corresponds to the actual version.
☐ The changelog has been updated.
☐ Backup or rollback is possible.
☐ The developer has explicitly approved the release.
Vibe coding is not necessarily the opposite of professional software development. It can be the beginning of it.
AI allows a single freelancer to experiment faster and develop software that previously would have required significantly greater resources. But precisely because productivity increases so dramatically, control points become necessary.
Idea → vibe coding → prototype → requirements → structured development → testing → compliance review → release → maintenance
There is no need to document every prompt or experiment. However, when a prototype begins to turn into a product, requirements, architecture, security, privacy, dependencies and testing should gradually become formalised.
AI can assist with almost all of these tasks. It can write test cases, search for security problems, maintain documentation, analyse dependencies, check a release against a checklist and compare implementation with requirements.
But one task should not be delegated: the decision that the product is responsible and safe enough to release.
For a freelancer, the goal is therefore not enterprise compliance in miniature. The goal is a documented, proportionate and reproducible process demonstrating that the product was not simply generated, but understood, reviewed, tested and approved.
.