Vibe Hacking: AI's New Cybersecurity Craze and Why Fundamentals Matter

AI can draft a script, explain a vulnerability, or turn a plain-language request into a polished security workflow in seconds. But when the person using it cannot explain the system, verify the result, or recognise a dangerous assumption, speed becomes a liability. The future belongs to practitioners who are AI-augmented, not merely AI-enabled.

A new phrase is appearing around AI-assisted development: vibe coding, the practice of describing an outcome to an AI tool, accepting generated code, and iterating until it seems to work. A related pattern is emerging in security. Call it vibe hacking: asking AI to produce a scanner, test plan, exploit explanation, detection rule, or report, then trusting the fluent result without understanding the systems underneath it.

AI-assisted work is not the problem. The problem is mistaking a convincing output for competence, evidence, or authorisation. In cybersecurity, the cost of that mistake is paid by real organisations and the people whose data and services they depend on.

1. What vibe hacking looks like

Vibe hacking is not a formal discipline or a particular tool. It describes a habit: using AI to move directly from an idea to an action while skipping the understanding and verification that make security work trustworthy. Someone might ask a model to generate a port checker, review an API, write a cloud policy, or interpret a proxy trace. They then run or repeat the answer because it looks professional, not because they can explain what it does or why its conclusions follow.

That habit can appear at any stage. A generated script may mishandle redirects or fail open on an error. A proposed API test may confuse authentication with authorisation. A security finding may describe a theoretical weakness without showing that it exists in the target application. A detection rule may look plausible but match normal activity or miss the behaviour it was meant to detect.

The distinction is not whether AI wrote the first draft. Experienced engineers have always used documentation, libraries, colleagues, and automation. The distinction is whether the practitioner can inspect, challenge, test, and take responsibility for the result. If the answer is no, the workflow has outsourced judgment along with typing.

2. What we heard in interviews

In interviews we conducted, we encountered candidates presenting cybersecurity as a new career direction with CVs containing security titles, tool names, and technical phrases. Some struggled to explain basic computing concepts, network protocols, or the inner workings of web applications and APIs. We also heard examples of AI-generated keywords being added to CVs to make a career pivot appear more technically grounded than the candidate's practical experience showed.

These are qualitative observations from our interviews, not a representative survey of candidates or a measure of how common this is across the industry. They are still worth taking seriously. When a CV lists a tool, a framework, and an AI speciality, a hiring team needs a way to distinguish familiarity with the vocabulary from the ability to reason through a real system.

There is nothing wrong with changing careers or using AI to learn. Cybersecurity needs people with varied backgrounds, and an entry-level candidate should not be expected to know everything. The concern is a mismatch: presenting generated terminology as hands-on experience, then being unable to explain the basic concepts that the terminology depends on.

3. Why fundamentals matter more in an AI-assisted workflow

Security work is applied computing. A practitioner does not need to memorise every protocol specification, but they do need a working mental model of the systems they assess. Fundamentals let them ask better questions, recognise when an answer is incomplete, and see when an apparently harmless test could affect a real user or service.

Computing and operating systems

Understand how processes execute, how files and permissions are managed, how memory and input/output work at a useful level, and how applications depend on the operating system. This helps make sense of logs, endpoint behaviour, command output, and the difference between what a program claims to do and what it actually does.

Networking and protocols

Know the purpose of DNS, IP addressing, routing, TCP, TLS, and common application protocols. Be able to follow a connection from name resolution through transport and encryption to an application response. Without that foundation, an error message, a timeout, or a certificate warning can be misread as a security finding when it may be a configuration, routing, or client issue.

Web applications and APIs

Understand the browser-server relationship: requests and responses, methods, headers, cookies, sessions, origins, TLS, and the roles of the client and server. For APIs, understand resources, schemas, authentication, authorisation, state, and how identity and permissions should be enforced on each operation. Those concepts are what make it possible to reason about a test result rather than simply replay a suggested request.

Consider a response that returns data successfully. Is the user authenticated? Is that user authorised to access this particular record? Is the response cached? Does the application intentionally share it? What evidence would distinguish a real access-control failure from a test setup mistake? AI can help enumerate questions, but the practitioner needs enough understanding to select the relevant ones and interpret the evidence.

4. The organisational risk is more than a bad interview

When foundational knowledge is missing, AI can amplify the gap by increasing output volume and confidence at the same time. A person can generate more tests, code, findings, and recommendations than they can safely review. For an organisation, that can create several kinds of risk:

False confidence: fluent reports can make unsupported claims look validated, diverting attention from real weaknesses.
Operational disruption: generated commands or tests may exceed the intended scope, use unsafe defaults, or put availability at risk.
Missed vulnerabilities: a checklist may cover familiar tool outputs while missing application-specific business logic and trust boundaries.
Data exposure: prompts may include customer information, source code, credentials, or internal architecture without an appropriate data-handling review.
Fragile dependency: a team may be unable to debug or maintain scripts and procedures that nobody can explain once the AI tool changes or becomes unavailable.
Hiring and capability debt: keyword-led selection can place people in roles before they can carry the responsibilities those roles require.

These risks are not an argument against AI. They are a reminder that security is an accountability function. A model does not own the scope, understand the business impact, or answer to the people affected by a mistake. The professional using it does.

5. AI-enabled is not the same as AI-augmented

An AI-enabled practitioner has access to AI tools and can prompt them. An AI-augmented practitioner brings domain knowledge to the task, uses AI to extend their capacity, and independently checks the output before acting on it. The difference is judgment and accountability, not the sophistication of the prompt.

A useful rule

Let AI accelerate work you understand. Use it to expose assumptions, explain unfamiliar material, draft routine code, compare alternatives, or suggest tests. Keep authorisation, execution controls, evidence validation, and consequential decisions with accountable people and trusted systems.

An augmented workflow might ask AI to explain an unfamiliar protocol field, then confirm the explanation against a specification and a packet capture. It might use a model to suggest test cases, then review each case against the application design and execute only within written scope. It might draft a detection query, then replay it against representative benign and malicious test data before deployment.

In each example, AI contributes speed and breadth. The practitioner contributes context, verification, and responsibility. That combination is more valuable than either unreviewed automation or a refusal to use useful tools.

6. How to build durable skills while using AI

New entrants do not need to wait until they know everything before using AI. They do need a deliberate learning loop in which the tool supports understanding instead of hiding the gaps.

Learn the underlying model: study computing, operating systems, networking, HTTP, identity, and application architecture. Build a working mental model before collecting tool names.
Practise in controlled environments: use local applications, intentionally vulnerable training labs, sample logs, and synthetic data. Keep practice authorised and separate from production systems.
Trace one complete request: follow a browser action through DNS, connection setup, TLS, HTTP, application logic, data access, and the response. Explain where identity and permissions are checked.
Use AI as a tutor: ask it to explain concepts at different levels, quiz you, compare two hypotheses, or identify assumptions in your explanation. Check important claims against primary documentation.
Reproduce and verify: when AI suggests a test or diagnosis, state what evidence would confirm or disprove it. Run the smallest safe check and record what actually happened.
Own the code: read generated scripts line by line, understand inputs and side effects, test failure cases, and be able to modify or remove the code without asking the model to explain every change.
Keep an evidence trail: distinguish observations from hypotheses, note tool and model versions where relevant, and record how conclusions were validated.

A useful measure of progress is not how many AI tools someone can name. It is whether they can explain a system clearly, identify uncertainty, choose a proportionate test, and revise their conclusion when the evidence contradicts it.

7. How employers can assess capability fairly

Employers can reduce keyword bias by making interviews practical, transparent, and appropriate to the level of the role. Ask candidates to explain a request-response flow, diagnose a simple network or application issue, or review a short piece of code. For AI-assisted work, ask what the candidate prompted, what they changed, what they verified, and what they would not trust.

Assess reasoning as well as the final answer. A candidate who says, “I do not know yet; here is what I would check,” may demonstrate more security judgment than someone who offers a confident but unsupported conclusion. Give career changers a fair opportunity to show how they learn, and be explicit about which skills are essential on day one and which can be developed with supervision.

For organisations adopting AI, pair access to tools with clear boundaries: approved data handling, authorised environments, code review, evidence requirements, and a route to escalate uncertain results. Training should include both how to use AI and how to recognise when it is wrong, incomplete, or operating outside the task.

The future is hands-on and AI-augmented

Vibe hacking captures the temptation to skip the hard part: understanding what a system is doing and proving what a security result means. AI makes that shortcut easier to take, but it also makes sound practitioners more effective. The difference is whether the tool is building on knowledge or concealing its absence.

Hands-on knowledge remains essential in an AI-shaped security industry. The next generation of engineers should be comfortable using AI, but they must also understand computing, protocols, networking, web applications, and APIs well enough to verify the work. We do not need a workforce that is merely AI-enabled. We need one that is technically grounded, curious, and AI-augmented.