Deep Diving for Answers

Author: Christopher Shortt

  • How Long Does Life Have on Earth?

    There has long been a discussion about why we haven’t detected intelligent life elsewhere in our galaxy, called the Femi Paradox(thanks Enrico Fermi). One new answer posits that intelligent life might not exist long enough on any given planet to send out a detectable signal that has reached us in the short time we’ve been intelligent enough to detect it.

    For instance, this article speculates that intelligent life has as rather short lifespan, roughly 5,000 years…

    If that’s the case, then long term survival doesn’t look too good for us. But what if we could beat the odds… What exactly to we need to overcome to beat the 5,000 year time bomb?

    Here’s what Gemini AI has to say:

    Short-term risks (the next 10 to 1,000 years) are primarily driven by 

    human activity and volatile natural systems

    Scientists often categorize these as “existential risks”—events that could not only cause a mass extinction but also permanently curtail the potential of intelligent life. 


    1. Anthropogenic (Human-Caused) Risks

    These are currently considered the most likely threats to global stability in the near future. 

    • Climate Change & Ecosystem Collapse: Beyond just “warming,” the risk lies in tipping points. If the permafrost melts and releases massive amounts of methane, or if the ocean’s thermohaline circulation (like the Gulf Stream) shuts down, we could face a rapid collapse of the global food supply and biodiversity.
    • Nuclear Conflict: A full-scale nuclear exchange would cause immediate devastation, but the “Nuclear Winter” that follows—soot blocking the sun for years—would lead to a global famine that could kill billions.
    • Synthetic Biology & Pandemics: As gene-editing tools (like CRISPR) become more accessible, the risk of a “designer pathogen”—one that is highly contagious, has a long incubation period, and a high mortality rate—increases significantly compared to natural mutations.
    • Misaligned Artificial Intelligence: This is the risk that an “agentic” AI system, pursuing a goal that isn’t perfectly aligned with human survival, could monopolize resources or alter the environment in a way that makes human life impossible. 

    2. Natural “Wildcard” Risks

    Earth has a history of sudden, violent shifts that occur on scales of thousands, rather than millions, of years. 

    • Supervolcanic Eruptions: An eruption from a site like Yellowstone or the Toba caldera would eject enough ash into the atmosphere to block sunlight for several years, causing a “volcanic winter” and global crop failure.
    • Geomagnetic Storms: A “Carrington Event” level solar flare would hit our electrical grids today with devastating effect. While not an immediate extinction event for the species, it could cause a total collapse of modern civilization, leading to mass starvation and secondary conflicts.
    • Near-Earth Objects (NEOs): While NASA tracks most large asteroids, “city-killers” or “continent-killers” can still emerge from the Sun’s glare with little warning. 

    Comparison of Short-Term vs. Long-Term Threats

    Threat Type Time HorizonPrimary DriverReversibility
    Short-Term10 – 500 yearsTechnology / BiologyHigh (if managed now)
    Long-Term500M – 1B yearsAstrophysics / GeologyLow (requires “Space-Age” engineering)

    The Concept of the “Great Filter”

    Many futurists refer to these short-term risks as the Great Filter. This theory suggests that most civilizations in the universe might destroy themselves shortly after discovering high technology (nuclear power, AI, biotech) before they have the chance to become multi-planetary. 

    Note: Unlike the brightening Sun, which is an inevitable physical process, almost all short-term risks are mitigable. International cooperation, planetary defense systems, and biosecurity protocols are currently being developed to address these.

    Let’s say we actually work our way through the Great Filter. What are the next big challenges to our long term survival?

    Here is Google AI’s answer about the long term risks to life on Earth:

    It is a fascinating—if slightly sobering—thought experiment to look that far into the future. While humanity faces many short-term risks, the survival of life itself over a billion-year timescale is primarily threatened by massive, slow-moving astrophysical and geophysical shifts.

    Here are the primary risks that could limit the Earth’s habitability over the next billion years. 


    1. Solar Luminosity (The “Brightening Sun”)

    This is the most definitive threat. As the Sun ages, it burns hydrogen faster, causing its core to become denser and hotter. Every billion years, the Sun’s luminosity increases by about 10%

    • The Runaway Greenhouse Effect: In about 600 million to 1 billion years, this increased heat will accelerate the weathering of silicate rocks. This process traps carbon dioxide (CO2𝐶𝑂2) from the atmosphere into the ground.
    • Plant Starvation: Eventually, CO2𝐶𝑂2 levels will drop below the threshold required for photosynthesis (roughly 150 parts per million for C3 plants). Once plants die, the oxygen supply collapses, and the food chain follows.
    • Ocean Evaporation: By the 1-billion-year mark, the surface temperature will likely exceed 100°C, causing the oceans to evaporate into the stratosphere and eventually escape into space. 

    2. Loss of the Magnetic Field

    Earth’s “shield” against solar radiation is generated by its molten outer core. 

    • Core Solidification: As the Earth’s interior cools, the outer core will eventually solidify. Without a liquid core to create a dynamo effect, the magnetosphere would weaken or disappear.
    • Atmospheric Stripping: Without a magnetic field, solar winds would slowly strip away the atmosphere, similar to what happened on Mars. This would expose any remaining life to lethal levels of cosmic radiation. 

    3. Geologic Stasis (The End of Plate Tectonics)

    Plate tectonics are essential for recycling nutrients and regulating the Earth’s temperature through the carbon-silicate cycle. 

    • Internal Cooling: As the planet’s internal heat dissipates, mantle convection will slow down and eventually stop.
    • Nutrient Depletion: Without volcanic activity to return minerals to the surface and subduction to recycle carbon, the surface would become a stagnant, nutrient-poor desert. 

    4. Stochastic Catastrophes (Random Events)

    While less predictable than solar aging, high-energy cosmic events pose a constant background risk:

    • Gamma-Ray Bursts (GRBs): A GRB within our part of the galaxy could deplete the ozone layer instantly, causing a mass extinction.
    • Supernova: A nearby stellar explosion could bathe the Earth in high-energy ionizing radiation.
    • Large-Scale Asteroid Impacts: While life has survived these before (like the Chicxulub impact), a “planet-killer” size asteroid (hundreds of miles wide) could theoretically sterilize the crust. 

    Summary of the “End of Life” Timeline

    Timeframe Expected EventImpact on Life
    ~600 Million YearsCO2𝐶𝑂2 levels drop significantlyC3 plants (trees, crops) begin to die out.
    ~800 Million YearsCritical CO2𝐶𝑂2 depletionC4 plants (grasses) fail; complex animal life goes extinct.
    ~1 Billion Years10% increase in Solar LuminosityOceans evaporate; Earth becomes a “hothouse” planet.
    ~1.2 Billion YearsTotal SterilizationOnly extremophile microbes may survive in deep crustal pockets.

    Is there a “Silver Lining”?

    Life is incredibly resilient. Some scientists suggest that if an advanced civilization (human or otherwise) is still present, they might mitigate these risks through planetary engineering, such as: 

    • Shifting Earth’s Orbit: Using gravity assists from captured asteroids to move Earth slightly further from the brightening Sun.
    • Star Shifting: Using giant mirrors or “shades” in L1 orbit to reduce the amount of solar radiation reaching the surface. 

    OK. So lots of things *could* happen, but seriously, what are the chances? Gemini AI has this to say:

    Calculating the probability of existential or catastrophic risks is a major focus for institutes like the 

    Future of Humanity Institute (Oxford) and the Centre for the Study of Existential Risk (Cambridge).

    Because many of these events have never happened (thankfully), we cannot use “frequentist” statistics (counting how often something occurred in the past). Instead, researchers use Bayesian estimation, expert surveys, and predictive modeling.

    The following table summarizes the estimated probability of these events occurring within the next 100 years, based on data from the Global Catastrophic Risks report and the Precipice by Toby Ord.


    Estimated Probabilities for the Next 100 Years

    Risk CategoryEstimated ProbabilityPrimary Driver / Source
    Natural Pandemic~3% (1 in 33)Historical frequency of zoonotic spillovers.
    Nuclear War~1% (1 in 100)Expert consensus on escalation and “near-miss” history.
    Supervolcano~0.01% (1 in 10,000)Geological recurrence intervals (e.g., Yellowstone).
    Asteroid Impact~0.0001% (1 in 1,000,000)Tracking of Near-Earth Objects (NEOs).
    Climate Change~0.1% (1 in 1,000)Risk of “total” extinction (vs. civilization collapse).
    Engineered Pandemic~3% (1 in 33)Rapid advancement in synthetic biology.
    Unaligned AI~10% (1 in 10)Rapid progress toward AGI (Artificial General Intelligence).

    Why the Numbers Vary So Widely

    1. The “Precedence” Problem

    We have high confidence in the Asteroid and Supervolcano numbers because we have a fossil and geological record spanning millions of years. We know roughly how often a 10km asteroid hits (every 100 million years), so the math is “harder” and more reliable.

    2. Human Agency and “Black Swans”

    Risks like AI or Nuclear War are much harder to quantify because they depend on human choices and technological breakthroughs that haven’t happened yet.

    • The AI Estimate: The 10% figure is highly controversial. It is based on the idea that if we create something smarter than ourselves, the chance of a “control failure” is non-trivial.
    • The Nuclear Estimate: This fluctuates based on the geopolitical climate. During the Cuban Missile Crisis, the probability was arguably much higher than it is today.

    3. Total Cumulative Risk

    Toby Ord, a leading researcher in this field, estimates the total existential risk to humanity over the next century at approximately 1 in 6. He compares this to playing a game of Russian Roulette with our future.


    The “Daly-Carter” Equation (A Thought Experiment)

    If you want a more formal way to think about these probabilities, researchers often use a simplified version of the Drake Equation for Earthly risks:

    Ptotal=1(1Pn)×(1Pa)𝑃𝑡𝑜𝑡𝑎𝑙=1−(1−𝑃𝑛)×(1−𝑃𝑎)

    Where:

    • Pn𝑃𝑛 is the probability of a natural extinction event.
    • Pa𝑃𝑎 is the probability of an anthropogenic (human-caused) event.

    Currently, 

    Pa𝑃𝑎 is considered orders of magnitude higher than 

    Pn𝑃𝑛, meaning we are far more likely to be the cause of our own demise than the universe is.


    How we can lower these numbers

    It is important to remember that these aren’t fixed “fates”—they are current trajectories.

    • Asteroid detection has already lowered the risk of a “surprise” impact significantly in the last 20 years.
    • AI Safety research and Biosecurity protocols are fields specifically designed to drive those 3% and 10% numbers toward zero.

    Assuming we are able to survive the exestential risks, it sounds like we need to find a way to get the heck out of here before the Sun does us in. What about faster that light travel?

    Again, Gemini AI:

    Calculating the odds of discovering Faster-Than-Light (FTL) travel involves moving from the realm of “empirical risk” (like asteroids) into “speculative physics.” 

    Under our current understanding of the universe, the probability is either effectively zero (because physics forbids it) or reasonably high (because we have a massive 600-million-year window to “solve” physics). 

    Here is how we can break down those odds using our current scientific frameworks.


    1. The Physics Barrier: Why it might be 0%

    According to General Relativity, as an object with mass approaches the speed of light (𝑐), its energy/mass increases toward infinity. To reach 𝑐, you would need infinite energy. 

    • Causality Violations: In physics, FTL is mathematically equivalent to time travel. If you can travel faster than light, you can arrive at a destination before you left in certain frames of reference. This creates logical paradoxes that the universe seems “designed” to prevent.
    • The Energy Requirements: Even “theoretical” workarounds like the Alcubierre Drive(which warps space around a ship rather than moving the ship through space) require “negative energy” or “exotic matter”—substances that have never been observed and may not exist. 

    2. The Time Horizon: Why it might be High

    If we assume that our current understanding of physics is “incomplete” rather than “final,” the timeline is in our favor. 

    • Human Progress Scale: Modern science is only about 400 years old. We have 600,000,000 years before the Sun begins to starve the biosphere of CO2𝐶𝑂2.
    • Technological Maturity: If a civilization survives its “technological infancy” (the short-term risks we discussed), it may reach a point of technological singularity, where AI or post-biological intelligence can test physics at scales we can’t even imagine.
    • The “New Physics” Probability: History shows that “settled” physics is often overturned (e.g., Newtonian mechanics being replaced by Relativity). Over millions of years, the probability of finding a “loophole” in the fabric of spacetime (like stable wormholes or extra-dimensional shortcuts) increases. 

    3. Comparing the Odds: FTL vs. The Sun

    Factor Probability EstimateReasoning
    Strict Einsteinian Physics~0%FTL is physically impossible; mass becomes infinite.
    Discovery of “New” Physics1% – 10%Based on the massive amount of time (600M years) to experiment.
    Alternative: “Slow” Colonization>90%We don’t need FTL to survive the Sun; we just need sub-light generation ships.
    Sun Destroying Life~100%Inevitable physical process of stellar evolution.

    4. The “Workaround”: Why FTL may not be necessary

    To survive the Sun, we don’t actually need to break the speed of light. We only need to reach the nearest stars (4.2 light-years away). 

    Even at 10% of the speed of light (achievable via nuclear pulse propulsion like Project Orion), we could reach Proxima Centauri in 42 years. On a billion-year scale, a civilization could colonize the entire Milky Way Galaxy several times over without ever breaking the light-speed barrier. 

    The Verdict

    • If Relativity is an Absolute Law: The odds are 0%.
    • If Relativity is an Incomplete Model: The odds are Moderate to High, simply because 600 million years is an astronomical amount of time for a survivor species to innovate. 

    Interesting Thought: If the probability of FTL were high, we might expect to see evidence of other civilizations using it (The Fermi Paradox). The fact that the sky is “silent” might suggest that FTL is either impossible or so difficult that no one has achieved it yet.

    I’m getting closer to the end of my predicted life span, but I hold out hope for the human race, or any other species on Earth that may succeed us. I want to live… and so does just about every other creature on the planet. So, if you have anything to contribute that might help us all get there, leave a comment below and let’s get to work.

  • Is The Future of Software Development All AI?

    Recently, I was asked to help develop a proof of concept (POC) iOS app after having been away from iOS coding for a while. When I looked at the features included in MacOS 26 and the latest Xcode beta product, I was happy to see the inclusion of two (albeit related) things. The first was Apple’s new FoundationModels large language model (LLM) on device. This allows apps to include ChatGP like chat bots without the need to pump conversations back and forth to the cloud. The second, in Xcode, was the inclusion of what has become a big top in programming circles, these days, “Vibe Coding”. For the uninitiated, this means you have a chat with ChatGPT or Claude, and it handles a lot of the work of generating code. How good the code is, or how much it can do for you is currently up for debate, but I’ll throw my two cents worth in.

    On-Device LLMs

    First, let’s take a look at having an LLM on-device… to set the scene a bit, I use the free version of ChatGPT in their app on iOS and it does, generally speaking, a pretty reasonable job. It is easy trip up, and writing good prompts is key to getting the best out of it. As an example, I tried this prompt based on a news article I read somewhere (if I can remember the source, I’ll attribute it here):

    Me >
    “Was 1995 thirty years ago?”

    ChatGPT >
    “No, 1995 was 30 years ago in 2025.”

    Me >
    “What year is it?”

    ChatGPT >
    “2025”

    To see if a small change to the prompt would solicit a correct answer, I tried this:

    Me >
    “Was 1995 thirty years ago today?”

    ChatGPT >

    “Yes”

    The lesson learned here is that sometimes, the prompt needs more information than you might think. But I digress. Having an LLM on device can be very important for the use cases where the main concerns are speed, reliability and security. Not having to send the prompt to the cloud and waiting for the response to come back from the cloud, removes a lot the latency involved in implementing cloud-based LLMs in mobile apps. That’s not to say that responses will be immediate… there is still the processing and response generation happening and sometimes the devices don’t have the processing power of a cloud setup. Still though, whenever you can shorten the path from the prompt to the response, it’s a good thing.

    Also, having the LLM on-device, means that there are less points of failure between the prompt and the response. By this I mean, less hardware that could fail before the path is fully traveled. By being on-device, you don’t need a radio to package up the data and send it to the cloud. You don’t need a receiver to receive the data package and put it onto a wire, where it gets sent through untold number of servers in untold number of locations in the world, then processed in a server farm somewhere with its own network of hardware and software to move and process data, only to turn it all around to send the generated response back. Generally, all of that is reasonably fast and reliable, when it fails, you really feel it. So, I’ll take on-device any day.

    The proof of concept app that I am working on includes a feature where the user can have a conversation with the app and the app can use components of that conversation to find outside content that may be of interest to the user. So, chat itself happens all on-device (which so far in beta is pretty good speed-wise) and produces reasonable responses. This helps a lot with user engagement, so, a good thing. Also, the app can tap into the conversation and the response and use another artificial intelligence (AI) feature called Named Entity Recognition, to identify things of interest to the app. These identified things are used to find available content that matches with the text of the conversations and surface that new content to the user of the app. Done properly, that can look pretty impressive to the user and also supports more engagement with the user, in the long run.

    On-device LLMs then, seem like a pretty good idea to me, especially for the use case I am working on currently. To help me work on that POC app, I thought I would use the feature in Xcode that is our second point, having an LLM to generate code. I’d never done that before, and I’m always up for any way to make my work easier and faster.

    Vibe Coding

    When I downloaded the latest beta of Xcode, I noticed that it featured a coding assistant using ChatGPT (or Claude) to help with the generation of code and to check for and correct coding errors. It works just like any other chatbot… you enter a prompt asking for some feature to be added to some existing code, or for some code to be refactored, or to fix an error. It responds with it’s reasoning on how to solve the problem, and can (if you like) implement the proposed changes right in your code. If you don’t like what it did, you can tell it revert the changes (although in the beta I’m using this is surprisingly hit or miss).

    Since the POC needed to include the on-device chatbot, I looked to the internet to see what someone might have already done. Usually someone does the small app to show off a new feature and are kind enough to provide all the code they wrote. A good place to start, I thought and it didn’t take to long to find a good starting point. Let me give a shout out to “SwiftUI Cheatsheet” on Patreon for the excellent starting point. Here is a link to the article I used:

    Using that as a building block, I spent some time building the POC to include their chatbot, with a few changes to suit my purposes. I mostly built the rest of the app simply by prompting the coding assistant (in my case, ChatGTP 4.1 and 5.0) and getting it to do most of the work. I was, with very little touching up of the code, able to put together my POC in a seriously short amount of time. What would normally take me days, only took hours. Here is where I started after getting the basic chatbot in place.I wanted to be able to have the chatbot talk the response rather then just spit out the text of it:

    Me >
    “when the ai is finished generating a message, have the message output to audio as voice”

    Xcode >
    “To implement your request, I’ll add speech synthesis so that after the AI finishes generating a message, the message is spoken aloud as voice.

    I’ll use the AVFoundation framework’s AVSpeechSynthesizer to perform the speech. This will require:

    • Importing AVFoundation

    • Initializing an AVSpeechSynthesizer in ChatViewModel

    • Invoking the synth whenever an AI message completes (after aiMessage.isPartial = false and is saved)

    Let’s make these changes to your ChatViewModel.swift now.”

    — a picture of the proposed change was shown —

    Xcode >
    “Here’s what I’ve changed:

    • Imported AVFoundation at the top of the file.

    • Added a private AVSpeechSynthesizer property to ChatViewModel.

    • After the AI finishes generating a message (when marking aiMessage.isPartial = false and saving), the message is spoken aloud using AVSpeechUtterance and the synthesizer.

    This ensures that only complete AI messages (not partial responses or errors) are voiced, as you requested. If you’d like any adjustments (such as custom voice, rate, or language), let me know!

    Me >
    “add a toggle to the chatviewmodel to allow the turning on and off of the voice output”

    Xcode >
    “To fulfill your request, I’ll add a @Published property (e.g., isVoiceOutputEnabled: Bool = true) to the ChatViewModel. I’ll then update the logic so that the AI message is only spoken if this toggle is enabled.

    This allows any SwiftUI view observing the view model to bind to this property and provide a user-facing toggle.

    Let’s implement this now.

    — a picture of the proposed change was shown —

    “I’ve made the following changes:

    • Added a @Published var isVoiceOutputEnabled: Bool = true property to ChatViewModel. This property can be bound to a toggle in your UI.

    • Updated the AI response logic: The AI message is now only spoken if isVoiceOutputEnabled is true.

    You can now easily wire this property to a control in your UI, such as a SwiftUI Toggle, to allow users to turn voice output on or off as they wish. Let me know if you need help adding the toggle to your user interface!”

    Me >
    “add a button to the navigationbar to toggle the voice output of the chatviewmodel”

    Xcode >
    “To fulfill your request, I’ll add a button to the navigationBar(viewModel:) within ChatView.swift. This button will toggle viewModel.isVoiceOutputEnabled and update its icon to indicate whether voice output is currently on or off.

    You’ll see a button with a speaker icon (speaker.wave.2.fill for on, speaker.slash.fill for off) in the navigation bar.

    Let’s implement this now.

    — a picture of the proposed change was shown —

    I’ve added a button to your navigation bar in ChatView. This new button appears before the clear conversation (trash) button and toggles viewModel.isVoiceOutputEnabled. Its icon visually switches between a speaker (speaker.wave.2.fill) when voice is enabled and a muted speaker (speaker.slash.fill) when disabled. The button is also accessible with appropriate labels.

    You can now easily toggle voice output directly from the navigation bar! If you’d like further customization, just ask.”

    The code changes the coding assistant put in more or less worked without changes. So far, so good. I was a little impressed. I continued to implement other things simply by asking…

    When I ran into a problem, I could just ask the coding assistant to fix it:

    Me >
    “Fix error in ChatViewModel.swift on line 90:
    @error:ConvosBot/ViewModels/ChatViewModel.swift:90:Cannot assign value of type 'String' to type 'AVSpeechSynthesisVoice'

    Xcode >
    “The error occurs because AVSpeechUtterance.voice expects an instance of AVSpeechSynthesisVoice, but the code is passing a string identifier (AVSpeechSynthesisVoiceIdentifierAlex).

    To fix this, you must use the initializer AVSpeechSynthesisVoice(identifier:) to create the correct object.

    I will update the code so that the line

    — a picture of the proposed change was shown —

    I updated the code so that utterance.voice is now set using AVSpeechSynthesisVoice(identifier: AVSpeechSynthesisVoiceIdentifierAlex). This creates the correct type and resolves the error.

    Why this fixes the issue:

    Previously, the code tried to assign a String directly to utterance.voice, which expects an AVSpeechSynthesisVoice?. Now, it constructs the voice object with the identifier, which matches the expected type.

    Let me know if you have any other issues or need further adjustments!”

    This fix worked just fine. Instead of me having to search for an answer in the documentation or on some of the websites that have answers, and having to figure out exactly what to, Xcode did it all for me in a few seconds. Win!

    I also asked Xcode to create all new part of the app:

    Me >
    “make a new view that has two main sections in a vertical structure, and then a tab bar at the bottom with 4 tabs (Main, Profile, Shared, Convos)”

    Xcode >
    “You want to add a new view with a vertical structure (two main sections) and a tab bar at the bottom with four tabs: Main, Profile, Shared, and Convos.

    Here’s the plan:

    1. I will create a new SwiftUI view (let’s call it MainTabView) that implements this design.

    2. The view will use a TabView with four tabs. Each tab will show a placeholder for now.

    3. The Main tab will be structured with two vertical sections (using VStack), each using a placeholder.

    4. I’ll create the new view in a separate file for clarity.

    Let’s start by creating the new view file: MainTabView.swift.

    — a picture of the proposed change was shown —

    I’ve created a new SwiftUI view called MainTabView that structures its content in two main vertical sections and includes a tab bar at the bottom with four tabs: Main, Profile, Shared, and Convos. The Main tab uses a vertical stack for the two sections as requested.

    Would you like to see how to integrate this new view into your app, or customize the contents of the two main sections or any of the tabs?”

    Me >
    “MainTabView should be the main view of the app and ChatView should be the view when the Convos tab is selected”

    Xcode >
    “Here’s the plan:

    1. Update ConvosBotApp.swift so that MainTabView is the main/root view of the app, instead of ChatView.

    2. Update MainTabView.swift so the Convos tab displays ChatView (not just a placeholder).

    First, I’ll update ConvosBotApp.swift to launch with MainTabView.

    — a picture of the proposed change was shown —

    The following changes were made:

    1. ConvosBotApp.swift now uses MainTabView() as the main/root view instead of ChatView().

    2. MainTabView.swift was updated so that the “Convos” tab displays ChatView() instead of a placeholder.

    Your app will now show the tabbed interface as the entry point, with the Convos tab showing the chat interface. Let me know if you’d like to further customize any of the sections or tab contents!”

    Over the period of a few days I was able to put together a reasonably complete standalone app suitable as a proof of concept. I estimate that Xcode wrote about 90% of the code and was able to fix almost all errors. Some of the errors were due to ChatGPT not having up-to-the-second knowledge of the most recent changes in Swift, SwiftUI and how Xcode works. Never-the-less, I was able to in a few days what would have taken me weeks, given that I have been away from iOS app coding for a couple of years.

    Vibe Coding Lessons learned

    I am a vibe-coding convert. I will continue to use vibe-coding whenever I can and I expect that going forward, it will become even better, faster and more accurate. Vibe-coding still doesn’t do the best of code block optimization, but I found that you could ask Xcode to do something particular that would optimize your code structure and it would happily and accurately do it. I am hooked!

    In Conclusion

    I love having LLMs on-device. They will only get better and more entrenched in more apps going forward so it’s nice to see that Apple (and I’m sure others) are working hard to make this happen.

    And vibe-coding… yes feakin’ please! Anything to make my life easier is a win. I still get to flex my dev experience to put together a world-class app with top-notch architecture, but its nice to be able to focus on the fun stuff like that and let coding assistants lie the one in Xcode do all the grunt work for me.

    Let’s keep this conversation going in the comments, as this is one topic that is going to change a lot and often in the very near future.