Forem: Patrick Cornelißen

Vibe coding: where it helps and where it breaks

Patrick Cornelißen — Sun, 03 May 2026 10:00:00 +0000

Vibe coding is one of those terms that sounds unserious until you notice how many people are actually doing it.

The basic idea is simple: describe what you want, let an AI coding tool generate the implementation, run it, adjust the prompt, and keep going.

It can feel magical. It can also go wrong very quickly.

What vibe coding is good at

Vibe coding works best when the problem is visible and forgiving:

small prototypes
internal tools
UI experiments
scripts
throwaway demos
first drafts of a feature

In those cases, speed matters more than perfect architecture. You can see whether the result works, and mistakes are usually cheap.

Where it breaks

The approach becomes risky when the code has to survive contact with real users.

Typical failure modes:

hidden edge cases
inconsistent state management
weak error handling
missing tests
security issues
duplicated logic
code that "works" but nobody understands

The danger is not that the AI writes bad code every time. The danger is that it often writes plausible code. Plausible code is harder to distrust.

The human job changes

With vibe coding, the developer's role shifts. You spend less time typing boilerplate and more time judging direction.

You still need to decide:

what should be built
which constraints matter
whether the implementation fits the architecture
which tests are missing
whether the code is maintainable

If you skip that judgment, the speed advantage turns into technical debt.

A better workflow

Vibe coding becomes more useful when it is paired with review loops:

1. Ask the AI to implement a small slice.
2. Run the tests.
3. Ask the AI to explain the changes.
4. Review the diff yourself.
5. Ask for tests and edge cases.
6. Refactor before moving on.

The point is to keep each step small enough that you can still understand the result.

The real skill

The real skill is not prompting the model into writing more code. It is knowing when to stop and inspect.

Good questions:

What assumptions did the model make?
What happens when input is empty or invalid?
Which part of this code would be hard to change later?
Is there a simpler design?
Would I be comfortable reviewing this in a pull request?

If the answer is no, the workflow is moving too fast.

Bottom line

Vibe coding is useful as a creative and exploratory mode. It is not a replacement for engineering discipline.

Use it to get moving. Do not use it as an excuse to stop reading the code.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/grundlagen/vibe-coding/

From prompt engineering to context engineering

Patrick Cornelißen — Sat, 02 May 2026 10:00:00 +0000

For a long time, "prompt engineering" meant finding the right words. Better instructions, clearer examples, stricter output formats.

That still matters, but it is no longer the whole story. The more useful shift is from prompt engineering to context engineering.

Prompting is only one layer

A good prompt can improve an answer. But many failures do not come from bad wording. They come from missing context.

The model does not know:

your codebase conventions
the current ticket
the relevant API documentation
your team's security rules
which files changed
what "done" means in this workflow

If that context is missing, the model has to guess. Better phrasing will not fix that.

What context engineering means

Context engineering is the practice of deliberately shaping what the AI sees before it acts.

That includes:

system instructions
project documentation
examples of good output
relevant source files
test results
tool output
business constraints
role-specific requirements

The goal is not to dump everything into the context window. The goal is to provide the smallest useful context that lets the model make the right decision.

A simple example

A weak request:

Review this code.

A better prompt:

Review this TypeScript code for bugs and readability.

A context-engineered workflow:

Review the diff for this pull request.
Use our TypeScript conventions from AGENTS.md.
Pay special attention to error handling and tests.
Include only findings that could affect behavior, security or maintainability.
Reference file paths and lines.

The last version is not just better wording. It tells the model what information matters and what kind of output is useful.

Context beats cleverness

Teams often spend too much time tuning a single prompt and too little time improving the surrounding workflow.

Useful context usually comes from boring places:

a clear project README
a short architecture note
well-named files
test output
a current ticket description
examples of accepted work

AI tools become much stronger when these sources are easy to retrieve.

The risk of too much context

More context is not always better. Huge context dumps can make the model slower, more expensive and less focused.

Good context has shape:

include what is relevant
exclude stale information
prefer source files over summaries when precision matters
prefer summaries when the details are not needed
keep instructions consistent

The skill is deciding what the model needs for this task, not what might be interesting.

Practical team pattern

One useful pattern is to move repeated instructions out of chat and into versioned files:

coding conventions
review checklists
release note format
security rules
writing style
deployment steps

Then the AI tool can load those instructions when needed. This is more reliable than copying an old prompt from Slack.

Bottom line

Prompt engineering is still useful, but it is only one part of the workflow. The bigger advantage comes from giving AI systems the right context at the right moment.

That is what makes the difference between a clever answer and a useful result.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/grundlagen/prompt-engineering-2026/

MCP explained: how AI tools connect to real systems

Patrick Cornelißen — Fri, 01 May 2026 10:00:00 +0000

Most AI tools started as isolated chat windows. You pasted in a prompt, copied the answer back out, and hoped the model had enough context.

That model does not scale well. Modern AI agents need access to tools, files, APIs and structured context. That is the problem the Model Context Protocol, or MCP, tries to solve.

What MCP is

MCP is a protocol for connecting AI applications to external tools and data sources. Instead of every AI app inventing its own plugin system, MCP defines a shared way for tools to expose capabilities to models.

In practice, an MCP server can provide things like:

database queries
file access
issue tracker data
browser automation
internal documentation search
custom business tools

The AI client can then discover and call those tools through a common interface.

Why this matters

The interesting part is not "the model can call an API". That has been possible for a while. The interesting part is standardization.

Without a shared protocol, every integration becomes a one-off bridge:

AI client A -> custom GitHub integration
AI client B -> different GitHub integration
AI client C -> yet another GitHub integration

With MCP, the shape becomes cleaner:

AI client -> MCP server -> tool or data source

That does not remove all complexity, but it gives teams a better integration boundary.

A useful mental model

Think of MCP servers as adapters between an AI agent and a real system.

The model should not know every detail of your internal API. It should know that a tool exists, what it does, what parameters it accepts, and what kind of result it returns.

That separation is important. It makes tool access easier to review, test and restrict.

Where MCP helps

Good MCP use cases are usually context-heavy:

"Summarize the open bugs for this release."
"Find the related pull requests for this Jira ticket."
"Check whether this API route has documentation."
"Create a draft changelog from merged commits."
"Look up our internal policy before answering."

In all of these examples, the model is useful only if it can reach the right context.

The security angle

MCP also creates a new security boundary. A tool server can expose sensitive data or actions, so teams need to treat it like infrastructure, not like a harmless prompt helper.

At minimum, think about:

which tools are exposed
which actions are read-only
which actions mutate state
how credentials are stored
whether the model can reach production data
how tool calls are logged

The protocol makes integration easier. It does not make governance optional.

When to build an MCP server

Do not build one just because MCP is trendy. Build one when the same tool or data source should be available to multiple AI clients or workflows.

Good signs:

the integration will be reused
the data source is important enough to control
tool behavior should be logged or tested
the team wants one maintained integration instead of many ad hoc scripts

If it is a one-off experiment, a small script may be enough.

Bottom line

MCP is useful because it gives AI tools a more stable way to interact with the systems teams already use. The biggest value is not novelty. It is making context and tool access explicit enough to maintain.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/grundlagen/mcp-model-context-protocol/

AI workflows with n8n: practical automation for teams

Patrick Cornelißen — Thu, 30 Apr 2026 09:24:25 +0000

Most AI tools are useful in isolation: write text, review code, summarize a document, classify a ticket. The bigger productivity jump starts when AI becomes part of an existing workflow.

That is where n8n gets interesting. It is an open-source workflow automation platform, similar in spirit to Zapier or Make, but with two important differences: it can be self-hosted, and its AI features are deep enough for real operational workflows.

Why n8n is worth a closer look

n8n is built around visual workflows: triggers, nodes, branches, API calls and data transformations. For AI work, that means you can place a model call exactly where it belongs instead of treating AI as a separate chat window.

Current reasons teams look at n8n for AI automation:

Self-hosting for teams that cannot send workflow data through another SaaS platform
More than 700 integrations, including Slack, Jira, GitHub, Notion and Google Workspace
AI nodes for OpenAI, Anthropic, LangChain, vector databases and agent workflows
Human-in-the-loop steps where a workflow can pause for approval
Pricing based on workflow executions rather than every single step

For teams in regulated environments, the self-hosting option is the big one. API keys, customer data and workflow state can stay on infrastructure the team controls.

Example 1: AI-assisted support ticket routing

A simple but useful automation:

Trigger: New ticket in the helpdesk

Step 1: Claude classifies the ticket
  - Category: bug, feature request, question, complaint
  - Priority: high, medium, low
  - Affected product area

Step 2: If priority is high
  - Send a Slack message to the on-call team
  - Update the ticket priority in the helpdesk

Step 3: Generate a first response draft
  - Pause for human review
  - Send only after approval

The important part is not the model call itself. It is the handoff around it: routing, notification, review and a clear approval point before anything reaches a customer.

Example 2: Sprint review summaries

Another practical workflow:

Trigger: Every Friday at 16:00

Step 1: Pull completed tickets from Jira
Step 2: Pull related pull requests and commits from GitHub
Step 3: Ask an AI node to produce a sprint summary
  - What shipped?
  - What is still open?
  - What risks should the team discuss?
Step 4: Post the summary to Slack or Teams

This does not replace the sprint review. It removes the boring preparation work so the meeting can focus on decisions.

Example 3: A lightweight RAG pipeline

n8n can also orchestrate document workflows:

Trigger A: New document in Google Drive or Confluence

Step 1: Extract the document text
Step 2: Split it into chunks
Step 3: Create embeddings
Step 4: Store them in a vector database

Trigger B: User asks a question

Step 1: Embed the question
Step 2: Retrieve matching document chunks
Step 3: Answer with context and source references

This is not a replacement for a purpose-built knowledge platform. But for internal workflows, prototypes and small team automations, it can be enough.

Human-in-the-loop is the feature that matters

AI workflows become risky when every model output turns directly into an action. n8n's human-in-the-loop pattern is useful because it lets the workflow pause before sensitive steps.

Good candidates for approval gates:

AI-written emails to customers
CRM or database updates
Financially relevant decisions
Ticket closures or priority changes
Anything that could create legal, security or support fallout

The best AI automation is not fully autonomous everywhere. It is selective: automate routine judgment, pause at the points where accountability matters.

Role-specific ideas

Developers

n8n is API-first and workflows can be exported as JSON. That makes versioning, review and deployment possible. Custom nodes can be written in TypeScript, and LangChain integrations make more complex agent workflows possible.

Project managers

Many useful workflows do not require code: status reports, meeting summaries, sprint review preparation and reminders. The visual editor is approachable enough to prototype without waiting for engineering capacity.

Product owners

Product teams can collect feedback from support tickets, app reviews and community channels, classify it with AI and turn it into a weekly product insight report.

QA

QA teams can summarize CI results, detect regressions, create tickets automatically and notify the right channel when a test signal needs attention.

n8n vs. Zapier vs. Make

Criterion	n8n	Zapier	Make
Self-hosting	Yes	No	No
AI depth	Strong, including LangChain and agent workflows	Useful but less deep	Good ChatGPT-style integrations
Pricing model	Per workflow execution	Per task	Per operation
Open source	Yes, fair-code model	No	No
Learning curve	Medium to high	Low	Low to medium
Human-in-the-loop	Native pattern	Limited	Limited

When n8n is a good fit

n8n is strongest when a team needs flexible automation, controlled data flows and enough technical depth to go beyond simple "when this happens, post that" workflows.

It is probably not the fastest tool for a single lightweight SaaS automation. Zapier or Make may still be quicker for that. But once AI enters the workflow, especially with private data or approval gates, n8n becomes much more compelling.

The best way to evaluate it is small: pick one recurring workflow, build it end-to-end, add one AI step and one approval step, then see whether the process actually gets better.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/workflow/n8n-ki-workflow-automation/