11 ms·

Boris from the Claude Code team here. Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s als

by bcherny 8mo ago

Boris from the Claude Code team here. Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it. That said, engineering is all about tradeoffs and this may change in the future!

blibble 8mo ago
this is you? https://www.youtube.com/watch?v=We7BZVKbCVw https://www.youtube.com/watch?v=We7BZVKbCVw if that's the case, why don't you just ask it to "make it not shit"?
- kenonet 8mo ago
  hahaha
- runlevel1 8mo ago
  I'm not sure what's more insane: That they're willing to make those claims or that companies are willing to downsize based on them.
- afroboy 8mo ago
  Like Warren Buffett said, Never ask your barber if you need a haircut.
PKop 8mo ago
Users would benefit from native apps, hopefully you guys will give it a try. I bet Claude would be great at it too, no?
deleted 8mo ago
[deleted]
endergen 8mo ago
The second you wanted to add a webview, you want Electron. Devs want Chrome DevTools and Chrome runtime. You guys just did add it too, so yeah!
fourside 8mo ago
Thanks for chiming in! My takeaways are that, as of today: - Using a stack your team is familiar with still has value - Migrating the codebase to another stack still isn’t free - Ensuring feature and UX parity across platforms still isn’t free. In other words, maintaining different codebases per platform still isn’t free. - Coding agents are better at certain stacks than others. Like you said any of these can change. It’s good to be aware of the nuance in the capabilities of today’s coding agents. I think some people have a hard time absorbing the fact that two things can be true simultaneously: 1) coding agents have made mind bending progress in a short span 2) code is in many ways still not free
ProAm 8mo ago
Couldn't this have been vibe coded into a native app that is more performant?
- WJW 8mo ago
  > vibe coded > more performant I found the problem.
  - LtWorf 8mo ago
    I mean, we both know it couldn't, but the company claims it can be done so why don't they do it?
    - amelius 8mo ago
      I suppose because generating tokens is slow. It is a limitation of the technology. And when data is coming in slowly, you don't need a super high performance client.
      - LtWorf 8mo ago
        Do you really need an incredibly slow client though?
  - Wowfunhappy 8mo ago
    ...I think a vibe-coded Cocoa app could absolutely be more performant than a run-of-the-mill Electron app. It probably wouldn't beat something heavily optimized like VS Code, but most Electron apps aren't like that.
hedgehog 8mo ago
As a user I would trade fewer features for a UI that doesn't jank and max out the CPU while output is streaming in. I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. (edit: this applies to the mobile app as well)
- ajross 8mo ago
  > a UI that doesn't jank and max out the CPU While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help. I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candidates. In order of increasing complexity: 1. Gmail 2. VSCode 3. www.amazon.com (this one is just shockingly big if you think about it) If your client machine can handle those (and obviously all client machines can handle those), it's not going to sweat over a comparatively simple Electron app for talking to an LLM. Basically: the war is over, folks. HTML won. And with the advent of AI and the sunsetting of complicated single-user apps, it's time to pack up the equipment and move on to the next fight.
  - cgh 8mo ago
    You think VSCode’s ui is more complicated than eg Microsoft Excel? Or am I misunderstanding?
    - SR2Z 8mo ago
      It definitely is, seeing as how it can embed a spreadsheet.
  - kadoban 8mo ago
    > While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help. From the person you're responding to: > I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. Pretty clearly they're not saying that this is a necessary property of Electron.
WD-42 8mo ago
Didn’t you say coding is a solved problem? So why are you still reaching for the lowest common denominator tech stack?
- senordevnyc 8mo ago
  Did they say that? I doubt it.
  - greazy 8mo ago
    They did, with the caveat that its solved" for most use cases". https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens https://www.lennysnewsletter.com/p/head-of-claude-code-what-...
    - IhateAI_2 8mo ago
      [dead]
    - no-name-here 8mo ago
      I would have expected the non-solved-cases to be the relatively unique ones, but considering the plethora of both A) non-Electron desktop apps, and B) coding agents (Copilot/Windsurf/Cursor/Codex/OpenCode/Qwen/Amazon Kiro/Devin/JetBrains AI/Gemini CLI/Gemini Code Assist/Antigravity/Warp/Kilocode/Cline/RooCode/Atlassian Rovo/Claude Code/etc), it seems like neither of the building blocks is very rare - perhaps Claude is just incapable of putting it together?
  - WD-42 8mo ago
    https://m.youtube.com/watch?v=We7BZVKbCVw https://m.youtube.com/watch?v=We7BZVKbCVw within the first few seconds.
    - furyofantares 8mo ago
      The full quote (in response to: should people learn programming) is "In a year or two it's not gonna matter, coding is largely solved". Which is still quite the statement, and damn the video is intolerable. But the full quote still feels a little different than how you put it here.
LtWorf 8mo ago
And they couldn't vibe code a client in Qt?
dude250711 8mo ago
> Finally, Claude is great at it. So the model is not a generalised AI then? It is just a JS stack autocomplete?
- danjl 8mo ago
  I think that comment is interesting as well. My view is that there is a lot of Electron training code, and that helps in many ways, both in terms of the app architecture, and the specifics of dealing with common problems. Any new architecture would have unknown and unforeseen issues, even for an LLM. The AIs are exceptional at doing stuff that they have been trained on, and even abstracting some of the lessons. The further you deviate away from a standard app, perhaps even a standard CRUD web app, the less the AI knows about how to structure the app.
- lkbm 8mo ago
  Claude isn't AGI, but this is a terrible argument. I'm better at Javascript than C, too. Does this mean I'm not a generalized intelligence? I'm just JS stack autocomplete?
  - dude250711 8mo ago
    It kind of does.
exabrial 8mo ago
Boris, native app on OSX would be awesome. Totally understand the engineering decision tradeoff... but man... Electron apps are just not that great.
al_borland 8mo ago
I keep being told by Anthropic and others than these AI coding tools make it effortless to write in new languages and port code from one language to another. This is an important lesson to watch what people do, not what they say.
- softwaredoug 8mo ago
  Coding is solved. Engineering is not solved.
  - whattheheckheck 8mo ago
    Coding ain't solved
  - bdangubic 8mo ago
    that is because software “engineering” does not exist, it only exist as a fairytale story and bullshit job titles like SW”E”
    - SR2Z 8mo ago
      Right, the biggest driver of global economic growth is not based on engineering at all, and these people (who've made massive amounts of money) clearly don't know how to describe the work they do.
      - bdangubic 8mo ago
        so money = “engineering” - that exactly computes with my post :) you should read this - all three parts, very educational (though with 30 years as “engineer” I don’t agree with it all but it is very educational, especially part 1): https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/
- seanmcdirmid 8mo ago
  You should definitely ignore the “I tried nothing and nothing worked” crowd.
noosphr 8mo ago
Why not just vibe code binary executables for each platform? The sheer speedup all users will show everyone why vibe coding is the future. After all coding is a solved problem.
- Terr_ 8mo ago
  Not "eating their own dog-food" may not be conclusive, but it sure is suggestive.
- dmix 8mo ago
  I'm guessing the first question will be "How are we going to keep the UI consistent?". The hard part is never the code writing it's carefully releasing fast changing features from product people. Their chat UX is the core product which is replicated on the internet and other devices. That's almost always React or [JS framework] these days. Migrating the system would be the easier part in that regard, but they'll still need a JS UI unless they develop multiple teams to spearhead various native GUIs (which is always an option). Almost every AI chat framework/SDK I've seen is some React or JS stuff. Or even agent stuff like llamaindex.ts. I have a feeling AI is going to reinforce React more than ever.
  - aembleton 8mo ago
    Why does the ui need to be consistent? If its for documentation I then an llm should be able to write those instructions.
    - Voultapher 8mo ago
      Yep, I understand why let's release this one feature everywhere is a great lure and I do get annoyed when desktop vs mobile spotify gets features later or never. However, a phone is not a desktop capability wise and what we usually get is the power of the phone on a desktop, aka the lowest common denominator of capabilities. This fetish we as an industry have to hide platform specifics makes us blind to the platform specific capabilities. Some software would be better off if it leaned into the differences instead of fighting them.
amelius 8mo ago
Question from a Claude web user here. Could you visualize the user's usage? For example, like a glass of water that is getting emptier the more tokens are used, and gets refilled slowly. Because right now I have no clue when I will run out of credits. Thanks!
samrus 8mo ago
But the question isnt really why claude is electron based. Its that if, for some reason, it had to be native on 3 platforms, could a swarm of agents make and maintain the 3 aps while all the humans did was make the spec and tests? With your context and understanding of the coding agent's capabilities and limitations, especially Opus4.6, how do you see that going?
- cyanydeez 8mo ago
  It is really confusing how we're told the last few years how all ourp rogrammers are obsolete and these billion dollar companies can't be arsed touse these magical tools to substantially improve their #1 user facing asset.
- NewsaHackO 8mo ago
  >But the question isnt really why claude is electron based Huh?
BiraIgnacio 8mo ago
That's a very sensible, realistic and non-BS response. I'm glad to see this coming from a company that is so popular these days. Thanks!
fatata123 8mo ago
[dead]
ncb9094 8mo ago
Somehow claude is only great at things that are surface level 80.9% And for some reason i believe "may change in the future" will never come. we all know coding was never the problem in tech, hype was. ride it while you can
gozucito 8mo ago
Makes sense to me. It's the fastest way to iterate because Electron is the best cross platform option and because LLMs are likely trained on a lot of HTML/Javascript. Which is why Claude is great at it.
sensanaty 8mo ago
I thought coding was already solved by Claude? Why aren't you vibe coding something that isn't dogshit with your fancy little Code Solver?
mvdtnz 8mo ago
Shouldn't the AI be doing the building if your hype is to be believed? What does it matter what the team is experienced in?
solarkraft 8mo ago
I’m okay with Electron. I’ve used great Electron apps (VSCode). I like that the feature set is the same between the website and the app. But it should be possible to make an Electron app that is more reliable and eats less resources.
- bigtex 8mo ago
  Shouldn't Anthropic just prompt Claude to "make an Electron app, but more reliable and eats less resource?" That easy right?
  - solarkraft 8mo ago
    "Make no mistakes"
Sateeshm 8mo ago
> Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively Why does it matter what tech the engineers used in the past? I thought they didn't write code anymore.
jbverschoor 8mo ago
No need to make those trade offs anymore. Sounds like conflict of interest instead
KronisLV 8mo ago
Seems pretty sensible! I always wonder how those established Electron codebases would map over to something that uses the system specific WebViews and how broken (or not) those would prove to be: https://wails.io https://wails.io https://tauri.app https://tauri.app But admittedly that would just decrease the bundle size while doing not much for the performance or resource usage: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... so maybe not super relevant to this particular discussion.
spwa4 8mo ago
Really? Because the point is that when it comes to performance, just implementing your own "DOM" in C++ or some other low level language is going to have 10x the performance of electron, easily, in addition to having more features (better, smoother, file uploads would be welcome btw). If you can put in unlimited coding engineering effort, why isn't Claude Code the very best it can possibly be? Why isn't the fact that it can work 10% better an excuse to get claude to work on it for however long it takes? I mean, most people here have done development with claude code, and we suppose the answer is simply: because that doesn't work without a capable engineer constantly babysitting the changes it's making, guiding it, nudging it, reminding it about edge cases, occasionally telling it it's being stupid ... it's a great product, incredible even, but it doesn't work without senior engineers. Same question: Why doesn't it have more plugins and batch script and modfications than the app store? Surely it can by itself come up with 10000 good ideas and just implement them? Everything from little games to how to active bedroom lights by chinese vendor #123891791 ?
coldtrait 7mo ago
Couldn't you ask Claude Code to vibe-code a Swift app?

by bcherny 8mo ago

blibble 8mo ago

this is you? https://www.youtube.com/watch?v=We7BZVKbCVw https://www.youtube.com/watch?v=We7BZVKbCVw if that's the case, why don't you just ask it to "make it not shit"?

kenonet 8mo ago
hahaha
runlevel1 8mo ago
I'm not sure what's more insane: That they're willing to make those claims or that companies are willing to downsize based on them.
afroboy 8mo ago
Like Warren Buffett said, Never ask your barber if you need a haircut.

PKop 8mo ago

Users would benefit from native apps, hopefully you guys will give it a try. I bet Claude would be great at it too, no?

deleted 8mo ago

[deleted]

endergen 8mo ago

The second you wanted to add a webview, you want Electron. Devs want Chrome DevTools and Chrome runtime. You guys just did add it too, so yeah!

fourside 8mo ago

Thanks for chiming in! My takeaways are that, as of today: - Using a stack your team is familiar with still has value - Migrating the codebase to another stack still isn’t free - Ensuring feature and UX parity across platforms still isn’t free. In other words, maintaining different codebases per platform still isn’t free. - Coding agents are better at certain stacks than others. Like you said any of these can change. It’s good to be aware of the nuance in the capabilities of today’s coding agents. I think some people have a hard time absorbing the fact that two things can be true simultaneously: 1) coding agents have made mind bending progress in a short span 2) code is in many ways still not free

ProAm 8mo ago

Couldn't this have been vibe coded into a native app that is more performant?

WJW 8mo ago
> vibe coded > more performant I found the problem.
- LtWorf 8mo ago
  I mean, we both know it couldn't, but the company claims it can be done so why don't they do it?
  - amelius 8mo ago
    I suppose because generating tokens is slow. It is a limitation of the technology. And when data is coming in slowly, you don't need a super high performance client.
    - LtWorf 8mo ago
      Do you really need an incredibly slow client though?
- Wowfunhappy 8mo ago
  ...I think a vibe-coded Cocoa app could absolutely be more performant than a run-of-the-mill Electron app. It probably wouldn't beat something heavily optimized like VS Code, but most Electron apps aren't like that.

hedgehog 8mo ago

As a user I would trade fewer features for a UI that doesn't jank and max out the CPU while output is streaming in. I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. (edit: this applies to the mobile app as well)

ajross 8mo ago
> a UI that doesn't jank and max out the CPU While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help. I mean, look: the most complicated, stateful and involved UIs most of the people commenting in this thread are going to use (are going to ever use, likey) are web stack apps. I'll name some obvious ones, though there are other candidates. In order of increasing complexity: 1. Gmail 2. VSCode 3. www.amazon.com (this one is just shockingly big if you think about it) If your client machine can handle those (and obviously all client machines can handle those), it's not going to sweat over a comparatively simple Electron app for talking to an LLM. Basically: the war is over, folks. HTML won. And with the advent of AI and the sunsetting of complicated single-user apps, it's time to pack up the equipment and move on to the next fight.
- cgh 8mo ago
  You think VSCode’s ui is more complicated than eg Microsoft Excel? Or am I misunderstanding?
  - SR2Z 8mo ago
    It definitely is, seeing as how it can embed a spreadsheet.
- kadoban 8mo ago
  > While there are legitimate/measurable performance and resource issues to discuss regarding Electron, this kind of hyperbole just doesn't help. From the person you're responding to: > I would guess a moderate amount of performance engineering effort could solve the problem without switching stacks or a major rewrite. Pretty clearly they're not saying that this is a necessary property of Electron.

WD-42 8mo ago

Didn’t you say coding is a solved problem? So why are you still reaching for the lowest common denominator tech stack?

senordevnyc 8mo ago
Did they say that? I doubt it.
- greazy 8mo ago
  They did, with the caveat that its solved" for most use cases". https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens https://www.lennysnewsletter.com/p/head-of-claude-code-what-...
  - IhateAI_2 8mo ago
    [dead]
  - no-name-here 8mo ago
    I would have expected the non-solved-cases to be the relatively unique ones, but considering the plethora of both A) non-Electron desktop apps, and B) coding agents (Copilot/Windsurf/Cursor/Codex/OpenCode/Qwen/Amazon Kiro/Devin/JetBrains AI/Gemini CLI/Gemini Code Assist/Antigravity/Warp/Kilocode/Cline/RooCode/Atlassian Rovo/Claude Code/etc), it seems like neither of the building blocks is very rare - perhaps Claude is just incapable of putting it together?
- WD-42 8mo ago
  https://m.youtube.com/watch?v=We7BZVKbCVw https://m.youtube.com/watch?v=We7BZVKbCVw within the first few seconds.
  - furyofantares 8mo ago
    The full quote (in response to: should people learn programming) is "In a year or two it's not gonna matter, coding is largely solved". Which is still quite the statement, and damn the video is intolerable. But the full quote still feels a little different than how you put it here.

LtWorf 8mo ago

And they couldn't vibe code a client in Qt?

dude250711 8mo ago

> Finally, Claude is great at it. So the model is not a generalised AI then? It is just a JS stack autocomplete?

danjl 8mo ago
I think that comment is interesting as well. My view is that there is a lot of Electron training code, and that helps in many ways, both in terms of the app architecture, and the specifics of dealing with common problems. Any new architecture would have unknown and unforeseen issues, even for an LLM. The AIs are exceptional at doing stuff that they have been trained on, and even abstracting some of the lessons. The further you deviate away from a standard app, perhaps even a standard CRUD web app, the less the AI knows about how to structure the app.
lkbm 8mo ago
Claude isn't AGI, but this is a terrible argument. I'm better at Javascript than C, too. Does this mean I'm not a generalized intelligence? I'm just JS stack autocomplete?
- dude250711 8mo ago
  It kind of does.

exabrial 8mo ago

Boris, native app on OSX would be awesome. Totally understand the engineering decision tradeoff... but man... Electron apps are just not that great.

al_borland 8mo ago

I keep being told by Anthropic and others than these AI coding tools make it effortless to write in new languages and port code from one language to another. This is an important lesson to watch what people do, not what they say.

softwaredoug 8mo ago
Coding is solved. Engineering is not solved.
- whattheheckheck 8mo ago
  Coding ain't solved
- bdangubic 8mo ago
  that is because software “engineering” does not exist, it only exist as a fairytale story and bullshit job titles like SW”E”
  - SR2Z 8mo ago
    Right, the biggest driver of global economic growth is not based on engineering at all, and these people (who've made massive amounts of money) clearly don't know how to describe the work they do.
    - bdangubic 8mo ago
      so money = “engineering” - that exactly computes with my post :) you should read this - all three parts, very educational (though with 30 years as “engineer” I don’t agree with it all but it is very educational, especially part 1): https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/
seanmcdirmid 8mo ago
You should definitely ignore the “I tried nothing and nothing worked” crowd.

noosphr 8mo ago

Why not just vibe code binary executables for each platform? The sheer speedup all users will show everyone why vibe coding is the future. After all coding is a solved problem.

Terr_ 8mo ago
Not "eating their own dog-food" may not be conclusive, but it sure is suggestive.
dmix 8mo ago
I'm guessing the first question will be "How are we going to keep the UI consistent?". The hard part is never the code writing it's carefully releasing fast changing features from product people. Their chat UX is the core product which is replicated on the internet and other devices. That's almost always React or [JS framework] these days. Migrating the system would be the easier part in that regard, but they'll still need a JS UI unless they develop multiple teams to spearhead various native GUIs (which is always an option). Almost every AI chat framework/SDK I've seen is some React or JS stuff. Or even agent stuff like llamaindex.ts. I have a feeling AI is going to reinforce React more than ever.
- aembleton 8mo ago
  Why does the ui need to be consistent? If its for documentation I then an llm should be able to write those instructions.
  - Voultapher 8mo ago
    Yep, I understand why let's release this one feature everywhere is a great lure and I do get annoyed when desktop vs mobile spotify gets features later or never. However, a phone is not a desktop capability wise and what we usually get is the power of the phone on a desktop, aka the lowest common denominator of capabilities. This fetish we as an industry have to hide platform specifics makes us blind to the platform specific capabilities. Some software would be better off if it leaned into the differences instead of fighting them.

amelius 8mo ago

Question from a Claude web user here. Could you visualize the user's usage? For example, like a glass of water that is getting emptier the more tokens are used, and gets refilled slowly. Because right now I have no clue when I will run out of credits. Thanks!

samrus 8mo ago

But the question isnt really why claude is electron based. Its that if, for some reason, it had to be native on 3 platforms, could a swarm of agents make and maintain the 3 aps while all the humans did was make the spec and tests? With your context and understanding of the coding agent's capabilities and limitations, especially Opus4.6, how do you see that going?

cyanydeez 8mo ago
It is really confusing how we're told the last few years how all ourp rogrammers are obsolete and these billion dollar companies can't be arsed touse these magical tools to substantially improve their #1 user facing asset.
NewsaHackO 8mo ago
>But the question isnt really why claude is electron based Huh?

BiraIgnacio 8mo ago

That's a very sensible, realistic and non-BS response. I'm glad to see this coming from a company that is so popular these days. Thanks!

fatata123 8mo ago

[dead]

ncb9094 8mo ago

Somehow claude is only great at things that are surface level 80.9% And for some reason i believe "may change in the future" will never come. we all know coding was never the problem in tech, hype was. ride it while you can

gozucito 8mo ago

Makes sense to me. It's the fastest way to iterate because Electron is the best cross platform option and because LLMs are likely trained on a lot of HTML/Javascript. Which is why Claude is great at it.

sensanaty 8mo ago

I thought coding was already solved by Claude? Why aren't you vibe coding something that isn't dogshit with your fancy little Code Solver?

mvdtnz 8mo ago

Shouldn't the AI be doing the building if your hype is to be believed? What does it matter what the team is experienced in?

solarkraft 8mo ago

I’m okay with Electron. I’ve used great Electron apps (VSCode). I like that the feature set is the same between the website and the app. But it should be possible to make an Electron app that is more reliable and eats less resources.

bigtex 8mo ago
Shouldn't Anthropic just prompt Claude to "make an Electron app, but more reliable and eats less resource?" That easy right?
- solarkraft 8mo ago
  "Make no mistakes"

Sateeshm 8mo ago

> Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively Why does it matter what tech the engineers used in the past? I thought they didn't write code anymore.

jbverschoor 8mo ago

No need to make those trade offs anymore. Sounds like conflict of interest instead

KronisLV 8mo ago

Seems pretty sensible! I always wonder how those established Electron codebases would map over to something that uses the system specific WebViews and how broken (or not) those would prove to be: https://wails.io https://wails.io https://tauri.app https://tauri.app But admittedly that would just decrease the bundle size while doing not much for the performance or resource usage: https://github.com/Elanis/web-to-desktop-framework-comparison https://github.com/Elanis/web-to-desktop-framework-compariso... so maybe not super relevant to this particular discussion.

spwa4 8mo ago

Really? Because the point is that when it comes to performance, just implementing your own "DOM" in C++ or some other low level language is going to have 10x the performance of electron, easily, in addition to having more features (better, smoother, file uploads would be welcome btw). If you can put in unlimited coding engineering effort, why isn't Claude Code the very best it can possibly be? Why isn't the fact that it can work 10% better an excuse to get claude to work on it for however long it takes? I mean, most people here have done development with claude code, and we suppose the answer is simply: because that doesn't work without a capable engineer constantly babysitting the changes it's making, guiding it, nudging it, reminding it about edge cases, occasionally telling it it's being stupid ... it's a great product, incredible even, but it doesn't work without senior engineers. Same question: Why doesn't it have more plugins and batch script and modfications than the app store? Surely it can by itself come up with 10000 good ideas and just implement them? Everything from little games to how to active bedroom lights by chinese vendor #123891791 ?

coldtrait 7mo ago

Couldn't you ask Claude Code to vibe-code a Swift app?