{"id":33893,"date":"2026-05-27T16:00:21","date_gmt":"2026-05-27T14:00:21","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/ai-apps-harnesses-for-angular\/"},"modified":"2026-06-04T14:50:34","modified_gmt":"2026-06-04T12:50:34","slug":"ai-apps-harnesses-for-angular","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/ai-apps-harnesses-for-angular\/","title":{"rendered":"Agentic: Which App\/Harness Is Best for Angular Development?"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 2 of 4 in the series “Agentic Engineering”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Agentic Engineering: Which LLM Is Best for Angular Development?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Agentic: Which App\/Harness Is Best for Angular Development?<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Agentic Engineering: What Does AI Coding Really Cost?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Agentic Engineering: What Do AI Coding Tools Do With Your Code?<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    In my last post<\/a>, published yesterday, I wrote about which LLMs I currently like to use for Angular<\/em> development and promised a follow-up about the apps and harnesses around them. This is that follow-up.<\/p>\n

    It is the second post in this small series. The follow-ups look at costs<\/a> and the data and privacy side<\/a> of agentic coding.<\/p>\n

    From Models to Agent Harnesses<\/h2>\n

    Picking the model is only half the picture. The same Opus 4.7<\/a> behaves very differently in a JetBrains chat window, in Claude Code<\/a> on the terminal, or wrapped in Cursor<\/a>'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<\/em> work, that part matters at least as much as the underlying model<\/strong>.<\/p>\n

    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<\/em> 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.<\/p>\n

    This Is Not a Benchmark<\/h2>\n

    Before we go any further, one important disclaimer: this is not a scientific benchmark, not a universal ranking, and definitely not the final truth about AI coding tools. It is my subjective opinion<\/strong> based on my own daily work with Angular<\/em> projects, workshops, code reviews, refactorings, and experiments over the last few months.<\/p>\n

    \"Apps\/Harnesses<\/p>\n

    The sketch above is a very simplified overview of the different tools and how I see them in terms of their capabilities and my personal preferences. It is not meant to be an objective comparison, but rather a visual aid to understand my current opinion of these apps and harnesses.<\/p>\n

    Your workflow might be different. Your team might have different constraints. Your preferred IDE, operating system, budget, company policies, and tolerance for agentic autonomy might lead to a completely different result.<\/p>\n

    So please, read this post as a practical field report from my current setup, not as a neutral lab test.<\/p>\n

    TL;DR: My Current Setup<\/h2>\n

    If you only have thirty seconds: my daily drivers for Angular<\/em> work are currently Codex<\/strong> (with GPT 5.5) and the Claude desktop app<\/strong> (with Opus 4.7), 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<\/strong> with Composer 2.5 is a strong third option, especially when speed, cost, IDE integration, or cloud agents matter. Antigravity<\/strong> 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<\/strong>.<\/p>\n

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

    My AI Coding Journey<\/h2>\n

    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.<\/p>\n

    WebStorm + GitHub Copilot<\/h3>\n

    \"WebStorm<\/p>\n

    For over a decade PhpStorm (starting in my WordPress era) and later WebStorm<\/a> have been my main IDEs for web development. So when GitHub Copilot<\/a> 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.<\/p>\n

    I just looked up in my GitHub Billing History<\/a> 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<\/a>), 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.<\/p>\n

    However, it also had its limitations. It often struggled with larger code contexts, complex Angular<\/em> patterns, and multi-file refactorings. In particular, it was usually a step or two behind modern Angular<\/em> APIs<\/strong>: it kept suggesting NgModule<\/code>-based code long after standalone components had become the default, leaned on ngIf<\/code> and <\/em>ngFor<\/code> instead of the new control flow syntax, and rarely reached for signals, input()<\/code> or output()<\/code> 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.<\/p>\n

    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.<\/p>\n

    WebStorm + AI Assistant + Junie + Opus 4.5<\/h3>\n

    Switch to November 2025 when Opus 4.5<\/a> 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.<\/p>\n

    For context: JetBrains AI Assistant<\/a> 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.<\/p>\n

    Junie<\/a> 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.<\/p>\n

    But then, since I was using Claude Opus 4.6<\/a> 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<\/a> for my agentic coding.<\/p>\n

    VS Code + Claude Code + Opus 4.6<\/h3>\n

    \"VS<\/p>\n

    A few weeks after Opus 4.6<\/a> was released to the public, I think it was around the end of November, 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<\/em> work? But the more I compared the different tools, the more obvious it became that the surrounding app matters a lot<\/strong>.<\/p>\n

    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<\/em> workshops<\/a>, where many participants use it as their main editor. And with the Claude Code extension<\/a> in VS Code, I had the first setup where Opus really felt stronger because of the harness<\/strong> around it. Suddenly Opus could read across an entire Angular<\/em> feature folder, follow a signal from computed()<\/code> back to its source, and propose multi-file edits that respected my standalone-component setup, my routing, and even my providedIn: 'root'<\/code> services without me having to spoon-feed it the context.<\/p>\n

    That was the moment where I started to think: OK, this is not only about the LLM anymore<\/strong>. Well and that was even before I tried the Agentic coding apps or what I like to call them super apps<\/em> for the first time.<\/p>\n

    Beyond IDE: Agentic Coding Apps (Super Apps)<\/h2>\n

    After using VS Code for my agentic coding for about a month or so, I was ready to start a new journey.<\/p>\n

    \"Super<\/p>\n

    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?<\/p>\n

    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<\/strong>. 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.<\/p>\n

    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<\/strong>. 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.<\/p>\n

    Claude desktop app + Opus 4.7<\/h3>\n

    \"Claude<\/p>\n

    That is why I really care about reviewing everything these tools do, and I want every line of code to look exactly as if I had handcrafted it<\/strong>. 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.<\/p>\n

    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.<\/p>\n

    So basically, the first one of these super apps that I really used on a day-to-day basis was the Claude desktop app<\/a>. 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.<\/p>\n

    The big strength of Claude Code is still the terminal story<\/strong>. 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.<\/p>\n

    For Angular<\/em> work specifically, Claude Code with Opus 4.7 is the harness I trust most<\/strong> 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()<\/code>. It also handles the boring-but-important parts well, like keeping app.config.ts<\/code>, route definitions, and lazy-loaded feature routes in sync after a rename.<\/p>\n

    Codex + GPT 5.5<\/h3>\n

    \"Codex<\/p>\n

    And that is already a big difference compared with the Codex app<\/a> by OpenAI, because Codex does not split these workflows into separate apps. Instead, it combines coding and co-working in just one app.<\/p>\n

    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<\/strong> most of the time.<\/p>\n

    What I like about Codex is that it usually feels less theatrical<\/strong>. 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<\/em> application with local setup, browser checks, environment variables, internal packages, and maybe a slightly weird test configuration, that matters a lot.<\/p>\n

    And there is another practical detail I really like: Codex can now be controlled from the smartphone<\/a> 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.<\/p>\n

    So my personal verdict would be that the Codex app is superior<\/strong> 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<\/strong> to GPT 5.5<\/a> in many cases, especially in the fields I mentioned in the last post, such as architecture, design, and more.<\/p>\n

    In day-to-day Angular<\/em> tasks, though, the gap is often smaller than the model benchmarks suggest<\/strong>. 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<\/code>, 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.<\/p>\n

    Cursor + Composer 2.5<\/h3>\n

    \"Cursor\"<\/p>\n

    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<\/a>.<\/p>\n

    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.<\/p>\n

    Nevertheless, Cursor recently announced a major deal with SpaceXAI<\/a> 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.<\/p>\n

    So why are Cursor and SpaceXAI such a good match? Because SpaceXAI has huge compute with Colossus 2<\/a>, while Cursor has a ton of collected user data and usage statistics. Together, they are about to enter, or have already entered, the frontier stage of agentic coding.<\/p>\n

    By the way, Cursor<\/a> and Composer 2.5<\/a> are also super fast, and they can be a cheap alternative<\/strong> 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<\/a>.<\/p>\n

    The part I had underestimated is Cursor's cloud story<\/strong>. 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<\/a> become much more interesting than the editor alone. Of course, this also makes the data and policy side<\/a> more important.<\/p>\n

    For Angular<\/em> 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 code>@Input()<\/code<\/a> to the new input()<\/code> signal API, or rewriting a template from ngIf<\/code>\/<\/em>ngFor<\/code> to the new code>@if<\/code<\/a>\/code>@for<\/code<\/a> control flow. It is fast enough to feel interactive<\/strong>, and that speed changes how often you actually run a refactor instead of postponing it.<\/p>\n

    Antigravity + Gemini 3.5 Flash<\/h3>\n

    \"Antigravity<\/p>\n

    A little more than a week ago, Google also announced a new release at Google I\/O<\/a>, where they presented the new agentic coding app called Antigravity 2.0<\/a>. 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<\/strong> of all the options.<\/p>\n

    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.<\/p>\n

    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<\/strong>, 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<\/a>, 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.<\/p>\n

    On Angular<\/em> tasks, Gemini 3.5 Flash is genuinely capable, and its speed is useful when you want fast iterations over a whole feature module or a long template. But in practice I still see it default to slightly older Angular<\/em> 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, but it currently needs more steering<\/strong> than the other two.<\/p>\n

    Open Source Alternatives to the Big Ones<\/h3>\n

    Beyond the big names, I would also keep an eye on OpenCode<\/a> and T3 Code<\/a>. 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.<\/p>\n

    But I'm super happy with working in the terminal<\/h3>\n

    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<\/strong> 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.<\/p>\n

    If you are still happiest in the terminal, Pi<\/a> is probably the option I would suggest trying first. It is a minimal terminal coding harness with AGENTS.md<\/code> 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.<\/p>\n

    Which Coding Agent Harness Would I Choose Today?<\/h2>\n

    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.<\/p>\n

    My two favorite tools are definitely Codex and the Claude desktop app. I would put them roughly on par<\/strong>. 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<\/a>.<\/p>\n

    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<\/em> codebases.<\/p>\n

    The practical difference is not only which one can solve a given prompt. It is also how it tries to solve it<\/strong>. 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.<\/p>\n

    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.<\/p>\n

    For my beloved IDE WebStorm, I see difficult times ahead<\/strong>. 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.<\/p>\n

    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.<\/p>\n

    Agentic Engineering Workshop<\/h2>\n

    This is also why I don't think about harnesses in isolation: the model, the app, my Angular<\/em> Guardrails, my Angular<\/em> Coding Style Guide and the Angular<\/em> Skills all belong together.<\/p>\n

    If you want to learn how to pick the right harness and build a strict human-in-the-loop workflow where every generated line of Angular<\/em> code looks handcrafted, make sure to join our Agentic Engineering Workshop<\/strong>, both in English and German.<\/p>\n

    In this workshop, advanced Angular<\/em> 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.<\/p>\n