DEV Community: Patrick Cornelißen

AI in testing: better test ideas, less routine work

Patrick Cornelißen — Mon, 11 May 2026 10:00:00 +0000

QA is one of the most practical places to use AI.

Not because AI replaces testers. It does not. But because testing contains a lot of repetitive thinking that can be accelerated: finding edge cases, drafting test cases, summarizing failures and turning vague requirements into concrete checks.

Where AI helps in testing

Useful starting points:

generate test ideas from a requirement
identify edge cases
summarize failing CI logs
draft regression test cases
compare expected and actual behavior
create exploratory testing charters
review whether acceptance criteria are testable

The output still needs review. But it often gives QA a faster first pass.

Example prompt

Read this user story and generate test cases.
Include happy path, edge cases, invalid input and permission checks.
Return the result as a table with:
- scenario
- steps
- expected result
- priority

This kind of prompt works well because the task is bounded and the expected output is clear.

AI is good at variation

One strength of AI is generating variations:

different input combinations
unusual user flows
missing data
invalid formats
role-based access cases
localization issues

That makes it useful for broadening a test plan.

AI is weaker at truth

AI does not know whether your system actually behaves correctly. It can infer likely behavior, but it cannot replace evidence.

For QA, that means:

generated tests must be checked against requirements
assumptions need to be validated
results from real systems matter more than confident explanations
unclear requirements should be pushed back to the team

The model can help ask better questions. It should not silently decide the answer.

CI failure analysis

AI can also help with noisy logs.

Good prompt:

Analyze this CI log.
Find the first meaningful failure.
Ignore follow-up errors caused by the first failure.
Explain the likely cause and suggest the next debugging step.

This saves time because logs often contain hundreds of irrelevant lines.

Keep QA judgment central

The tester's expertise is still the important part:

which risks matter?
which flows are business-critical?
where do users usually make mistakes?
what changed since the last release?
which bugs would be expensive in production?

AI can generate material. QA decides what matters.

Bottom line

AI is useful in QA when it acts as a thinking assistant: generate options, summarize evidence, point to gaps.

It becomes risky when teams treat generated tests as proof of quality.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/grundlagen/ki-einstieg-fuer-qa/

Building MCP servers with Spring AI: a practical boundary for agents

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

MCP becomes especially interesting when it connects AI agents to systems that already exist in enterprise applications.

For Java teams, Spring AI is one practical way to build that bridge.

Why build an MCP server?

An MCP server exposes tools or data sources to AI clients through a shared protocol.

Instead of wiring every AI client directly into your application, you can provide a controlled integration layer:

AI client -> MCP server -> application logic or data source

That layer can enforce boundaries, validate inputs and keep tool behavior explicit.

Why Spring AI fits

Spring teams already have patterns for:

dependency injection
configuration
security
observability
REST APIs
database access
testing

If your organization runs a lot of Java and Spring Boot, building AI tool integrations inside that ecosystem can be easier to operate than a separate experimental stack.

Example use cases

A Spring-based MCP server could expose tools like:

search internal documentation
look up customer records
fetch release information
create a support ticket
summarize incident data
validate a business rule

The important part is that each tool should have a narrow purpose.

Keep tools small

Bad tool:

doEverythingForCustomer()

Better tools:

findCustomerById()
listOpenTickets()
createFollowUpTask()
summarizeAccountHistory()

Small tools are easier to test, log and restrict.

Security concerns

An MCP server can become a powerful gateway. Treat it like backend infrastructure.

Think about:

authentication
authorization per tool
read-only vs write actions
audit logs
input validation
rate limits
secrets management
production data access

Do not expose a dangerous internal operation just because the model might use it correctly.

Testing matters

Tool behavior should be testable without the model.

For each tool, check:

valid input
invalid input
permission failures
empty results
downstream service errors

The AI client may be probabilistic. The tool boundary should not be.

Bottom line

Spring AI and MCP are a useful combination for teams that want AI agents to interact with real backend systems without turning every integration into a one-off script.

The value is not just "AI can call Java". The value is a maintainable boundary between agents and business systems.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/tools/spring-ai-mcp/

Running AI models locally with Ollama: where it fits

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

Local AI models are not just a hobbyist topic anymore. For many teams, they are a practical way to experiment with AI while keeping data under tighter control.

Ollama is one of the easiest ways to run language models locally.

Why local models matter

Cloud models are powerful and convenient, but they are not always the right fit.

Local models can help when:

data should not leave a machine or network
teams want predictable experiments
latency matters for small tasks
costs should stay bounded
developers need offline workflows
the use case does not require the strongest frontier model

Local AI is not automatically better. It is a different trade-off.

What Ollama gives you

Ollama provides a simple way to download, run and call local models.

The developer experience is intentionally small:

ollama run llama3.1

You can then use local models from scripts, tools or applications through an API.

Good use cases

Local models are useful for tasks where privacy and iteration speed matter more than maximum reasoning quality:

summarizing internal notes
generating first drafts
classifying small text snippets
local coding experiments
data extraction prototypes
offline demos
testing prompts before using a paid API

They are less suitable for tasks that require the best available reasoning or very large context.

The limits are real

Running locally does not remove every problem.

You still need to think about:

hardware requirements
model quality
context length
update management
access control
evaluation
prompt injection risks

The model is local, but the workflow still needs discipline.

Local does not mean isolated

One useful pattern is hybrid:

local model for low-risk, repetitive work
cloud model for complex reasoning
clear rules for what data may leave the environment
logging and review for sensitive workflows

This gives teams flexibility without pretending every task needs the same model.

Bottom line

Ollama makes local AI approachable. That matters because many teams need a place to experiment before committing to bigger platform decisions.

Use local models where they fit. Do not expect them to replace every cloud workflow.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/tools/ollama-lokale-ki/

Using multiple AI coding agents without creating chaos

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

Using more than one AI coding agent can sound messy. In practice, it can be useful if each tool has a clear role.

The trick is not to run agents against each other randomly. The trick is to design a workflow where their strengths complement each other.

Why combine coding agents?

Different agents can be better at different parts of the work:

exploring a codebase
implementing a focused change
reviewing a diff
debugging a failing test
explaining unfamiliar code
preparing a clean commit

You do not need every tool for every task. But for larger changes, a second agent can act like a fresh reviewer.

A practical division of labor

One useful pattern:

Agent A: implement the change
Agent B: review the diff
Human: decide what to accept

The second agent should not rewrite everything immediately. It should first produce findings:

Review this diff for bugs, missing tests and behavior changes.
List issues first. Do not edit files yet.

That keeps the workflow understandable.

Avoid agent chaos

Problems start when multiple agents edit the same files without coordination.

Safer rules:

keep tasks small
define file ownership
avoid parallel edits to the same module
run tests after each meaningful change
review diffs before asking for another pass
never let one agent blindly revert another agent's work

The workflow should still look like software engineering.

Good use cases

Combining agents can help with:

large refactors split by module
adding tests around existing code
reviewing generated code
checking documentation changes
debugging failures after an implementation
comparing implementation approaches

It is less useful for tiny changes where one agent and a human review are enough.

The human role

The human should stay in control of intent:

what problem are we solving?
what behavior must not change?
what is acceptable risk?
which findings matter?
when is the change done?

Agents can move fast. That makes human judgment more important, not less.

Bottom line

Multiple coding agents can be useful, but only with structure. Treat them like contributors with narrow tasks, not like magic parallel workers.

Good delegation beats tool collecting.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/tools/claude-code-codex-cli-kombinieren/

Skills for AI agents: reusable instructions that scale

Patrick Cornelißen — Thu, 07 May 2026 10:00:00 +0000

AI agents get much more useful when they do not have to rediscover your workflow every time.

That is the idea behind skills: reusable instructions, scripts and references that teach an agent how to do a specific kind of work.

What a skill is

A skill is usually a small, versioned package of instructions. At minimum, it contains a Markdown file that tells the agent:

when to use the skill
what steps to follow
which tools or commands matter
what output should look like
what constraints apply

Some skills also include scripts, templates or reference files.

Why not just use a prompt?

Prompts are great for one-off work. Skills are better for repeated workflows.

If you always paste the same prompt before a code review, release note draft or QA checklist, that prompt is doing the job of a process document.

A skill makes that process explicit.

Good skill use cases

Skills are useful when work has a repeatable shape:

reviewing pull requests
writing release notes
checking accessibility
preparing sprint summaries
creating test cases
transforming content for another platform
following a deployment checklist

The agent still needs judgment, but the skill gives it a reliable starting point.

What makes a good skill

Good skills are not huge manuals. They are compact and practical.

They should include:

a clear trigger
the smallest useful workflow
examples of expected output
important constraints
links to deeper references only when needed

Bad skills try to include everything. Good skills help the agent do one job well.

A simple structure

my-skill/
  SKILL.md
  scripts/
  references/
  assets/

Not every skill needs scripts or assets. Many useful skills are just a well-written SKILL.md.

The important part is that the instructions are no longer hidden in a chat history.

Skills are team infrastructure

Once a skill lives in a repository, the team can improve it like code:

review changes
add examples
remove stale rules
adapt it to new tools
document why decisions were made

This is where skills become more than prompt snippets. They become lightweight operational knowledge.

Bottom line

If your team uses AI agents regularly, skills are a practical way to make them more consistent.

They do not replace expertise. They make expertise easier to reuse.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/skills/skills-was-sind-skills-und-wie-nutze-ich-sie/

Turn repeated prompts into reusable AI skills

Patrick Cornelißen — Wed, 06 May 2026 10:00:00 +0000

Every team has prompts that slowly become unofficial process.

Someone writes a good review prompt. Someone else copies it into Slack. A week later there are three versions. One has the security checklist, one has the test checklist, one has a better output format.

At that point, it is no longer just a prompt. It is a workflow standard.

The problem with copy-paste prompts

Prompts shared in chat tools have a few predictable problems:

people copy old versions
important edits get lost
new team members never find the right prompt
output formats drift
quality depends on who remembered which instruction

This is annoying for writing tasks. It is risky for code reviews, release notes, QA checklists and security workflows.

Turn repeated prompts into skills

A better pattern is to put repeated instructions into a versioned file that the AI tool can load when relevant.

That file can define:

when the workflow applies
what context the AI should gather
which checks matter
what output format to use
which project conventions to follow
what the AI must not do

In many AI coding tools, this is the role of a skill, project instruction or agent playbook.

Example: a code review skill

Instead of pasting a prompt like this every time:

Review this code for TypeScript issues, missing tests and security problems.
Use severity levels and include file references.

Put the review rules into the repo:

team-code-review/
  SKILL.md

The skill can include the exact severity definitions, framework conventions and output format.

Now the workflow is:

Review this pull request using our team code review skill.

The important part is not the shorter prompt. The important part is that the standard is versioned.

Why versioning matters

Once the instruction lives in the repo, it becomes maintainable:

changes show up in Git
reviews can discuss the workflow itself
the whole team gets the same version
new team members inherit the standard
improvements can be tested over time

This is much better than "I think the latest prompt is somewhere in Slack".

When to create a skill

A simple rule:

If you have reused and modified a prompt three times, turn it into a skill.

Good candidates:

code review checklists
release note generation
sprint summary formats
bug report triage
accessibility reviews
security review prompts
documentation standards

Do not create a skill for every tiny prompt. Create one when consistency matters.

Bottom line

Prompts are useful for exploration. Skills are useful for repeatable work.

If a prompt has become part of how your team works, give it a home in the repo.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/workflow/vom-prompt-zum-eigenen-skill/

AI-generated code: almost right is still risky

Patrick Cornelißen — Tue, 05 May 2026 10:00:00 +0000

AI-generated code is often close to correct. That is exactly what makes it dangerous.

Obviously broken code is easy to reject. Code that compiles, looks reasonable and passes the happy path is much harder to distrust.

"Almost right" is not enough

In software, small gaps matter:

one missing null check
one unhandled timeout
one weak authorization condition
one unsafe default
one test that only covers the obvious path

AI tools can produce useful code quickly, but they can also create these gaps quickly.

The common failure pattern

AI coding tools tend to optimize for a plausible solution. That is not the same as a production-ready solution.

You often get:

clean-looking structure
reasonable names
a working example
incomplete edge cases
shallow tests
error handling that looks present but does not help much

This is why reviewing AI code can take a different kind of attention. You are not only looking for syntax problems. You are looking for missing thought.

Review the assumptions

A good review question is:

What did the model assume that may not be true?

Examples:

input is always valid
the API always responds
the user has permission
the array is never empty
the environment variable exists
the model response is well-formed

If the code depends on those assumptions, they need to be explicit or handled.

Tests matter more, not less

AI can generate tests, but generated tests often mirror the implementation instead of challenging it.

Ask for tests that cover:

invalid input
empty states
missing permissions
timeouts
malformed API responses
duplicate data
race conditions where relevant

The test suite should make the implementation prove something.

Ask the AI to criticize its own code

One useful pattern is a second pass:

Review this implementation as if you did not write it.
Look for bugs, missing edge cases, weak error handling and security issues.
Do not rewrite the code yet. List findings first.

This does not replace a human review, but it often catches issues from the first draft.

Keep changes small

The larger the AI-generated diff, the harder it is to review. Small changes keep accountability intact.

Good task shape:

one function
one component
one route
one failing test
one refactoring pattern

Bad task shape:

"rewrite the module"
"add auth everywhere"
"modernize the whole app"
"fix all tests"

The model can produce large changes. That does not mean you should accept them.

Bottom line

AI coding tools are useful, but the quality bar does not change. Code still needs tests, review, error handling and security thinking.

Treat AI output as a fast draft, not as a trusted implementation.

This article is based on the German original on KIberblick:
https://kiberblick.de/artikel/grundlagen/ki-code-qualitaet/

From vibe coding to agentic engineering

Patrick Cornelißen — Mon, 04 May 2026 10:00:00 +0000

Vibe coding is a good starting point, but it is not where serious AI-assisted development ends.

The next step is agentic engineering: using AI coding agents inside a controlled engineering workflow, with context, tests, review and clear boundaries.

From output to workflow

Vibe coding often focuses on the generated output:

Ask for feature -> get code -> run it -> ask for fixes

Agentic engineering focuses on the system around the model:

Define task -> provide context -> implement small slice -> run checks -> review diff -> iterate

The model is still important, but it is not the whole process.

What changes

In an agentic workflow, the AI tool can do more than answer questions. It can:

read relevant files
edit code
run tests
inspect errors
update documentation
prepare commits
compare alternatives

That is powerful, but only if the environment gives the agent good constraints.

Constraints are not bureaucracy

Good constraints make the agent more useful.

Examples:

project instructions in a versioned file
clear test commands
lint and typecheck gates
small tasks with explicit acceptance criteria
code review before merge
no direct pushes to main
no production credentials in the workspace

These are normal engineering practices. AI makes them more important, not less.

A practical pattern

A useful agentic coding loop looks like this:

1. State the goal and constraints.
2. Let the agent inspect the relevant files.
3. Ask for a small implementation.
4. Run tests and type checks.
5. Review the diff.
6. Ask the agent to fix only the findings.
7. Commit once the change is understandable.

The key is that the agent is allowed to work, but the workflow keeps evidence visible.

Where agents help most

Agentic tools are strongest when the work is local but tedious:

refactoring a repeated pattern
adding tests around existing behavior
wiring a small feature through several files
updating documentation after a change
investigating a failing test
generating migration helpers

They are weaker when the task depends on unclear product judgment or hidden team context.

The developer remains accountable

Agentic engineering does not remove responsibility. It changes where attention goes.

Instead of typing every line, the developer watches for:

wrong assumptions
unnecessary complexity
weak tests
architecture drift
security issues
behavior changes hidden in refactors

The human is still the reviewer of meaning.

Bottom line

The useful future is not "AI writes all the code while developers vibe". It is AI agents doing more of the mechanical work inside workflows that still look like engineering.

That is less flashy, but much more valuable.

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

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/