DEV Community: José González

Why Your AI Strategy Is Three-Quarters Wrong

José González — Fri, 13 Mar 2026 10:38:45 +0000

Everyone's talking about AI productivity. Ship faster. Write more code. Automate the boring stuff. Kill the developers (well, kind of). And sure, that's real — I've seen it myself, having built several Claude Code plugins for my team at Dow Jones. AI genuinely makes you faster.

But here's the thing: if your entire AI strategy is "make developers more productive," you're focusing on one quarter of the picture and ignoring the three quarters that actually matter for the long-term health of your engineering organisation.

Bold claim? Absolutely. Let me earn it.

The knowledge problem nobody talks about

Before we get to AI, let me ask you something. Think about the best engineer you've ever worked with. The one who, when a production incident happens at 2 AM, somehow knows where the problem is before anyone else has finished reading the logs. The one who reviews your pull request and spots the architectural issue you didn't even know existed.

Now ask yourself: how much of what makes that engineer great is written down somewhere?

If your answer is "not much," congratulations — you've just identified the most valuable and most fragile asset in your organisation. That engineer's knowledge is tacit: it lives in their head, was built through years of experience, and is extraordinarily hard to articulate. It's the difference between knowing the syntax of a language and knowing when not to use a particular pattern.

The counterpart is explicit knowledge — the stuff that IS written down. Documentation, runbooks, architecture decision records, onboarding guides. The kind of knowledge you can hand to someone and say "read this."

The central challenge of any engineering organisation — and this is not a new insight, by the way — is converting the first into the second. Because tacit knowledge, no matter how brilliant, walks out the door when that engineer takes a new job.

A model from 1995 that explains everything

In 1995, Nonaka and Takeuchi published The Knowledge-Creating Company, where they described something called the SECI model (pronounced "SEH-kee," in case you were wondering — I certainly was). It describes four modes of knowledge conversion that form a continuous spiral:

Socialization (Tacit → Tacit): you learn by sitting next to an expert. Pair programming, mentoring, the hallway conversation where someone casually drops a gem that saves you three days of debugging.
Externalization (Tacit → Explicit): someone writes down what they know. Design docs, ADRs, that one Confluence page that actually explains how the payment system works, or that script that automates a repetitive established workflow.
Combination (Explicit → Explicit): you synthesise scattered knowledge into something structured. Wikis, knowledge bases, that quarterly report that pulls together insights from five different teams.
Internalization (Explicit → Tacit): you read the docs and, through practice, develop genuine understanding. Not just knowing what the architecture is, but feeling why it has to be that way.

These four modes form a spiral because the output of each phase feeds the next. Tacit knowledge gets externalised, combined with other knowledge, internalised by new people, who then socialise it further through their own practice. Round and round it goes, each turn creating new knowledge that didn't exist before — which is why Nonaka called it knowledge creation, not knowledge transfer.

You can also think of it as two complementary movements: capture (Externalization + Combination) makes knowledge available to the organisation, while spread (Socialization + Internalization) gets knowledge into people's heads.

"That's a nice academic model," you might say. "But what does it have to do with AI?"

Everything.

AI disrupts every phase (and not equally)

Here's where it gets interesting. AI — and specifically LLMs — disrupts every single phase of the SECI spiral, but the impact is wildly uneven:

SECI Phase	AI Role	Impact
Socialization	AI as synthetic pair partner	Moderate
Externalization	AI as articulation partner	Transformative
Combination	AI as synthesis engine	High
Internalization	AI as practice partner	Mixed

The biggest impact is on Externalization — the historically hardest conversion. Ask any senior engineer to write down what they know, and you'll get a mixture of procrastination, vague hand-waving, and a half-finished Confluence page abandoned three months ago. It's not that they're lazy (well, maybe, I must admit that I may hate like hell writing documentation, but just may) — it's that articulating tacit knowledge is genuinely difficult. You know more than you can tell, as Polanyi put it.

AI changes this equation dramatically. You can now think out loud with an LLM, and it helps you structure your vague understanding into coherent, shareable text. It's like having a patient interviewer who asks the right follow-up questions and turns your stream of consciousness into an architecture decision record. The friction of externalization drops by an order of magnitude.

For Combination, AI serves as a synthesis engine that can search, cross-reference, and recombine explicit knowledge across silos. That information buried in a JIRA ticket from six months ago, connected to a design doc in Confluence, connected to a Slack thread that nobody bookmarked? An AI with the right context can pull those threads together. This is the "boring but transformative" category — not glamorous, but it solves the very real problem of knowledge scattered across fifteen different tools.

For Socialization, AI pair programming creates a new form of working alongside a knowledgeable colleague. It's moderate because it lacks the richness of genuine human interaction — but it's available at 2 AM when your actual colleagues are, sensibly, asleep (as you'd probably be too, by the way).

And for Internalization... well, this is where it gets complicated. AI can accelerate learning by explaining concepts, generating exercises, and providing on-demand tutoring. But it can also short-circuit the learning process entirely. If the AI writes the code and you just accept it, you never develop the tacit understanding that makes you effective. More on this in a moment.

The fourfold strategy (or why you're focusing on the wrong quarter)

Given how AI disrupts the spiral, I think the strategic response has to be fourfold:

1. Build knowledge infrastructure — create shared tools and agents that encode team expertise and lower friction across both capture and spread. Skills that automate workflows while documenting why those workflows exist. Agents that connect to your wiki, your issue tracker, your codebase, and synthesise across them. This isn't about a specific tool — it's about building the infrastructure for the entire SECI spiral to turn faster. This is just the enabling layer for the other three goals — infrastructure without deliberate practice is just an empty pipeline.

2. Boost productivity — the obvious one. Use AI to synthesise internal and external knowledge to accelerate work. This is where 99% of the conversation is today.

3. Capture senior expertise — use AI as an articulation partner to help senior developers externalise their tacit knowledge. That architect who "just knows" how the system should evolve? Sit them down with an AI and help them turn that intuition into documentation, ADRs, and design principles that outlive their tenure. This is Externalization, and it's arguably more valuable than productivity — because it creates the knowledge base that makes productivity possible.

4. Upskill junior developers — the most neglected goal, and the one I feel most strongly about. AI should be deliberately used to accelerate Internalization: helping juniors build the deep tacit knowledge they need to become the strong engineers who make AI effective. Not just making them productive today, but growing their actual understanding.

Here's the uncomfortable truth: almost everyone jumps straight to #2 without building the infrastructure that makes everything else possible, and almost nobody has a strategy for #4. The absence of an upskilling strategy is itself a strategy — it defaults to deskilling.

Lisanne Bainbridge identified this paradox back in 1983 in a paper called Ironies of Automation: the more we automate, the more we depend on highly skilled operators — whose skills are degraded by the automation itself. If juniors never struggle with problems because AI solves them, they never develop the tacit knowledge that makes senior engineers effective. And if we deplete that pipeline, we lose the very capacity to direct AI well.

The four goals are interdependent. Infrastructure (#1) enables everything but is useless without the people to fill it. Productivity (#2) depends on having externalised knowledge to draw from (#3). And upskilling (#4) ensures the pipeline of engineers who can do all three.

The dark side (because of course there is one)

Every one of these disruptions has a flip side, and I'd be dishonest if I didn't mention them:

Hidden explicit knowledge: your tools, agents, and plugins work beautifully — but nobody understands why the decisions embedded in them were made. The workflow rationale becomes invisible once it "just works." This is Bainbridge's irony applied to AI infrastructure.
False externalization: AI produces text that looks like expert knowledge but is actually hallucinated. If that enters your knowledge base unchecked, you now have institutional misinformation that nobody questions. That's worse than having no knowledge at all.
Context poisoning: if you build a knowledge system (as I argue you should), bad context compounds just like good context. A stale note about a reversed decision will confidently lead the AI — and your team — astray.
Knowledge homogenization: if everyone uses the same AI with the same context, you risk everyone converging on a single way of thinking. The SECI spiral needs diverse tacit input; shared AI context can suppress that diversity.
The curator burden: knowledge systems need maintenance. If nobody reviews, prunes, or updates them, you've just moved the graveyard of stale documents from Confluence to a new tool.

The common thread? None of these are solved by technology alone. They all require human judgment, review rituals, and active stewardship. The same engineers you're trying to boost with AI need to be the ones keeping the knowledge system honest.

So what now?

If you've read this far — first of all, thank you for your patience. Let me leave you with the thought that prompted this entire article.

The question isn't whether AI will change how knowledge moves through your engineering organisation. It already is. Every time a developer uses an AI assistant, they're participating in the SECI spiral — creating knowledge, consuming knowledge, sometimes creating false knowledge. This is happening whether you have a strategy for it or not.

The question is whether you shape that deliberately, or let it happen by accident.

A productivity-only AI strategy is like optimising one gear in a four-gear machine. It'll spin faster, sure. But if the other three gears are rusty, the machine doesn't move.

Why You Are Wasting Your Time Making Your Code Performant

José González — Sun, 08 Mar 2026 17:09:11 +0000

I'm sure you may have come across some post in LinkedIn comparing junior vs senior code. They are unmistakable, with that fresh morning smell of heated arguments and even holy wars, with endless comments arguing why some option is better than another option or how something runs 1% faster.

Sometimes they favour highly performant code, other times they favour much shorter code, usually including some nerdy or obscure feature of the language being used. These snippets of code are shared to show you how senior the original poster is, seniority being directly proportional to the amount of those obscure features they know and inversely proportional to the length of their code.

Some other times they discuss functional vs imperative approaches, arguing about the time and space complexity of the different solutions. These discussions offer endless insights about the vast knowledge of the senior developers involved in the discussion.

Calculating the price of discounted products

One of those posts showed the following snippets of code, comparing functional and imperative versions of the same functionality, apparently calculating the cost of certain discounted products, that you would only buy if they are more expensive than a certain amount of money. I have adapted the code to Scala from the original Javascript version.

Let's assume you have the following data:

// Note to really senior developers, I'm aware that Double is not an
// appropriate data type for prices, just using it for the sake of simplicity
case class Product(name: String, price: Double)
val products = List(
  Product("Apple", 50),
  Product("Banana", 21),
  Product("Orange", 70)
)

Here you have the functional version of the code (with the curried functions that weren't included in the original example):

def applyDiscount(discount: Double)(product: Product) =
  product.price * (1 - discount)
def priceGreaterThan(limit: Double)(price: Double) =
  price > limit
def calculateTotalPrice(firstPrice: Double, secondPrice: Double) =
  firstPrice + secondPrice

val totalPrice = products
  .map(applyDiscount(0.1))
  .filter(priceGreaterThan(20))
  .reduce(calculateTotalPrice)

And here you have the imperative version:

var totalPrice = 0.0
for product <- products do
  val discountedPrice = product.price * 0.9

  if discountedPrice > 20 then
    totalPrice += discountedPrice

The original poster, blatantly ignoring the Hic sunt dracones annotation, candidly asked which option looked better, stating his mild preference for the functional version of the code for its improved readability and intention conveying.

Of course the obvious happened: hell rained upon Earth.

Are you crazy? Functional code is O(3n)!

One of the main discussions around the merits of each version came down to the performance of the code, with some senior developers arguing that the functional code had O(3n) time complexity.

Why O(3n) isn't worse than O(n)

First of all, let me clearly state this:

O(3n) is not a thing. Period.

The reasoning behind this was that the functional code iterates three times through the products collection, one for map, another for filter, and a last one for reduce. Meanwhile the imperative code only had one loop, iterating only once through the collection. So according to these senior developers, the functional code had O(3n) time complexity, while the imperative code had O(n) time complexity.

First of all, I won't go into the nitty-gritty details of the mathematical definition of the Big-O notation, but suffice to say that this notation is usually used to define an asymptotic behaviour when the input size tends to infinite. In the case of O(n) we are saying that the time spent by the algorithm grows linearly based on the size of the input (again this is a simplification). So it doesn't matter if the time function of your algorithm is n/150, n, 3n, or 12500000n, they all grow linearly, so they all are O(n).

Duh, but functional code still runs three times slower

Really? Again, to keep things simple we won't take into account the nuances associated with modern computing and memory layering. Even without taking into account this, dereferencing a memory position in an array is usually a much quicker operation than anything that you do with that data inside the loop. If those operations are an order of magnitude greater than the dereferencing, the dereferencing operations become negligible.

You don't believe me? Let's do some basic maths:

Let's say that you do three operations per loop, which take a, b and c
Let's say dereferencing a position in the input array takes d

The total time of the operation will be, for an input of size n:

In the case of three loops: 3dn + an + bn + cn = (3d + l)n, where l = a + b + c
In the case on one loop: dn + an + bn + cn = (d + l)n

So, the ratio between them will be (3d + l)/(d + l). When will the code with three loops be three times slower? When you spend zero time inside the loop. And what if the operations in the loop are quite feasibly just one order of magnitude greater than loop itself? If l = 10d then the ratio becomes 13/11, just a 18% increase, not a triple increase in time. So no, going over the collection three times doesn't make the code three times slower.

But you have the cost of invoking those curried functions

Yes, but those curried functions are improving the legibility of the code clearly conveying its intention. And if you want to stop comparing apples to oranges, you can still use similar operations in the functional code just including some anonymous functions (and even replacing reduce with sum):

val totalPrice = products
  .map(_.price * 0.9)
  .filter(_ > 20)
  .sum

Anyway, you create lot of useless structures

Ok, here you may have a fair point. When you perform functional transformations, each transformation creates an intermediate structure which is discarded once its results are used in the next step of the functional pipeline.

So in this case map would create a structure of size n, which is consumed by filter which creates another structure of at most n (because it may filter out some results), which in turn is processed by sum to compute the final result. So we have an O(2n) space complexity solution (just kidding, O(n), I wanted to check if you were still paying attention).

In any case, unless we are doing some kind of nested transformations, we will have a solution whose space grows linearly with the size of the input, and arguably worsened by the number of steps in the pipeline.

Why this is a pointless discussion: strict vs lazy evaluation

Once reached this point I would just include a method invocation in the functional code to finally settle the question:

val totalPrice = products.view
  .map(_.price * 0.9)
  .filter(_ > 20)
  .sum

Do you see that .view method there? That's the Scala way of switching to lazy evaluation in collections, with the use of Views. In contrast to strict evaluation, where all the transformations are eagerly applied — hence producing new structures — when you use lazy evaluation, computations are delayed until they are strictly needed.

In our case this would mean that map and filter, instead of returning a concrete collection, would be returning another View (wrapping the underlying view and remembering the closure needed to compute values in that new view), but without performing any actual operation.

Once we reach sum, which needs to access the elements to produce its output, we do the real computation. But thanks to the magic of lazy evaluation, we loop through the original input only once without creating any intermediate structure, making this functional code effectively equivalent to the single-loop imperative code we saw in the beginning.

Of course lazy evaluation comes with its costs, in this case creating the intermediate view structures, and creating and storing those intermediate closures, which for small input sizes may be even more costly than simply performing the "loop" several times and creating intermediate collections.

In the case of functional languages, some of them are lazy (or non-strict) by default, as Haskell, and others are strict by default offering mechanisms to switch to lazy evaluation, as Scala.

Why this discussion is even more pointless: legibility and maintainability

As I said in the beginning of this article, it seems that seniority is considered to be directly proportional to the number of features you know of a given language and inversely proportional to the length of the code you generate. It also seems to be related with your ability to micro-optimise your code, so it has O(n) performance instead of O(3n) performance (kidding again).

I would argue that in a business environment the senior developer (or the valuable developer) is that who manages to lower the total cost of ownership of a software product as much as possible. Or simply said, the one who saves more company's money. But how can we know where to focus when trying to save money?

According to some people who know much more than me (I won't be the one disagreeing with an O'Reilly's published author):

Fully 60% of the life cycle costs of software systems come from maintenance [...]. During maintenance, 60% of the costs on average relate to user-generated enhancements (changing requirements), [...], and 17% to bug fixes.

So it seems that maintenance costs are much greater than operational costs (those related to the infrastructure needed to run the software). This means that unless you are Google — and an improvement in performance has an impact on millions of machines — you better focus on making your software much more maintainable and bug free. And that means stopping micro-optimising your code for measly performance gains and instead focus on making your code tell a beautiful story, one that other fellow developers and your future self are delighted to read and evolve. I would argue that functional programming has an edge here, but that is probably the topic for another post.

Anyway I hope that you, as Martin Golding asked,

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Why Swift Sucks as a Functional Language

José González — Sun, 08 Mar 2026 17:09:11 +0000

Some months ago, I became one of the many victims of a dreaded massive layoff. Due to personal issues — among them caring for my father after he fell ill with COVID — I'm still searching for a job.

In this search, I've encountered a trend that's relatively new to me: the rise of coding tests. I studied data structures and algorithms during my degree, but that was more years ago than I'm comfortable admitting. Years of just storing data in databases and retrieving it to display on a screen haven't exactly kept those skills sharp.

In my last set of interviews, I failed more often than I'd like to admit. Thankfully, I came across a kind team lead (yes, they exist!) who gave me valuable feedback on my performance. With his guidance, I've developed a plan to succeed in future interviews. But that's a topic for another post.

The problem: Find any local maxima

One of the coding problems I encountered was to find a local maxima in an array of integers. A local maxima is a value greater than its neighbours, considering only one neighbour for the first and last elements. The input array had an additional constraint: you wouldn't find any repeated values.

The key insight needed to properly solve this problem (which I failed to find without a bit of help due to a severe case of rustiness in some parts of my brain) is this: if you select any value which isn't a local maxima, you are guaranteed to find one on the side of a neighbour that's greater than the current value.

Here's an example:

let values = [5, 15, 1, 6, 8, 9, 7]

If we pick the middle position (6), this isn't a local maxima, since 6 < 8 (right neighbour). This 8 becomes a local maxima candidate (it is already halfway there after all). So if we now take the right half of the array:

let rightSideValues = [8, 9, 7]

we are guaranteed to have a local maxima. Why? 8 was already greater than its left neighbour, so we have two cases:

either 8 is greater than its right neighbour, then 8 is a local maxima
or 8 is less than its right neighbour, in which case we can discard it and repeat the process, potentially finding the maxima at the end of this subarray

We have a typical divide and conquer approach which will give us O(log(n)) complexity. With this insight in mind implementing this should be trivial... Or maybe not?

The solution: Swift vs Scala (or imperative vs functional)

During the interview, I mistakenly used Swift, despite having spent months on the bench and, adding insult to injury, recently diving into Scala again. My brain works in a curious way and tends to create big pictures while forgetting details and mixing things up if I don't refresh them continuously, so I leaned toward functional programming, leading to some interesting decisions that most likely confused my interviewer.

A few days after the interview, I revisited and solved the problem using Scala, but just out of curiosity I asked ChatGPT about the solution in Swift to compare it with my solution. Here's the imperative Swift solution it generated:

func findAnyLocalMaxima(in numbers: [Int]) -> Int? {
    guard numbers.count > 1 else { return numbers.first }

    var left = 0
    var right = numbers.count - 1

    while left <= right {
        let mid = left + (right - left) / 2

        // Check if mid is a local maxima
        if (mid == 0 || numbers[mid] > numbers[mid - 1]) &&
           (mid == numbers.count - 1 || numbers[mid] > numbers[mid + 1]) {
            return numbers[mid]
        }

        // If left neighbor is greater, search the left half
        if mid > 0 && numbers[mid - 1] > numbers[mid] {
            right = mid - 1
        } else {
            // Otherwise, search the right half
            left = mid + 1
        }
    }

    return nil
}

What was my solution in Scala like? Let's take a look at the functional alternative:

import scala.annotation.tailrec
import scala.collection.IndexedSeqView

def findAnyLocalMaxima(numbers: Array[Int]): Option[Int] =
  extension (numbers: IndexedSeqView[Int])
    def hasLocalMaximaAt(index: Int) =
      numbers(index) > numbers(index - 1) && numbers(index) > numbers(index + 1)

    def leftHalf = numbers.slice(0, numbers.length / 2)
    def rightHalf = numbers.slice(numbers.length / 2 + 1, numbers.length)

  @tailrec
  def findAnyLocalMaximaInView(numbers: IndexedSeqView[Int]): Option[Int] =
    numbers.length match
      case length if length > 2 =>
        val middleIndex = length / 2
        if numbers.hasLocalMaximaAt(middleIndex) then
          Some(numbers(middleIndex))
        else if numbers(middleIndex - 1) > numbers(middleIndex) then
          findAnyLocalMaximaInView(numbers.leftHalf)
        else
          findAnyLocalMaximaInView(numbers.rightHalf)

      case 2 => Some(math.max(numbers(0), numbers(1)))
      case 1 => Some(numbers(0))
      case 0 => None
  end findAnyLocalMaximaInView

  findAnyLocalMaximaInView(numbers.view)
end findAnyLocalMaxima

Ok, I admit it, I got a bit fancy with that extension to make the main code even more readable.

Comparisons are odious, so let's compare!

Functional programming emphasises referential transparency — the ability to replace a function call with its result without changing the program's behaviour, as long as you use pure functions. This aligns with recursive approaches, where you rewrite the problem into smaller cases to reach a base case. As a result, functional programming favours recursive calls instead of loops, because that way you express much better the intent of your code.

If you inspect the above functional code the algorithm's intent is crystal clear:

Check if the middle value is a local maxima
If not, recurse into the appropriate half

That intention is totally lost in the imperative version, which relies on side effects to adjust indices to inspect the data you are interested in. You even require comments explaining the logic!

So what's the problem of going fully functional in Swift?

Don't look at my tail, I'm not optimising it

In two words: stack overflows! I bet you will have faced at some point a stack overflow exception. This happens because whenever you invoke a new function you push a frame in the stack containing information needed for the runtime environment to run that function. So if you nest too many calls, the stack runs out of space and you get the dreaded stack overflow exception.

But wait a minute... Isn't this a problem in Scala too? No! Why? Because Scala is a proper functional language in this aspect. This mechanism of recursive invocation instead of loops is so common in functional programming that all decent functional languages have what is called tail call optimisation (TCO), where instead of adding a new frame to the stack, the current frame is substituted if the last operation of a function is a call to itself: you simply won't need the previous frame if you do nothing apart from recursively calling yourself.

See that @tailrec annotation before findAnyLocalMaximaInView? That is in fact signalling the Scala compiler to use this optimisation so you can confidently make potentially infinite recursive calls without incurring in a stack overflow exception.

But wait a minute, Swift DOES optimise tail calls

Well, Swift sometimes optimises tail calls.

First of all, depending on the level of optimisation you set during the compilation phase, tail call optimisation may be left out completely causing a stack overflow in your debug build (when you use -Onone).

But even if you set the optimisation level to -Osize or -O as far as I know there is no guarantee that tail calls will be optimised: they aren't mentioned at all in the Writing High-Performance Swift Code article of the Swift documentation, and I have only been able to find an ancient proposal in the Swift Forums regarding this (where they mention Scala's @tailrec by the way) that was apparently closed without being implemented.

Summing up, unless I stand corrected (which I'd love), if you want to use one of the most common mechanisms of algorithm implementation in functional programming, this is tail recursion, you are at your own risk. Sometimes it will work, sometimes it won't. But hey, maybe you are one of those who like to live on the edge. And we don't have data structures requiring thousands or millions of frames in our stacks... Until we do.

Ok, but functional approaches are awful regarding space complexity

Coding tests focus on both time and space complexity: does your algorithm use an awful amount of extra space to deliver its results? How does that extra space grow in relation to the input data? Is it a constant, linear, logarithmic or quadratic relationship? If the functional approach is awful regarding this, doesn't that rule out this approach in favour of the imperative mutable approach?

When you think of functional programming you also usually think of immutability. You use to work with immutable data structures, transforming them in pipelines that in the end produce the desired results. All those transformations usually create intermediate data structures that are created and discarded on the fly, as steps leading you to the final goal.

In the case of recursive algorithms with a divide and conquer strategy you usually pass down chunks of the original input data until you reach some base case that is trivially solved, and then the solution is built up from the bottom. In the case of this problem we are passing down approximately half the input data until we reach the base cases. If we sum all these arrays that we create (?) we get that the space complexity of the functional implementation is O(n). This is, we need additional space that is linearly proportional to the size of the input data. Or maybe not?

Here both Scala and Swift are smart enough to provide mechanisms to avoid this problem:

Swift returns Slices or ArraySlices when performing operations on Arrays that return a chunk of the array (for example prefix(_:) or subscript(_:) with a Range). These are views wrapping an underlying collection that don't use any additional memory to hold their elements, so they have O(1) time and space complexity.
Scala has a similar mechanism, although a bit more explicit. You can see it in the code when we invoke numbers.view: we are creating a view which will wrap the underlying collection, so all the operations will be performed without creating additional structures. In our case we can slice those arrays (well, IndexedSeqViews to be fair) ad infinitum with the certainty that we will remain O(1) compliant.

Conclusion

So yes, maybe the title was a bit of a clickbait, although this is not the only reason why I think Swift still sucks as a real functional language. Anyway if you reached this point you likely agree that the functional approach is way better at conveying the original algorithm definition and:

either you have learnt that Swift isn't suitable to be used as a real functional language unless you want to ditch one of the most common approaches to implementing functional algorithms (tail recursion)
or you know more than me regarding tail recursion optimisation in Swift, in which case I'd love to hear you in the comments!