Here is what we did.

The Starting Point

The site was running on Hugo with the hello-friend-ng theme committed directly into the repository. It had not been touched in years. The Hugo version had moved on significantly, and the build was broken. There were also 10 open Dependabot pull requests and 75 reported vulnerabilities — all from an unused theme.

Fixing a Broken Build

The first problem: hugo --minify failed with errors. Three deprecated APIs had been removed from Hugo since the theme was last updated:

• .Site.Language.Get — removed from Hugo’s language API
• .Site.GoogleAnalytics — moved to site.Config.Services.GoogleAnalytics.ID
• .Site.Author — moved to [params.Author]

Claude diagnosed all three, created layout overrides in layouts/ to fix them without touching the theme directly, and the build passed. This is exactly the kind of yak-shaving that normally eats an hour — reading changelogs, hunting down the right replacement API, checking if the fix actually works.

Cleaning Up Dependabot

The 75 vulnerabilities were all coming from themes/hello-friend — an old theme that was never used. The site used hello-friend-ng. The solution was simple: delete it.

git rm -r themes/hello-friend

That dropped the vulnerability count immediately. Claude also closed all 10 stale Dependabot PRs in one go via the GitHub CLI.

New Domain

I moved from michal.codes to michalkonturek.dev. This meant updating:

• baseurl in config.toml
• The CNAME echo step in the GitHub Actions workflow
• static/CNAME (properly, so Hugo copies it to public/ on every build)
• content/about.md

Claude caught all the references across the repo in one search.

Modernizing the Config

A few housekeeping changes:

• Renamed config.toml to hugo.toml — Hugo’s preferred filename since v0.110
• Removed the deprecated [author] top-level section (now lives in [params.Author])
• Updated the site description to something less dated

Switching the Theme to a Hugo Module

The biggest improvement. Instead of committing the entire theme into the repository, the theme is now a proper Hugo module:

[module]
  [[module.imports]]
    path = "github.com/rhazdon/hugo-theme-hello-friend-ng"

With a go.mod and go.sum tracking the dependency. Updating the theme in the future is now just:

hugo mod get -u && hugo mod tidy

Switching to the module also pulled in a newer version of the theme that had already fixed the deprecated APIs — so the layout overrides we created earlier could be deleted. The repo ended up smaller and cleaner than when we started.

Fixing the Deployment Pipeline

The old workflow (gh.yml) pushed the built site to a master branch, which GitHub Pages then served. GitHub now has a better approach: deploy directly from an Actions artifact without needing a separate branch.

Claude replaced the old workflow with the modern actions/deploy-pages approach, added Go setup for Hugo module support, deleted the now-redundant master branch, created main from develop, and fixed a GitHub Pages environment protection rule that was blocking deployment — all via the GitHub API.

Reflections

The thing that stood out was how Claude handled the layered nature of the problems. Each fix revealed the next issue, and it just kept going — diagnosing, fixing, verifying the build, moving on. No context switching, no tab soup of documentation.

It is not that any individual task was hard. It is that there were a lot of them, they were interconnected, and doing them manually would have meant a lot of stopping and starting. With Claude Code it felt more like pairing with someone who had already read all the changelogs.

The repository is now leaner, the build is clean, and the deployment pipeline is straightforward. A good afternoon’s work.

A decade is a long time in Swift. The language that existed in 2016 (Swift 3.0) is almost unrecognisable compared to Swift 6.0. I decided to bring MKUnits fully up to date, and I did it with AI assistance.

Here is what that looked like.

Where Things Stood

The last commit before this modernisation effort was from November 2016. The library was:

• Written in Swift 3.0
• Distributed via CocoaPods and Carthage
• Tested with XCTest
• Structured as an Xcode-first project

None of these are wrong per se, but none of them are where the Swift ecosystem is in 2026 either.

Swift 3 to Swift 6

The biggest jump. Swift 6 introduced strict concurrency checking — every type that crosses concurrency boundaries must conform to Sendable. The AI worked through the entire codebase, adding Sendable conformance where needed, replacing deprecated APIs, and updating Swift syntax that had evolved across ten major versions.

What makes this particularly tedious to do by hand is that you have to understand why each change is needed, not just what to change. The compiler error messages for Swift 6 concurrency are verbose. Having the AI reason through them systematically meant we got through the migration without getting lost in the noise.

The result was tagged as v5.0.0.

SPM First

CocoaPods and Carthage were the standard in 2016. Swift Package Manager is the standard now. The project was restructured from the ground up as an SPM-first library — proper Package.swift, sensible target layout, no more .xcodeproj as the source of truth.

This also meant the library could now be used on Linux, not just macOS and iOS. A GitHub Actions workflow was added to run tests on both platforms on every push — something that simply was not possible with the old Xcode-only setup.

Tagged as v6.0.0.

XCTest to Swift Testing

Apple introduced Swift Testing as the modern replacement for XCTest. The entire test suite — hundreds of tests — was migrated to the new framework.

The difference is meaningful. Swift Testing uses macros (#expect, #require) instead of assertion functions, has better failure messages, and integrates more naturally with the rest of Swift. Migrating a large test suite by hand is exactly the kind of repetitive structural work that AI handles well. The tests went from this:

func testThatItConverts_1_Kilogram_to_Pound() {
    let sut = MKMass.kilogram(1)
    let result = sut.convert(to: MKMassUnit.pound)
    XCTAssertEqual(result, MKMass.pound(2.20462))
}

To this:

@Test func kilogram_to_pound() {
    let sut = MKMass.kilogram(1)
    #expect(sut.convert(to: .pound) == MKMass.pound(2.20462))
}

Cleaner, more expressive, and all without manually touching each of the hundreds of test cases.

New Units

With the foundation modernised, adding new units became straightforward. Two new unit types were added:

ByteUnit — digital storage conversions: bit, byte, kilobyte, megabyte, gigabyte, terabyte, and the full IEC binary variants (kibibyte, mebibyte, gibibyte, tebibyte).

TemperatureUnit — this one required some thought. Most unit conversions are multiplicative (metres to feet is just a constant factor). Temperature is different — Celsius, Fahrenheit, and Kelvin all have different zero points, so conversion requires both scaling and offset. The AI worked through the maths, implemented offset-based conversion correctly, and added a full test suite to verify it.

A Demo Target

A small command-line executable was added to the package — MKUnitsDemo — that exercises the library and serves as a living example of how to use it. Useful for anyone evaluating the library, and useful as a quick sanity check during development.

Reflections

The thing that struck me most was the speed at which a decade of drift can be addressed. Not because AI writes perfect code — it does not — but because it removes the activation energy. Looking at a 10-year-old Swift 3 codebase and knowing you need to bring it to Swift 6 is daunting. Starting a conversation and just… doing it, step by step, is not.

The AI was particularly good at the mechanical parts: migrating syntax, applying consistent patterns across many files, translating XCTest to Swift Testing. It was less useful for decisions that required judgement — like how to structure the offset-based temperature conversion, or what the right API shape should be. Those conversations happened, but they needed me to push back and think carefully.

MKUnits is now a modern Swift 6 library. It took one session to cover what ten years had left behind.

You begin with creating a Podfile:

pod 'MKUnits', '~> 2.0.0'

and running pod install to install pods in your project.

Nice, so far so good. Cocoapods successfully integrated with Xcode 6 project. All we need to do now is to import our pod header file into Swift project. How do you do that?

Definitely not by adding #import <MKUnits/MKUnits.h> to a Swift file as it would result in this error:

Expected expression
Expected identifier in import declaration

To expose Objective-C files to Swift you must use Objective-C bridging header, as Mix and Match section of Using Swift with Cocoa and Objective-C documentation explains.

To do so, you must create a new Objective-C header file, let’s call it Example-Bridging-Header.h, and add it to the project. Then, you need to set Objective-C Bridging Header for your target:

and finally add import statement to the bridge header:

#import <MKUnits/MKUnits.h>

Voilà! Now you can use your pods in Swift.

let kilograms = NSNumber.mass_kilogram(2)()
let pounds = NSNumber.mass_pound(10)()
let result = kilograms.add(pounds)
println(result)

You can also integrate imported Objective-C classes with Swift types. For example, by creating an extension for Int:

extension Int {

    func mass_kilogram() -> MKQuantity {
        return MKQuantity.mass_kilogramWithAmount(self)
    }

    func mass_pound() -> MKQuantity {
        return MKQuantity.mass_poundWithAmount(self)
    }
}

you can replace previous code with:

let kilograms = 2.mass_kilogram()
let pounds = 10.mass_pound()
let result = kilograms.add(pounds)
println(result)

References

• Swift and Objective-C in the Same Project
• The Swift Programming Language

I required a library that:

• is easily extendable
• has built-in rounding functionality
• is precise up to at least 10 decimal places
• allows manipulation between units of the same group, i.e. kg and pounds, without the need of conversion

Quantity Pattern

Before I started coding, I had a quick read through the chapter of Analysis Patterns by Martin Fowler, which describes the Quantity Pattern. This pattern is extremely useful when you want to represent dimensioned quantities.

The idea behind this pattern is straightforward; it is a class that represents both the amount and the unit, and allows arithmetic behaviour, e.g. addition and subtraction, and conversion to other quantities.

The initial interface for the MKQuantity was:

@class MKUnit;

@interface MKQuantity : NSObject

@property (nonatomic, copy) NSDecimalNumber *amount;
@property (nonatomic, strong) MKUnit *unit;

- (id)initWithAmount:(NSNumber *)amount withUnit:(MKUnit *)unit;

- (instancetype)add:(MKQuantity *)other;
- (instancetype)subtract:(MKQuantity *)other;

- (instancetype)convertTo:(MKUnit *)unit;

- (NSComparisonResult)compare:(MKQuantity *)other;

@end

Also, it’s worth to mention that MKQuantity is a value object.

A value object is a simple object whose equality is not based on identity.

In other words, two value objects are equal if all their attributes are equal. In this case, it is amount and unit.

- (BOOL)isEqual:(id)object {
    if (![object isKindOfClass:[self class]]) return NO;
    if (![[object unit] isEqual:self.unit]) return NO;
    return [self.amount isEqual:[object amount]];
}

- (NSUInteger)hash {
    return [[NSString stringWithFormat:@"%@%@%@",
             [self class], self.unit.symbol, self.amount] hash];
}

MKQuantity is associated with MKUnit:

@interface MKUnit : NSObject<NSCopying>

@property (nonatomic, strong) NSString *name;
@property (nonatomic, strong) NSString *symbol;
@property (nonatomic, strong) NSDecimalNumber *ratio;

- (id)initWithName:(NSString *)name
        withSymbol:(NSString *)symbol
        withRatio:(NSDecimalNumber *)ratio;

@end

The ratio property is used to convert unit to base unit, eg. for Length a base unit is meter, therefore, the ratio for kilometer unit is 1000 as amount_in_meters = 1000 * amount_in_kilometers.

Unit conversion

Since this is a unit conversion library, the first type of a behaviour to be added is conversion.

- (instancetype)convertTo:(MKUnit *)unit {
    [self _assert_that_is_convertible_with_unit:unit];

    id converted = [self.unit convertAmount:self.amount to:unit];
    return [[self class] createWithAmount:converted withUnit:unit];
}

The conversion process of unit A to unit B consists of:

• asserting that unit A is convertible with unit B

- (void)_assert_that_is_convertible_with_unit:(MKUnit *)unit {
    NSAssert(
      [self.unit isConvertibleWith:unit],
      UNITS_NOT_CONVERTIBLE
      );
}

The aim is to perform conversion and arithmetic operations not only on the same units, but also on the other units of the same quantity, eg. adding 500 pounds to 2.5 kilograms should be allowed, but adding 500 grams to 1 meter should not.

- (BOOL)isConvertibleWith:(MKUnit *)unit {
    return [unit isMemberOfClass:[self class]];
}

• converting amount of unit A to amount of unit B

Firstly the amount of unit A must be converted to amount of base unit, and then the result is converted to amount of unit B.

- (NSNumber *)convertAmount:(NSNumber *)amount to:(MKUnit *)unit {
    return [self convertAmount:amount from:self to:unit];
}

- (NSNumber *)convertAmount:(NSNumber *)amount
                       from:(MKUnit *)from to:(MKUnit *)to {
    NSAssert([from isConvertibleWith:to], UNITS_NOT_CONVERTIBLE);

    id baseAmount = [from convertToBaseUnit:amount];
    id converted = [to convertFromBaseUnit:baseAmount];
    return converted;
}

• creating new Quantity object of unit B with converted amount

This is due general consensus that a Value Object should be entirely immutable.

Arithmetic

Addition and subtraction operations of two quantities are allowed as long as their units are convertible.

- (instancetype)add:(MKQuantity *)other {
    MKQuantity *converted = [other convertTo:self.unit];
    id amount = [self.amount decimalNumberByAdding:converted.amount];
    return [[self class] createWithAmount:amount withUnit:self.unit];
}

- (instancetype)subtract:(MKQuantity *)other {
    MKQuantity *converted = [other convertTo:self.unit];
    id amount = [self.amount decimalNumberBySubtracting:converted.amount];
    return [[self class] createWithAmount:amount withUnit:self.unit];
}

NB As this is a unit conversion library, we should only allow multiplication and division by scalar numbers.

If you would like to know more, please visit MKUnits GitHub repository.

I am @michalkonturek on Twitter.

Looking forward to your feedback.