DEV Community: Tom Seidel

Low-Code Automation's 2026 Hype Isn't Fading. That's the Problem.

Tom Seidel — Thu, 24 Sep 2026 07:18:10 +0000

People keep asking whether the low-code automation hype — n8n, Zapier, Make, Coze, Dify, LangFlow — is finally cooling off in 2026. I researched it. The answer is worse for the skeptics than you think: the low-code automation market is not cooling. It's at its peak. The thing that's in the trough is the promise it's built on — autonomous AI agents. And that's exactly why I think code-first is the winning play.

The data: low-code automation is not fading

If you ask "is the low-code automation hype over in 2026?", the numbers say no:

n8n more than doubled its valuation in 2026. $2.5B after its $180M Series C (October 2025) [1], then $5.2B when SAP took a strategic stake in May 2026 — and signed a multi-year deal to embed n8n's workflow canvas inside Joule Studio, SAP's AI agent-building platform [2][3].
195k+ GitHub stars [4], a growing "fair-code" community, and a flagship conference ("In The Loop 2026") that's now an industry event in its own right.
Zapier shipped "Agents" with 7,000+ app integrations. Make, Coze, and Dify are all expanding their AI-node feature sets [5]. The entire category is racing to add "AI" to the visual canvas.

So let's not pretend the 2010-style "it all died out" narrative applies here. It doesn't. The low-code automation market in 2026 is the strongest it's ever been.

So the market isn't growing because the visual canvas got better. It's growing because the canvas is now the delivery vehicle for agentic AI. n8n's own homepage says it: "Build visually, go deep with code" — for AI agents [6]. Zapier sells autonomous agents [5]. SAP is buying n8n to put the visual canvas inside its agent platform [2][3]. The visual workflow builder has quietly become the industry's preferred way to ship "AI agents" to business users.

And now we get to what is in the trough.

What is fading: the agentic AI promise underneath the canvas

In April 2026, Gartner published its first dedicated Hype Cycle for Agentic AI — separated from the broader GenAI cycle for the first time [7]. Its verdict: AI agents are at the peak of inflated expectations and will slide into the trough of disillusionment throughout 2026. Gartner calls 2026 the "year of disillusionment" for agentic AI [8].

The supporting data:

An 88% security incident rate for AI agents (NoCode.Tech's coverage of enterprise incident data) [9] — what happens when autonomous decision-making touches live infrastructure without a governance layer.
Microsoft pausing data-center construction. Anthropic delaying a major release over safety concerns [10]. The broader AI sector is hitting real headwinds in 2026.
Gartner's framing: the trough "reflects how agentic AI was sold and bought, not whether the technology works." One line, the whole 2010–2013 story.

Read those two facts together — low-code automation at an all-time peak, agentic AI heading into its trough — and the picture gets sharp: low-code automation has become the Trojan horse for the agentic AI hype. The growth in workflow platforms is largely growth in "AI agent" workflows: LLM nodes on the canvas, natural-language workflow building, agents that "reason" between connectors. When the agentic trough lands — and Gartner says it lands in 2026 [7][8] — the platforms won't shrink, but a lot of what their users built will be graphs of LLM calls that nobody can explain, test, or trust.

That's a more dangerous position than the old hype, not a less dangerous one. In 2010, a broken BPM graph was a maintenance chore. In 2026, a broken 400-node agent graph is a silent compliance and security incident.

Why the 2010 wave matters: we saw this ending once

Around 2010 the enterprise world got a structurally identical pitch: SOA orchestration, ESB tools, Mule, TIBCO, jBPM, Camunda's rise, BPMN modelers, iPaaS. "Developers are the bottleneck — let business people wire integrations visually. No code. Citizen developers. Done."

The ending is well documented: abstraction tax, version drift, connector sprawl, "who owns this when the modeler leaves." The industry went back to code. The only piece of that wave that survived is the BPMN modeler as a companion to the IDE — modeling survived, implementation did not.

The 2026 wave repeats the same core move (visual abstraction over real integration logic) and adds one new ingredient: nondeterminism inside the graph. That's the difference between a 2013 problem and a 2026 problem.

Why AI makes the visual canvas worse, not better

1. Two hidden layers of nondeterminism. A 200-node graph already has a black box in every connector. Now 15 of those nodes are LLM calls that return something different every run. Model nondeterminism stacked on platform nondeterminism: the pipeline isn't flaky anymore, it's unprovable.

2. "AI builds your workflow from a description" just moves the drift into the prompt. Hallucinated field names, mismatched connectors, silently best-effort transformations. The 2010 wave hid complexity behind boxes; this wave hides it behind a chat.

3. Observability and review stop working. How do you trace a 400-node graph with 12 LLM calls in it? Diff it? Regression-test it? The visual format was never a good git citizen; with LLM nodes it becomes unauditable.

4. The abstraction tax now includes the model's limits. Every LLM node is a context window, a token cost, a hallucination risk, and a latency spike — wrapped in a pretty node. Your "simple" workflow is a distributed system with a stochastic dependency you can't upgrade.

5. The platforms know the ceiling exists — that's why they all ship code nodes. n8n's feature list literally says "fall back to code: drop into JavaScript or Python in a code node" [11]. The escape hatch is part of the product. That is the entire low-code thesis conceding defeat, shipped as a feature.

6. "Low-code" was never low-maintenance; it just looked that way. AI makes it look even more low-maintenance. The work doesn't disappear — it becomes invisible until an LLM node returns a different JSON shape on a Tuesday at 2 a.m. and the pipeline quietly stops.

Why code-first wins — especially in the AI era

The architecture for AI automation is deterministic core, stochastic edges: code that orchestrates, with well-defined LLM calls at the edges — schema-validated, tested, version-controlled.

AI collapsed the cost of code. Low-code's historical advantage was access for people who can't code. AI-assisted coding erased that. Code is now the fast path — generated in seconds, reviewed in minutes, diffable.
Determinism is a feature. You can unit-test, replay, and prove a deterministic pipeline. You cannot prove a graph of LLM calls. In production, "it usually works" is a failure state.
Review and rollback survive. A 200-line diff is reviewable. A 400-node YAML blob is not. AI writes the code; you review the diff. That combination is the whole game.
You control the whole stack. Containers, CI, secrets, observability, backup, upgrades. Code-first gives you the levers; the canvas gives you a vendor roadmap — which in 2026 is literally "embedded in SAP's agent platform" or "not" [2][3].
Complexity doesn't scale linearly. A well-factored 300-line module covering 15 integrations is maintainable. 150 nodes is not.

Low-code in the AI era isn't "more automation." It's more hidden nondeterminism with a bigger funding round.

Where low-code still makes sense

Throwaway prototypes and MVPs. Weeks, not years. Validate, then rewrite in code.
Trivial one-offs. "Email → Slack," "CSV from A to B." No state, low risk.
Business-owned, low-risk internal flows. When the business genuinely owns the maintenance and the flow isn't regulated or high-volume.
When visual authoring is the feature. Some process changes are inherently visual — and the 2010 wave proved that modeling (BPMN) survives even when implementation doesn't.

Rule of thumb: low complexity + low risk + short-lived = fine on a canvas. The moment you need state, idempotency, scale, security, testability, review, or portability — the decision flips to code, and in the AI era that flip comes sooner, because AI made the code path cheaper, not more expensive.

The controversial part

The same buyers who bought the 2010 SOA/iPaaS dream are buying the 2026 dream in the same clothes with a new logo: end the developer bottleneck, visually. The dynamic hasn't changed — abstraction doesn't remove complexity, it hides it. In 2010 the hidden complexity became a maintenance liability. In 2026 it becomes hidden nondeterminism inside an LLM — which is exactly where outages, runaway token costs, and compliance breaches breed.

And the "is it cooling?" question deserves a straight answer: the low-code canvas market isn't cooling — it's at its peak, worth billions, embedded in SAP [2][3]. What's cooling is the agentic AI promise the whole category rebranded itself around, and Gartner says that trough hits in 2026 [7][8]. So the risk isn't that low-code automation dies. The risk is that it survives on top of a hype cycle entering its disillusionment phase, leaving every organization with hundreds of LLM-node graphs that can't be explained, tested, audited, or trusted — and a platform roadmap deciding what they can and can't do.

Code-first isn't developer ego. It's the only lever that doesn't get linearly more expensive as complexity grows, and the only one that survives a trough. AI didn't change that — AI made the code path cheaper and the canvas path more dangerous, in the same year.

We saw the 2010 ending in 2013. The 2026 ending won't be a shrinking market. It'll be a peak-sized market full of graphs nobody can debug.

Sources

n8n Blog, "n8n raises $180M to get AI closer to value with orchestration" (Oct 9, 2025) — $2.5B Series C led by Accel. https://blog.n8n.io/series-c/
AyAutomate, "n8n Hits $5.2B Valuation: Enterprise-Ready in 2026" — SAP strategic stake (May 2026), canvas embedded inside Joule Studio (SAP's AI agent-building platform). https://www.ayautomate.com/blog/n8n-enterprise-valuation-2026
Wikipedia, "N8n" (accessed Sep 2026) — SAP strategic investment, May 2026, roughly doubling the valuation; founded by Jan Oberhauser, launched Oct 2019. https://en.wikipedia.org/wiki/N8n
GitHub, "n8n-io/n8n" — 195k+ stars; "fair-code platform to build and deploy AI agents and workflows, 1500+ integrations." https://github.com/n8n-io/n8n
Virtua, "n8n vs Zapier vs Make: Kosten, DSGVO & Datenschutz (2026)" — Zapier Agents with 7,000+ app integrations. https://www.virtua.cloud/learn/de/concepts/n8n-vs-zapier-vs-make-kosten-datenschutz
n8n homepage — "Build visually, go deep with code, connect to anything. Every step of your agents' reasoning, traceable on the canvas." https://n8n.io/
Gartner, "2026 Hype Cycle for Agentic AI" (Apr 15, 2026) — first dedicated agentic AI hype cycle; AI agents at peak of inflated expectations, trough of disillusionment predicted throughout 2026. https://www.gartner.com/en/articles/hype-cycle-for-agentic-ai
Generative, Inc., "Agentic AI in 2026: How AI Evolved from Chatbots to Autonomous Agents" (Jul 10, 2026) — 2026 as the "year of disillusionment" for agentic AI. https://www.generative.inc/agentic-ai-in-2026-how-ai-went-from-chatting-to-doing
NoCode.Tech, "Gartner's 2026 Hype Cycle for Agentic AI: What the Trough of Disillusionment Actually Means for No-Code Teams" (Jul 21, 2026) — 88% AI agent security incident rate. https://www.nocode.tech/article/gartners-2026-hype-cycle-agentic-ai
Financial Express, "Is an AI bust coming?" (Apr 12, 2026) — Microsoft pausing data-center construction, Anthropic delaying a release over safety concerns. https://www.financialexpress.com/market/global-market-pulse/is-an-ai-bust-coming/4204135/
n8n, "Workflows App Automation Features" — "Fall back to code: drop into JavaScript or Python in a code node, add npm packages when you self-host." https://n8n.io/features/

Jev Is Fast Because the Reasoning Moved Into Your Architecture

Tom Seidel — Wed, 23 Sep 2026 06:43:57 +0000

The hype train is packed again. Ever since TypeSafe AI released Jev, the internet has been
full of examples that make it look like the fast, cheap alternative to a classical LLM:
70–500 ms instead of seconds, $0.042 per million input tokens, output "too cheap to meter", 40x to 200x speedups. The conclusion is drawn implicitly and sometimes explicitly:
why pay for a reasoning model, when this thing answers instantly for nothing?

That conclusion is wrong, and it is wrong in a way that costs money. Jev is not a cheaper way to do what an LLM does. It is a different computation for a different problem — and it quietly moves the expensive part of the work into your codebase, where the hype slides, the demos and the LinkedIn posts never look.

Here is the honest version.

The speed is not an optimization, it is a different problem

Give a reasoning model this task:

Should this pull request be merged? Analyze the changes, consider security, tests,
architecture and possible regressions.

Roughly this happens: context, understand, form hypotheses, intermediate steps, compare, decide, and finally formulate an answer. That last step is where the bill is. An LLM generates autoregressively, token by token, conditioned on the token before it. Structured JSON output does not change that — it is still one token at a time, just with a schema.

Jev gets a different shape of input:

STATE:
- change touches OAuth callback handling
- security scan: no findings
- tests: 142/142 passing
- API compatibility: unchanged
- review finding: possible missing null check
- project policy: severity >= HIGH blocks merge

QUESTIONS:
1. finding_severity = [NONE, LOW, MEDIUM, HIGH, CRITICAL]
2. merge_blocking = [yes, no]
3. needs_human_review = [yes, no]

and returns a distribution:

severity:
  MEDIUM: 0.74
  HIGH:   0.19
  LOW:    0.07

merge_blocking:
  no:  0.81
  yes: 0.19

No text. No chain of thought. All outputs in a single forward pass. TypeSafe calls the architecture a parallel sampler and the training method Reinforcement Learning for Calibrated Decisions (RLCD) — probabilities optimized against outcomes instead of against human raters' preference.

Line those two up and the "faster LLM" story collapses. The reasoning model pays for every token of its own deliberation:

flowchart TB
    C[Context / prompt] --> N[Neural pass]
    N --> T1["First I need to check ..."]
    T1 --> T2[token]
    T2 --> T3[token]
    T3 --> T4["However ..."]
    T4 --> T5[token]
    T5 --> T6["... and therefore the answer is"]
    T6 --> D[Decision]

Jev pays once per question and hands back a distribution:

flowchart TB
    C["Context / state<br/>diff summary, scan results, test results,<br/>API compatibility, findings, project policy"] --> N[Neural pass]
    N --> D1["severity: MEDIUM 0.74, HIGH 0.19, LOW 0.07"]
    N --> D2["merge_blocking: no 0.81, yes 0.19"]
    N --> D3["needs_human_review: no 0.9, yes 0.1"]

Comparing those as if one were the optimized version of the other is like calling a calculator a faster author. Text in either way, and a transformer under the hood according to TypeSafe — but a fundamentally different compute problem.

Does Jev not reason at all? Wrong question

Jev still has to see relationships in the state and weigh them. What it does not do is narrate that weighing as tokens. The difference is not "reasoning versus no reasoning", it is where the decomposition happens:

With a reasoning LLM, the decomposition happens at inference time, in tokens, inside the model. You pay for it on every call, and you get a rationale you cannot trust.
With Jev, the decomposition has to have already happened — in your questions, in your options, in the workflow that assembled the state. If you did not do that work, no parallel sampler will do it for you at 3 a.m.

So the honest sentence is not "Jev needs less reasoning". It is: Jev relocates the reasoning, and the new location is your repository.

Nobody advertises the pipeline that feeds Jev

Consider the question people actually want answered:

Is this change safe?

To answer that, someone has to walk this chain:

flowchart TD
    Q["Is this change safe?"] --> A[Read the diff]
    A --> B[Find the affected classes]
    B --> C[Follow the call graph]
    C --> D[Look up auth configuration]
    D --> E[Determine library versions]
    E --> F[Check CVE data]
    F --> G[Inspect the tests]
    G --> H[Decide]
    H --> I["Jev: probabilities for this one decision"]
    style Q stroke-dasharray: 5 5

Jev does not collapse that chain. Not in 100 ms, not in 100 s. What it collapses is the last hop: instead of asking a model to find out what is going on and decide in one breath, you hand it a state that is already bite-sized and ask it to decide. The difference is the whole product:

Not "figure out what the situation is." But: "here is the entire situation — decide."

That is a legitimate, valuable, genuinely hard-to-do-well thing. It is also a thing that presupposes the chain above it exists, runs, and is correct. Every millisecond Jev saves on decision latency is a millisecond some other system spent on context assembly. That system is written by you, tested by you, and paged at 3 a.m. by you.

What a Jev integration actually looks like

flowchart TB
    A["Classical software<br/>collect context, read the database,<br/>call APIs, compute, apply rules"] --> B["Jev<br/>fuzzy decision, 100-500 ms"]
    B --> C["probabilities and confidence"]
    C --> D["Classical software<br/>if / route / retry / stop"]
    D -.->|"next iteration"| A

And what it does not look like:

flowchart LR
    U[User] --> J[Jev] --> X["Autonomously solves a complex problem"]
    X --> Y["This is not a feature request, it is a category error"]

The confusion is understandable: the name "System One" — borrowed from Kahneman's fast, intuitive thinking — plus the framing of "frontier intelligence in a function call" suggests that Jev thinks like a reasoning model, only faster. It does not. It is an extremely capable, context-dependent classifier with calibrated confidence. An agent it is not. Calling it one is how you end up with autonomy that works in the demo and
flakes in production, with nothing to read in the logs but floats.

The reasoning moves into your program graph — and that is the good news

Here is the pattern people are actually building, for the merge decision above:

flowchart TD
    S["Prepared state:<br/>diff summary, scan results, test results,<br/>API compat, findings, project policy"] --> SR["securityRisk = Jev(...)"]
    S --> TR["testRisk = Jev(...)"]
    S --> AR["apiRisk = Jev(...)"]
    S --> QR["qualityRisk = Jev(...)"]
    SR --> D1{"securityRisk above 0.8?"}
    D1 -->|yes| B[BLOCK]
    D1 -->|no| D2{"apiRisk above 0.6?"}
    D2 -->|yes| H[HUMAN_REVIEW]
    D2 -->|no| D3{"testRisk below 0.2<br/>and qualityRisk below 0.3?"}
    D3 -->|yes| M[MERGE]
    D3 -->|no| H

The knowledge that used to be implicit in a model's chain of thought — security outranks style, so check security first; if security is critical, the other results do not matter anymore — is now explicit in code. Which is genuinely better: code is diffable, reviewable, unit-testable, and it does not cost a token to branch.

But notice what had to happen for this to work. Somebody had to write down that security outranks style. Somebody had to define the four questions, the option sets, the thresholds 0.8 / 0.6 / 0.2 / 0.3, and somebody has to own the answer to "why 0.8?". With an LLM agent you never wrote any of that down and it mostly worked anyway. With Jev, the design is the
product. That is not a flaw — it is the bill arriving for the architecture you skipped.

The only combination worth building into an agent

The interesting hybrid is not "Jev instead of the reasoning model". It is a division of
labour:

flowchart TB
    L["Reasoning LLM<br/>explore, investigate, generate"] --> ST["state / results"]
    ST --> G1["Jev: is this finding relevant?"]
    ST --> G2["Jev: is a retry worth it?"]
    ST --> G3["Jev: did the review gate pass?"]
    ST --> G4["Jev: another tool call needed?"]
    G1 --> W["workflow / code"]
    G2 --> W
    G3 --> W
    G4 --> W
    W -.->|"next step"| L

The expensive model does only what needs exploration or generation. The dozens of small judgements per step — relevant? retry? good enough? escalate? — go to a model that answers in milliseconds with a number attached. At 40x to 200x the speed and a small fraction of the cost per call, you can afford gates that were previously too expensive to even
consider, and that is the real win: not replacing your model, but adding judgement where you previously made do with a hard-coded rule or nothing at all.

Now the part nobody puts on the slide: gates multiply. A chain of ten gates at 95% accuracy lands at 60% end-to-end. Twenty land at 36%. To keep twenty gates above 98% you need roughly 99.9% per gate — which is exactly why "it is just a classifier with calibrated probabilities" is not a downgrade, it is the whole requirement. And it is why your test suite now needs calibration checks on your distribution, not benchmark leaderboards.

The myth of "it cannot hallucinate"

This one deserves a hard stop. TypeSafe's claim is technically careful: possible outputs are defined in advance, so the model never makes type errors, and schema matching is guaranteed. Fine. That is a statement about form, not about truth.

Jev can absolutely decide wrongly. It can label a CRITICAL finding as MEDIUM at 0.74, and your code, having been told that 0.74 is the answer, will route on it. What Jev removes is the visible failure mode, not the failure:

flowchart LR
    A["LLM: a wrong sentence<br/>in fluent text"] --> B["Someone notices,<br/>laughs, retries"]
    C["Jev: a wrong label<br/>with a confident probability"] --> D["Your code branches silently"]
    D --> E["Weeks later:<br/>a post-mortem with<br/>no rationale to read"]

Hallucination has not been abolished here. It has been converted into silent miscalibration — and for operations, that is the worse failure mode, because a wrong sentence is loud while a wrong float is invisible, reproducible, and trusted by CI. Three consequences follow immediately:

You cannot ask why. Simon Willison's complaint is the right one: an LLM at least produces a rationale you may not trust; a decision model produces a number. If Jev flags something, which content signals tipped it off? Nobody can tell you, and bias now hides inside a float.
Calibration is a claim, and it is about their distribution. That a model returns honest probabilities does not mean it stays honest on your inputs. TypeSafe's own jaggedness notes admit weak spots on numbers, dates and adversarial content. Perturb a prompt slightly, watch a decision flip, and try to explain it to an auditor.
The blast radius got bigger. An LLM hallucinating a tool call is inconvenient. The same model buried three layers deep in a dependency chain with a latency budget is a production incident.

So: not "Jev cannot hallucinate". Rather: "Jev's wrong answers no longer look like wrong answers". If you cannot detect them, you have not automated a decision — you have automated trust.

If you are going to build this, build it honestly

Keep state assembly in ordinary software. Jev decides, it does not look things up.
Express every decision as a question with a typed, closed option set — if you cannot, you have not thought the decision through yet.
Set thresholds explicitly and write down why they are what they are. A number nobody can justify is a liability, not a configuration.
Measure calibration on your inputs, not on the vendor's benchmark. Then break your inputs on purpose and watch which decisions flip.
Read the gate chain end to end and multiply the accuracies. Compound error is where "fast and cheap" turns into "fast, cheap and quietly wrong".
Never let a gate decide something you cannot explain to a reviewer, a customer or an auditor. "The model said 0.74" is not an explanation.

Verdict: a very good tool with a very bad pitch

Jev is a serious, interesting approach, and for the right problem shape it is the best tool currently on the market: constant, documentable, cheap judgement inside ordinary software. Used well, it is what makes agentic systems affordable — cheap gates around an expensive explorer.

But it is not a replacement for LLM reasoning. It is less reasoning, applied precisely where reasoning was never what you needed — only a decision. Everything that made the decision hard (knowing what matters, assembling the state, choosing the questions, setting the thresholds, owning the calibration) stays on your side of the fence.

Which is the actual provocation here. The hype train is selling you speed and a price tag.
What Jev really ships is a demand: write down what you actually decide, in code, with numbers, and test it. Teams that skipped that work are not going to be saved by a parallel sampler; they are going to discover, in production, that they never knew what they were asking.

Stop calling it a faster LLM. Start treating it as a receipt — for the architecture you have been postponing all along.

Before Sovereign AI, You Need Sovereign IT

Tom Seidel — Tue, 22 Sep 2026 06:39:57 +0000

Sovereign AI Is Loud — But The Real Issue Is Sovereign IT

Most articles here are focused on very concrete, technical problems: setups, architectures, and reproducible solutions. This one takes a step back. Still, at its core, it remains technical — because questions of “sovereignty” ultimately materialize in infrastructure, operations, and the ability to make and reverse decisions.

The Current Narrative: Sovereign AI

The debate around sovereign AI has gained remarkable momentum. Across industry reports, policy discussions, and conference stages, there is a growing emphasis on regaining control over data, models, and infrastructure. Especially in Europe, the dependency on non-local providers has become a recurring concern, driven by both geopolitical tension and regulatory realities.

Conceptually, the idea is straightforward: build, run, and control AI systems within your own sphere of influence. In practice, however, this turns out to be significantly more demanding.

Operating a self-hosted LLM setup today requires assembling a stack from relatively young and still evolving components:

inference engines such as vLLM or Ollama
containerized deployments and orchestration, often via Kubernetes
surrounding services like vector databases, authentication, observability, and networking
and, perhaps most critically, access to and operation of suitable GPU infrastructure

There is no widely accepted, production-ready “standard stack” comparable to what exists for more traditional enterprise workloads. Instead, organizations are faced with a growing but fragmented ecosystem. While this provides flexibility, it also means that building such a platform still requires a considerable amount of in-house expertise and operational maturity.

Infrastructure Is Scaling — But Not Necessarily Becoming Sovereign

At the same time, the physical backbone of digital infrastructure is expanding rapidly. Driven largely by AI workloads, Europe is experiencing a strong increase in data center construction and capacity.

Key Data Points

Topic	Data
Demand driver	AI is now the leading driver of data center demand in Europe 1
Capacity growth	Avg. deployments: 16 MW → 33 MW → 47 MW (2023–2025) 1
Investment scale	> €100B expected in European data centers by 2030 2
Pipeline size	~14 GW planned capacity in EMEA by mid-2025 3

This expansion is often interpreted as a positive signal for digital sovereignty: more infrastructure, closer to users, under European jurisdiction.

Yet the picture is more nuanced. Much of this newly built capacity is designed to support hyperscale cloud and AI platforms. Even when physically located in Europe, these systems often operate within technological, contractual, and operational frameworks defined elsewhere. In that sense, infrastructure alone does not automatically translate into control.

The Overlooked Context: Sovereignty Decisions Were Made Earlier

Seen in this light, the current intensity of the AI sovereignty debate is somewhat surprising. Over the past decade, many organizations have already made fundamental decisions that reduced their control over IT systems — often quite deliberately.

The shift toward cloud-based and platform-centric architectures brought undeniable advantages: faster deployment, reduced operational overhead, and access to highly sophisticated tooling. At the same time, it gradually relocated critical capabilities:

infrastructure to cloud providers
development workflows to hosted platforms
collaboration and communication to SaaS ecosystems
customer-facing systems to externally operated services

None of this was irrational. In many cases, it was the most pragmatic choice available. However, it also meant that certain aspects of control — over data flows, system behavior, or long-term portability — became harder to maintain.

Different Industries, Different Trade-offs

In my own experience, the way organizations approach these questions varies significantly by industry.

In medical technology, there remains a noticeable degree of caution when it comes to outsourcing critical IT systems. This is not simply a cultural preference but largely shaped by regulation. Requirements around data protection, auditability, and traceability leave relatively little room for ambiguity. As a result, questions about where data resides, who can access it, and how systems can be audited or replaced tend to be addressed early and in detail.

This does not necessarily mean that cloud usage is avoided altogether. Rather, it is approached more deliberately, and often with additional safeguards or hybrid models. In that sense, sovereignty is less an abstract concept and more an operational constraint that needs to be managed.

By contrast, in parts of the automotive industry, the shift toward external platforms was often more assertive. Internal infrastructure teams were frequently seen as cost-intensive and less flexible, while cloud providers offered scalability, speed, and a rich ecosystem of services. Over time, this led to a situation where a significant portion of the IT landscape — from development pipelines to collaboration tools — relies on a relatively small number of external vendors.

This approach brought clear benefits in terms of velocity and standardization. At the same time, it introduced new forms of dependency, some of which only become visible when trying to change direction. Migration paths, data portability, and operational independence tend to become more complex as systems are more deeply integrated into proprietary platforms.

Why AI Changes the Tone of the Debate

Against this backdrop, it becomes clearer why AI has triggered a more pronounced reaction.

AI systems tend to sit very close to core value creation. They process sensitive data, encode domain knowledge, and increasingly influence decision-making processes. As a result, questions of control feel more immediate. Where earlier layers of abstraction — infrastructure, collaboration tools, or workflow systems — could be externalized with relatively limited visibility, AI makes dependencies more tangible.

At the same time, many of the underlying challenges are not new. Vendor lock-in, limited transparency, reliance on external roadmaps, or the gradual loss of internal expertise are all dynamics that have been present for years. AI does not introduce them so much as amplify their impact.

A More Nuanced View on Sovereignty

It is also worth noting that sovereignty is rarely absolute. In practice, it tends to manifest as a spectrum rather than a binary choice.

Levels of Sovereignty

Level	Example
Low	Full reliance on SaaS / hyperscalers
Medium	EU hosting with contractual safeguards
High	Open-source, portable architectures
Maximum	Fully self-hosted or air‑gapped systems

For many organizations, a balanced approach is likely the most practical: retaining control where it matters most while leveraging external services where appropriate. What becomes increasingly important, however, is the ability to make these choices consciously — and to revisit them if needed.

Early Signs of a Shift

There are indications that the broader conversation is evolving. In the public sector, for example, initiatives are emerging that explicitly frame digital sovereignty as a strategic objective.

Programs that move away from proprietary ecosystems toward open-source-based infrastructures — such as the adoption of LibreOffice, Linux, and open collaboration platforms — reflect a growing awareness of long-term dependencies and their implications. 4

These efforts are not without friction. Migration, training, and organizational change can be challenging. Yet they also demonstrate that alternative approaches are possible, even at scale.

Conclusion

The renewed focus on sovereign AI is both understandable and valuable. At the same time, it risks narrowing the perspective if it is treated in isolation.

Questions of control, dependency, and adaptability do not begin with AI — they extend across the entire IT landscape. In that sense, sovereign AI is less a starting point and more a visible manifestation of a broader theme.

A more comprehensive view would therefore consider not only AI systems, but the surrounding architecture, data flows, and operational capabilities. Ultimately, sovereignty is less about complete independence and more about maintaining the flexibility to respond, adapt, and make informed choices.

Or, put differently:

it is not necessarily about building everything yourself —

but about retaining the ability not to be entirely dependent on others.

The 2026 Developer Job Market Isn't Collapsing — It's Splitting in Two

Tom Seidel — Fri, 11 Sep 2026 06:05:46 +0000

Regarding the Job Market: Why 2026 Feels Like a Crisis — and Why the Profession Isn't Dying

When ChatGPT started making its way into development workflows — back then it was all copy-paste from the chat window — and non-developers suddenly started vibe-coding prototypes that looked genuinely impressive, the question immediately surfaced: do we even need developers anymore? From day one I was a convinced believer in AI as a tool, and I still am: I'm more confident than ever that developers are needed more than before, not less. And the job-market statistics from the major job boards broadly support that view. We still have a massive deficit of applications that are supposed to drive the digitalization of everyday processes, and the demand for software remains unbroken.

The numbers: strong overall demand, a transforming job market

The current state of the market is best described as a split, not a collapse. AI engineering roles are growing much faster than classic software engineering roles, while generalist positions are growing only modestly or sitting flat.[1] At the same time, the tooling is already everywhere: 84% of developers now use or plan to use AI tools in their development process, and 51% of professional developers use them daily.[9] Roughly 40% of software engineering job postings already mention AI coding tools — Copilot, Cursor, Claude Code — as a requirement or a plus.[23]

The junior paradox: the right data, the wrong conclusion

In certain bubbles, the warning is loud: getting in as a junior developer is the hardest it has ever been. The numbers back that up. A study by Stanford's Digital Economy Lab, built on ADP payroll data covering millions of U.S. workers, found that employment for software developers aged 22–25 declined by nearly 20% from its late-2022 peak.[5][7] U.S. entry-level tech job postings dropped by roughly 67% between 2023 and 2024 in that same Stanford/ADP analysis.[3]. The reason why I've chosen statistics from the U.S. is that they are the most detailed and reliable I could find.

But that is the wrong way to look at it. Getting into the profession has not become harder in an absolute sense — the profile of the entry-level role has simply changed. Tasks that junior developers typically handled are now done reliably by AI. What has changed is the job description, not the demand for fresh talent. What juniors need is to adapt their skill set to the new conditions: use AI as an accelerator in their own work, focus on system design and software architecture, build more business and domain knowledge — or pick crisis-resistant industries. That work methods and tools keep changing and improving is nothing new. We have been using tools and abstractions that massively boost productivity for decades. Business as usual.

Why 2026 feels like a crisis year

If demand is still there, why does 2026 subjectively feel like a crisis year for software developers? My analysis of the market psychology behind that:

1. The fear of "tech debt"

Companies are afraid to spend millions today on software architectures or large teams for projects that new AI models could render obsolete — or solve in a radically different way — in two years.

The worry: anyone who commits to a specific framework or expensive in-house development today may be building tomorrow's legacy baggage.

The consequence: companies wait until standards for AI-native software architectures have settled. The market's own uncertainty feeds this: Gartner predicts that 40% of agentic AI projects will be scrapped by 2027,[22] and 2026 Gartner/IDC data puts the share of enterprise AI agent pilots that stall at 89%.[13]

2. The team-scaling paradox

The core uncertainty is a simple question: how many developers will we need in three years for the same work?

The worry: If AI agents multiply a single developer's productivity several times over, an aggressive hiring wave today becomes massive overcapacity tomorrow.

The consequence: Companies currently prefer to invest in higher compute capacity and AI licenses rather than in additional full-time employees. They scale performance through technology, not through headcount. The money is visibly moving in that direction: enterprises are burning through entire AI budgets in months,[11] while the hyperscalers alone are planning roughly $700 billion in AI capex for 2026.[12] Gartner even predicts that AI coding token costs will overtake the average developer's salary by 2028.[18]

3. The legacy problem

Many companies are standing in front of gigantic migration projects — replacing old COBOL or Java monoliths, for example. Here the "wait and see" attitude is extreme

The worry: Why pay consultants millions when LLMs might soon handle such migrations fully automated and error-free at the push of a button (btw: This rests on a promise that track record does not yet support)?

The consequence; Vendors are aggressively selling exactly that promise,[20][21] and as long as the pain isn't acute, those mega-projects get postponed.

What makes the situation feel even more strained is that the "freeze" is only selective. Companies are waiting on juniors while simultaneously hunting, almost frantically, for tech leads and software architects who can bridge existing systems and generative AI — the field is bifurcating, with implementation roles shrinking while system-level, architecture, and AI-oversight roles expand.[25]

The doomsday hype in the filter bubbles

In certain online bubbles — LinkedIn, select subreddits — there is a partly hysterical fear that has little to do with reality. I see four causes:

1. The "survivor bias" of the frustrated

Extremely frustrated people who wrote 200 applications and got only rejections, then pin the blame on AI — plus attention-hungry tech influencers chasing clicks and reach with dark prophecies. It is easy to overlook the thousands of developers who say nothing, write code, and use AI to write better code.

2. Confusing "coding" with "software engineering"

Most demos show an AI implementing a specific function in the shortest possible time. The thinking error is that many people believe typing code is a developer's main job. Reality looks very different: research puts the time developers actually spend writing code at around 11% of the working week — about 52 minutes a day,[26] and broader industry data on how developers spend their time points in the same direction.[17] The real work consists of tasks that LLMs cannot perform on their own.

3. Hype distortion

On LinkedIn or Reddit it often feels like the state of the art is already successfully deployed in enterprises — "AI agents now replace whole teams." In reality, companies are still fighting the basics: data privacy, hallucinations, intellectual property, and how to build a unified, resilient AI infrastructure inside an enterprise at all. The numbers tell the same story: a March 2026 survey found 78% of enterprises have AI agent pilots, but fewer than 15% have scaled even one agent to operational use.[14] Gartner's own forecast for "vibe coding" — 40% of new enterprise software built with these techniques — is only dated 2028, not today.[19]

4. Underestimating maintenance

"If AI writes the code, we don't need people" is completely wrong — the opposite is true. The cheaper it becomes to generate code, the more code exists in our systems that has to be understood, maintained, updated, and secured — work that will require plenty of developers for decades. You can already see this spillover in open-source projects, which are being flooded with AI-generated contributions: in February 2026, GitHub itself acknowledged the surge in low-quality AI-generated contributions and described it as an "Eternal September" for open source.[15]

Bottom line

The fear of the profession changing is justified. The fear of the profession disappearing is a product of filter bubbles. The profession of software developer is not dying — it is changing at high speed. Anyone who develops from a "code typist" into a "system problem-solver" will have a secure career in the future as well.

The wage data points in the same direction as the conclusion: the Stanford/ADP analysis found that workers with AI skills earn roughly 62% more than their peers.[6] If AI were simply replacing developers, it should depress their wages — and it is not. The data is consistent with a market in which AI raises the value of developers who can direct it, which is precisely the bet that the "adapt, don't panic" advice is based on.

Sources

https://newsletter.pragmaticengineer.com/p/state-of-the-job-market-2026 — The Pragmatic Engineer: State of the job market 2026
https://www.danilchenko.dev/posts/junior-developer-jobs-2026 — Danilchenko: Junior developer jobs in 2026
https://byteiota.com/junior-developer-extinction-67-hiring-collapse-explained — ByteIota: Junior developer extinction, 67% hiring collapse
https://hakia.com/news/junior-developer-crisis-2026 — Hakia: Junior developer crisis 2026
https://thecollegeinvestor.com/81990/stanford-study-entry-level-software-jobs-down-nearly-20-as-ai-reshapes-hiring-for-college-grads — The College Investor: Stanford study on entry-level software jobs
https://www.digitalecononews.com/en/articles/stanford-economist-ai-entry-level-jobs-crisis — Digital Econ News: Stanford economist Brynjolfsson on AI entry-level jobs crisis
https://msftnewsnow.com/stanford-study-generative-ai-entry-level-jobs — Stanford study: Generative AI's early impact on entry-level jobs
https://digitaleconomy.stanford.edu/project/indicators/canaries-dashboard — Stanford Digital Economy Lab: Canaries Dashboard
https://survey.stackoverflow.co/2025/ai — Stack Overflow 2025 Developer Survey: AI
https://stackoverflow.co/company/press/archive/stack-overflow-2025-developer-survey — Stack Overflow 2025 Developer Survey press release
https://www.forbes.com/sites/timbajarin/2026-04-29/ai-compute-surpasses-human-costs-enterprise-budgets-shift — Forbes: AI compute surpasses human costs, enterprise budgets shift
https://www.cnbc.com/2026-02-06/google-microsoft-meta-amazon-ai-cash.html — CNBC: Tech AI spending approaches 700B in 2026
https://www.beri.net/article/ai-agent-adoption-enterprise-2026-gartner-idc — Gartner/IDC 2026: 89% of enterprise AI agent pilots stall
https://agentmarketcap.ai/blog/2026-04-11/ai-agent-reality-check-hype-to-production-gap-2026 — AI Agent Reality Check: 78% pilots, under 15% to production
https://en.wikipedia.org/wiki/Vibe_coding — Wikipedia: Vibe coding
https://www.sonarsource.com/blog/how-much-time-do-developers-spend-actually-writing-code — Sonar: How much time do developers spend actually writing code?
https://www.software.com/reports/code-time-report — Antenna: Global Code Time Report
https://www.techtimes.com/articles/319333/20260629/ai-coding-costs-can-drain-budget-days-gartner-predicts-they-will-match-developer-pay.htm — TechTimes: Gartner on AI coding costs vs developer pay
https://theoutpost.ai/news-story/vibe-coding-transforms-software-development-as-gartner-predicts-90-enterprise-adoption-by-2028-30292 — The Outpost: Gartner vibe coding 40% by 2028
https://medium.com/@hashbyt/what-happens-when-ai-meets-legacy-cobol-systems-00dae11f51d3 — Medium: AI COBOL modernization in 2026
https://ascendion.com/ai-basic/mainframe-and-cobol-modernization-with-agentic-ai-whats-actually-possible-in-2026 — Ascendion: Mainframe modernization with agentic AI in 2026
https://www.kore.ai/blog/ai-agents-in-2026-from-hype-to-enterprise-reality — kore.ai: Gartner predicts 40% of agentic AI projects scrapped by 2027
https://gitgood.dev/blog/2026-tech-job-market-hiring-rebound-ai-roles — GitGood: 40% of SE job postings mention AI coding tools
https://ucstrategies.com/news/ibm-lost-40b-because-ai-cant-actually-modernize-cobol — UC Strategies: AI COBOL modernization evidence gap
https://theboard.world/articles/technology/will-ai-replace-software-engineers-2026-reality-check — TheBoard: Will AI replace software engineers in 2026?
https://medium.com/@vikpoca/developers-spend-only-11-of-their-time-coding-what-3a53f65982df — Ponamarev: Developers spend only 11% of their time coding

Running Self-Hosted AI Code Reviews with Ollama on a Small VPS

Tom Seidel — Thu, 10 Sep 2026 13:25:25 +0000

AI-assisted code review doesn't necessarily require sending every pull request to a hosted AI service.

For some teams, running the review workflow inside their own infrastructure can be an interesting alternative—particularly when they already operate Gitea, GitLab, GitHub Enterprise, or other self-hosted development infrastructure.

I wanted to see how small such a setup could reasonably be.

The result is a fairly simple architecture:

flowchart LR
    git["Git platform"] -->|Webhook| workflow["AI workflow"]
    workflow -->|Repository context + prompt| ollama["Ollama"]
    ollama --> model["Local coder model"]
    model -->|Review comments| git

There is no per-developer component in this architecture. The main constraints are instead the compute required by the model, the size of the pull requests being reviewed, and how quickly you expect reviews to complete.

For my experiments I use AI-Git-Bot as the workflow layer, Ollama as the local inference server, and an open-weight coder model.

The interesting part isn't really the particular bot, though. It's what becomes possible once the Git workflow and the model runtime are separated.

Why run code review locally?

Hosted AI development tools are convenient, and for many teams they're probably the simplest option.

But they also come with trade-offs.

Pricing commonly scales with the number of developers, while the underlying workload doesn't necessarily do so in the same way. A ten-person team might generate fewer pull requests than a three-person team working on a very active repository.

There is also the question of where source code is processed.

Depending on the organization, sending diffs to an external model provider can require additional security, contractual, or compliance review. In some environments it isn't allowed at all.

A self-hosted setup changes those trade-offs:

flowchart LR
    repo["Repository"] -->|Webhook| workflow["Workflow engine"]
    workflow -->|Prompt + context| model["Local model"]
    model -->|Review result| workflow
    workflow -->|Publish findings| repo

The source code, prompts, model inference, and generated review stay within infrastructure you control.

The downside is equally important: you now operate the infrastructure yourself.

You have to think about memory, model performance, updates, monitoring, and what happens when the model produces a poor review.

So this isn't automatically a better architecture. It's just a different one.

What the workflow layer does

A local LLM alone isn't enough to provide automated code reviews.

Something still needs to:

react to pull-request events,
retrieve the diff and repository context,
construct the prompt,
call the model,
interpret the response,
and publish findings back to the Git platform.

That's the role AI-Git-Bot plays in my setup.

It supports GitHub/GitHub Enterprise, Gitea, GitLab, and Bitbucket Cloud and can react to normal Git events.

For example:

Workflow	Trigger	Result
PR review	PR opened / review requested	Summary and findings
Interactive Q&A	Bot mentioned in a PR	Context-aware answer
Unit-test generation	PR opened	Regression tests
E2E / full-stack QA	PR opened	Test execution and results
Issue triage	Issue opened	Classification or assignment
Issue implementation	Issue assigned to coding agent	Implementation pull request
Documentation sync	PR opened	Documentation changes
i18n coverage	PR opened	Missing translations

Not every workflow makes sense with a small local model.

That distinction turned out to be quite important.

A minimal deployment

For a self-hosted experiment, the basic stack consists of:

AI-Git-Bot
PostgreSQL
Ollama
an open-weight coder model

A simplified Docker Compose setup looks like this:

services:
  app:
    image: tmseidel/ai-git-bot:latest
    ports:
      - "8080:8080"
    environment:
      SPRING_PROFILES_ACTIVE: docker
      DATABASE_URL: jdbc:postgresql://db:5432/giteabot
      DATABASE_USERNAME: giteabot
      DATABASE_PASSWORD: giteabot
      APP_ENCRYPTION_KEY: change-me
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    environment:
      POSTGRES_DB: giteabot
      POSTGRES_USER: giteabot
      POSTGRES_PASSWORD: giteabot
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U giteabot"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    restart: unless-stopped

  ollama-pull:
    image: ollama/ollama:latest
    entrypoint:
      - sh
      - -c
      - sleep 5 && ollama pull qwen2.5-coder:7b
    environment:
      OLLAMA_HOST: http://ollama:11434
    depends_on:
      - ollama

volumes:
  ollama_data:
  pgdata:

Once Ollama is running, the AI integration points at:

http://ollama:11434

with, for example:

qwen2.5-coder:7b

There are no model API credentials involved because inference happens locally.

How small can the model be?

This was the more interesting question.

A 7B coder model is obviously not going to compete with the largest hosted reasoning models on every task.

But not every Git workflow needs the same capabilities.

I've found a useful distinction between workflows that mostly generate natural language and workflows that need reliable agentic behavior.

Workload	7B class	14–32B class
PR review	Works reasonably well	Better
Explain a change	Works reasonably well	Better
Documentation updates	Often sufficient	Better
Issue classification	Depends on required output structure	Better
Multi-step coding agent	Limited	Much more suitable
Strict structured output	Can be unreliable	More reliable

For a pull-request review, a smaller model can still inspect a diff and produce useful natural-language observations.

Agent workflows are harder.

Consider an issue-to-pull-request workflow:

flowchart TD
    issue["Issue"] --> understand["Understand task"]
    understand --> inspect["Inspect repository"]
    inspect --> choose["Choose files"]
    choose --> edit["Modify code"]
    edit --> test["Run tests"]
    test --> result{"Tests pass?"}
    result -->|Yes| pr["Create pull request"]
    result -->|No| diagnose["Interpret failures"]
    diagnose --> edit

Each additional decision increases the importance of reasoning quality, tool use, structured output, and instruction following.

That's where the difference between a small local model and a larger model becomes much more visible.

A hybrid setup may be more practical

Self-hosting doesn't have to mean that every workflow uses the same local model.

For example:

flowchart LR
    event["Git event"] --> workflow["Workflow"]
    workflow -->|Review task| local["Local 7B model"]
    local --> review["PR review"]
    workflow -->|Agentic task| large["Larger model"]
    large --> agent["Coding agent"]

The inexpensive, frequent tasks can run locally.

The less frequent workflows that need stronger reasoning can use a larger local model or an external provider.

I find this architecture more interesting than treating the model provider as a global application setting.

Different workflows have different requirements.

A PR summary, security review, issue classifier, and autonomous coding agent don't necessarily benefit from the same model.

What about the "$5 VPS"?

This needs a qualification.

The application itself is lightweight. Model inference is not.

A quantized 7B model is only a few gigabytes on disk, but the machine also needs memory for the model runtime, context, operating system, database, and application.

So whether an actual $5/month VPS is sufficient depends heavily on the provider, available RAM, CPU performance, context size, and acceptable latency.

If you already have an 8 GB machine, a small home server, a workstation, or other unused infrastructure, the incremental software cost can be close to zero.

If you're renting infrastructure specifically for inference, you should size and benchmark it rather than assuming the cheapest VPS will provide acceptable performance.

For me, the useful observation isn't really "$5."

It's this:

The cost of a self-hosted review service is primarily tied to the inference infrastructure and workload rather than directly to the number of developers using it.

That's a different scaling model from per-seat SaaS.

Whether it's cheaper depends on your team and infrastructure.

CPU inference is possible, but latency matters

A GPU isn't strictly required for experimenting with a 7B quantized model.

CPU inference works.

But "works" and "feels fast" are different things.

For asynchronous workflows such as pull-request review, latency is often less critical than it would be for an interactive coding assistant.

If a review takes a few minutes after a pull request is opened, that may still be perfectly usable.

For interactive Q&A or agentic coding loops, the same latency becomes much more noticeable because every model call is part of a sequence.

This is another reason I wouldn't use one deployment strategy for every AI-assisted development workflow.

Where I think this architecture makes sense

There are a few situations where I've found self-hosting particularly interesting.

Self-hosted Git platforms

A lot of AI developer tooling starts with GitHub support.

If your organization primarily runs Gitea or another internally hosted Git platform, connecting a generic workflow layer to a local model can be more flexible than trying to fit the environment into a GitHub-centric SaaS product.

Source code shouldn't leave the network

Some teams have contractual, regulatory, or internal-security constraints around source code.

Keeping the complete path

flowchart LR
    git["Git platform"] -->|Event + repository data| workflow["Workflow engine"]
    workflow -->|Prompt + context| model["Local model"]
    model -->|Generated result| workflow
    workflow -->|Comment or change| git

inside the same environment makes that boundary easier to reason about.

It doesn't automatically make the system secure—you still have to secure the infrastructure—but the data flow is much simpler.

Existing compute is available

If an organization already operates machines with sufficient RAM or GPU capacity, running another small inference workload may be inexpensive.

The economics are quite different if hardware has to be purchased specifically for the workload.

What this setup doesn't replace

A self-hosted review workflow isn't a replacement for every AI developer tool.

It isn't code completion.

An IDE assistant helps while code is being written. A Git workflow operates after an event such as opening a pull request.

Those are different places in the development lifecycle.

It also doesn't remove the need for human review.

I treat model-generated findings much like static-analysis findings: potentially useful signals that still need context.

And a smaller local model makes that distinction especially important.

The experiment I find interesting

What started as an attempt to run inexpensive AI code reviews has turned into a broader architectural question for me:

How much AI infrastructure actually needs the largest available model?

Some development workflows clearly benefit from powerful reasoning models.

Others look much more like repeated, bounded classification or transformation tasks.

Once those workloads are separated, the architecture becomes more flexible:

flowchart LR
    git["Git"] --> workflow["Workflow"]
    workflow --> route{"Choose model for task"}
    route --> local["Small local model"]
    route --> large["Large local model"]
    route --> hosted["Hosted reasoning model"]

The workflow chooses the appropriate model for the task rather than treating "the AI" as one monolithic dependency.

That's also where I'm currently experimenting with AI-Git-Bot.

The project is MIT licensed, and the repository contains deployment and Ollama examples if you want to reproduce the setup.

If you've tried running code review on small local models, I'd be especially interested in hearing which model and hardware combination you used—and where you found the quality threshold stopped being acceptable.

AI-Git-Bot — an open-source gateway that connects your Git platforms with AI providers

Tom Seidel — Sun, 12 Apr 2026 10:35:23 +0000

🚀 Excited to share AI-Git-Bot — an open-source gateway that connects your Git platforms with AI providers for automated code reviews and autonomous issue implementation.

After weeks of development, I'm proud to release v1.2.0 of AI-Git-Bot — a lightweight, self-hostable application that sits between your Git hosting and AI providers, acting as an intelligent gateway.

🤖🧠 Half Bot, Half Agent

As a Bot: It automatically reviews pull requests, answers questions in comments, and delivers context-aware inline feedback — like a code-review partner that never sleeps.

As an Agent: Assign it to an issue and it autonomously reads the codebase, generates an implementation, validates the code with build tools, and creates a finished pull request — all on its own.

🌉 The Gateway Principle

What makes AI-Git-Bot unique is its gateway architecture:
✅ 5 Git platforms — Gitea, GitHub, GitHub Enterprise, GitLab, Bitbucket Cloud
✅ 4 AI providers — Anthropic Claude, OpenAI, Ollama, llama.cpp
✅ Mix & match — Any Git platform with any AI provider
✅ Multi-bot — Different personas (security reviewer, performance expert, mentor) on the same PR
✅ One dashboard — Manage everything through a web UI

🔒 Built for Self-Hosters

Run everything on-premise with local LLMs. No code ever leaves your infrastructure — perfect for teams with regulatory or compliance requirements.

Tech Stack

☕ Java 21 / Spring Boot 4
🐘 PostgreSQL
🐳 Single Docker image

Get Started

docker compose up -d

That's it. Navigate to localhost:8080, create an admin account, configure your integrations, and you're reviewing code with AI.

📦 GitHub: https://github.com/tmseidel/ai-git-bot
🐳 Docker Hub: https://hub.docker.com/r/tmseidel/ai-git-bot

📄 License: MIT