DEV Community: Alexander Thalhammer

Agentic Engineering: How to Set Up Your Harness for Angular Development

Alexander Thalhammer — Fri, 26 Jun 2026 08:12:15 +0000

Agentic Engineering: How to Set Up Your Harness for Angular Development

Over the last few weeks (starting in late May 2026) I've written about which LLM is best for Angular development and, right after, about which app or harness to use around it. In that second post I treated the words app and harness as more or less the same thing and never really drew a line between them. This post is the follow-up that does exactly that.

It zooms in on the harness: what it actually is, and how to set one up for your Angular projects so the agent not only runs smoothly, but produces generated and refactored code that I would actually accept in long-lived, continuously evolving Angular codebases.

TL;DR: The Harness Is Where Your Quality Lives

If you only have thirty seconds: the harness is the software around the model – it gives the LLM its tools and runs the agentic loop, and it is the layer you control. Set it up in five steps: a clean baseline, formatting and linting that run on every commit, your own Angular style guide (the single highest-leverage file in the whole setup), an AGENTS.md operating contract, and thin config files that wire every agent back to the same rules. Then give the agent fast feedback loops, from ng lint all the way to Playwright. Everything below lives in the companion repo ng-agentic.

So What Is the Harness?

Small naming note for Angular readers: I do not mean the Angular CDK ComponentHarness for testing components. In this post, a harness is the software around the model.

The harness is the thing that contains the model. And here's what a lot of people miss: on its own, even a strong LLM is basically just fancy autocomplete, like the one we've been using for years from GitHub Copilot. The only thing it can really do is respond to our messages by writing text. So how is it possible that it can edit our code at all?

This is where the harness comes in. It gives the model the power of tool calling, and suddenly that autocomplete can do real work: list the current directory, search the whole project for inject(, open a file, apply an edit, run ng build. Instead of only writing text back to us, the model emits a structured tool call, the harness actually runs it, and then feeds the result back into the conversation. (Simon Willison has a really nice, no-nonsense walk-through of how coding agents work if you want to go one level deeper.) So in short: the harness is the wrapper around the model that lets it read our projects and then actually change them.

And that feedback loop is the whole trick. A coding agent is really just our LLM running in a loop: it proposes an action, the harness runs the tool and hands the output back, the model reads that output and decides what to do next – open another file, fix the error it just caused, run the tests again. This loop is what most people mean today when they talk about AI agents: the harness manages the context, the tools, the prompts, and the control flow, while the model does the actual reasoning.

If that loop feels like a big jump from the autocomplete days, that's because it is – but we got here in small steps. First we copy-pasted code into ChatGPT and pasted the answers back, being the loop ourselves. Then the chat moved into our IDEs, right next to the code. Then came tool calling, and the wrapper could suddenly act instead of just talk. And today the harness runs the whole loop for us. The models improved along the way, sure – but every one of those steps was a harness step.

My personal take? The harness, not the model, is where most of the day-to-day quality comes from. Two developers can run the exact same Opus or GPT model and still get wildly different results, simply because one harness has the right tools, the right project context, and sensible guardrails – and the other doesn't. And that's exactly why this post exists: the harness is the part you control, so setting it up properly for Angular is not some nice-to-have. In my opinion, it's the highest-leverage thing you can do.

Model, Harness, App – What's the Difference?

We now know what a harness does – but it's easy to confuse it with the model underneath it and the app around it. So let me make that concrete with the exact setup I've been using for Angular development today:

The model (our LLM): Opus – the brain (BTW, I hope we get Fable 5 back soon 😏).
The harness: Claude Code – gives Opus its tools and runs the loop we just talked about.
The app: the Claude Desktop app – the window I happen to be looking at all of this through.

Here's the part that trips a lot of people up: we can swap the app without touching the harness or the model at all. The exact same Claude Code + Opus combination can live in a bunch of different places:

in the Claude Desktop app,
in the Claude Code CLI, right in our terminal – historically its native home,
as the official Claude extension in VS Code,
as the official Claude plugin in WebStorm (and the other JetBrains IDEs),
and even inside Cursor – whose extension is basically the same one we use in VS Code, since Cursor is a VS Code fork.

Same brain, same harness, five different windows. The app is mostly just the UI we sit in front of. BTW, everything we said about the Claude Code harness is also true for Codex. You can use it in the Codex app, in the terminal directly, or in an extension in VS Code, JetBrains IDEs, or Cursor.

Now it gets interesting. Inside Cursor, we don't have to use the Claude extension at all – we can switch to Cursor's own harness instead, still running Opus underneath. So suddenly we have one app and one model, but two different harnesses to choose from. That's the cleanest way I know to actually feel the difference: nothing changed except the harness.

And harnesses are not created equal. In my experience – and in some benchmark results – Cursor's own harness can squeeze noticeably more out of the same Opus model than the Claude extension does: better scores, smoother experience. The gap can be surprisingly large: in an independent benchmark cited in Paweł Józefiak's harness comparison, the same planning task with the same model went from 77% running in Claude Code to 93% in Cursor – nothing changed but the harness. That does not mean Cursor wins every harness benchmark; the Artificial Analysis chart below shows a different picture for a different Opus comparison. The point is narrower and more important: the wrapper changes the result.

And the reason isn't magic, it's tuning: a team like Cursor's pours real effort into shaping its tools, system prompt, and tool descriptions for each new model, and that hand-tuning is what wrings the extra points out. So why would anyone still pick the Claude extension inside Cursor? One big reason: cost. With the Claude extension you can run Opus on your existing Claude subscription, while Cursor's harness bills you per API token. For heavy daily Angular work, that's the difference between a flat monthly fee and a frankly scary API bill.

So that's the whole picture: the model is the brain, the harness is what gives it hands and runs the loop, and the app is just the window we watch it through. We can mix and match them surprisingly freely – and as the rest of this post will show, the harness is the layer that's really worth getting right.

When the Claude Code Harness Leaked

If you ever doubted that the harness is its own engineering layer, April 2026 gave us an accidental case study. A Claude Code npm package included source maps that exposed a large part of the TypeScript source, so developers could inspect the harness from the inside.

And what was visible? No secret model, no hidden API – mostly the harness. The leaked code exposed Claude Code's system prompt, the definitions and logic for its tools (bash, read, write, edit, glob, grep), the shape of its agentic loop, and how it pulls in CLAUDE.md. In other words: exactly the stuff we've been calling "the harness" all along. Anthropic's public statement framed it as a release packaging issue rather than a customer-data breach.

For me, the fascinating part is what it confirmed: a huge amount of what makes Claude Code feel so capable lives in the system prompt and the tool descriptions, not only in the model weights. That's the harness doing its job – and a pretty good reminder that this layer is something real, inspectable, and very much worth getting right.

So Which Harness Is Best for Angular?

So if the harness is the layer worth getting right, the obvious next question is: which one should we actually use for Angular? Short answer: I can't prove it. There's no benchmark that measures the "best harness for Angular" specifically, and honestly I don't think there could be one – so everything in this section is my personal, subjective verdict, same as the rest of this series.

That said, there is one place we can compare setups with the model held fixed. The Artificial Analysis Coding Agent Index is one of the few benchmarks where that's actually possible – for example, here is the same Opus model at medium effort running through opencode, Cursor CLI, and Claude Code:

Harness comparison by Artificial Analysis for the same Opus model at medium effort across opencode, Cursor CLI, and Claude Code – click the chart for the live comparison. That's exactly what makes it a harness benchmark and not just another model leaderboard.

In the Terminal

If you live in the terminal, here are the harnesses worth knowing about, roughly in the order I'd reach for them today:

opencode – if you only want one recommendation, start here. It's the open-source community favorite – a polished, terminal-native harness with a huge user base, and it's just as bring-your-own-key and model-agnostic as the rest, so you can point it at Opus, GPT, Gemini or even a local model.
Pi – the alternative for the tinkerers among us. A refreshingly minimal harness built around a tiny core that you extend yourself with TypeScript extensions and skills. Lovely if you enjoy reshaping your tools; probably overkill if you just want to get coding.
Claude Code – a few months ago, this was the one to beat: one of the best harnesses and one of the best overall experiences you could get in the terminal, full stop. Honestly, though, I wouldn't reach for it there anymore. It's the same harness that now powers the Claude Desktop app, and the experience inside that app – and the other super apps – has become so much better that the bare CLI just doesn't feel worth it today.

The Super Apps

Personally, though, I keep coming back to the super apps: Codex, the Claude Desktop app, and Cursor. As I wrote in the apps and harnesses post, these three give me the biggest, most polished feature set – and they happen to ship really good harnesses, too. As an app, I personally like Codex the most.

So where does that leave us? All three of my go-to super apps (Codex, the Claude Desktop app and Cursor) are genuinely good choices. For me it mostly comes down to whether I want GPT or Opus doing the work – and whether I feel like switching between them depending on the task. If you like to switch, you can either juggle several apps and harnesses (what I usually do), or just use Cursor for everything, since it happily runs all the major models under its own harness.

Inside Your IDE

Not everyone wants to leave their editor, though. If you'd rather keep the harness inside your IDE, Cline is the one I'd point you to: an open-source, model-agnostic extension that drops into VS Code (and its forks, plus JetBrains) and runs whatever model you bring – Opus, GPT, Gemini, or a local one. Same bring-your-own-key, vendor-neutral spirit as opencode, just living in your editor instead of the terminal.

And here's the part I didn't see coming: you don't always have to pay per API token. Cline can run on the subscriptions you already have instead of metered API billing – sign in with your OpenAI account to use your ChatGPT plan through the OpenAI Codex provider, or point it at a locally authenticated Claude Code CLI to bring your Claude plan. Either way it's the same flat-fee-not-scary-bill advantage I made a fuss about above, now inside your editor. (The Claude path trades away token-by-token streaming and some prompt caching for it, but for daily Angular work that's an easy deal.)

One setup I'd gently steer you away from, even though it's still the most common one I see: plain VS Code with GitHub Copilot. The GPT model inside is perfectly capable – this isn't a model problem. It's that Copilot grew out of autocomplete, and its agent experience still feels a step behind the purpose-built harnesses to me. Tellingly, even VS Code's own team now frames Copilot around "the harness" – "The model is the engine. The harness is the car." – and says it's where they spend most of their engineering time. They're right. So if your whole AI setup is still VS Code plus Copilot, that's exactly the setup worth outgrowing.

The Fourth Factor: Your Codebase

So far this post has been about three things you assemble: the model, the harness, and the app. But there's a fourth factor that quietly shapes everything the agent produces, and it's the one you can't pick from a menu: your existing codebase.

Here's why it matters so much. An agent doesn't write Angular in a vacuum – it reads the code around the change first, and then it imitates. Give it a clean, modern, consistent codebase and it has the best possible reference: it sees your real components, your signal stores, your services, and writes new code that looks like what's already there. In a codebase like that, honestly, the harness setup matters less – the style guide, the AGENTS.md, the lint rules are still worth having, but the code itself is already doing half the teaching.

Now flip it. Point the same agent at a legacy codebase – any everywhere, NgModules, *ngIf, RxJS where signals belong, no strict typing, a barely-there ESLint config – and it imitates that instead. It will happily match the mess, because the mess is what it sees. This is where the setup stops being a nice-to-have and becomes the thing holding the line: a strong style guide, strict TypeScript, a serious ESLint rule set, and an opinionated AGENTS.md are what override the bad examples in the surrounding code and pull the output back up to the standard you actually want.

So there's an inverse relationship worth internalizing: the worse your codebase, the more your harness setup matters. On a pristine greenfield project you can get away with a light touch. On the brownfield codebases most of us actually work in, the guardrails and the style guide aren't decoration – they're the only thing between you and an agent that cheerfully writes 2019-era Angular because that's what it found lying around.

With a harness picked – and a clear-eyed sense of the codebase you're aiming it at – the real work only starts: actually setting it up so it writes Angular the way we want. That's what the rest of this post is about.

So How Do I Actually Set This Up?

Enough theory – let me show you the exact setup I use. Everything below lives in a companion repo, ng-agentic: a small Angular workspace I generated fresh with the Angular CLI 22 and then turned, commit by commit, into something every agent can work in. Clone it, read through the history, or just follow along here and build the same thing into your own project – either way, the goal is one workspace where the harness produces the Angular code we actually want.

At a high level, the setup has five parts:

start from a clean CLI baseline, or identify the brownfield baseline you already have
make formatting and linting non-negotiable
hand the agent your Angular style guide
turn AGENTS.md into an operating contract
wire every app, IDE, and agent back to the same rules

That greenfield-or-brownfield choice shows up immediately, at the very first command. I went greenfield for this repo – a fresh ng new – because it makes every step easy to show on its own. But let's be honest: most of us aren't starting from scratch. We're dropping the agent into an existing Angular app – brownfield, legacy or not – the more common case by far. The good news is that almost everything below is identical either way. The only greenfield-only step is the ng new itself – on an existing project you simply skip it and layer the same tooling and conventions on top of what you already have.

Start from a Clean `ng new`

The greenfield path is the boring one – a fresh project straight from the Angular CLI:

ng new ng-agentic

That gives us the usual scaffold – config, dependencies, a starter component, an initialized Git repo. The CLI can also generate agent config for us along the way – either when ng new asks which AI tools we use, or later via ng generate ai-config – and that's where the first AGENTS.md comes from, the file every agent reads first. We'll make that file do real work further down; for now it just needs to exist.

The only cleanup on that first commit was trimming a few duplicated instructions out of the generated AGENTS.md and running the formatter over everything:

pnpm format   # runs prettier --write .

Doing that by hand on every commit gets old fast – which is exactly the next thing to automate.

Quality Gates: Make Formatting and Linting Non-Negotiable

Here's the thing about handing an agent the keys: it'll write code in whatever style the prompt nudges it toward, and it'll just as happily commit a half-formatted mess if nothing stops it. So before I teach the harness how I want my Angular written, I give it a hard floor it can't sink below – formatting and linting that run automatically on every commit, whether the code came from me or from the model.

The enforcer is a Husky pre-commit hook:

pnpm add -D husky
pnpm exec husky init

husky init creates .husky/pre-commit; I point it at the project's format script, so every commit gets prettier-formatted before it lands. No more "fix formatting" commits, and no more arguing with the agent about quotes and trailing commas.

Formatting is the easy half. For real code quality I add Angular ESLint, which understands Angular and not just plain TypeScript:

ng add @angular-eslint/schematics

Linting the whole project on every commit is slow, so I scope it to the staged files with lint-staged and run that from the hook instead:

{
  "lint-staged": {
    "*.{html,js,ts}": ["eslint --fix", "prettier --write"],
    "*.{css,json,md,scss}": ["prettier --write"]
  }
}

The default Angular ESLint preset is fairly relaxed, so I tighten eslint.config.js with the stricter rules I actually care about, then do a one-time cleanup pass with ng lint --fix.

And here's a small moment that captures the whole point of this post. After the auto-fix, two issues are left that ESLint won't touch on its own – a component missing OnPush, and a function missing its return type. Both are mechanical, so I don't fix them by hand: I hand them to the agent and let the harness close its own loop. The guardrail flags the problem, the model fixes it, and the hook verifies the fix on the way back in.

One word for the brownfield crowd: that first ng lint won't print two warnings, it'll print a few hundred. Don't --fix the whole pile in one heroic commit – treat that wall as your honest baseline, the real starting state of the code, and chip away at it deliberately. It's exactly the kind of backlog the agent is good at later, but that's a story for another post.

Hand the Agent Your Style Guide

If you take only one thing from this entire post, take this one. The style guide is the single highest-leverage file in the whole setup – it matters more than the linting, more than the MCP servers, more than the clever AGENTS.md we'll get to next.

Here's why. A strong model already knows Angular – generically. Ask it for a component and you'll get a perfectly reasonable, perfectly generic one: maybe Jest where you use Vitest, maybe half-remembered NgModules from 2021, maybe RxJS where you'd reach for a signal. What the model doesn't know is how your team writes Angular – your stack, your conventions, your taste. The style guide is where you hand it exactly that. And the moment you do, the harness stops writing generic Angular and starts writing yours.

In the repo this lives in a style-guide/ folder. One general style-guide.md sets the baseline – it pins the target stack (Angular v22+, TypeScript 6, zoneless, Vitest + Playwright) and lays out plain Do / Should / Don't rules. It's a living document, too – versioned (2.0.1 as I write this), not a one-off.

Around that baseline sit focused, file-type-specific guides. Start with the Angular Coding Style Guide itself, then jump straight to whichever specific one is relevant:

Two design choices in here are worth copying:

It's written for humans and agents at once. Same document, one source of truth. A new teammate reads it on day one; the agent reads it on every task. No second set of conventions quietly drifting out of sync.
It's split by file type on purpose. When the agent edits a template, it should pull in the HTML guide – not the SCSS rules, not the testing checklist, not the entire wall of conventions at once. This isn't just tidiness: a model's accuracy actually drops as its context fills up, and burying the one rule that matters among hundreds that don't is the worst needle-in-a-haystack problem you can hand it. Picture fixing a bug when you're shown the two files it might live in versus all two thousand. Narrower, relevant context means sharper focus and better output, and it pays off more and more as the guide grows.

So this is the section to spend real time on. Borrow the structure from the repo if you like, but fill it with your rules – the ones you'd give a sharp new hire in their first week. That document is what turns a capable-but-generic harness into one that writes Angular the way your codebase actually wants it written.

And mine is genuinely never finished. I keep refining this style guide as Angular moves and as I learn what actually holds up in practice – so if you spot something missing, something you'd do differently, or a rule that has aged badly, I'd honestly love to hear it. Open an issue or a pull request on the repo, or just reach out and tell me. Good conventions are a team sport, and this one gets a little better every time someone pushes back on it.

Turn AGENTS.md Into an Operating Contract

If the style guide is about how the code should look, AGENTS.md is about how the agent should behave – the rules of engagement it reads before it touches anything. The version the CLI generates is fine, but generic. So I rewrote it into a repo-specific operating contract: a short document that tells the harness exactly how to act in this codebase.

The part I care about most is the workflow rules, because this is where a model goes from "powerful but a bit reckless" to "careful teammate." A few that earn their place:

Preserve my edits. Before changing a file, check its current state and don't revert, rewrite, or drop my changes or comments unless I asked. It's the same rule I'd give any human collaborator – and the one I try to hold myself to.
Keep fixes local. When fixing a bug, change the minimum needed. No opportunistic refactors, no "while I'm here" cleanups smuggled into the diff. Spotted a worthwhile refactor? Suggest it; don't sneak it in.
Stay in your lane. Don't touch unrelated files, prefer minimal diffs, and run lint and the relevant tests before declaring a task done.
Don't start the dev server. Never fire up ng serve on its own – I usually already have one running on :4200.

This is also where the two layers connect. AGENTS.md is the primary instruction – the one file the agent always loads, on every task, no exceptions. The style guides are not; they come in through progressive disclosure, just-in-time, only when the agent actually touches a matching file. Create or edit a template and the HTML guide loads; touch a .scss and the styling guide loads; nothing else competes for the model's attention. AGENTS.md spells out that contract in one decisive line – read only the narrowest relevant guide – plus a precedence rule: project rules override generic Angular advice and any skill's examples. That precedence is what stops a confident model from quietly defaulting to the Angular it learned two years ago.

There's a deeper reason this file pulls its weight. An agent starts every session knowing nothing about your repo – and if something isn't in its context, it may as well not exist for the model – so without AGENTS.md it has to spend tool calls rediscovering how the project is laid out, every single time. AGENTS.md front-loads just enough to skip that: not the whole codebase, but the always-true orientation – your conventions, where things live, which narrow guide to read next – so the agent starts pointed in the right direction instead of guessing.

And it bakes in the modern Angular v22+ defaults so I don't have to repeat them in every prompt: standalone and zoneless, signals over decorators (input(), output(), computed(), .set()/.update() – never .mutate()), native @if/@for instead of *ngIf/*ngFor, resource()/rxResource() for data fetching, inject() over constructor injection, strict TypeScript with no any, ever, AXE/WCAG AA on every template, and no .spec.ts files unless a real Vitest or Playwright setup exists. (Always worth mentioning: computed() is my favorite feature in modern Angular.)

One warning from experience, though. The moment you have three layers of rules – AGENTS.md, the style guides, and the ESLint config – they can quietly start to contradict each other, and a contradiction is worse than no rule at all. If AGENTS.md says "Signal Forms" while a style guide still shows a Reactive Forms example and ESLint enforces neither, the agent picks one almost at random and burns a round-trip second-guessing itself. So I treat the three as a single system: they have to say the same thing, and wherever a rule can become an ESLint rule, I make it one – a check the harness actually runs beats a sentence it merely reads. Manfred takes this same principle all the way up to architecture itself – turning layer and domain boundaries into checks the agent must satisfy, with Sheriff and feedback hooks.

The whole thing fits on a screen or two – you can read the full AGENTS.md in the repo. Steal what fits, drop what doesn't; the point isn't my exact rules, it's that the agent should walk into every task already knowing how your team works instead of guessing.

A caveat before we wire everything up: this setup is tuned for a specific model generation. The style guide, the AGENTS.md, and the level of detail in both were developed and tested against Opus 4.5 to 4.8 and GPT-5.2 to 5.5. Newer, more intelligent models that were trained on the latest Angular and TypeScript best practices – think Fable 5 or GPT-5.6 – will likely need less steering, and I'll have to reevaluate which of these detailed rules still earn their place and which the models simply internalize by then. So treat all of this as a constantly evolving instruction set, not a finished artifact.

Wire Up Every Agent

The last step is pure plumbing, but it's what makes the whole thing portable. Everything so far lives in AGENTS.md and the style guide, so the final move is simply to make every tool read them. Each assistant – Claude Code, Codex, Cursor, Cline, Junie, Gemini, Windsurf, GitHub Copilot, plain VS Code – gets a thin little file (.cursorrules, .clinerules, .gemini/GEMINI.md, .github/copilot-instructions.md and friends) that does nothing but point back to AGENTS.md. Yes, that includes the ones I'd nudge you away from – if a teammate still reaches for Copilot, it should at least follow the same rules as everyone else. One brain, many front-ends: switch tools and the rules come with you.

Two more things round it out – and the first one deserves a better introduction than the throwaway sentence I almost gave it. I register the project's MCP servers once in .mcp.json (Angular CLI, Spartan UI, Chrome DevTools, Figma) so any agent can reach the same extra tools. That sounds like plumbing, but it quietly fixes a model limitation nothing else in this setup touches: the knowledge cutoff. Every model stopped learning at some point in the past – ask it about an Angular v22 API that shipped after that date and it will confidently improvise something v18-flavored instead. The Angular CLI MCP server closes exactly that gap: it hands the agent live documentation search and curated, current code examples, so it can look up what it cannot know. Think of it as the counterpart to the style guide: the style guide teaches the harness our conventions, the MCP server keeps it honest about the framework itself.

Alongside that, I make sure no agent ever reads secrets or environment files – .env, *.pem, *.key, Angular's environment*.ts. Fair warning: there's no .gitignore-style standard for this yet (ironic, given how nicely AGENTS.md converged), so this one is per-tool config. For Claude Code, it's permissions.deny rules in .claude/settings.json – a committable file, so the whole team gets the same policy:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./.env.*)", "Read(*.pem)", "Read(*.key)", "Read(./src/environments/**)"]
  }
}

For Codex, it's a permissions profile in .codex/config.toml, enforced by its sandbox:

default_permissions = "no-secrets"

[permissions.no-secrets.filesystem]
"**/.env" = "deny"
"**/.env.*" = "deny"
"**/*.pem" = "deny"
"**/*.key" = "deny"
"**/environments/**" = "deny"

Not pretty – the same rule written twice – but these are checks the harness actually enforces, and by now you know how much I prefer those over conventions the agent merely promises to follow. The rest is housekeeping: a .prettierrc.json rename and an ng:update script for upgrades. It's all in the repo if you want the exact files.

And that's the setup – or at least the static half of it. None of these last pieces are clever on their own, but together they mean the harness behaves the same whether I open Codex today or Cursor tomorrow – and that every one of them writes Angular the way I actually want. What's still missing is the dynamic half: all these rules tell the agent what good Angular looks like, but they don't tell it whether the code it just wrote actually works. For that, it needs feedback.

Feedback Loops

Remember the loop from the beginning of this post – the agent proposes an action, the harness runs it, the model reads the result and decides what to do next? That loop is only as good as what flows back through it. Everything we've set up so far tells the agent what good Angular looks like; feedback loops are how it finds out whether it actually delivered. The more of them the agent can run on its own, the less it has to guess – so I hand it several, ordered here from cheap to expensive. (The agent-facing side of these loops – lint and static verification, who owns the dev server, test setup boundaries – is captured in AGENTS.md, of course.)

One thing before we walk through them, because it's what turns these loops from advice into a system: the best feedback is the kind the harness enforces, not the kind the agent merely promises. My AGENTS.md says "run lint and the relevant tests before declaring a task done" – but that's a sentence the model reads, and a model in a hurry will happily skip it and report success anyway. Most harnesses can make the check deterministic instead. Claude Code, for example, has hooks: I can register a Stop hook that fires whenever the agent believes it's finished, runs ng lint or the tests, and – if anything fails – blocks the "done" and feeds the errors straight back into the loop. The agent doesn't get to decide it's finished; the check does. Same principle as the ESLint moment earlier – a check the harness actually runs beats a sentence it merely reads – applied at the moment it matters most: right when the model would say "it should work now".

Linting

The cheapest loop, and the first one the agent should hit. ng lint turns all the static rules we configured above into immediate feedback – style, accessibility, and TypeScript issues surface before anything even runs, and the diagnostics flow straight back into the agent's next step. This is the guardrail-fixes-itself moment from the ESLint section, running on every task.

Building

ng build answers the bigger question: does the whole Angular graph still compile? Strict TypeScript, templates, imports, bundling – if any of it broke, the error output hands the agent the exact files and symbols to fix. No guessing, no "it should work now".

Serving

The dev server is the live loop: manual checks, browser inspection, debugging. But this one comes with my house rule from AGENTS.md: the agent does not start the dev server – I do. I want full control of that process, and there's usually one running on :4200 anyway. The agent should use the app that's already running instead of firing up its own.

Chrome Debugger

Some tools, including Codex, ship an internal browser the agent can use to debug browser state, console errors, network traffic, and interaction bugs. Honestly, I still prefer my own Chrome in debugging mode: start it with a remote debugging port – the Chrome DevTools remote debugging docs explain the setup in more detail – for example open -na "Google Chrome" --args --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-agent-debug – and then connect Chrome DevTools or the agent's browser tool to http://localhost:9222. Same spirit as the dev server rule: my browser, my process, my control.

E2E Testing

The most expensive loop, and the one that catches what all the others miss: real user flows in a real browser. When a Playwright (or Cypress) run fails, the screenshots, traces, logs, and failure messages are exactly the kind of focused feedback an agent can use to repair the feature – much better than me describing the bug in prose.

Agentic Engineering Workshop

Everything in this post – the guardrails, the Angular Coding Style Guide, the opinionated AGENTS.md, and the work of keeping all three in sync – is exactly the kind of setup we build together, hands-on.

If you want to build this kind of setup for your own Angular projects – an AI-ready workspace, real guardrails, and a strict human-in-the-loop workflow where every generated line still looks handcrafted – join our Agentic Engineering Workshop, available in English and German.

In the workshop we take exactly this foundation further: spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring – moving advanced Angular teams from vibe coding to traceable Agentic Software Engineering workflows.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

If there's one line to take away, it's the same idea this post started with: the harness, not the model, is where your day-to-day Angular quality comes from. The model will keep getting better whether you do anything or not – that part is out of your hands, and as models internalize current Angular best practices, parts of this setup will get lighter, not heavier. The harness is the part you control, and it's what decides whether a strong model writes generic Angular or writes yours.

And setting it up isn't mysterious. A clean baseline, formatting and linting that run themselves, a style guide that actually encodes your taste, an opinionated AGENTS.md, and every tool wired back to the same rules – that's the whole game. If you invest in only one piece, make it the style guide: it's the cheapest, highest-impact way to turn a capable-but-generic harness into one that feels like a teammate who already knows your codebase.

One honest note on the human-in-the-loop part, because attentive readers of the Fable 5 post might sense a tension here: yes, I wrote there that human review might have an expiry date, and I stand by that. For now, though, reviewing every diff is still necessary – and here's the nice thing: this setup doesn't care who the reviewer is. Guardrails, style guide, and feedback loops make the diff better before anyone looks at it, and they stay just as valuable on the day a stronger model takes over more of the reviewing from me.

The best part is that none of this is locked to a vendor. The same AGENTS.md and style guide work whether I'm in Codex today, Cursor tomorrow, or some app that doesn't exist yet – so when the next model or the next super app shows up, I just point it at the setup I already have. That's exactly why I'd rather invest in the harness than chase the model leaderboard.

Everything here lives in the ng-agentic repo – clone it, steal what fits, and make it yours. And this is really just the foundation: in upcoming posts I'll build on top of it with reusable agent skills, the workflows that decide how much structure a task needs, and the part I'm most excited about – using all of this for real brownfield refactoring of dusty Angular code.

And if you want to dive deeper on the harness as its own discipline – beyond Angular – the open-source Learn Harness Engineering course is a solid, hands-on starting point for the fundamentals.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Anthropic Just Released the First Next-Gen Model to the Public

Alexander Thalhammer — Sat, 13 Jun 2026 11:08:27 +0000

Updated three times, on June 13th, June 22nd, and July 4th – see at the bottom.

Like many others, I misread what Anthropic did with their new model Mythos – now officially Mythos 5 – over the past few months, when they didn't release it to the public but only to Project Glasswing partners. I assumed it was a marketing stunt: the model would surely be better than the previous ones, but the whole story around it felt exaggerated. Their argument about implementing safeguards and guardrails first – so users cannot abuse the model for malicious exploits against other entities – sounded like an excuse to me. The real reason, I thought, was that they simply didn't have enough compute available, because the new model needs many more tokens and a huge amount of compute.

I was wrong.

The safeguards were not an excuse: through Project Glasswing, around 200 vetted organizations across more than 15 countries have been scanning critical codebases – power, water, healthcare, communications – with the Claude Mythos Preview and have found more than 10,000 high- or critical-severity security flaws. And compute was not the real bottleneck either. The public version simply needed new safety classifiers first – for cybersecurity, biology and chemistry, and distillation attempts – which now route affected queries to Opus 4.8 in flagged sessions.

I started this blog series with my AI coding journey, and that journey began in early December – exactly half a year ago, a few weeks after Opus 4.5 was released. That release was clearly an inflection point, at least in my personal history, because with that model I could write – or let's say prompt – code for the first time. I hope this doesn't sound arrogant, but I'm quite opinionated about how code should look, and Opus 4.5 was the first model that wrote code as if I had written it myself: the same quality, the same style, the same patterns, and so on. Until Opus 4.5, I thought these agentic tools just create slop. I was proven wrong six months ago.

Now I thought the Mythos story was a marketing stunt – and again, I was proven wrong. On June 9, 2026, Anthropic released Fable 5 to the public – the same underlying model as Mythos 5, but with the new safeguards in place. And this isn't just another release. This is a new generation of LLMs, and it is really, really capable.

You can use it for everything you previously used GPT 5.5 or Opus 4.8 for – it just does the job even better, with a level of quality and robustness I haven't seen before. I personally have to admit: it writes code better than I would. That is of course not to say I'm obsolete. The model still needs a skilled and senior web developer to steer it in the right direction for a high-quality result. And that is always my goal: to ship high-quality code, no matter what the project or the setup might be.

Honestly, I didn't plan to publish any model updates in this series, at least not in the first three or even six months, because I'm kind of annoyed by all the model hype posts and videos. But as I already said, I think this model really is a new generation, so I had to cover it here. Yesterday, Manfred asked me why I think this model is a new generation, and it was surprisingly hard for me to answer. I said: "Let me think about it. I will tell you tomorrow – or even better: I will write a blog post about it."

So this is the post.

What Makes Fable 5 a New Generation?

The first thing that makes Fable 5 a new generation is the quality of the code it writes. The code is not just good, it's really high quality. It follows best practices, it has good structure, it's clean, and it looks like it was written by a good senior developer. This is a huge step up from previous models. I used it to review work I had previously done with GPT 5.5 and Opus 4.8 – it immediately tracked down bugs, issues, and potential issues. I also used it for simplification, and it handled that just as well. So it can basically be used for everything.

An incomplete list of outstanding features and capabilities of Fable 5 includes:

Long-horizon autonomy: Anthropic says Fable 5 can stay with a problem far longer than any model before it and operate for days without intervention. Andrej Karpathy called it a step change of the same order as Opus 4.5 was in November – especially for long problem-solving sessions on very difficult problems. I totally agree with him, and that is the actual reason for writing this post. This is the model you point at a problem, not at a file.
Vague goals in, validated results out: you can hand it an instruction as open as "look into options to make this more performant", and it will synthesize ideas, test them – even write its own fuzzers and test beds – and come back with validated results instead of a guess. Skills and elaborate prompt engineering are not really necessary anymore – although I dare to make a prediction: they will play a huge role again in the future, when token efficiency becomes the highest priority.
Token efficiency despite the price tag: at roughly €10 per million input and €50 per million output tokens (official pricing is in US dollars; converted to euros and rounded up a bit), it costs about double Opus 4.8 per token. But it needs far fewer tokens per task, so on DeepSWE – still my favorite coding benchmark – the early numbers put it roughly on par with GPT 5.5 while beating every Opus score at lower total cost. Artificial Analysis has already run the new model through their coding-agent version of DeepSWE (see the chart below), and the official DeepSWE leaderboard now shows the same story from the benchmark source itself.
Benchmark jump: on the Artificial Analysis intelligence index it is now simply the smartest model ever measured, about five points ahead of GPT 5.5 – one of the biggest single jumps in a long time. As always: useful signals, not final answers.
Vision: for the first time, Anthropic takes the vision lead from OpenAI. That matters more than it sounds for our work – think screenshot-based UI verification of Angular components and design work with real taste instead of the same old templates.
Not just coding: Anthropic explicitly positions it for finance, research, economics, and law – and the early reviews agree that even its writing is noticeably less LLM slop than before.

To that last bullet, I would personally add design and writing – basically anything from emails to project planning. It is incredibly good at all of these things. It does what you tell it to do, it guides you through the process of whatever you are working on, and it comes back with useful proposals for the next step towards your goal.

DeepSWE scores for the current coding agents, captured on June 12, 2026 – click the chart for the live comparison. Strictly speaking, these are coding-agent results, so the harness matters: Fable 5 runs inside Claude Code at max effort here. The nice bonus of this view is that it even includes Composer 2.5, which the original DeepSWE leaderboard could not test due to the missing public API.

The official DeepSWE leaderboard, updated June 20, 2026, now puts Fable 5 at 70% pass@1 on v1.1, narrowly ahead of GPT 5.5 at 67% and clearly ahead of Opus 4.8 at 59%. The cost view is the important caveat: Fable 5 is the strongest model in this slice, but not the cheapest one, so I would use it for hard, long-horizon engineering work where the extra quality actually changes the outcome.

So this model really is insanely good – almost too good to be true. Which brings us to the obvious question: what's the catch?

Every Fable Has Its Fine Print

There is not one catch, there are several – some are merely annoying, some might be deal-breakers for your setup.

The safeguards are real, and you will notice them. Anthropic says fewer than 5% of sessions get routed to Opus 4.8, and in my coding work so far that matches – I have not hit a single refusal yet. But Artificial Analysis recorded fallback routing in 8% of their benchmark tasks, mostly on scientific questions. At least the routing is transparent: when it happens, you are told.

One safeguard is silent, though. When Fable 5 detects that you are working on frontier LLM development, it does not notify you – it quietly limits its own capabilities through prompt modification, steering vectors, and parameter-efficient fine-tuning. Anthropic estimates this affects 0.03% of traffic and fewer than 0.1% of organizations, so most Angular developers will never encounter it. Still, paying full price for a quietly limited model is a precedent I really don't like.

There is no zero data retention. All Fable 5 traffic requires 30-day retention – even for enterprise customers, with no opt-out. Anthropic claims the data is not used for training or any non-safety purposes, but as I wrote in the data privacy post: "not used for training" does not mean "not retained". For regulated industries and strict company policies, this alone can be a non-starter.

And now to the three catches that affect all of us directly:

The clock was ticking – faster than expected. Fable 5 was effectively available to me only from June 10 through June 12, 2026. Originally, I wrote that the included window would close on June 22 and then require usage credits. That turned out to be far too optimistic: on June 12, Anthropic had to disable Fable 5 and Mythos 5 for all customers after a US government directive. For roughly three days, we saw the next generation, and then it was gone.

It is slow. Even simple tasks take one to three minutes, and I have barely seen a run finish faster. This is not a model for the tight interactive loop where Composer 2.5 or GPT 5.5 on low reasoning shine. But as I argued in the costs post, the practical speed metric is not tokens per second – it is the end-to-end time until I have a reviewed diff. For long autonomous runs, Fable 5's pace is acceptable. For quick edits, use something else.

It is expensive. Roughly €10 input and €50 output per million tokens is about double the Opus 4.8 price, and the usage limits drain accordingly: early adopters report burning through roughly €100 of usage-based inference in less than ten minutes, and maxing out the 5-hour session limits of two €200 subscriptions in a single evening. Yes, it needs fewer tokens per task, so the cost per accepted, reviewed, merged change can still come out ahead for hard problems. But for everyday edits, this model is simply overkill – and after June 12, it was not priced like anything anymore because it was gone.

So my original call to action aged badly: we did not have until June 22. We had June 10 to June 12, and then the model was shut down. If you tested it in that tiny window, you got a glimpse of what a next-gen model can do for a real codebase. If not, we are all waiting to see whether Anthropic can bring it back.

My Updated Current Setup

In my personal verdict, published less than two weeks ago (in early June 2026), my default was Codex with GPT 5.5, complemented by the Claude Desktop app with Opus 4.8 for architecture, design, refactoring, and reviews. Three days of Fable 5 have turned that ratio upside down:

Before June 10: Codex with GPT 5.5 was my default (70%), while the Claude Desktop app with Opus 4.8 handled architecture, design, refactoring, and reviews (35%).
From June 10 to June 12: the Claude Desktop app with Fable 5 took 80% of my work, Codex with GPT 5.5 the remaining 20%.

Attentive readers of that verdict will remember why my old percentages added up to more than 100%: I used to review what each of the two main apps produced with the other challenger. That habit has basically stopped now – there is simply no need to review Fable 5's work with GPT 5.5, because Fable 5 is just way better.

I do keep using Codex for computer use, image generation, and simple tasks that should be done very fast – exactly the kind of work where Fable 5 would be wasted. And I'm not planning to cancel my OpenAI subscription either, because I guess we will soon see GPT 6 as the response to Fable.

So the decision tree from the personal verdict still stands – but its top branch has a new label, at least for now.

Human in the Loop – for How Much Longer?

There are basically two camps in the agentic engineering field right now.

The first camp is the progressive one. Their position: "Just trust the coding model. You don't have to review its work anymore – human review is the new bottleneck." A lot of my friends sit in this camp.

The second camp says: "You still need to review everything the model builds, because that is the only way to keep slop out of your codebase." If you have read this series, you know which camp I belong to: in the apps and harnesses post, I wrote that I review every diff and expect every generated line to look as if I had handcrafted it myself, and the later harness setup post turns that idea into concrete guardrails. A lot of my colleagues sit in this camp. Some of them are still trying to find time to even try agentic engineering. Crazy, right?

I was fully convinced of the human-in-the-loop (HITL) position. The last two days have made me a lot less convinced.

Not because my standards dropped, but because the reviews changed sides: as described above, I let Fable 5 review work that GPT 5.5, Opus 4.8, and I had produced together – and it found the bugs, the issues, and the simplifications, not me. When the model reviews my work more reliably than I review its work, the question is no longer whether human review is sacred. The question is what it still catches.

So here is the uncomfortable sentence I did not expect to write this soon: I can imagine that human reviews really become obsolete in the near future – not because we get lazy, but because they stop finding anything the model has not already found itself.

For now, I have not changed my workflow: every diff still gets my review, and that is also what I still recommend to every professional Angular team. But for the first time, this feels less like a timeless principle and more like a practice with an expiry date. Ask me again in six months. Or even three. Let's see. Exciting times!

Agentic Engineering Workshop

And this is exactly why a new model – even a new generation – does not change the fundamentals: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, and the review workflow still belong together. Fable 5 just raised the ceiling of what that system can do.

If you want to judge new models like Fable 5 on your own codebase – and put them to work on real modernization, refactoring, testing, and review tasks – join our Agentic Engineering Workshop, available in English and German. In it, advanced Angular developers learn how to move from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

Half a year ago, Opus 4.5 convinced me that agentic tools can write real code. Fable 5 is the first model since then that gives me the same feeling of crossing a threshold – not because of benchmark wins, but because of what it does in my own daily work: it stays with a problem, it validates its own results, and it writes code I like and want to merge.

In the first post of this series, I wrote that benchmark wins are useful signals, not final answers, and that no single release should change your workflow overnight. I stand by that – and yet Fable 5 is the first release that made me update my setup within days, and the first that made me question my own human-in-the-loop dogma. Both things can be true: stay skeptical of the hype, and recognize a new generation when it lands in your terminal.

The catches are real: the safeguards, the data retention, the speed, the price, and above all the June 12 shutdown. So let me correct my original call to action one last time: the included Fable 5 window did not close on June 22; it ended on June 12, 2026, when Anthropic disabled access after the US government directive. If it comes back, judge it the same way I recommended for every model before it – in your own codebase, with your own tasks, your own tools, and your own review standards.

One last confession: this is my first model-release hype post – exactly the kind I claimed to be annoyed by at the top. I hope I don't have to write another one anytime soon. Wait, there will probably be one when GPT 6 lands – let's see how long it takes OpenAI to respond.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Update June 13th

So this is the real catch: The model was shut down by the US government. Really sad. What a shame. So the AI war has escalated – let's see what happens next. For now, we're back to doing more of the work ourselves.

Update June 22nd

Inserted new charts by DeepSWE from June 20th. Still waiting for the model to be released again.

Update July 4th

Fable 5 is back. On July 2nd, Anthropic re-enabled access for subscription customers – for now until July 7th. What happens after that date is unknown. And the model still is everything I described above – I love working with it.

The price catch, however, is also unchanged: the usage limits drain as fast as ever. My workaround: I let Fable 5 do the thinking and delegate to cheaper sub-agents for the legwork – Opus 4.8 via the Agent tool and GPT 5.5 via Codex – running Fable 5 itself at effort level medium to high. That stretches the limits considerably, but not enough: I still max out my plan, so I just bought a second $200 subscription. Make of that what you will – for me, it's worth it.

Agentic Verdict: What's the Best Solution for You?

Alexander Thalhammer — Fri, 05 Jun 2026 22:00:00 +0000

Agentic Verdict: What's the Best Solution for You?

In the first four posts of the original series arc, I looked at LLMs, apps and harnesses, costs, and the data and governance side of agentic coding. This fifth post brings those threads together.

Update: This was the original final verdict. Since then I added the Fable 5 update and the harness setup post, which extend the story without changing the basic decision framework.

I want to start with my current rankings and then move to the practical question I get asked most often: which setup should I actually use?

This Is Still Not a Benchmark

One last time: this is my personal verdict for professional Angular work in enterprise projects (TypeScript, HTML, SCSS), not a scientific benchmark. The benchmarks are useful signals, but the final answer still depends on your codebase, your IDE, your budget, your company rules, and your willingness to review AI-generated code properly – which, in my opinion, is still necessary to avoid slop.

TL;DR: My Current Verdict

Once again, my favorite benchmark currently showing coding capabilities, DeepSWE, as discussed in the LLMs post:

And if you're an enterprise and tokens and costs matter to you, this chart from the costs post:

And the Winner (My Current Setup) Is

My default solution (70%): Codex app with GPT 5.5 – very good, fast (depending on effort), reliable (€100/month sub).
For architecture, design, refactoring, writing, and often just reviewing Codex/GPT 5.5 work (35%): Claude Desktop with Opus 4.8. To me, it's the best model currently for complex, high-quality Angular work, but it's pretty slow and the app experience is not as good as in Codex (€100/month sub).
For careful handcrafted Angular work (5%): WebStorm with Junie and Opus 4.8 (€20/month sub & API pricing).
For high-speed work (2.5%): Cursor with Composer 2.5 (€20/month sub).
For demoing why Antigravity and Gemini are pretty useless (0.1%): Antigravity with Gemini (€20/month sub, cos I had Drive anyway).
For showing why Copilot is no good (0%): GitHub Copilot with any model (€8/month sub).

In parentheses, the percentage is a rough estimate of how much of my work currently goes through that setup. The percentages add up to more than 100% because I often use multiple setups for the same task – e.g. I might start with Codex/GPT 5.5 for implementation and then switch to Claude/Opus 4.8 for review and refactoring. And sometimes I just want to compare two models on the same task, which is also a good way to keep track of how they evolve.

Whichever of these you settle on, picking the app is only step one – the bigger lever is how you set up the harness around it. I walk through that end to end for Angular in the harness setup post.

So roughly that sums up to €270 each month (heavy subsidization makes it possible). Considering my hourly rate of €150–300, that means that I have to save 1–2h per month. Mediocre quote of former mayor of Vienna (legendary Michael Häupl) incoming: That's done during lunch on the 1st day of the month. Still considering not using agentic coding? I hope not.

I do actually hate the fact that in Codex I cannot switch to other model providers, because if I could, I would stop using everything else. I also hate the fact that Google has fallen far behind. Of all the big labs, I actually like Google the most as a company. But they do seem to have an organizational problem and cannot currently compete against the three frontier labs – OpenAI, Anthropic, and now Cursor, which after the SpaceXAI deal and Composer 2.5 I count as part of the frontier rather than a challenger. Hopefully Google Gemini will catch up. We need competition, and three frontier labs are already better than the old "duopoly".

And of course I do prefer open source tools like OpenCode or T3 Code where you can switch the model provider, because that gives you more freedom and flexibility. And I'd love to use open weight models. But for now those are not good enough for my work. This will probably change in 6–12 months, and I'll update my verdict & my recommendations accordingly.

Also, I worry that Chinese labs may become less generous with open weight releases. That would be understandable after Cursor's recent coup of building their astonishing Composer 2.5 upon Moonshot's Kimi K2.5.

However, I won't let them (neither OpenAI nor Anthropic) lock me in, so I will keep trying other setups and keep an eye on the market. But for now, this is my setup.

What Is the Best Solution for You?

Yes, the best solution for you depends on your company policy, your workflow preferences, and your willingness to review AI-generated code carefully. But choosing your setup is actually not that complicated.

Nevertheless, I have created a sophisticated decision tree to help ya out (click to enlarge):

But Alex, My Favorite IDE Is Not Mentioned

I hear ya. Of course I mention the IDEs that I've been using the most – which is nothing other than personal preference. If you're using something different, try to apply the pattern from the decision tree above:

Does my tool have an agent harness built in? If yes, go with the flow. If no, use Codex & Claude Desktop.
Does my tool support plugins/extensions for Codex/Claude Code? If yes, check out those plugins. If they're good, use them. If not, fall back to Codex & Claude Desktop.
If you're using something like Neovim, use Codex CLI & Claude Code CLI. Fine with me.

Do your own research, find the app & model that suits your preference, workflow, policy and ethics best.

Effort and Fast Mode

Easy: As I explained in the costs post, start with high effort. If your results are perfect, reduce effort to medium or low. If there are problems, try extra (or even max).

Enable fast mode by default. For the tradeoff, see the Codex speed configuration pricing and the Claude fast mode docs. If you hit your usage limits, turn it off or upgrade.

What Plan Do I Choose?

Also, an easy choice: start with the €20 plans. Upgrade once you see return on investment and frequently run into limits.

What I Would Recommend to Teams

For teams, I would recommend trying the Team Plan if your procurement and company policy allow it. Additionally:

Pick one or two approved tools instead of banning everything.
Start with a pilot on real Angular work.
Measure accepted changes, review quality, and cost.
Keep humans responsible for the final diff.
Review the setup again every few months because the tools change too quickly.

Enterprise / API Pricing Considerations

Cursor & Composer 2.5

If you can (depending on your setup, company policy, and personal ethics), I would recommend trying Cursor with Composer 2.5 for very good API pricing. It's the cheapest and the fastest. Results are somewhere between the frontier models (GPT 5.5 and Opus 4.8). So for ROI this might be your best bet – at least currently.

Codex, GPT (and Claude Opus) With Low Effort

However, if you want to use the models with the best coding capabilities, I would recommend using Codex with GPT 5.5 (and Claude with Opus 4.8) with low to medium effort.

There is no need to go back in model history or use the Sonnet models. By reducing the effort you can easily reduce the costs dramatically, while still getting good results.

Agentic Engineering Workshop

If this verdict has shown one thing, it is that none of these decisions stands alone: model, harness, costs, privacy, and workflow are one setup – choose them one by one and you end up with an expensive mess.

If you want to bring all of that into one coherent, professional Angular setup – join our Agentic Engineering Workshop, available in English and German. Together we take advanced Angular developers from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

This series started with a single question – which LLM is best for Angular – and slowly turned into something bigger, because no part of this works in isolation.

The model matters. Opus 4.8 and GPT 5.5 are genuinely different tools, and knowing when to reach for which one is half the battle.

The harness matters. Codex, the Claude Desktop app, Cursor, and your custom setup each shape the workflow differently – and setting that harness up properly for Angular is the highest-leverage thing you can do.

The pricing model matters. What counts is not the price per token but the cost per accepted, reviewed, merged change – and a subsidized subscription is still the best deal you can currently get.

And the data side matters too. Don't only say no. Approve a few safe paths and make the official workflow better than the unofficial workaround.

But if there is one thing to take away from the whole arc, it is this: the best setup is not the one that wins benchmarks, it is the one that fits your actual development workflow and still keeps code quality high. Pick a setup, run it on real Angular work, measure what it changes, and revisit it in a few months – because by then half of this will have moved again.

The teams that learn to do this professionally won't just write code faster. They will modernize faster, test faster, review faster, and learn faster. And they will stay competitive. That is the whole point.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Update June 21st

Updated with the new charts v1.1 by DeepSWE .

Agentic Engineering: What Do AI Coding Tools Do With Your Code?

Alexander Thalhammer — Fri, 05 Jun 2026 08:00:00 +0000

In the first post of this series arc, I wrote about the LLMs I currently like to use for Angular development. In the second post, I looked at the apps and harnesses around those models: Codex, Claude Desktop app, Cursor, Antigravity, VS Code, WebStorm, and a few more. In the third post, I focused on money: subscriptions, API costs, enterprise plans, token usage, reasoning levels, and cost control. I originally planned to squeeze all of this into that costs post, but it quickly became too much for one article, so both topics now get their own. This fourth part is about the less comfortable question behind all of that:

What do we actually share when we use agentic coding tools?

This is where pricing, privacy, enterprise rules, EU regulations, and the very common sentence "We are not allowed to use AI here" all meet.

Is our code safe?

Before I dive in: this is not legal advice and no replacement for your company's security review – just my practical view as an Angular builder and coach who refuses to pretend that data protection is somebody else's problem.

TL;DR: Do Not Ban AI, Approve Safe Paths

If you only have thirty seconds, my practical view is this:

personal subscriptions are great for learning, but not automatically fine for proprietary code
"not used for training" does not mean "not retained"
secrets, production data, customer data, and regulated personal data need clear rules
agents don't just read code, they run commands and can be tricked into leaking it, so limit them
companies should approve a few safe tools instead of forcing unofficial workarounds
every generated diff still needs human review

This Is Not a Legal Guide

You know the drill by now: my current opinion as of June 2026, based on too much time spent reading vendor documentation.

And these details change fast. Vendors change plans, defaults, retention settings, enterprise controls, and subprocessors, sometimes within weeks. While I was writing this series, three new models got released (Gemini 3.5 Flash, Composer 2.5 and Opus 4.8). The next model will be out next week I guess (we're waiting for GPT 5.6, right?). Google is folding Gemini CLI and Gemini Code Assist for individual users into Antigravity CLI, while enterprise access remains unchanged. So please check the official pages again before you decide anything for real, and read this as a practical field report.

What Do We Actually Share?

This was the part where I had to do the most research because it is easy to have a strong opinion here without knowing the details. When you use an AI coding agent, you might share much more than the prompt in the chat box.

Depending on the tool and settings, the provider or tool vendor may receive:

your prompt
selected code snippets
open and neighboring files
search results from your repository
diffs
terminal commands and outputs
stack traces
package names and dependency versions
file paths
screenshots
browser state
issue, pull request, and review text
telemetry about accepted suggestions

This does not automatically mean that the provider trains on all of that. Training is a separate question. But AI coding is still a real data-processing workflow.

For an Angular project, this can include product logic, internal architecture, API names, feature flags, business rules, test fixtures, local logs, screenshots, and sometimes personal data.

So the basic rule is simple:

Do not send secrets, production data, customer data, or regulated personal data to AI tools unless your legal and technical setup explicitly allows it.

Agents can see terminal output and files. If your .env files, logs, database dumps, screenshots, or test fixtures contain sensitive data, the agent might see them too – researchers have shown that Codex, Claude Code, and Cursor walk the working directory and can read .env files that .gitignore would normally keep out of sight.

What I Found in Vendor Docs

The exact wording differs between vendors, plans, products, and regions, so I would not treat the links below as a permanent legal answer. But they show why teams have to distinguish between training, retention, product telemetry, enterprise terms, and the actual tool context an agent can see.

Consumer Plans vs Business Plans

This is the most important distinction I found. Consumer plans often have data controls, but you need to check and configure them. Business, enterprise, and API products usually have stronger defaults, especially around model training.

OpenAI's help page on how data is used to improve model performance says individual services such as ChatGPT and Codex may use content to train models unless you opt out, but that it does not train on business products, ChatGPT Enterprise, and the API by default. The Codex plan usage article says the same for Codex.

Anthropic's Claude Code data usage page makes a similar distinction. Free, Pro, and Max users can allow data use for model improvement; for Team, Enterprise, API, third-party platforms, and Claude Gov, Anthropic says it does not train generative models on Claude Code prompts or code under commercial terms unless the customer opts in.

Cursor's pricing page says Privacy Mode, when enabled in settings or by a team admin, keeps code data from being stored by model providers or used for training. The security page adds that it is available to anyone, enabled by default for team members, and backed by technical controls and contractual terms such as zero data retention with model providers; the data-use overview spells out what is and isn't stored.

Google's consumer Gemini story also differs from the Google Cloud one. The Gemini Apps Privacy Hub warns users not to enter confidential information they would not want reviewed or used to improve services. In contrast, the Gemini for Google Cloud data governance docs say it does not use prompts or responses to train models, and the Gemini Code Assist Standard/Enterprise security docs describe coding context as Customer Data.

GitHub Copilot just made this split concrete. In March 2026, GitHub changed its defaults so interaction data from Free, Pro, and Pro+ users can train its models unless you opt out, while Business and Enterprise stay excluded. Independent reporting spelled out what that means for regulated industries, and the Copilot Trust Center holds the current details. Same lesson, fresh example.

So my practical conclusion is:

A personal €20 subscription is great for learning and experimentation, but it is not automatically the right setup for proprietary enterprise code.

Maybe it is allowed in your company after opt-out and review. Maybe it is not. But you should not guess.

No Training Is Not the Same as No Retention

Another thing that is easy to mix up: "not used for training" does not mean "not retained".

Providers may still retain data for abuse monitoring, security, debugging, billing, legal obligations, or product functionality. Some enterprise plans allow custom retention, some API setups offer zero data retention, and some consumer products keep conversation history unless you delete it or use temporary modes.

For example, Anthropic's privacy center says consumer users who do not allow data use for model improvement have 30-day retention, while those who do have 5-year retention.

OpenAI says individual users can opt out of training, and Temporary Chat will not appear in history, create memories, or be used to train models, though feedback may still be used.

Google Cloud says Gemini Code Assist Standard and Enterprise are stateless Google Cloud services and do not store prompts and responses in Google Cloud unless you configure logging.

For a serious company rollout, I would ask every vendor boring but important questions:

Is our code used for training by default?
Can we opt out organization-wide?
What is retained, where, and for how long?
Can we configure retention or use zero data retention?
Do you offer EU or regional processing?
Which subprocessors are involved?
Are human reviewers involved?
How are prompts, responses, diffs, screenshots, terminal outputs, and telemetry treated?
Can admins disable connectors, browser access, MCP servers, cloud agents, or external network access?

If a vendor cannot answer these questions clearly, I would not roll it out broadly in a regulated company.

EU and Regulatory Considerations

Since I work in Europe, I also care about the EU side. For many companies, GDPR is the main topic; depending on the use case, works councils, vendor management, data residency, contractual confidentiality, and the EU AI Act can also become relevant.

The EU AI Act entered into force in 2024 and applies gradually. The European Commission's implementation timeline shows obligations for general-purpose AI models started in 2025, and the Commission's enforcement powers start August 2, 2026 – not far away. For a normal Angular developer using a coding assistant, GDPR and confidentiality are probably more immediate than the AI Act.

In the DACH region, the practical questions are usually a data processing agreement (Auftragsverarbeitung) and EU data residency – German write-ups like this DSGVO comparison of ChatGPT, Copilot, and Gemini and this Claude Code AVV walkthrough are a decent starting point. But if your company builds AI features into products, uses agents in regulated workflows, or lets AI systems influence decisions, the AI Act becomes much more relevant.

For coding agents inside a company, I would keep the policy practical:

classify which repositories may be used with which AI tools
ban secrets and production data in AI context
require approved business, team, enterprise, or API terms for proprietary code
document approved vendors and subprocessors
require human review for generated code
educate developers on prompt privacy and tool permissions

The goal should not be bureaucracy – we have got enough of that.

The goal should be to make AI usage possible without pushing developers into unofficial workarounds.

Green, Yellow, Red

If I had to explain the policy to developers, I would use a very simple traffic-light model.
Not because it covers every legal edge case, but because people actually remember it.

Green: learning, experiments, public and open-source code – personal subscriptions are fine here.
Yellow: proprietary code – allowed, but only on approved business, team, enterprise, or API terms.
Red: secrets, credentials, production data, customer data, regulated personal data – never in the AI context, no exceptions.

Most real enterprise Angular work lives in the yellow zone. That is why a blanket ban is too blunt, but "just use whatever" is too naive.

"We Are Not Allowed to Use AI"

This is the part where I will be a bit opinionated.

I hear "we are not allowed to use AI" more and more often. Sometimes that is justified: if a company has no vendor review, no DPA, no data policy, no security story, and developers paste sensitive code into random tools, somebody should stop that. But a blanket "no AI" policy is not a serious long-term strategy. It has a hidden cost: the company becomes slower while competitors learn to use these tools safely. Long-term, I don't think that is survivable.

I believe professional software teams need agentic coding to stay competitive. Not because AI magically replaces good engineers. It does not. But because the baseline speed of software work is changing.

If one team can modernize code, write tests, review changes, and explore refactorings faster, the other team cannot keep working exactly as before and expect no consequences.

For Angular teams this is especially relevant. Enterprise Angular projects often have large, complex codebases, old RxJS flows, inconsistent test coverage, slow migrations, and a lot of technical debt – a lot of boring (I personally love it!) but important modernization work. Agentic coding helps with exactly that – if we keep strong human-in-the-loop review and a sophisticated Angular Coding Style Guide.

So I would not argue for "let everybody use everything". I would argue for this:

Do not ban AI. Approve a small number of safe paths and teach people to use them professionally.

That is the better security posture.

A Simple Company Policy

If I had to write a first version of an AI coding policy for an Angular company, I would keep it short:

Use approved tools only (might have to approve them first, a lot of work, but AI can help 😏).
Use business, team, enterprise, or approved API terms for proprietary code.
Use personal consumer accounts only for learning, public code, or explicitly approved use cases.
Do not send secrets, credentials, production data, customer data, or sensitive personal data.
Human review of every generated diff.
Treat AI-generated tests as useful, but not as proof that the implementation is correct.
Control command execution, browser, network, MCP, plugin, and connector access.
Track cost and usage during rollout.
Review the policy every quarter because the tools change too quickly.

That is not perfect, but it is better than either "everything is forbidden" or "everybody can use whatever they want".

My Personal Verdict

For individual developers, my recommendation is simple: use personal subscriptions for learning, experiments, public code, and approved professional work. But do not assume the same subscription is automatically fine for proprietary enterprise code.

For companies, I would not start with a blanket ban. I would start with the safest option developers will actually use: one or two approved business/enterprise tools, a clear data policy, and a serious pilot.

For policy work, I would not try to predict every possible AI use case. I would define a few safe paths, educate developers, and review the setup every quarter.

Agentic Engineering Workshop

Everything in this post is really an argument for treating agentic coding as a system, not a tool: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the review workflow – and yes, the data policy – all have to fit together, or the whole thing leaks somewhere.

If you want to use agentic coding safely with proprietary Angular code – with clear data flows, real guardrails, and a policy your developers will actually follow instead of working around – join our Agentic Engineering Workshop, available in English and German. It takes advanced Angular developers from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

AI coding tools are not just chat boxes. They can read files, search repositories, inspect diffs, run commands, see terminal output, connect to other systems and resolve nasty merge conflicts. That is what makes them useful, but it is also why privacy and governance matter.

For individual developers, the practical rule is simple: do not send secrets, production data, customer data, or regulated personal data unless the setup explicitly allows it. For companies, the practical rule is also simple: do not only say no. Approve a few safe paths, define clear boundaries, and make the official workflow better than the unofficial workaround.

Because the teams that learn to use agentic coding professionally – safely, on approved paths instead of workarounds – will simply outpace the teams that ban it. That gap grows quietly, until falling behind turns into going broke.

In the personal verdict, I pull all the threads of the original arc together – models, harnesses, costs, and privacy – into the agentic coding setup I would actually choose.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic Engineering: What Does AI Coding Really Cost?

Alexander Thalhammer — Thu, 04 Jun 2026 12:12:26 +0000

In my first post of this series arc, I wrote about the LLMs I currently like to use for Angular development. In the second post, I looked at the apps and harnesses around those models: Codex, Claude Desktop app, Cursor, Antigravity, VS Code, WebStorm, and a few more. This third part is about the annoying but important topic: money.

Actually, money is only one part of the story. The other part is what data we share with these tools and which setups companies can actually use. I first had all of that in this post too, but it became too much for one article. So this part stays focused on costs, and I will cover the data and policy side in the next post.

And yeah, spoiler: if one of the subsidized subscriptions (or in my case all four of them) works for your setup, that is by far the best deal you can currently get. Before I dive in, let me be clear about one thing: I am not trying to sell you anything here, except, well, my brand new Agentic Engineering Workshop 😅. So this post is primarily about informing you about the options that actually exist, so you can make your own decision.

One thought runs through this whole post, so let me say it up front: what matters in the end is not the price per token. It is the cost per accepted, reviewed, merged change. More on that later.

There is also a bigger reason I keep writing about this. In my opinion, too many European teams are still too slow to adopt agentic coding seriously – and that gap will only get bigger. So please help me spread the word, and share these posts with your friends and colleagues!

This Is Still Not a Benchmark

Same disclaimer as in the previous two posts, just shorter this time: this is my current opinion as of June 1, 2026, from real Angular work and a lot of time spent playing around in Codex and the Claude Desktop app – not a scientific benchmark, not procurement advice.

I also spend some time in Cursor because it is a serious candidate – even more so since Elon is going to buy Cursor later this year (I bet he will), and I want to keep checking where it is going. Antigravity, on the other hand, is more of a tool I test from time to time. I don't use it seriously for my daily Angular work yet, because it still does not feel mature enough compared with Codex, Claude Desktop app, and lately also Cursor.

The subscription prices themselves have been pretty stable so far. What changes more often is what you actually get: model access, included usage, rate limits, fast modes, and sometimes the hidden routing behind the scenes. For API and enterprise setups, longer agent runs can also change the real cost directly.

So if you read this in a few months, check the linked pricing pages again. The included usage and enterprise/API details might have changed. One more note on the numbers: the providers list their prices in US dollars, so the euro figures in this post are approximate, not the exact amounts on your invoice. But the general shape of the cost problem will probably stay the same:

subsidized subscriptions are amazing value when they fit your setup
API pricing is much more transparent, but can get expensive quickly
enterprise plans cost more, but also solve a different problem

TL;DR: Start With €40 or €60, Upgrade Only Where You Hit Limits

If you are an individual developer, freelancer, trainer, consultant, or working in a setup where these tools are available, I would not start with one tool. If you have no access yet, I would buy at least the €20 subscription from OpenAI and the €20 subscription from Anthropic. That is €40/month, and for me that is currently the most useful starting point.

If you can afford another €20, I would also add Cursor for a month. Then you are at €60/month and you can compare not only the models, but also the apps around them: Codex, Claude Desktop app, and Cursor. That is much more useful than reading another benchmark table.

The current pattern is roughly this:

€40/month: OpenAI Plus and Anthropic Pro, the minimum setup I would recommend for serious experiments
€60/month: add Cursor Pro if you want to compare a third strong app workflow
+€80/month per provider: upgrade OpenAI or Anthropic from the €20 tier to the €100 tier when that specific tool becomes your bottleneck
+€100/month more after that: move the same provider from the €100 tier to the €200 tier when you really need the 20x-style heavy-user tier
Cursor upgrades: separate ladder, with €20 Pro, €60 Pro+, €200 Ultra, and €40/user/month Teams
Enterprise: different billing, contracts, usage pools, overages, and usually much more expensive

If you are new to agentic coding, don't worry about the higher tiers on day one. Start with the base subscriptions, learn the apps, and upgrade only where you actually hit limits. That is what I did too.

Today my setup is heavier: OpenAI and Anthropic on the €100 tier, Cursor and Google both on the €20 tier. I don't need all of them every day, but I want to compare them quickly because this space changes so fast.

Why Subscriptions Are Such a Good Deal

These subscriptions are not just API pricing with a nicer UI. They are subsidized product bundles, and agentic coding involves a lot of hidden work: file reads, searches, tool calls, tests, terminal output, diffs, edits, and context compaction. At raw API prices, you would notice that quickly.

That is why subscriptions are so attractive. The providers want developers in their ecosystem, and right now we benefit from that. But the catch is important: these plans are usually meant for humans using the product, not as a cheap backend for your company, CI pipeline, or SaaS product. In larger companies, personal consumer subscriptions also do not match procurement, billing, reporting, and cost control.

So the real first question is not:

Which model is cheapest per token?

The real first cost question is:

Can we use the subsidized app subscription, or do we need a business, enterprise, or API setup?

That one question can easily change the cost calculation by a factor of 10 or more.

The €20 Tier Is for Getting Started

For me, the €20 tier is not only about "cheap access to a model". It is the entry ticket into the whole product around the model. That is why I would not buy only one subscription if I had no access yet. I would buy OpenAI and Anthropic first, and maybe Cursor too.

The important comparison is not only GPT versus Claude versus Composer or Gemini. The important comparison is Codex versus Claude Desktop app versus Cursor. These are the super apps where the real workflow happens: repository search, file editing, tool calls, terminal output, diffs, review, cloud tasks, local tasks, and all the little product decisions that make an agent useful or annoying.

So my recommendation is simple: spend €40 or €60 for one month and run the same real Angular tasks through the tools:

migrate a component to signal-based input() and output(), and rewrite a template from *ngIf and *ngFor to @if and @for
add tests for a service with a few dependencies
ask for a code review of a real pull request
try a Git workflow like rebasing one branch onto another and resolving a pile of merge conflicts
describe a bug by explaining the current behavior and the desired behavior, and ask the agent to find and fix it

Then look at the diffs, the review experience, the terminal usage, the verification, and how much steering you had to do. After two or three evenings, you will usually know much more than any pricing table can tell you.

The Current Pricing Picture

Let's look at that pricing table anyway, but only briefly. Again, please check the official pages before you make a real decision, because these numbers are moving targets.

Nothing special to see here. Roughly all three Frontier Labs – OpenAI, Anthropic, and Cursor (SpaceXAI) – have the same pricing, with the minor exception of Cursor offering you the 3x plan for €60.

OpenAI / Codex

For Codex, check the Codex pricing page and ChatGPT pricing page.

Anthropic / Claude

For Claude Code, check Anthropic's Claude pricing page.

Cursor

For Cursor, check the Cursor pricing page.

Google / Gemini / Antigravity

For Google, check the Gemini subscriptions page and the Google AI subscription update.

Copilot

Meh, I would not build a 2026 setup around Copilot anymore. And the pricing story is getting weaker too: GitHub has moved Copilot to usage-based billing today (June 1, 2026), replacing premium request units with AI Credits. So Microsoft's heavy subsidizing of frontier-model usage inside Copilot is over. On top of that, the frontier LLMs are being limited more and more in Copilot. But the bigger point is simple: Copilot is just not the best harness for agentic coding. If you're forced to use it in your company, try starting a revolution. In the end, you might just be securing your employer's survival. Hopefully this post series can support you with that.

Team Plans Sit in the Middle

Between the personal subscriptions above and the enterprise contracts below, both vendors offer a team tier that keeps the per-seat price low while adding pooled usage, central billing, and admin controls.

On OpenAI's side, the Team plan comes in two tiers: a standard tier at about €20 per seat and month and a premium tier at about €100 per seat and month with much more included usage – the same ladder as the personal plans. Both bundle Codex, company knowledge, SSO/MFA, and data that is never used for training. See ChatGPT Business pricing.

Anthropic's Team plan (for teams of 5 to 150) mirrors those two tiers: €20 or €100 per seat and month, again depending on how much included usage your developers need. Both tiers include Claude Code and Desktop, and the team gets the full agentic tooling, SSO, and "no model training". For the details, see Claude team pricing.

Enterprise Is a Different Game

It is easy to look at a €20 subscription and ask why a company should pay so much more. I get that reaction, but enterprise is not "more Plus". It is a different cost model: seats, pooled usage, overages, central billing, usage reports, admin controls, support, and predictable invoices.

The real question is what happens when 50 developers use the tool every day. Tight limits can turn cheap plans into overages, waiting time, retrying, and cleanup.

So I would start with a small pilot. Give a few strong developers two paid setups for four weeks, use them on real Angular work, and measure cost, accepted changes, review time, PR cycle time, and limits.

API Usage: Paying the Real Cost

Subscriptions and enterprise plans hide cost. API usage does not. The official OpenAI API pricing page and Claude API pricing docs currently list USD prices. Converted roughly for comparison, GPT 5.5 is about €5 per million input tokens and €30 per million output tokens, while Claude Opus 4.8 is about €5 input and €25 output.

Per million tokens that sounds manageable, and output tokens are usually much more expensive than input tokens.

Here is the current API price snapshot I would use for agentic coding discussions. Most official pricing pages still quote USD, so treat this as a practical comparison and check billing currency, VAT, and enterprise discounts before you make a procurement decision.

All prices are per million tokens, sourced from each provider's API pricing. The table is deliberately simple: no batch discount, no extra tool-call fees, no VAT, no currency conversion, no enterprise discount.

For IDE-heavy teams, BYOK (bring your own key) can be interesting, no matter whether you live in WebStorm or VS Code. On the JetBrains side, the JetBrains AI plans and Junie BYOK docs allow it, and most VS Code AI extensions offer the same idea: keep the IDE, connect provider keys, pay the provider.

But the catch is how many tokens an agent actually moves per task – and that is the real cost driver I look at next.

Token Usage Is the Real Cost Driver

OpenAI's help page on tokens says one token is roughly four characters of English text. For a coding agent, 200,000 input tokens are not some crazy edge case. Repository instructions, tool schemas, file excerpts, diffs, terminal output, and chat history pile up fast. Anthropic's pricing docs say the quiet part too: tool names, schemas, calls, and results are billed.

At current API prices, one turn with 200,000 input tokens and 20,000 output tokens costs roughly €1.60 on GPT 5.5 and €1.50 on Claude Opus 4.8. Fine once. Annoying after 20 turns. Expensive if the agent starts doing laps.

Prompt caching helps, but it does not make output cheap and it definitely does not fix a messy workflow. So I would not worship token price. A more expensive model can still be cheaper if it gets the work done in fewer turns.

This is also why I don't care too much about raw tokens per second. A model can stream quickly and still feel slow if it needs too many turns, too many tool calls, or too much reasoning to finish the task. For agentic coding, the practical speed metric is end-to-end time until I have a reviewed diff. A slower-streaming model can still be faster if it gets to the right files quickly and produces less unnecessary output.

So the number that matters is not cost per token. It is cost per accepted, reviewed, merged change.

The DeepSWE benchmark is the one I currently trust the most. Higher percentages mean stronger benchmark results; further right means better cost efficiency. Sadly it's missing Composer due to the lack of a public API.

This second chart – based on Artificial Analysis' coding-agent runs, which can test Composer through Cursor's own harness – includes Composer, and here it is the most efficient model by far, the best ROI in this comparison. Definitely an option to watch for API usage.

Low, Medium, High, Extra

If token volume is the real cost, the reasoning level is the first dial that changes it. Most tools now have some reasoning setting: low, medium, high, extra, max, and so on. The rule is simple: use the cheapest level that reliably solves the task.

For Angular work: low for tiny edits, medium for normal implementation, high for tricky bugs, component creation and refactorings, and extra/Pro/Max when a bad result would cost much more than the model usage.

In practice, I often just use High as my default (for GPT and Opus), because it is usually good enough and I don't want to waste time tuning. I know I will get hate for this, but the truth is that my time is precious and I don't care as much since I can use the subsidized subscription anyway. And I still have the option to upgrade my sub if necessary 😏

Fast Mode

Reasoning level is one dial; fast mode is the other. Fast mode is interesting because speed matters. If an agent is too slow, I lose focus. But fast mode is also a cost feature. In Codex, speed configurations increase credit consumption. In the Claude API, Fast mode gives faster Opus responses at a premium.

So I would definitely try it, experiment with it, and if your time is really precious, just use it.

How I Would Control Costs in a Team

Cost control is mostly workflow control. I would define simple rules from the beginning:

start with medium reasoning for normal implementation work
use high/extra only when the task deserves it
keep tasks focused
start a fresh thread when the context becomes messy
keep project instructions short and useful
watch terminal output size
keep humans responsible for the final review

This is not only about saving money. Agents are better when the task is clear.

Agentic Engineering Workshop

And here is the uncomfortable truth about cost control: the token price is the wrong dial. The model, the app, my Angular Guardrails, my Angular Coding Style Guide, and the review workflow together decide what an accepted change really costs you – and that system is something you can train.

If you want to keep AI coding costs under control and optimize for cost per accepted, reviewed, merged change instead of price per token – join our Agentic Engineering Workshop, available in English and German. There, advanced Angular developers move from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The cheapest serious setup today is still a subsidized individual subscription. If you have no access yet, I would start with OpenAI and Anthropic for roughly €40/month, and maybe add Cursor for another €20 for one month. That gives you Codex, Claude Desktop app, and Cursor on real Angular tasks, which is much more useful than reading another benchmark table.

Then keep what actually changes your daily workflow. If you hit limits, upgrade the tool that is limiting you: OpenAI or Anthropic from €20 to €100, and only then maybe to €200 for serious heavy use. For companies, the answer may be business or enterprise seats, pooled credits, API usage, or an IDE-based setup with your own provider keys – WebStorm with AI Assistant and Junie, or VS Code with its AI extensions.

So my recommendation is not "buy tool X". Build a small, serious AI coding workflow now, measure cost per accepted, reviewed, merged change, and keep humans responsible for quality.

Teams that learn this professionally will not only write code faster. They will turn the same budget into far more accepted, reviewed, merged changes – and that advantage compounds every month.

In the next post, I will look at the other half of the question: what we actually share with AI coding tools, and how I would think about privacy, retention, EU regulation, and company policy. In the personal verdict, I pull models, harnesses, costs, and privacy together.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic: Which App/Harness Is Best for Angular Development?

Alexander Thalhammer — Tue, 02 Jun 2026 07:14:46 +0000

In my last post, published yesterday (on May 26, 2026), I wrote about which LLMs I currently like to use for Angular development and promised a follow-up about the apps and harnesses around them. This is that follow-up.

Chronologically, this is the second post in the original series arc. The follow-ups look at costs and the data and privacy side of agentic coding, before the personal verdict pulls the first arc together.

From Models to Agent Harnesses

Picking the model is only half the picture. The same Opus 4.7 behaves very differently in a JetBrains chat window, in Claude Code on the terminal, or wrapped in Cursor's agent mode. The harness decides how the model sees your code, how it edits files, how it runs tools, how much it verifies, and whether it feels like autocomplete, a helpful assistant, or a real agent. For serious Angular work, that part matters at least as much as the underlying model.

So this post is about the other half: the apps, IDE integrations, and agentic coding tools I've used over the last few months. I'll move from classic Copilot-style autocomplete to IDE agents and today's super apps, and then explain where Codex, Claude Desktop app, Cursor, Antigravity, VS Code, and WebStorm currently fit (or don't) into my daily Angular workflow. I also want to look a little bit at the product philosophy behind these tools, because that often explains the day-to-day experience better than a feature checklist.

This Is Not a Benchmark

Before we go any further, one disclaimer: this is my subjective opinion from daily Angular work – projects, workshops, code reviews, refactorings – not a scientific ranking. Your IDE, operating system, budget, company policies, and tolerance for agentic autonomy might lead you to a completely different result, so read this as a practical field report from my current setup.

The sketch above is a very simplified overview of how I see these tools in terms of capabilities and my personal preferences – a visual aid, not an objective comparison.

TL;DR: My Current Setup

If you only have thirty seconds: my daily drivers for Angular work are currently Codex (with GPT 5.5) and the Claude Desktop app (with Opus 4.7 – meanwhile 4.8, see the conclusion), used roughly interchangeably. Codex has the more polished app experience, while the Claude Desktop app gives me access to the Opus models I trust most for architecture, design, and larger refactorings. Cursor with Composer 2.5 is a strong third option, especially when speed, cost, IDE integration, or cloud agents matter. Antigravity is interesting but, in my opinion, not yet on the same level. And whenever I do real handcrafting, I still happily switch back to WebStorm.

All of this assumes a strict human-in-the-loop workflow: I review every diff, and I expect every line of generated code to look as if I had written it myself.

My AI Coding Journey

To explain where I ended up, I first need to show the path that got me there. I'll start with the more traditional IDE integrations and then move on to the newer agentic coding apps.

WebStorm + GitHub Copilot

For over a decade PhpStorm (starting in my WordPress era) and later WebStorm have been my main IDEs for web development. So when GitHub Copilot launched, it was a natural choice to try it out in WebStorm. It was one of the first AI coding tools I used, and it had a big impact on how I thought about AI-assisted coding.

I just looked up in my GitHub Billing History and noticed that I've been using Copilot since 2023-10-27. That's exactly 31 months ago. What a journey. For the most part of that time – let's say the first 25 months, I used GitHub Copilot in WebStorm (and VS Code), which was a great way to get started with AI-assisted coding. It felt like a natural extension of the IDE's existing autocomplete features, and it worked well for small code snippets and boilerplate.

However, it also had its limitations. It often struggled with larger code contexts, complex Angular patterns, and multi-file refactorings. In particular, it was usually a step or two behind modern Angular APIs: it kept suggesting NgModule-based code long after standalone components had become the default, leaned on *ngIf and *ngFor instead of the new control flow syntax, and rarely reached for signals, input() or output() on its own. It was more of a helper for writing code than a partner for driving larger coding workflows. And sometimes it just was pretty annoying, suggesting irrelevant or incorrect code that I had to manually reject.

In 2025, I also experimented quite a bit with Cursor. However, I still didn't like the VS Code clone too much and preferred to stay in my beloved JetBrains editors.

WebStorm + AI Assistant + Junie + Opus 4.5

Switch to November 2025 when Opus 4.5 was released. People on social platforms got pretty excited and also some of my friends pushed me to try the new model. So again, I followed the easy path and I started to use the new model through AI Assistant and Junie in WebStorm.

For context: JetBrains AI Assistant is the AI layer built directly into JetBrains IDEs like WebStorm. It gives you the typical IDE-integrated AI features: chat, code explanations, code generation, documentation help, code completion, and smaller edits in the context of the project. The same AI Assistant interface is also becoming more of a hub for different agents and providers, so depending on your setup you can use tools like Junie, Claude, Codex or even Cursor and a lot more from inside the JetBrains workflow.

Junie is JetBrains' own more agentic coding tool. Instead of only answering questions or completing snippets, it can take a task, create a plan, edit multiple files, run commands or tests if you allow it, and iterate inside the IDE.

But then, since I was using Claude Opus 4.6 most of the time, I wanted to experiment with different harnesses for that model. So I came to a new workflow where I used VS Code with the Claude Code extension for my agentic coding.

VS Code + Claude Code + Opus 4.6

A few weeks after Opus 4.6 was released to the public, I think it was around the end of February, I started to look more seriously for the best harness for that model. Until then, I mostly thought about the model itself: is it good enough, fast enough, and useful enough for real Angular work? But the more I compared the different tools, the more obvious it became that the surrounding app matters a lot.

VS Code was a natural candidate for that experiment. I never loved it as much as my JetBrains IDEs, but I knew it well from the work in my Angular Architects workshops, where many participants use it as their main editor. And with the Claude Code extension in VS Code, I had the first setup where Opus really felt stronger because of the harness around it. Suddenly Opus could read across an entire Angular feature folder, follow a signal from computed() back to its source, and propose multi-file edits that respected my standalone-component setup, my routing, and even my providedIn: 'root' services without me having to spoon-feed it the context.

That was the moment where I started to think: OK, this is not only about the LLM anymore. Well and that was even before I tried the agentic coding apps or what I like to call them super apps for the first time.

Beyond IDE: Agentic Coding Apps (Super Apps)

After using VS Code for my agentic coding for about a month or so, I was ready to start a new journey.

In the screenshot above, you can see the four main apps I currently use for agentic coding: Claude Desktop app, Codex, Cursor, and Antigravity. Oh boy, they really look the same, don't they?

To be clear, I strictly follow a human-in-the-loop workflow here. That is because I care a lot about clean code and high-quality code. Some people think that the quality of the codebase does not, or will not, matter anymore in the future. I strongly disagree with that view, although I accept it as a fair point that challenges my own position.

At first glance, these tools look like different skins around the same idea. But the more I use them, the more I think they are actually making different bets. The Claude Desktop app feels terminal-first and model-first: give a strong model a lot of tool access and let it work. Codex feels app-first and verification-first: keep the interface calm, use the local environment when possible, and make the agent prove more of its work. Cursor feels IDE- and cloud-first: keep the editor close, but also make it possible to run agents somewhere else and bring the result back into the team workflow.

Claude Desktop app + Opus 4.7

Whichever of these bets a tool makes, my own rule stays the same: I review everything these tools do, and I want every line of code to look exactly as if I had handcrafted it. Since the Claude Desktop app and the VS Code extension share the same underlying Claude Code agent harness, the app already felt familiar to me. The Claude CLI is the canonical surface; the desktop app and the VS Code/JetBrains extensions are different front-ends that drive that same harness.

To be honest, I have never been much of a CLI guy (nor Linux – I prefer macOS – but I love Android), so I really prefer using a fancy desktop app. But I fully understand that this is a pure personal preference. And yeah, that's all I can say to that.

So basically, the first one of these super apps that I really used on a day-to-day basis was the Claude Desktop app. By the way, it also offers a Co-working tab, which is supposed to be the right choice for knowledge workers, while the Code tab is the choice for us developers.

The big strength of Claude Code is still the terminal story. It met developers where many of them already live, and that is probably one reason why adoption was so fast. The downside is that this also shapes the whole product: images, rich UI, visual verification, and desktop-app polish will always feel a bit different when the canonical workflow is the CLI. I also notice that Claude Code is very willing to spend tokens if that makes the agent feel more capable, for example with subagents or larger parallel explorations. That can be great for difficult tasks, but it is something I want to keep an eye on when cost and focus matter.

The newer workflow-style features make this even more extreme. Claude can split a larger task into many smaller agent runs, explore files in parallel, and compose the result back into one plan or implementation. That can be genuinely useful for broad refactorings or deep reviews, because one agent can focus on one file or concern. But it also changes the risk profile: more subagents means more tokens, more nondeterminism, and more places where a small misunderstanding can cascade. I would use this for hard, expensive problems – not for normal day-to-day edits.

For Angular work specifically, Claude Code with Opus 4.7 is the harness I trust most when a task spans the whole stack: introducing a new feature module, migrating an older area to standalone components and signals, or refactoring a non-trivial RxJS pipeline into a cleaner mix of signals and toSignal(). It also handles the boring-but-important parts well, like keeping app.config.ts, route definitions, and lazy-loaded feature routes in sync after a rename.

Codex + GPT 5.5

Remember the Claude app's split between the Code and Co-working tabs? That is already a big difference compared with the Codex app by OpenAI, because Codex does not split these workflows into separate apps. Instead, it combines coding and co-working in just one app.

Again, starting to use Codex at the end of April felt familiar because it more or less had the same interface as the Claude Desktop app. But from day one, I had the feeling that there were fewer bugs and that the Codex app, and therefore the GPT harness, just worked most of the time.

What I like about Codex is that it usually feels less theatrical. There is less visual noise, fewer little productivity animations, and more focus on the task, the diff, the terminal output, and the verification. That sounds boring, but for me boring is often good when I work on real code. I especially like the direction around using the machine and environment I already have configured instead of pretending that every project is easy to run in a clean cloud sandbox. For an Angular application with local setup, browser checks, environment variables, internal packages, and maybe a slightly weird test configuration, that matters a lot.

And there is another practical detail I really like: Codex can now be controlled from the smartphone while it still uses the desktop machine as the actual working environment. So I can start or continue a task from the couch, the train, or wherever, without moving the whole project into a cloud runner. Of course, I still review the diff properly later, but for keeping an agent moving this is very convenient.

So my personal verdict would be that the Codex app is superior to the Claude Desktop app. However, the underlying models in the Claude Desktop app, Opus 4.5, 4.6, and 4.7, are still superior to GPT 5.5 in many cases, especially in the fields I mentioned in the last post, such as architecture, design, and more.

In day-to-day Angular tasks, though, the gap is often smaller than the model benchmarks suggest. Codex with GPT 5.5 is very strong at the kind of work that fills most of my week: writing or updating standalone components, generating Vitest or Jasmine specs that actually use TestBed, scaffolding signal-based stores, and producing usable Signal Forms code. Where I still reach for the Claude Desktop app is the harder, more design-heavy work, for example shaping a new feature's component tree or untangling a legacy service.

Cursor + Composer 2.5

Once I decided to do a workshop about agentic coding, I realized I had to try out all the available options and not just use my favorite ones. So of course, one candidate for the best super app, or in other words, agentic coding app, is Cursor.

Cursor, basically a VS Code fork, was one of the first IDEs to really focus on agentic coding and agentic workflows, and many people started to use these workflows much earlier than I did. But in the past, let's say at the beginning of 2025, I had the feeling that the code generation was not really good enough for my requirements.

That was then. Today, Cursor plays in a different league: it recently announced a major deal with SpaceXAI that gives SpaceXAI the option to acquire Cursor for 60 billion dollars, or to pay 10 billion dollars for their partnership instead. So this is no longer only a small IDE story.

So why are Cursor and SpaceXAI such a good match? Because SpaceXAI has huge compute with Colossus 2, while Cursor has strong product usage signals and developer workflow telemetry. Together, they are about to enter, or have already entered, the frontier stage of agentic coding.

By the way, Cursor and Composer 2.5 are also super fast, and they can be a cheap alternative if you really have to pay for the tokens and cannot use the subsidized OpenAI or Anthropic subscription model. But more on the costs of using these tools in the next post.

The part I had underestimated is Cursor's cloud story. I used to think of Cursor mostly as the AI-first VS Code clone. That is still part of it, of course, but the more interesting direction is letting agents run away from my local machine and come back with a result. If your team wants to trigger work from Slack, run several agents in parallel, or give non-developers a safe way to start small engineering tasks, Cursor's cloud agents become much more interesting than the editor alone. Of course, this also makes the data and policy side more important.

For Angular specifically, I found Composer 2.5 most useful for the mechanical kind of refactor: renaming a service across an entire feature, converting a class-based @Input() to the new input() signal API, or rewriting a template from *ngIf/*ngFor to the new @if/@for control flow. It is fast enough to feel interactive, and that speed changes how often you actually run a refactor instead of postponing it.

Antigravity + Gemini 3.5 Flash

A little more than a week ago (on May 19, 2026), Google also announced a new release at Google I/O, where they presented the new agentic coding app called Antigravity 2.0. The interesting thing is that they transformed Antigravity from an IDE with an included agentic coding workflow into a super app similar to the Claude Desktop app and Codex. If you compare the user interface to Codex, it almost feels like a one-to-one copy, which is good because I think Codex currently has the best user interface of all the options.

The former IDE is now kind of an integrated sub-app that can be triggered from the Antigravity app whenever needed. This is actually a really good idea, and I like it very much. The same idea already exists in Codex, where you can open your preferred IDE. In my case, that would be WebStorm, of course. For whatever reason, the Claude Desktop app is missing that feature.

So while this 2.0 release is definitely a big step in the right direction, I personally don't think Antigravity is competitive with the other options yet. There are two reasons for that. First, the app still feels clunky and buggy, and it has fewer settings than the other apps, so it just does not feel as mature. Second, yes, you can use other models, but I think the real point of using Antigravity is to use it with Gemini models, especially Gemini 3.5 Flash in the new Antigravity 2.0 setup. Usage for models like Opus 4.6 has recently been reduced, and I guess it will be reduced even more in the future.

On Angular tasks, Gemini 3.5 Flash is fast, and that speed is useful when you want quick iterations over a whole feature module or a long template. But for my daily work it is simply not competitive yet: in practice I still see it default to slightly older Angular idioms more often than Opus 4.7 or GPT 5.5, especially around signals and the new control flow. With clear guardrails it gets there eventually, but it currently needs more steering than the other two – more than I'm willing to invest in real project work.

Open Source Alternatives to the Big Ones

Beyond the big names, I would also keep an eye on OpenCode and T3 Code. OpenCode is a solid open-source, terminal-first option if you want a model-agnostic agent and bring your own provider setup. T3 Code is interesting for the opposite reason: it gives you an open-source GUI on top of the agents you may already pay for, like Claude Code, Codex CLI, OpenCode, or Cursor.

But I'm super happy with working in the terminal

Fair enough. If you love the terminal, you can absolutely keep using it, but I no longer think it is obviously the best default for agentic coding. Apps make it easier to review diffs, manage several agents, use screenshots or browser checks, continue from the phone, and turn work into PRs. But that is personal preference, and I don't want to force anybody into my workflow.

If you are still happiest in the terminal, the OpenCode I just mentioned is the option I would suggest trying first. And if you like building your own tooling, have a look at Pi: a minimal terminal coding harness with AGENTS.md support, skills, extensions, tree-structured sessions, and many model providers. It feels less like a sealed product and more like something you can adapt to your own workflow.

I go deeper on that terminal-vs-IDE-vs-super-app split – including opencode, Pi, Claude Code, Cline, and the project setup around them – in the harness setup post.

Which Coding Agent Harness Would I Choose Today?

Okay, that was either a lot of information to digest, or you were already familiar with all the super apps and IDEs I mentioned. So let's try to summarize the current state of my workflow and which harnesses I prefer for different tasks.

My two favorite tools are definitely Codex and the Claude Desktop app. I would put them roughly on par. I use them daily for almost everything, and I feel really lucky that I can use these tools through subsidized subscription models. More on costs in the next post.

While preparing the upcoming workshop, I also found out that Cursor has really become a super app and that it supports agentic workflows very well. All three are capable of code generation, code review, modernization, refactoring, and writing tests in your Angular codebases.

The practical difference is not only which one can solve a given prompt. It is also how it tries to solve it. Claude Code is great when I want to give a strong model a lot of freedom and let it explore. Codex is great when I want a calmer engineering tool that uses my local setup and keeps verification close to the work. Cursor is great when the work should move beyond my own machine into an IDE, browser, cloud, or team workflow.

For Antigravity, however, I still see a lot of work for the Google teams before it reaches the level of the other three apps. And of course, those other apps will continue to improve as well.

For my beloved IDE WebStorm, I see difficult times ahead. I hope the JetBrains team will be able to catch up with the other apps in terms of productivity and usability when using these models for agentic tasks. There is still a big benefit to using IDEs, and they also allow you to choose between several model providers. Even Cursor allows you to do that, whereas Codex and the Claude Desktop app want to lock you into one LLM provider.

So today, I'll still stick with Codex and the Claude Desktop app. But maybe in a month or so, I might already be switching to the next super app. We will see.

Agentic Engineering Workshop

By now you can probably guess the bigger point: the app is only one piece. The model, the harness, my Angular Guardrails, my Angular Coding Style Guide, and the review workflow only work as one system – and picking that system deliberately is a skill you can learn.

If you want to pick the right harness for your team and build a strict human-in-the-loop workflow where every generated line of Angular code looks handcrafted – join our Agentic Engineering Workshop, available in English and German. Hands-on, advanced Angular developers move from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The main takeaway is simple: the harness matters. A great model in a weak app can feel surprisingly limited, while the same model in a strong agentic workflow can become much more useful for real Angular work. That is why Angular teams should not only ask which model is best, but also which harness, review process, and engineering workflow actually help them ship better code.

For my current workflow, Codex and the Claude Desktop app are still my daily drivers. Codex currently feels like the more polished app to me, while the Claude Desktop app gives me access to the Opus models that I trust most for architecture, design, and complex reasoning. By the way, Anthropic has since released Opus 4.8 (on May 28, 2026), which only underlines the point of this post: the model underneath keeps improving, while the harness around it is what I actually commit to. Cursor deserves a serious look when speed, cost, an IDE-like workflow, or cloud agents matter, and Antigravity is worth watching, but for now it still feels like it needs more time. When I do careful handcrafting, I still switch back to WebStorm.

One thing I learned quickly: don't force the same workflow onto every tool. Codex, the Claude Desktop app, Cursor, and even the smaller open-source options work best when you let them shape your workflow a little bit.

So don't get too attached to one app, one IDE, or one vendor workflow. These tools are changing too quickly, so it is worth trying new harnesses regularly and switching when they make your real project work better.

In the costs post, I look at pricing, subscriptions, and cost per accepted change. In the privacy post, I look at what these tools actually receive from your codebase and how I would think about company policy. In the personal verdict, I pull the first arc together. And in the harness setup post, I finally draw the line between app and harness and show how to configure one for Angular, step by step.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Agentic Engineering: Which LLM Is Best for Angular Development?

Alexander Thalhammer — Mon, 01 Jun 2026 20:40:36 +0000

My AI Coding Journey

It's almost six months since my last post on this blog, published in early December 2025. In that time, my daily work changed rapidly and completely. Until November 2025, I thought AI was not useful for my work in complex enterprise Angular projects, where code quality has to be very high.

But then Opus 4.5 was released to the public on November 24, 2025. I started to experiment with it and quickly found that it could help with real work: code generation, code review, documentation, modernization, refactoring, and a lot more.

The quality surprised me first. Some generated Angular code looked close to how I would have written it myself. The speed surprised me next. Naturally, I felt a bit obsolete, but it was and still is pretty exciting.

The biggest change is not that the latest models write better code. The bigger shift is that using them has become much easier: I no longer need to craft a perfect prompt upfront and hope that the result matches my intent. Instead, the interaction feels much closer to talking to a senior developer: I can describe the problem, add constraints, answer questions, clarify the spec, and let the model help discover what we actually want to build.

If you've been working with AI every day for months, there might not be much new for you in this post. But if you are rather new to Agentic Engineering and want to understand which LLM is best for Angular development, this post is for you.

Comparison from November 2025 (Outdated!)

BTW: SWE-bench itself is also showing its age. I will use more recent coding-agent benchmarks from Artificial Analysis later in this post.

I started using Opus 4.5 through my favorite IDE, WebStorm. But in this post, I don't want to talk about IDE integration, harnesses, and tools yet. That part of the journey deserves its own post. Here, I want to stay focused on one question: which LLM is the best fit for Angular development?

There is no public Angular benchmark, so we have to combine two imperfect sources: existing public coding benchmarks and personal experience from real Angular work. I want to start with the public benchmarks and then move to my own verdict.

TL;DR: My Current Ranking

In short: Opus 4.7 is my #1 for Angular, GPT 5.5 my #1 all-rounder, Composer 2.5 the newcomer to watch, and Gemini 3.5 Flash still experimental for now. The table below has the details:

Which Frontier LLMs Are Relevant for Angular in May 2026?

I personally want to use the best and latest LLMs that I can realistically use for Angular development, so I will mostly talk about frontier models that are generally available through common developer tools, APIs, or IDE integrations.

In my subjective opinion, the most relevant frontier LLMs for Angular development currently are (sorted by release date – earliest to latest):

Opus 4.7 by Anthropic, April 16, 2026
GPT 5.5 by OpenAI, April 23, 2026
Composer 2.5 by Cursor, May 18, 2026
Gemini 3.5 Flash by Google, May 19, 2026

The last two were released to the public only a few days before I wrote this, so I have not had the chance to experiment with them a lot yet. Still, I think Opus 4.7, GPT 5.5, and Composer 2.5 are the current candidates for the best LLM for Angular development. Gemini 3.5 Flash is included here because it is new and interesting, but my first impression is that it is not really a challenger to the other three models in this post. I'm still pretty sure Gemini 3.5 Pro will be a serious contender once it is released.

Public Benchmarks

At Google I/O in May 2026, Google released a bunch of new AI updates. One of those releases was Google Gemini 3.5 Flash, and the release notes included some benchmarks:

I see at least two problems here:

This is vendor-provided marketing material for Gemini 3.5 Flash, so it is not really objective.
We don't know enough about what the benchmarks are, how they were conducted, and what the results really mean for Angular development.

So what can we use instead? My favorite benchmarks are done by Artificial Analysis. They are still not Angular-specific, but they give us a better baseline for comparing model capability, speed, and token usage.

Artificial Analysis Benchmarks

I want to show you three views from Artificial Analysis: the "Coding Agent Index" for overall coding-agent performance, "Execution Time" for active agent runtime, and "Token Usage" for how much context and output the models need to solve tasks. The screenshots below were captured on May 26, 2026, so check the live leaderboard for the latest numbers.

Strictly speaking, these are coding-agent benchmarks, not pure LLM benchmarks. The harness matters a lot: the same model can behave differently in Claude Code, Cursor, Codex, OpenCode, an IDE integration, or a custom agent setup. That is why I cover harnesses and integrations separately in the apps/harnesses post and the practical setup side in the harness setup post; here I only use these numbers as a rough signal for model quality.

The Artificial Analysis Coding Agent Index is a composite score built from SWE-Bench-Pro-Hard-AA, Terminal-Bench v2, and SWE-Atlas-QnA. You can read their coding-agent benchmark methodology for the details.

It is useful for quick comparison, but it should be read alongside the per-eval breakdowns. Two agents with similar index values can still have different strengths across repository tasks, terminal workflows, and rubric-based evaluations.

Mean agent wall time per task. Lower is better.

Mean input, cache, and output tokens per task.

DeepSWE Benchmark

Update May 31st (including Opus 4.8): Another recent benchmark that matches my day-to-day impression more closely is DeepSWE. In this leaderboard – a snapshot from May 31, 2026 – GPT 5.5 leads at 70%, followed by Opus 4.8 at 58%, GPT 5.4 at 56%, Opus 4.7 at 54%, and both Opus 4.6 and Gemini 3.5 Flash at 28%. DeepSWE has since moved on to v1.1 with updated numbers, so treat these as the May snapshot and check the live leaderboard for the latest state. That lines up with my current feeling: GPT 5.5 and Opus 4.8 are both strong for serious coding work, while Gemini 3.5 Flash still feels more experimental for Angular development.

What I like about this benchmark is that it focuses more on the kind of work that matters in real agentic workflows: can the agent take a short behavioral prompt, find the right area of the codebase, and implement the change cleanly without me spelling out every file, module, and function? That is exactly the kind of workflow where traditional SWE-Bench results can feel disconnected from daily coding experience.

The most interesting part is not only the ranking itself, but the size of the gaps. A benchmark that makes a smaller model look almost as capable as a frontier coding model is not very useful for my daily work. DeepSWE feels more realistic because those gaps open up again: the weaker models fall back to where I would expect them from real agentic coding, while GPT 5.5 and Opus stay clearly ahead.

Composer 2.5 is unfortunately not part of this comparison, probably because it is mostly available through Cursor surfaces and not as a normal standalone model API.

What the Benchmarks Suggest

In these benchmark results, Gemini 3.1 Pro – still the current Pro tier, since Gemini 3.5 Pro has not shipped yet – does not look competitive with the other models. Gemini 3.5 Flash looks more interesting, but the public data is still very fresh and not specific to our framework.

My personal Angular impression is similar, but not identical: Gemini 3.5 Flash is sometimes fast and sometimes not, and it does not yet feel like a real challenger to my top three for my work. Gemini 3.5 Pro might become the more serious candidate here, but we don't have enough data yet.

In this benchmark snapshot, GPT 5.5 wins overall and is more efficient. So let me be upfront about the tension: the benchmarks I trust most currently lean GPT 5.5, yet my own Angular verdict below still puts Opus on top. That gap between leaderboard and lived experience is exactly why I treat these numbers as signals to weigh, not answers to follow.

I don't want to look at cost in detail here. That deserves its own follow-up after the tools and harnesses post, because cost depends heavily on how you access these models. For this post, the central question is still the same: which model gives Angular developers the best mix of quality, speed, and practical usefulness?

I also don't want to pretend that this post is a real benchmark. The deeper Angular evidence behind my preferences comes from my own daily work experience with modernization tasks, refactorings, code reviews, testing workflows, and brownfield scenarios. In our Agentic Engineering Workshop, I will show practical examples of why these models became my current favorites for professional Angular work.

Before I move to my personal verdict, there are four side questions worth clearing up because they often come up when comparing current LLMs: Chinese models, European models, local models, and whether any of them are actually open source.

But what about the Chinese LLMs?

As of May 2026, Chinese LLMs like DeepSeek V4, Qwen 3.6, and Kimi K2.6 are absolutely worth watching, especially because they are pushing very hard on coding quality, open weights, and low cost. But for serious Angular development, I have not seen enough evidence yet to put them in the same tier as Opus 4.7, GPT 5.5, or Composer 2.5, so for now they are interesting to observe, not models I would bet my enterprise work on.

And what about the European LLMs?

As of May 2026, European LLMs are mostly a Mistral story for me, with Mistral Large 3 as the latest model worth tracking: interesting, improving, and relevant when data residency, EU vendors, or open-weight deployment matter. But for raw coding capability in my Angular work, I would not rank them with the frontier labs right now, so I would treat them as strategic options rather than serious candidates for the best model.

And what about local LLMs?

As of May 2026, local LLMs are no longer just toys, but we have to be precise about what "local" means. Running a model on my MacBook Pro is very different from self-hosting a huge open-weight MoE (Mixture of Experts) model on serious GPU infrastructure.

For local or self-hosted coding workflows, Qwen 3.6 is probably the most interesting family to watch right now, especially because the Qwen team explicitly focuses on agentic coding, repository-level reasoning, and local deployment via Transformers, llama.cpp, MLX, vLLM, and SGLang. DeepSeek V4 is also very relevant in the open-weight space, but the larger variants are more realistic for server-side self-hosting than for a normal developer machine. From Europe, Mistral 3 is interesting because Mistral Large 3 and the smaller Ministral 3 models are open-weight, with the smaller models explicitly targeting edge and local use cases.

For my professional Angular work, I would not put local models in the same tier as my current favorites yet. The gap is not only raw model quality, but also tool use, long-running agent reliability, context handling, and integration quality. Still, local models are becoming useful for privacy- or regulatory-sensitive work, CI helpers, and teams that want more control over where their code goes. I would not ignore them anymore, but I also would not make them my choice for enterprise Angular development today.

Are any of these models open source?

This is where the wording gets a bit tricky, because with LLMs people often say "open source" when they really mean "open weights". Claude, GPT, Gemini, and Composer 2.5 are not open source models in the practical sense, although Composer is based on Moonshot's open Kimi checkpoint. DeepSeek, Qwen, Kimi, and some Mistral models are much closer to that world because their weights are available under permissive or semi-permissive licenses. Still, even there, we usually don't get the full training data, training code, and recipe, so I would call them open-weight models rather than fully open source models.

My Subjective Verdict

With that context out of the way, I want to move to my own experience with these LLMs. For me, the real question is not only which model wins a benchmark, but which model fits which part of an Angular workflow. This part is purely subjective, and I'm open to other opinions and experiences. If you disagree with me, please let me know in the comments on X or Reddit.

My #1 for Angular: Opus 4.7 by Anthropic

My favorite model is Opus 4.7. It is the best LLM for Angular development in my opinion because it has the strongest code quality, the best overall performance, and still feels fast enough for serious agentic work.

It is also the most versatile LLM. The big shift for me is that Opus 4.7 no longer feels like a junior helper that needs tiny step-by-step prompts, but more like a senior partner that works best when I give it context, constraints, and good questions.

I think this model is currently the most capable one for complex enterprise Angular applications. It's also the most expensive one, especially in Extra and Max Mode, but I think it's worth it for the quality of the results.

I really like doing agentic work with this model, especially for tasks where I want it to explore trade-offs, challenge assumptions, and come back with a concrete implementation plan. In the follow-up post about tools and harnesses, I show how I use it in practice.

My #1 all-rounder: GPT 5.5 by OpenAI

GPT 5.5 is also a great LLM for Angular development, and OpenAI's introduction matches what I see in practice: its real strength is focused implementation work. It writes excellent code and is very token-efficient, especially when you do not force the highest reasoning level. However, it is not as versatile as Opus 4.7, and I find it more sensitive to context: if it starts from the wrong assumption, I often get better results by opening a fresh thread with clearer constraints instead of trying to steer the old one back.

That efficiency matters because GPT 5.5 is expensive per token, but it often needs fewer tokens to finish a task than competing frontier models. For practical work, I would start with lower or medium reasoning and only move up when the task really needs it.

For everyday chat use cases, I really like this model. I use it for a variety of tasks, especially when I want to think through a problem by asking a series of focused questions, then start a clean implementation thread once the direction is clear. For example, if I need help fixing the language of this blog post, I will definitely choose GPT 5.5, but I also (currently) prefer it for modernization and refactoring of Angular projects. Have you tried resolving hard merge conflicts? Oh boy, that's really a relief. Hard to trust though because it's so fast. I think it's kind of a senior engineer while Opus 4.7 is the better architect, but that's for sure subjective.

My #1 newcomer: Composer 2.5 by Cursor

Composer 2.5 is a very interesting LLM for Angular development because it combines good code quality with very high speed. The most interesting claim from the current discussion around it is that Cursor post-trained it on Moonshot's Kimi K2.5 open-weight checkpoint and, on Cursor's own benchmark, got surprisingly close to GPT 5.5 and Opus 4.7 at a much lower cost. The important caveat is that this is still hard to verify independently because Composer is mostly available through Cursor surfaces, not as a normal model API.

If costs are important to you and you cannot rely on generous included usage in paid plans such as Claude Code or Codex, Composer 2.5 might be the best option for your setup, but only if Cursor fits your workflow. I cover tools and harnesses in the follow-up post, and then come back to costs and access models in a dedicated follow-up.

Candidate to watch: Gemini 3.5 Flash now, Gemini 3.5 Pro later

Gemini 3.5 Flash is interesting, but my first impression is mixed: sometimes it is fast, sometimes it is not, and for Angular development it does not yet feel like a real challenger to Opus 4.7, GPT 5.5, or Composer 2.5. I still need more hands-on time and better external benchmark data before I can recommend it with confidence. Gemini 3.5 Pro might become the more serious candidate here, especially if it combines stronger coding quality with more consistent speed.

But Alex, what about the new model(s)?

Only two days after publishing this post (on May 28, 2026), Anthropic released Claude Opus 4.8. So does that mean this post was already outdated two or three days later?

I don't think so.

There is probably some improvement from Opus 4.7 to Opus 4.8, and Anthropic's benchmark numbers are impressive. The new model, and the next ones after it, might beat other models such as GPT 5.5 on several benchmarks. But that does not change the main point of this post: benchmark wins are useful signals, not final answers.

For real Angular work, the best model is still the one that fits your workflow best. Try the new models when they arrive, but judge them in your own codebase, with your own tasks, your own tools, and your own review standards.

Agentic Engineering Workshop

This is also why I don't think about LLMs in isolation anymore: the model, the app, my Angular Guardrails, my Angular Coding Style Guide, the Angular Skills, and the review workflow belong together.

If you want to choose the right model for your Angular work – and actually put it to work on real modernization, refactoring, testing, and review tasks – join our Agentic Engineering Workshop, available in English and German.

In this workshop, advanced Angular developers learn how to move from vibe coding to traceable Agentic Engineering workflows: AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

The real shift is not that these models can generate code. The real shift is that they can participate in the engineering workflow: asking questions, clarifying requirements, exploring trade-offs, and helping us move from vague intent to working Angular code.

For serious Angular work, my current recommendation is simple: start with Opus 4.7 when quality, architecture, and complex agentic work matter most. Use GPT 5.5 when you want a very strong all-rounder that is efficient, pleasant to work with, and great for writing, modernization, and focused implementation tasks.

Watch Composer 2.5 closely, especially if you already work in Cursor and care a lot about speed and cost. Treat Gemini 3.5 Flash as experimental for now, and revisit once Gemini 3.5 Pro ships.

As the Opus 4.8 update above already shows, this space changes too quickly for fixed rankings to stay perfect for long. So whatever model you choose, don't rely on benchmarks alone: the real test is still whether the model helps you ship better Angular code in your own codebase.

In the next post, I look at the other half of the story: which apps, IDE integrations, and agentic coding harnesses actually make these models useful in daily Angular work. After that, I go deeper into AI coding costs, what AI coding tools do with your code, and my personal agentic coding verdict.

Thank you for reading 🙏 this blog post was written by Alexander Thalhammer. For feedback, remarks or questions, please reach out to me ❤️

Why Angular ARIA in v21 is pretty neat

Alexander Thalhammer — Mon, 01 Dec 2025 21:48:45 +0000

Angular ARIA is a collection of headless, accessible directives that implement common WAI-ARIA patterns. The directives handle keyboard interactions, ARIA attributes, focus management, and screen reader support. All you have to do is provide the HTML structure, CSS styling, and business logic!

You feel like you've already read this before? Perfectly possible, because I've just copied and pasted the paragraph from the official Angular ARIA docs. Why should I reinvent the wheel, right? It perfectly summarizes the concept.

So the Angular team just (together with v21 on Nov 19th, 2025) released a brand-new collection of components – I mean directives – that implement common web patterns while letting you choose your own HTML, styling (CSS, SCSS, or even Tailwind), and business logic (I'd suggest TypeScript).

This is pretty much the opposite approach of Angular Material, which is an opinionated Plug & Play Design System. Both are built on top of the Angular CDK A11y package. So what do we get here?

Components

In the first release with v21, the following 12 components / directives / UI patterns are available:

search and select	navigation / menu	content organization
Autocomplete	Menu	Accordion
Listbox	Menubar	Tabs
Select & Multiselect	Toolbar	Tree
Combobox		Grid

There are – of course – plans to extend this in the future 😏

Why is this neat?

Using the Angular ARIA directives is a great way to build Angular apps by offloading some of the heavy lifting to the Angular team while still allowing full customization and user-interface branding. BTW: Check out Jessica's talk at ViteConf on YT for other things in NG v21 that are neat.

When to use Angular ARIA?

You know how to style things (at least Senior in CSS)
You build a custom Design System or an enterprise component library
You don't use any Design System and instead handcraft everything yourself

When to avoid Angular ARIA?

You don't know how to style (Junior in CSS – join my NG Styling Workshop 🎨)
You use a Design System or an enterprise component library (should be covered there)
You don't care about accessibility (come on – don't be a jerk!)

Angular Styling Best Choices Matrix

Level	Angular Material 🔌	3rd-party DS 🎨	Angular ARIA ♿	Custom UI 🛠️	Custom DS 🏢
Design	🎨 Very opinionated	⚡ Plug & Play	🤷 Depends on you	🤷 Depends on you	🤷 Depends on you
Accessibility	⚡ Plug & Play	🙂 Usually okay	⭐ Best Choice	🤷 Depends on you	🤷 Depends on you
Effort	⭐ Very low	🙂 Medium	😬 High	😅 Only if 1 app	💀 Boss will kill ya
CSS Skills	🟢 None	🟡 Junior	🔴 Senior	🔴 Senior	🟣 Master
Customization	🔒 Hard	🤷 Depends	✔ Included	♾️ No limits	⭐ Best Choice
NG Updates	🚫 Don’t customize	😬 Sometimes painful	🙂 Smooth	😎 Very smooth	😵 A lot of work
Use it for	🚀 Prototypes & demos	💸 Low-budget/legacy	🌱 Greenfield	🎨 Hobbies	🏢 Enterprise apps

Stay tuned for my next blog post comparing popular 3rd party Design Systems for Angular vs. Angular Material.

Workshops

If you want to deep-dive into Angular, we offer a variety of workshops – in English and German.

Best Practices Workshop 📈 (including Design Systems & ARIA)
NG Styling Workshop 🎨 (including Design Systems)
Accessibility Workshop ♿ (including WAI ARIA)
Performance Workshop 🚀 (because it's neat)

Conclusion

Angular ARIA delivers headless, accessible building blocks for fully customizable Angular components. It shifts complexity – keyboard handling, ARIA attributes, focus management – to the Angular team, making it ideal for custom Design Systems and tailored UIs without relying on heavy, opinionated frameworks.

This blog post was written by Alexander Thalhammer. Comment it LinkedIn, bsky, X or Reddit.

Enhancing A11y with Angular CDK

Alexander Thalhammer — Thu, 05 Jun 2025 10:00:00 +0000

The @angular/cdk/a11y package is part of the Angular Component Dev Kit (CDK) and provides a collection of services, directives, SASS mixins, and other utilities to improve the Accessibility (A11y) of your Angular apps.

These tools are invaluable when building reusable, presentation-focused components with screen-reader announcements, robust keyboard and focus support, high-contrast theming, and more. They’re especially useful if you’re creating an Angular Component Library or a Design System.

Below are some of my favorites, along with brief code examples.

LiveAnnouncer for Screen Readers

The first service we want to highlight is the LiveAnnouncer. It allows you to announce messages to screen readers, which is particularly useful for providing feedback after user interactions. It's so simple: I often replace my console.log calls with announcements.

Here's an example of that:

private readonly liveAnnouncer = inject(LiveAnnouncer);

if (this.flights().length > 0) {
  // console.log('Found ' + this.flights().length + ' flights');
  this.liveAnnouncer.announce('Found ' + this.flights().length + ' flights');
} else {
  // console.log('No flights found');
  this.liveAnnouncer.announce('No flights found');
}

Make sure to test your announcements with the use of a screen reader.

Focus Tools

The Angular CDK also includes several tools supporting your focus management.

Focus Trap

The FocusTrap Directive allows you to trap focus within a specific element, ensuring that keyboard navigation remains within that element until the user explicitly exits it.

This is particularly useful for modal dialogs or pop-ups:

<dialog class="awesome-dialog" cdkTrapFocus>
  <!–- Yay, focus won't leave this element! -->
</dialog>

If you want focus to jump in automatically, enable the cdkTrapFocusAutoCapture flag:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <!–- Yay, focus won't leave this element! -->
</dialog>

With this flag set to true, the focus will automatically be captured when the dialog opens. However, it may not always be the best choice to have an element automatically capture focus, so we can avoid this with a trick:

<dialog class="awesome-dialog" cdkTrapFocus [cdkTrapFocusAutoCapture]="true">
  <h3 class="awesome-dialog__title" tabindex="-1" cdkFocusInitial>...</h3>
  <!–- Yay, focus won't leave this element! -->
</dialog>

By adding cdkFocusInitial the title will be secretly focused initially. Since it has tabindex -1, it won't be focusable by keyboard navigation afterward.

Focus Regions

The Regions are a powerful tool that allows you to define a specific area of your application where focus should be managed. This is particularly useful for complex components like dropdowns or menus, where you want to ensure that focus remains within the component while it is open.

cdkFocusRegionStart
cdkFocusRegionEnd and optionally
cdkFocusInitial

Here's an example of how to use the Regions:

<nav>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionStart>Focus region start</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page">Another focusable link</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusInitial>Initially focused</a></li>
  <a routerLink routerLinkActive="awesome" ariaCurrentWhenActive="page" cdkFocusRegionEnd>Focus region end</a></li>
</nav>

Note: To learn about the ariaCurrentWhenActive please read my post on Accessible Angular Routes

Focus Monitor

The FocusMonitor is a service that allows you to monitor focus changes within your application. It can be used to track when an element gains or loses focus, which is particularly useful for debugging focus-related issues.

This service can be injected into your components or services, and you can subscribe to focus changes:

import { Component, DestroyRef, effect, ElementRef, inject, viewChild } from '@angular/core';
import { FocusMonitor, FocusOrigin } from '@angular/cdk/a11y';

@Component({
  selector: 'app-navbar',
  template: `<nav #observed class="awesome-nav-cnt"><!-- children --></nav>`,
})
export class AwesomeFocusMonitorComponent {
  private readonly destroyRef = inject(DestroyRef);
  private readonly focusMonitor = inject(FocusMonitor);
  private readonly observedElementRef = viewChild.required<ElementRef<HTMLElement>>('observed');

  constructor() {
    effect(() => {
      const observedElementRef = this.observedElementRef(); // effect will run when the view is initialized
      this.focusMonitor.monitor(observedElementRef, true).subscribe((origin: FocusOrigin) => console.log(origin));
      this.destroyRef.onDestroy(() => this.focusMonitor.stopMonitoring(observedElementRef));
    });
  }
}

This is particularly useful for debugging focus-related issues, as it allows you to see when an element gains or loses focus.

FocusOrigin can be one of the following:

'mouse' the element was focused with the mouse
'keyboard' it was focused with the keyboard
'touch' it was focused by touching on a touchscreen
'program' it was focused programmatically, whereas
null indicates the element was blurred

So, this is also useful to check if a touch device is being used 😏

Styling utilities

The Angular A11y package also includes two useful Sass mixins.

Hidden Elements

Screen readers and other assistive technology skip elements that have display: none, visibility: hidden, opacity: 0, height: 0, or width: 0. In some cases, you may need to visually hide an element while keeping it available to assistive technology (e.g. Screen Readers).

@use '@angular/cdk';

@include cdk.a11y-visually-hidden();

<div class="awesome-toggle">
  <input type="checkbox" class="cdk-visually-hidden" />
</div>

High Contrast Mode

Some operating systems and/or devices include a High Contrast Mode. The Angular A11y package provides a Sass mixin that lets you define styles that only apply in high contrast mode. To create a high contrast style, just wrap it into the high-contrast mixin.

@use '@angular/cdk';

button {
  @include cdk.high-contrast {
    outline: 3px solid gold;
  }
}

The mixin works by targeting the forced-colors media query.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

With these tools, you can significantly enhance the accessibility of your Angular Apps. They help ensure that your components are not only functional but also user-friendly for everyone, including those with disabilities.

One last thing: In this Code lab by Google, you can find some exercises on the most important Angular CDK A11y tools https://codelabs.developers.google.com/angular-a11y#8

That's all folks!

This is the last edition of our A11y series. I hope you found it helpful and learned something new about making your Angular Apps more accessible and user-friendly for all of us, and that you are ready for the European Accessibility Act (EAA). If uncertain, please go back to the start of the A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Angular CDK Accessibility – official docs
Google codelab on A11y by Emma Twersky

Building Accessible Forms with Angular

Alexander Thalhammer — Mon, 02 Jun 2025 10:00:00 +0000

Accessible Angular Forms are essential to ensure that all our users – including those with disabilities – can interact with our Angular App effectively. By implementing forms with Accessibility (A11y) in mind, we meet legal (EAA 2025 ♿) and ethical standards, and create a more inclusive experience. Accessible forms work better with screen readers, keyboard navigation, and assistive technologies – which not only helps users with impairments but also enhances the overall UX of our Angular Apps.

Angular Forms

In Angular, we have two types of forms:

Template-driven Forms: These are simpler and more declarative, relying on Angular Directives to create forms. They are built around the NgModel directive and generally used for simple forms. As the name suggests, these are implemented in the template through attributes.
Reactive Forms: These are more powerful and flexible, allowing for complex form structures and dynamic validation. They are built in the component class around the FormGroup and FormControl classes. Most often the FormBuilder service is used to create the forms.

In 2025, the Angular team is expected to work on Signal integration for Angular Forms.

However, no matter which type of form you choose – and whether you migrate from Observables to Signals or not – the goal is to ensure that your forms are accessible to all users. This includes providing proper labels, error messages, and keyboard navigation. To keep the focus on A11y, we will use the simpler template-driven approach without any reactivity in our examples.

Keyboard Navigation & Tab Focus

Keyboard navigation is a critical part of form A11y. Many users rely on the keyboard – rather than a mouse – to move through a form using the Tab, Shift + Tab, Arrow, and Enter keys. Ensuring a logical tab order, using semantic HTML elements like <label>, <input>, <button>, and avoiding custom controls that break default behavior, helps users navigate efficiently. You should not change the order. However, you can add tabindex="0" to include non-interactive elements or custom components, and use tabindex="-1" to remove elements from the tab order.

Additionally, visual focus indicators (like outlines, at least 2 if not 3px width) should be clearly visible to show which element is currently active. When done right, keyboard-friendly forms not only improve A11y but also lead to a smoother and more intuitive experience for all users 😎

Form Fields

Labels & type attribute

To ensure A11y, always associate <label> elements with their corresponding form controls using the for and id attributes. This improves support for screen readers and enables better keyboard navigation – clicking a label should focus the related input. Make sure each id is unique, especially when using multiple forms on the same page. Additionally, specify the correct type for all <input> and <button> elements to ensure proper behavior, like submitting a form when pressing Enter on a <button type="submit">.

<label for="from">From</label> <input type="text" name="from" id="from" [...] />

Grouping fields

When we have a group of related inputs, especially radio buttons or checkboxes, screen readers benefit from extra semantic context by <fieldset> and <legend>:

<fieldset>
  <legend>Flight Class</legend>
  <label for="economy">Economy</label>
  <input type="radio" name="class" id="economy" value="economy" />
  <label for="business">Business</label>
  <input type="radio" name="class" id="business" value="business" />
</fieldset>

This provides context for assistive tech. Without this, users may hear "Economy" and "Business" without understanding they are part of a group. The <fieldset> element groups related controls, while the <legend> provides a caption for the group.

Required fields

When a form element (like <input>, <select>, or <textarea>) must have a value, use the required attribute. This prevents form submission unless the required fields are filled out, and helps users with assistive technologies understand which fields need valid content. For example, add the required attribute to both input fields in your form, and consider adding an asterisk (*) as an additional visual indicator.

<label for="name">Name (*)</label> <input type="text" name="name" id="name" required />

Autocomplete

The autocomplete attribute is a powerful tool for improving the user experience in forms. It allows browsers to remember and suggest previously entered values, making it easier for users to fill out forms quickly. By using the autocomplete attribute, you can specify the type of data expected in each field, such as name, email, or address. This not only enhances usability but also helps with A11y by providing clear context for screen readers and assistive technologies.

<input type="text" name="phone" autocomplete="phone" />

To avoid autocomplete, we should set the autocomplete attribute to off. This is especially useful for sensitive information like passwords or when you want to ensure that users enter fresh data.

<input type="password" name="password" autocomplete="off" />

ARIA attributes

ARIA attributes (more on them in our last post) can enhance the A11y of our Angular Forms by providing additional context to assistive technologies when native HTML alone isn’t enough. Attributes like aria-label or aria-labelledby can offer accessible names for form controls when visible labels aren’t practical. While ARIA should never replace semantic HTML, it’s a powerful tool to bridge A11y gaps and ensure all users can understand and interact with your forms effectively.

<input type="search" name="search" aria-label="Search flights" placeholder="Search..." />

For validation, aria-invalid="true" can indicate a validation error and aria-describedby can provide additional context or instructions. For example, if a user enters an invalid email address, you can set aria-invalid="true" on the input field and use aria-describedby to point to an error message that explains the issue.

@let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

<input type="text" name="from" id="from" required [attr.aria-invalid]="!!hasFromErrors" [attr.aria-describedby]="hasFromErrors ? 'from_error' : null" />

Speaking about error messages, let's take a look at how to handle them.

Error messages

Accessible error messages help all users understand and correct form issues. Use aria-describedby (as in the example above) to link inputs to their error messages, and add aria-live="polite" to ensure screen readers announce them when they appear. Messages should be clear, concise, and not rely on color alone – always provide text or icons for better clarity.

Personal preferences of error messages:

only after user interaction with the form: on blur ("touched" in Angular) or after submitting.
focus on the first invalid control (see code example below) upon submitting.
inline with the form fields, not at the top or bottom of the form.
after the form field, not before.
in (dark) red and with an icon (e.g., ❌) to make them more visible.

export class FlightSearchComponent {
  private readonly document = inject(DOCUMENT); // for the focus
  private readonly flightSearchForm = viewChild.required<NgForm>('flightSearchForm');

  protected onSearch(): void {
    if (this.flightSearchForm()?.invalid) {
      this.markFormGroupTouched(this.flightSearchForm());
      this.focusFirstInvalidControl(this.flightSearchForm());
      return;
    }

    // do the search
  }

  private markFormGroupTouched(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control instanceof FormGroup) {
        this.markFormGroupTouched(control);
      } else {
        control?.markAsTouched();
      }
    });
  }

  private focusFirstInvalidControl(formGroup: FormGroup): void {
    for (const key of Object.keys(formGroup.controls)) {
      const control = formGroup.get(key);
      if (control?.invalid) {
        const invalidControl = this.document.querySelector(`[name="${key}"]`);
        (invalidControl as HTMLElement)?.focus();
        break;
      }
    }
  }
}

<form #flightSearchForm="ngForm">
  <label for="fromAirport">From (*)</label>

  @let hasFromErrors = flightSearchForm.controls['from'] && flightSearchForm.controls['from'].touched && flightSearchForm.controls['from'].errors;

  <input
    type="text"
    name="from"
    id="fromAirport"
    required
    [minlength]="minLength"
    [maxlength]="maxLength"
    [pattern]="pattern"
    [attr.aria-invalid]="!!hasFromErrors"
    [attr.aria-describedby]="hasFromErrors ? 'fromErrors' : null"
    [(ngModel)]="from"
  />

  @if (hasFromErrors) {
  <app-flight-validation-errors id="fromErrors" [errors]="flightSearchForm.controls['from'].errors" fieldLabel="From" />
  }
</form>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Building accessible forms in Angular is not just a best practice – it’s a commitment to creating better experiences for everyone. With just a few thoughtful choices, you can make your forms inclusive, intuitive, and ready for the future. For more information on Angular and Accessibility, check out my A11y blog series.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

ARIA roles and attributes in Angular

Alexander Thalhammer — Fri, 30 May 2025 13:34:52 +0000

ARIA (short for Accessible Rich Internet Applications) roles and attributes are used to improve Accessibility of our Angular apps – especially for users who rely on assistive technologies like screen readers, voice control, or alternative input devices. Using ARIA is essential for building inclusive, user-friendly web apps.

About ARIA

ARIA was developed by the World Wide Web Consortium’s Web Accessibility Initiative (WAI) to enhance the accessibility of dynamic web content. The WAI also is the organization behind the Web Content Accessibility Guidelines (WCAG), which provide a comprehensive framework for A11y – more about WCAG in the intro of this A11y blog series.

Originating in the early 2000s, ARIA was created to bridge the gaps in native HTML, ensuring that modern, interactive and single-page applications are usable by people with disabilities ♿

ARIA in Angular

In Angular, ARIA roles and attributes can be easily integrated into your components. You can use them directly in your HTML view templates, just like any other HTML attribute. Angular also provides built-in support for ARIA through directives and bindings, making it easier to manage ARIA properties dynamically.

When using static values, you can simply add them to your HTML elements or components:

<!-- Static ARIA attributes require no extra -->
<button type="button" aria-label="Close">X</button>

However, when you want to bind ARIA attributes dynamically, you should use Angular's property binding syntax ("[]" square brackets) including the "attr." prefix:

<!-- Dynamic ARIA attribute property binding with "attr." prefix -->
<button type="button" [attr.aria-label]="myActionLabel">…</button>

ARIA vs. Semantic HTML

While ARIA is a powerful tool for enhancing accessibility, it should be used as a last resort. Native semantic HTML elements and attributes are preferred whenever possible, as they provide built-in accessibility features that ARIA does not have to replicate. Always prefer native elements like <button>, <label>, <nav> and <header> over their ARIA counterparts. For example, instead of using role="button" on a <div>, use a <button> element.

ARIA Roles

Speaking about ARIA roles, they define what an HTML element is or how it should behave – when native HTML elements are not applicable. They tell assistive technologies how to interpret an element and its purpose within the page. Roles are particularly useful for custom components that don’t have native semantic meaning.

Most commonly used ARIA roles

Here is a not exhaustive list of some ot the most commonly used ARIA roles:

role="button" (prefer <button>) indicates an interactive element that triggers an action.
role="main" (prefer <main>) the main content of your app – typically <router-outlet />.
role="complementary" (prefer <aside>) denotes content that complements – like a sidebar.
role="navigation" (prefer <nav>) denotes a section of navigation links – like your route nav.
role="alert" used for important messages that should be immediately announced.
role="dialog" signifies a modal or popup window.
role="listbox" used for a widget that allows the user to select from a list of options.
role="tablist" composes a tabbed interface.
role="tab" represents a selectable tab in a tabbed interface.
role="tabpanel" the container for the content associated with a tab.

Find a comprehensive list of all ARIA roles by MDN.

Examples

This could be a <app-dialog> component:

<app-dialog role="dialog" aria-labelledby="dialogTitle" aria-modal="true" cdkFocusTrap>
  <h2 id="dialogTitle">{{ dialogTitle() }}</h2>
  <p>{{ dialogContent() }}</p>
  <button type="button" (click)="onClose()">Close</button>
</app-dialog>

In this simple example, the role="dialog" indicates that this is a dialog window. The aria-labelledby attribute associates the dialog with its title, and aria-modal="true" indicates that the dialog is modal, meaning it prevents interaction with the rest of the page until closed. Note that we also use the cdkFocusTrap directive to ensure that (keyboard navigation) focus is trapped within the dialog while it is open.

Another example could be a tab interface:

<app-tablist role="tablist">
  @for (tab of tabs(); track tab.id) {
    <button role="tab" aria-controls="panel_{{ tab.id }}" id="tab_{{ tab.id }}"
            [attr.aria-selected]="activeTab() === tab.id ? 'true' : 'false'">
      {{ tab.label }}
    </button>
  } @empty {
    No tabs available.
  }
</app-tablist>
@for (tab of tabs(); track tab.id) {
  <app-tab role="tabpanel" aria-labelledby="tab_{{ tab.id }}" id="panel_{{ tab.id }}">
    {{ tab.content }}
  </app-tab>
}

In this example, we have a tabbed interface. The role="tablist" indicates that this is a list of tabs. Each tab has the role="tab" and is associated with its corresponding panel using aria-controls. The aria-selected attribute indicates which tab is currently selected. The panels have the role="tabpanel" and are associated with their respective tabs using aria-labelledby.

ARIA Attributes

ARIA attributes provide additional details about an HTML element’s state, properties or relationships. They enhance the semantic meaning of your Angular components and other HTML elements, especially when default HTML does not fully describe an element’s behavior.

We distinguish between states and properties. States are dynamic and can change over time, while properties are static and describe the element's characteristics.

Most commonly used ARIA attributes

Widget attributes (states and properties)

aria-disabled (state/property): indicates whether an element is disabled or not – not necessary if native disabled is used.
aria-required (property): indicates that user input is required before submitting a form – not necessary if native required is used.
aria-expanded (state): communicates whether an element, such as a collapsible menu, is expanded or collapsed.
aria-hidden (state): indicates whether an element should be exposed to assistive technologies.
aria-invalid (state): indicates whether the value of an input field is valid or invalid.

Live region attributes (states)

aria-live: specifies how updates to content should be announced to the user (e.g., assertive for error messages).
aria-busy: indicates whether an element is currently being updated (e.g., loading spinner).

Drag-and-Drop attributes (states)

aria-grabbed: indicates whether an element is currently being dragged (e.g., true when dragging).

Relationship attributes (properties)

aria-label: provides a text alternative for elements that may not have visible text.
aria-labelledby: identifies an element (or elements) that labels the current element.
aria-describedby: identifies an element (or elements) that describes the current element.
aria-controls (state): references the element(s) whose content is controlled by the current element.

And here is again the full list of all ARIA attributes by MDN.

Examples

A toggle button using aria-label and aria-expanded:

<button
  type="button"
  aria-label="Toggle navigation menu"
  [attr.aria-expanded]="isMenuOpen() ? 'true' : 'false'"
  (click)="onToggleNav()">
  <i class="icon-menu"></i>
</button>

In this simple example, the aria-label attribute provides a text alternative for the button, indicating its purpose. The aria-expanded attribute indicates whether the navigation menu is currently open or closed. This is important for screen reader users, as it helps them understand the state of the button.

Using aria-live combined with role="alert" for an error message:

@let showFromErrors =
  flightSearchForm.controls.from.errors &&
  flightSearchForm.controls.from.touched;

<input
  [...]
  id="fromAirport"
  [attr.aria-invalid]="!!showFromErrors"
  [attr.aria-describedby]="showFromErrors ? 'fromAirportErrors' : null"
/>
@if (showFromErrors) {
  <app-flight-validation-errors
    aria-live="assertive"
    role="alert"
    id="fromAirportErrors"
    fieldLabel="From"
    [errors]="flightSearchForm.controls.from.errors"
  />
}

In this example, the aria-live attribute is set to assertive, which means that the screen reader will announce the error message immediately when it appears. The role="alert" indicates that this is an important message. Additionally, the aria-invalid attribute is used to indicate that the input field has validation errors and the aria-describedby attribute is used to associate the error message with the input field. Note that the aria-describedby attribute is set to null when there are no errors. This ensures that it's not present in the rendered DOM when not needed.

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility-related topics)
🚀 Performance Workshop

Conclusion

Implementing ARIA in Angular is essential for building web apps that are both accessible and inclusive. By leveraging ARIA roles and attributes appropriately, developers can bridge gaps where native HTML falls short, ensuring that all users have a positive experience. This approach not only meets accessibility standards but also lays the foundation for user-centric and future-proof design.

In the next edition of our A11y blog series, we'll cover Accessible Angular Forms.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

Accessibility in Angular Applications by Zama Khan Mohammed
Accessibility in Angular 17 by Amir Saeed
ariaCurrentWhenActive – official docs
ARIA roles
ARIA attributes

Accessible Angular Routes

Alexander Thalhammer — Tue, 27 May 2025 15:29:04 +0000

This article explains how to use Angular Router features to achieve quick wins in improving Accessibility (A11y). It is the third edition of our A11y blog series. If you want to enhance your Angular A11y skills, please make sure to read the other articles in this series as well.

Page Titles

Does your Angular App look like this if you open it in multiple tabs?

If it does, you should definitely consider adding unique page titles for each route. The very easy-to-use Route.title feature shipped with Angular v14 in 2022, yet many Angular Developers are still not using it 😱. Please take a look and adopt it in your Angular Apps.

Route.title

Use this built-in Router feature to automatically update the page <title> after each successful navigation, enhancing both accessibility and UX for all of us. To enable it in your primary <router-outlet />, you only need to set the title property in your routes configuration array:

export const routes: Routes = [
  {
    path: 'demo',
    title: 'Look how easy it is to use',
    component: DemoComponent,
  },
];

This will update the page title in the browser tab and make it accessible to screen readers.

In larger Angular Apps, setting page titles can become inconsistent due to the lack of a common prefix or suffix for routes.

Global Page Title Strategy

To address this, you can extend Angular's abstract TitleStrategy class and implement your custom page title strategy:

// [imports]

@Injectable()
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    const pageTitle = this.buildTitle(routerState);
    if (pageTitle) {
      this.title.setTitle(pageTitle + ' – Demo');
    } else {
      this.title.setTitle('Link to Demo below!');
    }
  }
}

Then add the custom title strategy to your app.config.ts:

// [imports]
import { PageTitleStrategy } from "./page-tite-strategy";

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes),
    { provide: TitleStrategy, useClass: PageTitleStrategy }, // add this line
  ],
};

Dynamic Page Titles using Angular Router Params

To create dynamic page titles using Angular Router parameters, follow these steps:

First, we set up the withComponentInputBinding() function to bind the route parameters to your component inputs:

// [imports]

export const appConfig: ApplicationConfig = {
  providers: [
    provideClientHydration(withIncrementalHydration()),
    provideExperimentalZonelessChangeDetection(),
    provideRouter(routes, withComponentInputBinding()), // add feature to router
    { provide: TitleStrategy, useClass: PageTitleStrategy },
  ],
};

Then, we add the parameter to the route definition:

export const routes: Routes = [
  // [...]
  {
    path: 'demo/:id',
    title: 'Demo #id', // note that this will be ignored and replaced by the dynamic title
    loadComponent: () => import('./demo/demo.component'),
  },
];

Now, we can simply add a input signal to the component that will automatically receive the route param (thanks to the withComponentInputBinding() feature):

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();

  // [...]
}

export default DemoComponent;

Finally, we can use an effect on our id input signal to display the dynamic page title:

// [imports & decorator]
export class DemoComponent {
  readonly id = input<number | undefined>();
  private readonly title = inject(Title);

  constructor() {
    effect(() => this.title.setTitle(this.id() !== undefined ? `Page #${this.id()} - Demo` : 'Page - Demo'));
  }
}

export default DemoComponent;

Now, when you navigate to /demo/1, the page title will be set to Page #1 - Demo.

All Together Now

To bring it all together – with the global page title strategy – we add another method to the PageTitleStrategy class and provide it in root:

// page-title-strategy.ts
import { RouterStateSnapshot, TitleStrategy } from '@angular/router';
import { inject, Injectable } from '@angular/core';
import { Title } from '@angular/platform-browser';

@Injectable({
  providedIn: 'root',
})
export class PageTitleStrategy extends TitleStrategy {
  private readonly title = inject(Title);

  updateTitle(routerState: RouterStateSnapshot): void {
    this.setTitle(this.buildTitle(routerState));
  }

  setTitle(pageTitle?: string): void {
    if (pageTitle) {
      this.title.setTitle(`${pageTitle} – Demo`);
    } else {
      this.title.setTitle('Page title like a pro');
    }
  }
}

And here is the final version of the dynamic page title effect in the DemoComponent using our injected PageTitleStrategy:

// demo.component.ts
// [imports & decorator]
export class DemoComponent {
  private readonly pageTitleStrategy = inject(PageTitleStrategy);

  readonly id = input<number | undefined>();

  constructor() {
    effect(() => this.pageTitleStrategy.setTitle(this.id() !== undefined ? `Page #${this.id()}` : 'Page'));
  }
}

export default DemoComponent;

Now you can set the page title depending on the route params and have a consistent suffix for all routes in your Angular App.

Pretty nice, huh? Check out the full source code in the title-strategy branch of my GitHub repo.

RouterLinkActive

The RouterLinkActive directive is another powerful and lightweight tool for indicating the active state of navigation links in your Angular App. It allows you to apply CSS styles to navigation links based on their active state, making it easier to create appealing and accessible menus.

<!-- nav.component.html -->
<nav>
  <a [routerLink]="demo" routerLinkActive="active">Demo</a>
  <!-- ... -->
</nav>

<!-- nav.component.scss -->
nav a.active {
  color: var(--nav-link--active__color);
  text-decoration: none;
}

Fine-tuned control with `routerLinkActiveOptions`

Since Angular v14, you can use the routerLinkActiveOptions directive to fine-tune the active state of your links. Where options will have either the shape of IsActiveMatchOptions:

export declare interface IsActiveMatchOptions {
  fragment: 'exact' | 'ignored';
  matrixParams: 'exact' | 'subset' | 'ignored';
  paths: 'exact' | 'subset';
  queryParams: 'exact' | 'subset' | 'ignored';
}

Or, just a boolean named exact:

{
  exact: boolean
}

To apply exact matching, add the routerLinkActiveOptions directive to your link:

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
  routerLinkActive="active"
  [routerLinkActiveOptions]="{ exact: true }"
  >
  Demo
  </a>
  <!-- ... -->
</nav>

Indicate current page `ariaCurrentWhenActive`

A final quick win in A11y in Angular is to highlight the current page link in the nav for screen readers via aria-current: We need to add the aria-current="page" attribute. This can easily be done using the ariaCurrentWhenActive input on the routerLinkActive directive by setting its value to "page":

<!-- nav.component.html -->
<nav>
  <a
    routerLink="/demo"
    routerLinkActive="active"
    [routerLinkActiveOptions]="{ exact: true }"
    ariaCurrentWhenActive="page"
  >
    Demo
  </a>
  <!-- ... -->
</nav>

Accessibility Workshop

For those looking to deepen their Angular expertise, we offer a range of workshops – both in English and German:

♿ Accessibility Workshop
📈 Best Practices Workshop (including accessibility related topics)
🚀 Performance Workshop

Conclusion

Implementing Angular's built-in router features is a simple yet powerful way to boost your A11y 🚀

By leveraging dynamic page titles, a global title strategy, and fine-tuning active link indicators with RouterLinkActive and ariaCurrentWhenActive, you can create a more inclusive UX that benefits everyone – from seasoned Devs (like me 😂) to users who rely on assistive technologies. These strategies not only improve UX but also help standardize navigation and page management across all Angular Apps. Back to our example from the beginning, now our browser tab bar looks like this:

I think this is a great example of a quick win! Keep playing with these features and explore the rest of our A11y blog series for more insights on building accessible, high-performing web apps.

In the next edition of our A11y blog series, we'll cover more ARIA roles and attributes.

This blog post was written by Alexander Thalhammer. Follow me on Linkedin, X or giThub.

References

GitHub repo of demo, by Alexander Thalhammer
Angular v14 – official blog post by Emma Twersky
Tweet about Route title by Emma Twersky
Page Titles With The Router by Brandon Roberts
Router Link Accessibility Features by Brian Treese
Make it accessible: Navigation in Angular by Daniel Marin
ariaCurrentWhenActive – official docs

DEV Community: Alexander Thalhammer

Agentic Engineering: How to Set Up Your Harness for Angular Development

Agentic Engineering: How to Set Up Your Harness for Angular Development

TL;DR: The Harness Is Where Your Quality Lives

So What Is the Harness?

Model, Harness, App – What's the Difference?

When the Claude Code Harness Leaked

So Which Harness Is Best for Angular?

In the Terminal

The Super Apps

Inside Your IDE

The Fourth Factor: Your Codebase

So How Do I Actually Set This Up?

Start from a Clean ng new

Quality Gates: Make Formatting and Linting Non-Negotiable

Hand the Agent Your Style Guide

Turn AGENTS.md Into an Operating Contract

Wire Up Every Agent

Feedback Loops

Linting

Building

Serving

Chrome Debugger

E2E Testing

Agentic Engineering Workshop

Conclusion

Anthropic Just Released the First Next-Gen Model to the Public

What Makes Fable 5 a New Generation?

Every Fable Has Its Fine Print

My Updated Current Setup

Human in the Loop – for How Much Longer?

Agentic Engineering Workshop

Conclusion

Update June 13th

Update June 22nd

Update July 4th

Agentic Verdict: What's the Best Solution for You?

Agentic Verdict: What's the Best Solution for You?

This Is Still Not a Benchmark

TL;DR: My Current Verdict

And the Winner (My Current Setup) Is

What Is the Best Solution for You?

But Alex, My Favorite IDE Is Not Mentioned

Effort and Fast Mode

What Plan Do I Choose?

What I Would Recommend to Teams

Enterprise / API Pricing Considerations

Cursor & Composer 2.5

Codex, GPT (and Claude Opus) With Low Effort

Agentic Engineering Workshop

Conclusion

Update June 21st

Agentic Engineering: What Do AI Coding Tools Do With Your Code?

TL;DR: Do Not Ban AI, Approve Safe Paths

This Is Not a Legal Guide

What Do We Actually Share?

More Than Reading: Breach and Industrial Espionage

What I Found in Vendor Docs

Consumer Plans vs Business Plans

No Training Is Not the Same as No Retention

EU and Regulatory Considerations

Green, Yellow, Red

"We Are Not Allowed to Use AI"

A Simple Company Policy

My Personal Verdict

Agentic Engineering Workshop

Conclusion

Agentic Engineering: What Does AI Coding Really Cost?

This Is Still Not a Benchmark

TL;DR: Start With €40 or €60, Upgrade Only Where You Hit Limits

Why Subscriptions Are Such a Good Deal

The €20 Tier Is for Getting Started

The Current Pricing Picture

OpenAI / Codex

Anthropic / Claude

Cursor

Google / Gemini / Antigravity

Copilot

Team Plans Sit in the Middle

Enterprise Is a Different Game

Start from a Clean `ng new`