DEV Community: Alexander Thalhammer

Agentic Engineering: Skills for Angular Development

Alexander Thalhammer — Sun, 06 Sep 2026 17:13:17 +0000

Less than a week ago (on August 29, 2026) I published my quarterly summer update post. Oh my god, has it aged in just a few days! At least four exciting models have been "released" since then. I put released in quotes, because the most interesting of those, namely GPT-6 Astra, hasn't yet landed in my Codex – I mean ChatGPT app (why the f. did they rename it?):

Claude Fable 5.1 by Anthropic (now we know why they released it 😏)
Muse Spark 1.3 by Meta AI (for free in opencode 😲)
GPT-6 Astra by OpenAI (not landed yet 😒)
Gemini 3.8 Flash by Google (not sure if it's any good, but still worth mentioning – plus it's available in T3 Code now 😎)

Nevertheless, I feel a bit overwhelmed by all the hype about the new models, and I'm flooded with posts and videos about how each of them is the greatest ever, or even AGI arriving. So I don't feel like I need to tell you anything about them – to be honest, I couldn't, since I'm not on the early access for Astra – which in the end will probably be the only model besides Fable that I'm going to use a lot. From what I know so far, Fable is going to stick as my favorite choice for frontend and specifically Angular development.

Quick recap for everyone joining late: this series started with which LLM is best for Angular development, continued with which app or harness to wrap around it, and the third post showed how to set that harness up properly for Angular – Agent = Model + Harness, in one line. At the end of it, I promised to build on that foundation with reusable agent skills – well, here we are.

TL;DR: A Good Prompt Helps Once, a Good Skill Helps Every Time

If you only have thirty seconds: a skill is a Markdown file with a folder around it – a named, versioned, reusable procedure your agent loads only when the task calls for it. Instead of stuffing every instruction into AGENTS.md and diluting the model's attention on every single task, a skill stays out of context until its trigger fires. My catalogue currently holds 31 skills: 11 adopted from third parties, 20 custom. Copy the ones you need – and only the ones you need – into your project, and adapt them to your rules. Or don't copy anything at all and just build your own.

Every skill in this post – except the two private bookkeeping ones you'll meet in a minute – lives in a new companion repo: ng-agentic-skills.

Now, instead of joining the hype, I want to talk about the really interesting part:

Putting the LLM Progress into Practice

In your day-to-day work and life, that is. Not even a year ago I was still wondering what I could actually do with AI. Now I'm at a point where I cannot imagine life, and especially work, without it. If the harness post was about giving your coding agent a clean workspace, real guardrails, and an operating contract, this one is about giving it repeatable procedures that load themselves.

So, maybe you're not yet deep into AI and your question is: why would I need skills? Or, on the contrary, you're an AI enthusiast and your opinion is: with the latest frontier models, harness engineering and skills aren't necessary anymore, because AGI has all the skills we need baked in. While this is true in some cases – for example, we don't have to teach the frontier models what modern Angular looks like (i.e. the Angular Developer skill becomes rather useless for frontier models – not for Gemini, though) – it is not the full picture.

What a frontier model doesn't know is how you want things done: which steps, which gates, who commits. That's what a skill encodes – and that's why a good skill survives the next model generation. The bookkeeping story below is my proof.

The Purpose of Skills

I remember the times, roughly 30 years ago, when I started playing around with my computer – somewhere between Windows 3.1 and 95 – and had a lot of fun writing .bat files for repeatable tasks. Fifteen years or so later, I started writing .sh scripts for the same purpose, just a bit more powerful. Now, in 2026, I'm building skills for the same purpose and much more: every repeatable pattern that I don't want to explain to the model a second time.

Speaking of talking to the model (aka prompting): I have completely switched from keyboard to speech-to-text. You haven't? Try Wispr Flow – when you register with this referral link, you get a full month for free. Cancel after that month if you can. I couldn't, because now I'm about two times faster, and my prompts tend to be much better, because I put more detail into them now that I don't need to type anymore. Funny: 21 years ago I learned the ten-finger typing system – I remember it was pretty tough – and for a few years now, that skill has been becoming irrelevant. So yes, skills can become irrelevant – same as your AGENTS.md instructions – so you should remove the ones you don't need anymore whenever a new generation of models lands (so now would be a good time for that!).

Another Story – and an Example

Back in June 2026 I finally started on a skill that has nothing to do with Angular – or with code at all. The story: every month I have to do my company's bookkeeping. Collect the invoices from Amazon, ChatGPT, Cursor, Anthropic, and my mailbox, download the bank statement, match every debit to a receipt, and enter all of it into BMD Com, the bookkeeping software I have to feed. The chore I kept putting off every single month – and one that usually cost me a few hours.

So in June I opened the Codex app and asked it, literally, "kannst du BMD, das Buchhaltungsprogramm, bedienen?" – can you operate BMD, the bookkeeping program? It could. It chewed through the 31 receipts of May, matched them against the CAMT53 export of my bank account – the machine-readable ISO 20022 statement – and handed me a work list plus four bank entries without a receipt. Impressive, but the next month I would have had to explain all of it again. A repeatable pattern, remember? So in August it became two skills, living in .agents/skills/ right inside my bookkeeping folder – no repo, no code, just Markdown next to the PDFs.

The first one, download-bookkeeping-documents, collects the month. Amazon, ChatGPT, Cursor, and Anthropic invoices come through the logged-in Chrome session – Codex's browser control, the computer use I praised in the summer update. Statement and CAMT53 export come from George, my bank's online banking – strictly read-only, and when strong customer authentication pops up, the skill hands me the tab instead of touching it.

The invoices in my company mailbox come through a small Python IMAP importer that ships with the skill: dry run first, password in the macOS Keychain, never in the chat. Even the paper receipts I scan with my phone get rendered page by page and filed under the printed invoice date, not the scan date. Everything lands in 2026/inbox as YY-MM-DD Vendor.pdf, nothing is overwritten, duplicates are caught by hash.

Then the part that matters: the skill walks through every debit on the statement and has to explain each one – an invoice, a standing document like the rent, or legitimately no invoice, like taxes and bank fees. Until every debit is explained, it isn't done – and it says so, instead of claiming completion.

The second one, maintain-bakawa-bookkeeping, takes that hand-off and enters the month into BMD's BaKaWa incoming-invoice book, again through the logged-in Chrome tab. It reads every row, opens the attached document when a correction needs evidence, fixes dates, invoice numbers, suppliers, expense accounts, and tax codes, turns a hotel bill with 10% and 20% VAT plus a tax-free part into a proper split booking, deletes duplicate rows while keeping the document, and clears BMD's "IBAN not yet processed" warnings. It's finished only when every row shows 4-Erfasst, zero warnings remain, and the saved grid – not the edit form – says so.

The gates are my favorite part: it never initiates a payment, never touches master data, never deletes a document, and asks me before creating a bank connection.

Not one line of Angular in there – and still the same format, one reference file per source – the progressive disclosure I'll get to in a minute – and the same rule as in every code skill: the agent reports, the human decides. My monthly bookkeeping now starts with $download-bookkeeping-documents and a coffee ☕

And the part that convinced me for good: these two skills save me three to four hours every month, and they halved my external bookkeeping bill – my tax advisor now needs one hour instead of two, and that remaining hour stays on purpose: it's the professional human-in-the-loop check that everything was booked correctly. So you could say this one workflow alone sponsors all my AI subs – roughly €500 a month right now (the details are in the summer update's cost section), soonish €600 for more Astra. Now do you get why it's time to subscribe? And I'm not only talking about AI – but also about this blog 😏

So What Is a Skill?

Let's draw the line properly, like we did with app vs harness earlier in this series.

A skill is a folder inside your project (mine live in .agents/skills/) with one mandatory file, SKILL.md, and optionally references/, scripts/, or assets/ folders next to it. The format is the Agent Skills open standard – Anthropic launched skills in October 2025 and opened up the spec that December, and by now dozens of tools read it, Claude Code, Codex, Cursor, and Copilot among them. The SKILL.md starts with a small frontmatter block – name, description, some metadata – followed by the actual instructions: the process the agent should follow, step by step, including the gates where it has to stop and ask you.

Here's what that looks like in practice – the head of my git-stack-rewrite skill, trimmed:

---
name: git-stack-rewrite
description: "Fold staged changes or an existing commit into an older Git commit and rebase every affected dependent branch stack onto the rewritten commit. Use when the user says prompts like \"use git stack rewrite to squash commit [source] into [target]\", or asks to squash, fixup, amend, or move staged changes back into an earlier commit and then rebase branches that were on top of it."
license: MIT
metadata:
  author: Alexander Thalhammer
  version: '1.0'
---

# Git Stack Rewrite

## Rules

- Treat this as destructive history rewriting even when it is local-only.
- Create backup refs before moving branch heads.

That's the whole format: frontmatter, then the process. Harness-specific invocation settings can sit alongside it – we'll get to those when it's time to write your own.

The description is the trigger. When you hand your agent a task, the harness shows it the name and description of every available skill – just those few lines, not the bodies. If the description matches the task ("write unit tests", "review the staged changes", "grill me on this plan"), the agent pulls in the full SKILL.md. If not, the skill costs you roughly 100 tokens – its name and description – and nothing else. You can also invoke a skill explicitly – /code-review in Claude Code and Cursor, $code-review in Codex. Claude Code has meanwhile merged its custom slash commands into skills: a .claude/commands/deploy.md and a deploy skill both give you /deploy and work the same way – your existing commands/ files keep working, the skill just gets a folder and a trigger.

Sound familiar? It should. This is exactly the progressive disclosure pattern from the harness post, one level up. There, the style guides loaded just-in-time by file type – touch a .scss file and the SCSS style guide loads, nothing else competes for attention. Skills do the same for procedures: the testing skill loads when you're testing, the migration skill loads when you're migrating, and neither pollutes the context of the other. A bloated context dilutes attention, buries the relevant instructions, and degrades the quality of the answer – the needle-in-a-haystack problem all over again.

And the references/ folder? Progressive disclosure again, one more level down. My ng-forms skill keeps the deep material – validation, custom controls, dynamic forms – in separate reference files, and the SKILL.md tells the agent which one to open for which job. The agent reads two levels deep at most, and only what it needs.

One more thing skills are, and this took me a while to appreciate: they are a tool for predictability. An LLM is a stochastic system; a skill exists to wrangle determinism out of it. The agent won't produce the same output every run – no LLM will. But it gets the same process every run. Same steps, same gates, same checkpoints where a human looks at the result. That's what makes agent output reviewable at scale.

How to Use Skills

The wiring is refreshingly boring, which is a compliment 😊

Project skills live in the repo, committed like any other code. I keep mine tool-agnostic in .agents/skills/ – Codex and Cursor read that folder natively, and Claude Code picks it up directly too – no symlinks, no duplicated .claude/skills/ mirror, one canonical location. They ride along with the repo, so every teammate and every CI agent gets the same procedures.

After the initial commit, the companion repo has exactly two more – the first mirrors the harness setup from ng-agentic, the second adds the complete skills catalogue. So if you want to see precisely what skills add on top of a well-configured Angular workspace, git diff between those two commits is the whole story. I like releases you can read in one diff – and it will stay that way: whenever I update the catalogue, the changes get folded into that skills commit and force-pushed (the git-stack-rewrite skill from the catalogue does exactly this kind of surgery), so the history stays three commits long. If you cloned the repo, git fetch plus git reset --hard origin/main instead of git pull – you've been warned 😉

Global skills are the ones you want in every project – for me that's the meta-skills like create-a-skill and handover. Those get copied (not symlinked) into the harnesses' user-level directories:

cp -R .agents/skills/create-a-skill ~/.claude/skills/
cp -R .agents/skills/handover ~/.claude/skills/
# and the same into ~/.agents/skills/, which Codex and Cursor share:
cp -R .agents/skills/create-a-skill ~/.agents/skills/
cp -R .agents/skills/handover ~/.agents/skills/

Yes, copied twice – once for Claude Code, once for everyone else. Not elegant, but explicit – and explicit beats clever when the thing being configured is an autonomous coding agent. It also means the global copies go stale – I re-copy them whenever I touch the project version, nothing fancier than that. A useful advantage of having a separate folder for Claude is that I can choose which skills I provide for Fable and which ones for GPT. At least on the global / user level.

And that's it. No build step, no marketplace account, no lock-in. Skills are Markdown files in a folder. The format is so simple that the same catalogue works across Claude Code, Codex, and friends – which is exactly why I bothered building one.

If you want to distribute a skills catalogue to other teams, Agent Plugins provides a standard for packaging it. The skills themselves stay the same. My project-level catalogue doesn't need that packaging, so I haven't added it.

Which brings us to what's actually in the catalogue. The ng-agentic-skills repo documents all of it in 02-SKILLS.md, but let me walk you through the two groups.

Third-Party Skills

Not everything needs to be homegrown. Some problems – brainstorming before coding, test-driven development, structured debugging – are not Angular problems, and smart people have already written excellent skills for them. I adopted eleven – though, spoiler, I've since stopped using two of them:

Skill	What it does	Origin
angular-developer	The Angular team's official skill – scaffolds via the CLI, adapts to the detected Angular version, and verifies its own output with `ng build`. Not needed if, like me, you're on a frontier model like Fable (or soon Astra): as a code quality nerd I have my `AGENTS.md` and a coding style guide, and that's guidance enough. So I don't need it!	angular/skills
brainstorming	Chooses a feasibility spike, a short design in chat, or a full written specification. Use when you don't know what you need; routine, well-specified work needs no brainstorming detour.	obra/superpowers (adapted)
code-review	Two-pass review of your changes – requirements first, then style-guide conformance per file type. Definitely useful – but there are many other options, so just create your own review skill. Mine even fires up three reviewer sub-agents on different models, e.g. Fable, Sol, and Opus (I have a lot of unused Opus budget, that's why) – and since the shared skill now honours a harness file such as `.claude/CLAUDE.md`, that setup is one config line, not a fork.	obra/superpowers (adapted from requesting-code-review)
diagnosing-bugs	Feedback-loop-first debugging: build a tight red/green loop before hypothesizing, then fix behind a regression test.	mattpocock/skills (adapted)
frontend-design	Anthropic's guidance for deliberate visual choices: palette, typography, layout, motion, and interface copy grounded in the product and its audience.	anthropics/skills
grill-me	Interrogates your plan relentlessly, one question at a time, until every branch of the decision tree is resolved. Use when you know what you need.	mattpocock/skills
implement-plan	Executes an approved plan in small working slices, verifies each one, and checks the final result against the acceptance criteria.	obra/superpowers (adapted from executing-plans)
ng-verify-feature	Checks a running Angular feature in Chrome against acceptance criteria, with reproduction evidence and an explicit coverage report.	vercel-labs/agent-browser (adapted from dogfood)
spartan	Manages spartan/ui components via the Brain (headless) + Helm (styled) layers and the spartan CLI. I plan to release a new component lib post soon – watch out for that.	spartan-ng/spartan
test-driven-development	Red-green-refactor discipline: no production code without a failing test you watched fail. I don't use it – I prefer letting the model write e2e tests instead, together with the implementation.	obra/superpowers (adapted)
unslop	Cuts AI tells, mannered prose, and over-compression while preserving your meaning. For docs, ADRs, PR descriptions, commit messages, and UI copy.	cursor/plugins (pstack) (adapted)

Seven of these have adapted workflows; angular-developer and spartan also carry content corrections I keep ahead of upstream. The index records what to preserve when updating each copy. More on that in a minute.

unslop is the odd one out: it's the only skill here that polices prose rather than code. It's Lauren Tan's skill from the pstack plugin in Cursor's marketplace: patterns such as "not just X, but Y", the forced rule of three, and "serves as" where "is" would do. The latest update also catches mannered prose and sentences compressed until you have to decode them. It dropped the old instruction to add personality; preserving what I meant matters more. If you've ever merged a PR description that read like a press release, you know why it earned its slot.

Two other additions fill a gap I had between an approved design and a feature I can actually use. implement-plan takes the agreed plan through small working slices: wire the booking filter into the view and data access, check that it works, then move on. It comes from Superpowers' executing-plans, but uses my existing skills and checks. No mandatory Superpowers chain, no automatic commit, and no extra approval after every routine step.

ng-verify-feature comes from Vercel's dogfood workflow. It opens the running feature in my existing Chrome session and checks what I asked for: cancelled bookings disappear, clearing the filter restores them, and I can use the control with the keyboard. It records what passed, failed, was blocked, or wasn't tested, with evidence. create-e2e-tests gives me reusable tests; this one checks the delivered feature against the request.

Both needed adaptation. The browser skill uses the tools already available in the project and leaves my browser and server running. I removed the upstream target of finding 5–10 issues – finding none is fine if the acceptance criteria pass – and made video optional when a screenshot or a console error already proves the problem. The plan skill keeps moving through authorized work and asks when a real decision is missing. That's the bit I want a skill to remember for me.

frontend-design is the new visual design skill, from Anthropic. It asks the agent to ground the design in the product and audience, choose the palette, type, and layout deliberately, and review the result against the brief. A dashboard and a toy shop should not end up looking like the same generated landing page. That's why I added it.

The Angular team ships a second skill: angular-new-app, for scaffolding a fresh app. I didn't adopt it – this catalogue is for the apps you already have – but both install with one command, npx skills add https://github.com/angular/skills, and both keep moving: angular-developer picked up HttpClient, naming-conventions, and pipes references just this summer. Upstream doesn't stand still, which is what the adaptation step just below is about.

A word of caution before you go skill shopping, and I mean it: skills are executable instructions, so a third-party skill is as risky as any dependency you pull in. It runs with your agent's permissions, inside your repo, with your credentials nearby. Skills can also ship code: brainstorming comes with a small Node server plus start/stop scripts, diagnosing-bugs with a shell-script template – I read all of them, and hardened the server, before they went in. The risk is no longer hypothetical either: when Snyk audited nearly 4,000 public skills across the ClawHub and skills.sh marketplaces in February 2026, more than a third had at least one security flaw and 13% a critical one – malware, prompt injection, leaked secrets. Read every third-party skill before adopting it – they're short, there's no excuse – and consider scanning them with a tool like NVIDIA's SkillSpector. You wouldn't npm install a random package without a glance at what it does. Same rule here, except this dependency talks your agent into things.

Adapting Skills to Your Project

Even the skills whose workflow I kept needed normalization. This is a step worth budgeting time for. Two kinds of changes, worth keeping apart:

Normalization – formatting and housekeeping that doesn't change behavior. I moved long docs into references/, rewrote descriptions into the "what it does + when to use it" shape so triggers fire reliably, ran everything through Prettier, switched every npm/npx command to pnpm, replaced em dashes with my spaced en dash, and kept published upstream license files next to the copies in references/. The ledger records exceptions, including unslop, whose source had no published license file when checked. Housekeeping, yes – but a copied skill that runs npm install in a pnpm repo leaves a stray lockfile behind, so it matters.

Adaptation – actual behavior changes, and this is where your project's rules win over the upstream author's. The upstream test-driven-development skill assumed a different toolchain; mine now speaks pnpm and Vitest and delegates test-writing to my local skills. diagnosing-bugs had its feedback loops renamed to match this stack – the same feedback loops, cheapest first, from the harness post. And the biggest one: upstream skills that auto-committed their results now surface the diff and let the user commit. My repo, my rules – the skill adapts, not the workflow. One more rule I learned the hard way: detection, not assertion. A skill that states "spartan is installed here" or "read ADR.md" lies the moment a branch is rewritten; it should check for the package or the file and act on what it finds.

A good example is unslop. Upstream bans em dashes, en dashes, and parentheses alike, wants sentence-case headings, and strips emojis from headings and bullets. My house style is the spaced en dash, the podium emojis stay, and heading case depends on the document – Title Case in posts like this one, sentence case in the repo docs – so the skill now leaves it alone instead of forcing either. Three of its patterns now say the opposite of upstream. Its invocation changed too: upstream is human-only (disable-model-invocation: true) with a description that just says "Must always apply", so I made it model-invocable and scoped the trigger to prose – not code.

Whatever you change, record it. My 02-SKILLS.md records each skill's upstream and the adaptations to preserve, so future-me knows what can be updated from upstream and what would be overwritten. Treat vendored skills like a fork you actually maintain – because that's what they are.

A well-written skill can still misbehave – not because it's wrong, but because it disagrees with your AGENTS.md. A three-model review of my own catalogue found exactly that: npm audit in a pnpm repo, a test command that enters watch mode and hangs the agent, a prototype step that starts ng serve although my rules say never without approval, and a mktemp template that only works on Linux. None of these show up when you read the skill on its own; all of them show up the first time the agent runs it. So read every copied skill next to your project rules – package manager, test runner flags, dev server, Git – and reconcile the two before it fires.

Keeping the Copies Up to Date

Copying a skill is the easy part. Updating it six weeks later, without losing your own rules, is where it gets interesting. So yes, I now have a skill for that too: update-skills.

Ask it to check, and it reports what changed without editing anything. Ask it to update, and it compares the complete skill folders at recorded upstream commits, applies the requested changes, and preserves my adaptations. A new repository commit does not necessarily mean the skill changed. And when the original vendoring revision is unknown, it says so instead of inventing a baseline.

The September 8 refresh is a useful example. brainstorming now chooses between a throwaway feasibility spike, a short design in chat, and a full architectural specification. code-review gives reviewers a self-contained handoff without the coordinator's conversation history, and prevents them from spawning more reviewers. diagnosing-bugs redacts credentials from evidence. The TDD skill adds guidance on tests that catch real bugs, with independently derived expectations and typed fixtures. There are smaller updates too: signal-driven toolbar selection in angular-developer, and TanStack Charts guidance in spartan.

I kept some deliberate differences: grill-me still asks one question at a time, and the hardened brainstorming server stays. implement-plan and ng-verify-feature had no upstream skill changes to adopt. That's what I want from an update: a comparison, not a replacement.

The source ledger records reviewed revisions, adaptation notes, and local file digests. The digest checker tells me whether my local files still match that record; it does not prove that a skill works. The maintenance guide keeps structural checks and instruction reviews separate from actual runs in a fresh agent session. Those behavioral runs are still outstanding for the refreshed skills.

My Custom Angular Skills

Now for the larger group – the 20 custom skills, most of them Angular-specific. This catalogue is the distilled version of what I keep explaining in workshops and code reviews: modern Angular v22+ defaults, signals everywhere, zoneless, strict TypeScript, and a human checkpoint at every step that matters.

Skill	What it does
create-a-skill	The meta-skill: creates, edits, and prunes skills so each one runs predictably. Combines and extends Matt Pocock's and Minko Gechev's skill-authoring guidance.
create-e2e-tests	Detects Playwright vs Cypress (scaffolds one with approval if missing), then writes and runs a behavior-level e2e spec.
git-stack-rewrite	Folds staged changes or a commit into an older commit and rebases every dependent branch stack – with backup refs, treated as destructive.
grill-with-style	The grilling loop, but anchored to your project's domain model and style guides – it sharpens the terminology as it goes.
handover	Compacts the current session into a handover document the next agent (or the next you) can pick up.
ng-accessibility	Audits and builds a11y to WCAG AA – semantic HTML, keyboard and focus, CDK a11y – verified with axe or Lighthouse.
ng-data-access	The typed server layer: reads via `httpResource()`/`resource()`/`rxResource()`, mutations via `HttpClient`, SSR-safe transfer caching.
ng-forms	Signal Forms (public API since v22): signal model + schema validation, field state, custom controls, dynamic forms.
ng-migrate	Runs `ng update` and the official migration schematics one verified checkpoint at a time – you commit each one.
ng-performance	Measure-first performance work – initial load and runtime – where every fix ends with a re-measure.
ng-prototype	Throwaway prototypes to answer a design question – a terminal logic app or several UI variations on one route – then absorb or delete.
ng-refactor	Modernizes one legacy component at a time via a 7-step blueprint: Analyze → Declutter → Update → Modernize → Type → Refactor → Review.
ng-review-architecture	Reviews the architecture through two lenses – DDD bounded contexts and deep vs shallow modules – then drills into chosen findings.
ng-review-style-guide	Whole-codebase audit against every project style guide, severity-ranked, fixing only on approval.
ng-security	Defense in depth: sanitization/XSS, nonce-based CSP and Trusted Types, `HttpClient` XSRF, SSR allowed hosts, dependency hygiene.
ng-signal-store	Guards whether state is genuinely shared first – then builds an `@ngrx/signals` SignalStore with entities, `rxMethod`, and store tests.
ng-styling	Audits styling against the style guide – encapsulation, design tokens, BEM, no `!important`, no `::ng-deep` – and fixes in small verified batches.
ng-testing	Vitest unit and component tests for standalone, zoneless Angular – TestBed, signal assertions, harnesses – asserting public behavior only.
update-skills	Compares vendored skills with upstream, applies requested updates, and preserves local adaptations, reviewed revisions, licenses, and snapshot digests.
update-skills-directory	Keeps the catalogue itself honest: audits every skill's frontmatter, structure, and house rules (dashes, package manager, watch-mode test commands, ungated dev servers), checks the snapshot digests, and keeps the index in sync.

A few of these deserve a sentence beyond the table.

The review skills do the most work. code-review (adapted) reviews the diff, ng-review-style-guide audits the whole codebase, ng-review-architecture questions the boundaries, and ng-styling polices the SCSS. Together they do the heavy lifting on the reviewing side of the human-in-the-loop workflow from the harness post – and they all share one rule: report first, fix only on approval. No skill in this catalogue commits your generated or refactored code – the agent surfaces the diff; the human commits (git-stack-rewrite is the deliberate exception, because rewriting history is its whole job). That single convention has saved me more grief than any prompt trick I know.

Some skills refuse to act. ng-signal-store refuses to build a store until it has established that the state is truly shared – prefer a local signal() or computed() first (computed() is still my favorite feature in modern Angular). create-e2e-tests won't silently pick a test runner; if neither Playwright nor Cypress is set up, installing one is an explicit, gated step.

And ng-refactor is the one I'm most excited about 🥳 – it's the direct on-ramp to the brownfield refactoring post I teased at the end of the harness setup post. Seven steps, a human checkpoint after each, and the boring parts (updates, schematics) delegated to ng-migrate. Please, please contact me if you've got any feedback on it.

You'll also notice what the custom skills don't repeat: the style rules themselves. The skills reference the project style guides from the harness post instead of duplicating them – the guides stay the single source of truth, and the precedence rule still holds: project rules override generic Angular advice and any skill's examples.

The Biggest Win: Creating Your Own Skills

You don't need my catalogue – you need your catalogue. Here's how I build a new skill, and yes, there's a skill for that: create-a-skill interviews me about the process, drafts the SKILL.md, and then prunes it. If you've read this far you already know why the meta-skill exists: creating skills is itself a repeatable procedure, so of course it's a skill.

What I've learned makes a skill actually good:

Write the description for the trigger, not the reader. The name and description are all the agent sees before deciding whether to load the skill, and the description does the routing. "What it does + when to use it", ideally with the literal phrases a user would say ("grill me", "hand over"). A beautiful skill with a vague description simply never fires.
Keep the SKILL.md lean. Mine stay under 500 lines, most far under – the spec itself recommends that cap, and a body under 5,000 tokens. Everything deep goes into references/. If your skill needs an essay, your skill is probably two skills.
Encode process, not knowledge. The model already knows what a unit test is. It does not know that in this repo the test must fail first, that the dev server is off-limits, and that you want to see the diff before anything lands.
Decide who may trigger it. The spec's frontmatter is deliberately thin – invocation control is the harness's job, layered on top. In Claude Code, disable-model-invocation: true makes a skill human-only, user-invocable: false keeps background knowledge out of the / menu, and context: fork runs a skill in a sub-agent so its noise never lands in your main context. Codex has the same gate in a skill's agents/openai.yaml, nested under policy: (allow_implicit_invocation: false). My current git-stack-rewrite keeps the Codex setting; its Claude Code frontmatter no longer disables model invocation. Either way, discovering a skill does not authorize a Git write – that still needs my explicit request.
Make skills delegate to each other. My test-driven-development skill enforces red-green-refactor but hands the actual test-writing to ng-testing or create-e2e-tests. Small skills that compose beat one mega-skill that tries to do everything – the same deep-vs-shallow-module argument as in ng-review-architecture, applied to the skills themselves.
Maintain the copies. update-skills compares upstream changes and applies the updates I request. update-skills-directory audits frontmatter, folder structure, house rules, snapshot digests, and the index whenever the catalogue changes.

Start small. Take the next process you explain to your agent for the third time, and turn exactly that into a skill. A good prompt helps once, remember?

Agentic Engineering Workshop

In our Agentic Engineering Workshop we build your setup hands-on: your style guide, your AGENTS.md, and a skills catalogue tuned to your team's rules instead of mine – and then put it to work on spec-first workflows, code review, testing, and brownfield refactoring in real Angular codebases. English or German, as always.

🤖 Agentic Engineering Workshop – 2 days (or 3 half-days online), remote or in-house, English or German, for advanced Angular developers – next public date (in English): November 30 to December 2, 2026

Conclusion

First: copy only the skills your project actually needs. The catalogue has 31 entries because it covers my work – and even I skip two of them, as the third-party table admits. Your project almost certainly needs fewer. Every model-invocable skill's name and description rides along in your agent's context on every task, so an unused skill isn't free, it's noise. A project without a store doesn't need ng-signal-store; a project that will never write e2e tests (fix that, by the way 😉) doesn't need create-e2e-tests. Pick, copy, adapt – don't hoard.

Second: skills expire, and that's a feature. Like the whole harness setup, these procedures are tuned to a model generation – most of them took shape while I was working with Opus 4.7 to 4.8 and GPT-5.5, and the gates show it. Some of them exist purely because a 2025 model couldn't be trusted without them; those can go with Fable 5.1 and Astra. The ones that exist because I want to decide stay. The pruning I recommended for your AGENTS.md up top starts with my own catalogue, and I fully expect to delete skills from it and count that as a win. The goal was never a big catalogue – it was good code with less steering.

Everything is in the ng-agentic-skills repo – clone it, take the skills you need, and make them yours 🚀 Next up: prompting and reviewing, the two moments where you still do the actual work – and after that the workflows I teased in the harness setup post. The real, dusty brownfield code gets its turn a little later in this series, I promise.

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

Agentic Engineering: Summer 2026 Update

Alexander Thalhammer — Mon, 31 Aug 2026 13:35:56 +0000

My agentic engineering series started in late May 2026, and I promised myself not to turn this blog into a weekly model-news ticker. But this space moves so fast that after one summer, some of my recommendations have quietly changed – and I'd rather tell you in one post than let the old ones age in silence. So this is an end-of-summer status update 📋 – the first in what I plan to make a quarterly series – across the three layers of the stack: the models, the harness, and the apps – plus what all of that costs. If you're new here, the apps and harnesses post and the harness setup post explain how I slice those layers. This is a subjective field report from my daily work.

TL;DR: What Changed This Summer

If you only have thirty seconds: my preferred models are now Fable 5, GPT-5.6 Sol, and – as the fast, cheap, and open-weight pick – GLM-5.3 Flash. On the harness layer, nothing important changed – the setup recommendations hold up. On the app layer, however, there is real news: the open-source T3 Code is now my preferred app, with the Codex app as my alternative for computer use. And the one thing to take home is my current workflow: Fable 5 as the orchestrating agent, GPT-5.6 Sol as the sub-agent – the best way I know to stretch the precious Fable budget. Plus my two cents on loop engineering, the buzzword of the summer.

Models: My New Trio

In the LLM post from late May, my ranking was Opus 4.7 for Angular, GPT-5.5 as the all-rounder, and Composer 2.5 as the newcomer. One summer later, all three have been pushed aside: Opus 4.7 by its maker's next generation, GPT-5.5 by its own successor, and Composer 2.5 by a model I hadn't even heard of in May – not because they got worse, but because the next round arrived. Interestingly, Cursor – by now part of SpaceX, since the SpaceXAI deal from the apps post closed on August 14 – didn't produce a podium model at all. In the apps post I expected them to enter the frontier stage, and so far that call was wrong.

#1: Fable 5 by Anthropic

No surprise if you read my Fable 5 post: this model is a new generation, and it is still the best model I have ever pointed at an Angular codebase – or at anything else, by the way. It is very intelligent and – I keep coming back to this word – expansive: give it a vague goal and it explores the problem space, tests its own ideas, and comes back with validated results instead of a guess. And the best part: it usually just understands what I meant. After the June shutdown drama, access came back on July 2 and has stayed ever since – and Fable 5 has settled in as my go-to for everything hard: architecture, design, reviews, and long-horizon refactorings. The catches from that post – price, speed, usage limits – are all still real.

#2: GPT-5.6 Sol by OpenAI

In the Fable post, I predicted OpenAI would answer with GPT-6. They answered with GPT-5.6 instead – and honestly, the name is the least interesting part. The big variant, GPT-5.6 Sol, is very intelligent, clearly a step up from GPT-5.5, and it comes at a fair price: the included usage in the OpenAI subscriptions remains generous, so I can let it work all day without watching a meter. And on August 21, OpenAI cut the Sol price again – 20% on input tokens, a third on output tokens, valid through November 21 – the third price cut in the GPT-5.6 family within a month; the subscriptions stay as they are, but Codex credits and API calls get cheaper too. It has taken over the role GPT-5.5 had in my setup – the reliable senior engineer for focused implementation work – and it is my sub-agent of choice. Both Fable and Sol write good, mergeable code, but Sol needs a bit more steering and is definitely not as capable as Fable.

#3: GLM-5.3 Flash by Zhipu (Z.ai)

The third step of my podium was empty for most of the summer. In May, this was the newcomer slot, held by Composer 2.5 – which, next to what came after it, simply isn't capable enough anymore. Then I gave Grok 4.5 a real shot at it – cheap, and for mechanical refactorings and test generation it held up fine – but when it mattered, I kept reaching for the two models above.

What finally filled the slot came from a lab I wasn't even tracking in May: GLM-5.3 Flash, the small sibling of Zhipu's GLM-5.3. It is not frontier intelligence – 63% on DeepSWE, ten points behind Sol – but it is absurdly fast, it gets there for about €0.25 per task, and in my Angular work it is simply more capable than the obvious alternative, GPT-5.6 Luna, which I already pay for through the OpenAI subscription.

The leaderboard doesn't back that up outright – Luna at max scores 67% – but at the effort I actually run Luna, high, it drops to 44%, while the Flash gets its 63% flat out at max, and at that price, effort levels stop mattering. That makes it the cheapest model whose output I'd actually merge. For the mechanical share of my work – the well-specified legwork you don't need to hand to Fable anyway – that is often enough, and next to two expensive models, a dirt-cheap third one is exactly what my setup was missing. More on that in the costs section, where it climbs to the top of the podium.

The shortlist behind it is longer than ever, and I'll keep re-evaluating it every quarter:

Kimi K3 by Moonshot and the big GLM-5.3 – both at 69% on DeepSWE for around €4 per task: stronger than the Flash, but not cheap enough to be the budget pick, and not strong enough to replace Sol.
Grok 4.6 by xAI – the successor to the model that didn't stick, now at 67%.
Muse Spark 1.2 by Meta AI – the outsider at 55%; I haven't spent enough time with it to say more, but it stays on the list.
DeepSeek V4 – the Pro variant scores 63% for under €2 per task, the Flash 53% for about €0.45 – the closest competitor to my new #3.
And yes, even Opus 5 by Anthropic – the DeepSWE winner at 74%, and, as always with the Claude line, the model with the most taste in this list. It does everything that made Opus 4.7 my #1 for Angular back in May, just a notch better. But that's the point: a notch, not a new tier. In my daily Angular work it is simply not as good as Fable 5 and GPT-5.6 Sol – and as an always-on third model for the legwork, it is far too expensive.

What DeepSWE Says

As in every post of this series, I put my gut feeling next to the one benchmark I trust the most: DeepSWE, because it measures a large share of my implementation work – a short behavioral prompt, a real codebase, and an agent that has to find the right place and implement the change cleanly. Here is the official v1.1 leaderboard, updated on August 26, 2026:

DeepSWE v1.1 pass@1 – snapshot from August 29, 2026, my selection of eight out of 26 models; click the chart for the live leaderboard. All models run through the same minimal harness (mini-swe-agent), so this really is a comparison of models, not of products.

And here it gets interesting, because the benchmark and I don't agree on the order. DeepSWE puts Opus 5 on top at 74%, GPT-5.6 Sol right behind at 73%, and Fable 5 third at 70% – all at max effort, and with the ±3 to ±4 points the leaderboard prints on them, all within one error bar of each other. Below the top three, the picture has changed a lot since May – and this is where my shortlist lives: GLM-5.3 and Kimi K3 sit at 69%, the small GPT-5.6 Luna, GPT-5.5, and Grok 4.6 at 67%, my new #3 GLM-5.3 Flash at 63%, and Opus 4.8 – my architecture and review model of early summer – sits at 59% (GPT-5.5, Opus 4.8, and Sonnet 5 are not in my eight-model selection above – click through for the full board). Sonnet 5 lands at 54% – and is, weirdly, the most expensive model per task in the whole table – which confirms what I wrote in the verdict post: there is no reason to go down to the Sonnet models.

So why is Fable 5 still my #1 when it comes third on my favorite benchmark? Because DeepSWE measures one well-defined task at a time – and that is exactly the kind of work I don't give to Fable anymore (see the budget section below). The things that make Fable a new generation to me – staying with a vague, long-horizon problem, validating its own ideas, the taste of the result – simply don't show up in a pass@1 number. Same story as in the first post: benchmarks are useful signals, not final answers. For the well-specified single task, the benchmark is right: GPT-5.6 Sol – and Opus 5 – are just as good, and cheaper.

My Podium: Models

🥇 Fable 5 – my best friend for architecture, design, reviews, and long-horizon refactorings. Expensive, slow, rationed – and still the best model I know for an Angular codebase.
🥈 GPT-5.6 Sol – the reliable senior engineer for focused implementation work, fairly priced, second on DeepSWE, and my sub-agent of choice.
🥉 GLM-5.3 Flash – not as intelligent as the two above, but absurdly fast and cheap: the model for the mechanical legwork.

As always: judge these models in your own codebase, with your own tasks and your own review standards.

Harnesses: My Project Setup Still Holds Up

My project setup hasn't changed much over the summer – and I mean that as a compliment. Everything from the harness setup post holds up: the style guide is still the single highest-leverage file, AGENTS.md is still the operating contract, and the feedback loops from ng lint to Playwright are still what turn a capable model into a careful teammate. The ng-agentic repo keeps evolving in small steps, but the recommendations stand. If you set up your harness in June, you don't have to rebuild it now.

One caveat, though: a harness is never finished. Whenever something goes wrong, I fix the setup right away – a rule in AGENTS.md, a line in the style guide, a missing check in the feedback loop – instead of re-prompting around it. And every new model deserves a pass over AGENTS.md and the other instruction files: some rules only exist because an older model kept making one specific mistake, and the new one may not need them anymore.

What DeepSWE Says About Harnesses

The official DeepSWE leaderboard deliberately runs every model through the same minimal harness, so it can't tell us anything about harnesses. Artificial Analysis can: they run DeepSWE through the real coding agents – Claude Code, Codex, Cursor CLI, opencode, and a few more – and in their harness comparison they even hold the model constant and swap only the harness. It's the same chart I used in the harness setup post – Artificial Analysis still pins the model at Opus 4.7, so the harness spread itself hasn't moved; what's new are the model-plus-harness pairs further down their page:

Artificial Analysis Coding Agent Index by harness for the same Opus 4.7 model at medium effort – snapshot from August 28, 2026; click the chart for the live comparison.

Two things stand out. First, with the model held constant at Opus 4.7 (medium), opencode scores 51 on their composite index, Cursor CLI 47, and Claude Code only 42 – and on the DeepSWE tab of the same chart the spread is even wider: about 40%, 32%, and 27%. Nothing changed but the wrapper – and the spread is bigger than between most models on the leaderboard. Second, and more relevant for my two favorite models: with current models, the agent pairs land at Codex with GPT-5.6 Sol at about 69%, Claude Code with Fable 5 at about 66% (including the sessions Anthropic's safeguards route to Opus), and Claude Code with Opus 5 at about 63%, each at its top effort level. So in harness form, the Codex-plus-Sol pair is the fastest and cheapest of the three frontier pairs – which at least suggests that Codex is a very efficient harness for its own model.

Does that mean I should run Opus through opencode instead of Claude Code? I use opencode for my Copilot setup. For my direct Claude subscriptions, though, I still prefer Claude Code: the Opus 4.7 chart is the only one where Artificial Analysis currently holds the model fixed across three harnesses, it's a spring model at medium effort, and the Claude Code harness keeps moving – sub-agents, hooks, /loop, everything my orchestrator workflow grew up in. What the chart proves is the point of the harness setup post, not a reason to switch: the wrapper changes the result, and the part of the wrapper you control – style guide, AGENTS.md, feedback loops – is where your points come from.

My Podium: Harnesses

🥇 opencode – the most flexible harness of the bunch: open source, model-agnostic, and it runs every model I care about on the subscriptions and keys I already have. The one chart that holds the model fixed also puts it ahead of both alternatives.
🥈 Claude Code – the harness I run Fable 5 and Opus 5 through – and it is fantastic at orchestrating sub-agents, even with GPT-5.6 Sol in the sub-agent seat. Sub-agents in .claude/agents/ are the reason my orchestrator workflow exists – hooks and /loop are the extras opencode can't match yet.
🥉 Cursor CLI – it still runs most of the models that matter, it hand-tunes its tools and prompts for every new one, it is very well integrated with the IDE, and it lands second on that same harness chart, ahead of Claude Code. Two catches, though. The price is the price: it meters usage at API prices, so the included budget drains far faster than a Claude or OpenAI subscription – not where my daily volume goes. And since Cursor became part of SpaceX, OpenAI has announced that it plans to wind down its contract supplying models to Cursor, with November 12, 2026, as the proposed shutoff date – so the "most models" part now has an uncertain expiry date.

Codex CLI just misses the podium: it's the harness my GPT-5.6 sub-agent runs on every day – GPT-5.6 Sol and GPT-5.6 Luna on my OpenAI subscription, other providers' models via API key – and, as the Artificial Analysis numbers above show, the Codex-plus-Sol pair is the most efficient of the frontier pairs. But it is built for OpenAI's models first, and – unlike Claude Code with its sub-agents and hooks – it adds nothing my orchestrator workflow needs. That is what keeps it off my podium. If you live in the terminal, opencode is still my recommendation – and Pi for the tinkerers who want to reshape their harness themselves.

Apps: T3 Code Takes the Lead

Here is the actual news of this post. In the apps and harnesses post, I mentioned T3 Code in one throwaway paragraph as an open-source GUI on top of the agents you already pay for. Since then, the open-source T3 Code has quietly become my preferred app. The Codex app is now my alternative, demoted from daily driver to solid second choice.

Why the switch? Three reasons – plus one big bonus:

1. Remote control, without the lock-in. Like the Codex app, T3 Code lets me control my agents from my phone while the desktop machine does the actual work – start a task from the couch, check the diff on the train. With T3 Code, this is easily set up through a Tailscale connection: my phone talks to my own machine, no cloud runner in between. That also keeps the data and privacy story refreshingly simple – the code still goes to whichever model I picked, but nothing else sits in between.

2. Open source and free. No subscription for the app itself, and the source is public, so I can read every line of it. After the Claude Code source-map episode from the harness setup post, I have come to appreciate being able to inspect the layer that wraps my code.

3. Any model, any provider. T3 Code doesn't care which vendor I'm loyal to this week. All three of my current favorites – Fable 5, GPT-5.6 Sol, and GLM-5.3 Flash – work perfectly in it, on the subscriptions and keys I already have – and two of them, Fable 5 and GPT-5.6 Sol, via opencode even on a company GitHub Copilot plan (see the T3 Code with Copilot tutorial). Remember the "don't get too attached to one vendor workflow" advice from the apps post? This is the answer.

My favorites in T3 Code's model picker, each one keyboard shortcut away: Fable 5 through Claude Code and – via opencode – through GitHub Copilot, GPT-5.6 Sol through Codex or Copilot, and GLM-5.3 Flash through opencode and OpenRouter.

4. The new sidebar. A (big) bonus rather than a reason to switch, but the recently released sidebar is genuinely cool to use – it keeps everything that matters in view while an agent is working, without the tab-juggling I got used to in the other super apps. Think of it as an inbox: one entry per thread with project, branch, and status, and when you're done with one, you settle it and it slides to the bottom.

The T3 Code sidebar as an inbox: the active threads on top, the settled ones at the bottom – client names pixelated, and this very post in the middle.

To be fair to Codex: if you live entirely in the OpenAI world, it remains a great choice. In my setup, it has moved from first pick to a specialist: T3 Code gets most of my day, and I open the Codex app mainly for computer use – the browser-driving, screenshot-checking kind of task where it is still the best tool I have.

And the terminal? Honestly, I hardly open one for agentic work anymore – the super apps have simply become too convenient. If you still prefer it: opencode for most people, Pi for the tinkerers – see the harness section above.

My Podium: Apps

No benchmark here – nobody measures how nice a sidebar is – so this one is pure taste:

🥇 T3 Code – open source, any model, remote control via Tailscale, and that sidebar. The app I open first every morning right now.
🥈 Codex app – still the most polished closed app, still just works, and my go-to for computer use. Also the one I'd hand a colleague who never leaves the OpenAI world.
🥉 Cursor – the super app with the strongest IDE integration, running most of the models that matter under its own harness – but Cursor-provided access to OpenAI's models is planned to end, with November 12 as the proposed date (see the harness section).

The Claude Desktop app lands just off the podium: still the natural home of the Claude Code harness, but T3 Code now does that job for me – with more models.

Costs: Fable 5 Is the Expensive One

Model podium, harness podium, app podium – now the boring part that decides whether any of it is sustainable: money. The costs post from June still holds in every important point: the subsidized subscriptions remain by far the best deal, and the number that matters is still the cost per accepted, reviewed, merged change, not the price per token. What has changed is the spread between the models at the top – and DeepSWE gives me the closest proxy I have for it, because it tracks the average API cost per task right next to the score:

DeepSWE v1.1 cost view – average API cost per task against the score, snapshot from August 29, 2026, my selection of 34 out of 63 configs – all effort levels for the frontier models and most of my shortlist, so you can see the curves; click the chart for the live leaderboard. Note the inverted cost axis – cheaper is further right – so up and to the right is where you want to be.

DeepSWE reports in US dollars; I converted to euros and rounded. For the frontier models, the chart shows all effort levels, because high is what I run most of the time and the leaderboard's default view only shows the best score per model – usually the max-effort one. At high effort, one DeepSWE task costs roughly €8.50 with Fable 5 (69%), €5.50 with Opus 5 (73%), and €2.50 with GPT-5.6 Sol (69%). At max effort, the same three score 70%, 74%, and 73% for about €20, €11, and €6. Read that again: max effort roughly doubles the bill for one extra point on both Claude models – Sol is the only one where it buys something real, four points.

The score order shuffles with effort, but the cost gap doesn't: at every level, Fable 5 costs about three times as much per task as GPT-5.6 Sol. Two reasons: Fable burns about twice the output tokens per task that Sol does (119k at max versus 60k), and its per-token price is well above Sol's on top of that. Token efficiency is where OpenAI is currently winning, and that matters even on a subscription, because tokens are exactly what your usage limits are made of.

The bargain corner is where it gets interesting, and it's where my #3 lives. GLM-5.3 Flash solves 63% of the tasks for about €0.25 – a tenth of what Sol costs at high effort, and a tiny fraction of Fable at any effort. It is clearly a class below the frontier models, but for the mechanical share of my work it's often enough, and it's fast – which is why it tops my cost podium below. The competition in that corner is real, though: GPT-5.6 Luna, the small sibling of Sol, is the line of dots hugging the right edge of the chart – 44% for about €0.15 at high effort, 67% for about €0.60 at max – with DeepSeek V4 Flash not far away and the DeepSeek V4 Pro a bit further up. The bigger open-weight pair from my shortlist, GLM-5.3 and Kimi K3, sits higher up at 69% – the highest score among the open-weight models, though Sol matches it for less, and the Flash beats both on cost per task.

Artificial Analysis tells the same story in harness form and adds the clock: a Codex run with GPT-5.6 Sol costs about €4.50 per task and finishes in roughly ten minutes, while Claude Code sits at about €7.50 with Opus 5 (at xhigh) and about €11 with Fable 5 – and both Claude runs take close to 24 minutes. That Fable is slow is nothing new; that the gap is now measurable is.

What does that mean for my wallet? Less than you'd think, because almost everything still runs on subscriptions, not per token: two €200 Claude subscriptions since July (as confessed in the Fable post), one OpenAI subscription that GPT-5.6 has never come close to exhausting – and, for GLM-5.3 Flash, an OpenRouter key I use through opencode inside T3 Code – plus a GitHub Copilot plan for T3 Code through opencode. OpenRouter adds a small fee on top of the model's own price, but at €0.25 per task that is noise, and in return I can try out any new model on the leaderboard the same afternoon. All of it together, at my hourly rate, is still paid for by lunchtime on the first working day of the month. But the per-task numbers above translate directly into how fast a subscription's limits drain.

My Podium: Cost per Accepted Change

Not price per token – cost per change I actually merge. DeepSWE's cost per task is only a proxy for that, so the rest is my judgment:

🥇 GLM-5.3 Flash – not as smart as the frontier models, but quick and close to free – which is fine, because I don't hand it the hard stuff. For mechanical work, it's the best cost per accepted change I have found.
🥈 GPT-5.6 Sol – the middle ground: top-three quality at a fraction of the Claude cost per task, the fewest tokens per task, plus the most generous included usage. The best deal among the frontier models, full stop.
🥉 Fable 5 – the best model and the most expensive one in my trio. The worst deal on paper, and the best deal for the problems that would otherwise cost me a day: worth every cent for hard, long-horizon work, overkill for everything else.

How I Save My Fable Budget

Fable 5 is the one model I actively ration, and after a summer of doing that, these are the habits that survived:

GPT-5.6 Sol is the default, Fable 5 is the exception. The question I ask before every task: would GPT-5.6 Sol – or even GLM-5.3 Flash – get this right too? For normal implementation work, the answer is yes, the benchmark agrees, and it doesn't touch the Claude limits at all. If I want to stay inside the Claude world, Opus 5 does the same job at roughly two thirds of Fable's cost per task at high effort, and about half at max. Fable gets the vague goals, the architecture, the reviews, and the brownfield refactorings that span half the codebase.
Medium to high effort, not max. The effort numbers from the costs section make the case better than I could: one extra point for double the bill – and even at medium, Fable still gets 65% for about €5.50. So I run Fable at medium or high and reserve max for the rare task where a wrong answer costs more than the tokens.
Plan first, then let it run. A few minutes of spec and plan before the long autonomous run save a lot of expensive laps. Fable is at its best when the outcome is clear but the route is not – a long-horizon problem it can explore without first having to guess what success means – and at its most wasteful when it has to discover the goal by trial and error, at Fable prices.
Keep the context lean. Fresh thread per task, short AGENTS.md, no sprawling terminal output – the team rules from the costs post, just applied more strictly. A bloated context is re-read on every turn, and those are the tokens that drain your 5-hour window.
Hand the legwork to a sub-agent. The tip from the July 4th update of the Fable post has become my standard workflow and saves me the most usage.

And if all of that still isn't enough? Then you're in my situation – see the two Claude subscriptions above.

Update September 3rd

Two things changed since publishing. First, Anthropic has released Fable 5.1, and it has replaced Fable 5 in my setup – everything in this post about Fable applies to the 5.1 just the same, price and limits included. Second, a small correction to habit #2: I've moved Fable 5.1's default effort from high down to medium – and I don't miss anything. For the work Fable does in my setup – planning, reviewing, delegating – medium gets the same results, and the 5-hour window lasts noticeably longer. The DeepSWE numbers from the costs section explain why: medium costs about €5.50 per task against €8.50 at high, so it's roughly a third less budget for four points on a benchmark that measures exactly the kind of task I don't give to Fable anyway. High is now what max used to be – the level I switch on deliberately for the rare task where I want the extra thinking.

My Current Workflow: Fable 5 Orchestrates, GPT-5.6 Sol Does the Legwork

The idea is simple: Fable 5 should think, not type. I run Fable 5 as the orchestrating agent – it does the planning, the architecture decisions, and the final review – and I hand the well-specified implementation legwork to GPT-5.6 Sol as a sub-agent. Fable 5 writes a self-contained task description, the sub-agent executes it through the Codex CLI on my OpenAI subscription, and Fable 5 reviews the result. The expensive model spends its tokens on judgment; the fairly priced model spends its tokens on volume.

In Claude Code (and therefore in any app driving that harness), this is one Markdown file in .claude/agents/:

---
name: gpt-implementer
description: "Delegates well-specified implementation tasks to GPT-5.6 Sol via the Codex CLI. Use for mechanical, clearly spec'd legwork – not for architecture or design decisions."
tools: Bash, Read, Grep, Glob
---

You are a thin wrapper around the Codex CLI. Take the task you were given, write it into a single self-contained prompt (all relevant file paths, constraints, and acceptance criteria included – Codex starts with zero conversation context), then run:

codex exec -m gpt-5.6-sol "<your prompt>"

Return Codex's output as your result. Do not implement anything yourself.

That's it. The orchestrating Fable 5 session now delegates on its own whenever a task is mechanical enough, and my Fable limits last noticeably longer – I run Fable 5 itself at medium to high effort and let the sub-agent burn the implementation tokens. The same division of labor works with Opus 5 in the sub-agent seat if you'd rather stay entirely in the Claude world – cheaper than Fable, same harness, no Codex detour. And of course, the harness setup does its quiet work here too: the sub-agent reads the same AGENTS.md and style guide as everyone else, so the code comes back looking like mine no matter which model typed it.

Bonus Tip: A 1M-Token Context Window for GPT-5.6 Sol in Codex

One related tip for the Codex side of this setup, because it comes up so often: by default, Codex runs GPT-5.6 with a deliberately smaller context window than the model supports – tuned for performance and cost. Earlier this month (on August 16, 2026), OpenAI's Tibo Sottiaux documented how to raise it to a 1M-token working window for GPT-5.6 Sol. Open ~/.codex/config.toml and add these three lines at the top level, before any [section] header:

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

The first line selects the model, the second gives Codex a one-million-token context budget, and the third starts automatic compaction of older history at around 900k tokens, leaving some headroom. Restart Codex and start a new session. If you'd rather try it once without touching your defaults:

codex -m gpt-5.6-sol \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=900000

For the sub-agent workflow above, this matters less than you might think – every codex exec starts fresh with a self-contained prompt anyway. Where it pays off is in the long-running Codex sessions you drive directly, in the app or the CLI: more code, tool output, and conversation history stay in view before Codex has to summarize older material. My take: OpenAI tuned the default carefully, and I'm not switching it on everywhere – but for the occasional big brownfield task, it's good to know the knob exists.

Only allowed to use Copilot at work? You can still use T3 Code – here's the step-by-step setup tutorial.

Loop Engineering: The Buzzword of the Summer

One more thing, because you will run into this term anyway: loop engineering. Google's Addy Osmani gave the term its big write-up earlier this summer (in June 2026), and it comes with two very quotable one-liners. Boris Cherny, head of Claude Code at Anthropic, said on stage in June – as quoted by Osmani: "I don't prompt Claude anymore. I have loops running that prompt Claude." And Peter Steinberger, the creator of OpenClaw, was even more direct on X: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

The idea in one sentence: after prompt engineering and context engineering, the next skill is not writing a better prompt – it's not typing the prompt yourself. Instead, you design the system that prompts the agent: a schedule that wakes it up every morning, a hook that fires when CI turns red, a goal it iterates on until the checks pass – and only then stops. The tooling is already there: Claude Code ships /loop, hooks, and scheduled agents, and the Codex app has its scheduled tasks.

My personal take? The name is new, the substance mostly isn't. Strip away the branding and loop engineering is what the harness setup post has been arguing all along: an agent is a model running in a loop, and that loop is only as good as the feedback flowing through it. If your ng lint, tests, and Playwright runs give the agent a reliable signal, you can let the loop run longer without you – if they don't, a self-prompting agent just produces slop on a schedule. Even Osmani warns about exactly that: unattended mistakes and the comprehension debt of code nobody read. So my rule doesn't change – whatever ran while I was away, I still own the final judgment on every diff. I'm using loops in small doses so far, and I'll dig into where they genuinely pay off – and where they're just a fancy cron job – in an upcoming post of this series.

Until then, read Manfred Steyer's Loop Engineering with Super Mario and Twelve AI Coding Agents: he handed twelve coding agents the same two tickets – a Koopa Troopa for an Angular-based Super Mario clone – and let one automated loop run all of them. All twelve delivered, at a 160x spread in cost and a 19x spread in speed, and his key finding is my harness mantra in one sentence: every systematic failure traced back to something the tickets didn't say. Loops don't fix a vague spec – they execute it, literally.

Agentic Engineering Workshop

In our Agentic Engineering Workshop we cover AI-ready project setup, guardrails, spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring. It's for advanced Angular developers, in English or German.

🤖 Agentic Engineering Workshop – 2 days (or 3 half-days online), English or German, for advanced Angular developers – next public date: November 30 to December 2, 2026

Conclusion

Three months into this series, the pattern is becoming clear: the models rotate fastest (Fable 5, GPT-5.6 Sol, and GLM-5.3 Flash today – ask me again in November), the apps every few months (open-source T3 Code now, Codex as the alternative), and the harness setup barely at all. The cost picture is just as stable: the subscription is still the deal, and Fable 5 is still the one model worth rationing.

The next edition of this update is planned for November 2026 – see you then.

You won't have to wait that long for the series itself, though: next week, it continues with the post I promised at the end of the harness setup post – Agent Skills for Angular Development. Where the harness gives your agent a clean workspace and an operating contract, skills give it repeatable procedures: a complete catalogue of Angular skills in a new companion repo, how to use third-party skills, how to write your own, and how to adapt them to your project. A good prompt helps once – a good skill helps every time.

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

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

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

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. Or, boiled down to a formula that's worth keeping in your head for the rest of this post – coined by LangChain's Vivek Trivedy in The Anatomy of an Agent Harness: Agent = Model + Harness.

My personal take? The harness setup is something we can improve ourselves. 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. So once you've chosen a capable model, spend some time setting up its harness for your Angular project. That's what I want to show you in this post.

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.

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.

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

I start with formatting and linting that run automatically on every commit, whether the code came from me or from the model. That way I don't have to keep asking the agent to fix things our tooling can already catch.

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.

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.

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.

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]
description = "Block reads of secrets and environment files"

[permissions.no-secrets.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env.*" = "deny"
"**/*.pem" = "deny"
"**/*.key" = "deny"
"**/*.p12" = "deny"
"**/*.pfx" = "deny"
"**/secrets/**" = "deny"
"**/credentials/**" = "deny"
"**/service-account*.json" = "deny"
"src/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

In our Agentic Engineering Workshop we build this setup for your own Angular projects: guardrails, a coding style guide, and an AGENTS.md that tells the agent how your team works. We then use it for spec-first and plan-first workflows, UX and component prototyping, code review, testing, and brownfield refactoring. The workshop is for advanced Angular developers, in English or German.

🤖 Agentic Engineering Workshop – 2 days, remote

Conclusion

Set up the harness for your own Angular projects. The model and the existing codebase matter too, as we've seen, but you can adapt the tools, instructions, and checks to how your team works. As models internalize current Angular best practices, some of those instructions will become unnecessary – so keep reviewing the setup as well.

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 Engineering: 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 ❤️

Angular ARIA initial version released

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, more about the v21 release in Manfred's post) 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?

When you:

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

When to avoid Angular ARIA?

When you:

Don't know how to style (Junior in CSS – join my NG Styling Workshop 🎨)
Use a Design System or an enterprise component library (should be covered there)
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.

DEV Community: Alexander Thalhammer

Agentic Engineering: Skills for Angular Development

TL;DR: A Good Prompt Helps Once, a Good Skill Helps Every Time

Putting the LLM Progress into Practice

The Purpose of Skills

Another Story – and an Example

So What Is a Skill?

How to Use Skills

Third-Party Skills

Adapting Skills to Your Project

Keeping the Copies Up to Date

My Custom Angular Skills

The Biggest Win: Creating Your Own Skills

Agentic Engineering Workshop

Conclusion

Agentic Engineering: Summer 2026 Update

TL;DR: What Changed This Summer

Models: My New Trio

#1: Fable 5 by Anthropic

#2: GPT-5.6 Sol by OpenAI

#3: GLM-5.3 Flash by Zhipu (Z.ai)

What DeepSWE Says

My Podium: Models

Harnesses: My Project Setup Still Holds Up

What DeepSWE Says About Harnesses

My Podium: Harnesses

Apps: T3 Code Takes the Lead

My Podium: Apps

Costs: Fable 5 Is the Expensive One

My Podium: Cost per Accepted Change

How I Save My Fable Budget

Update September 3rd

My Current Workflow: Fable 5 Orchestrates, GPT-5.6 Sol Does the Legwork

Bonus Tip: A 1M-Token Context Window for GPT-5.6 Sol in Codex

Loop Engineering: The Buzzword of the Summer

Agentic Engineering Workshop

Conclusion

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?

Start from a Clean `ng new`