Forem: Iván Garza Bermea

On the Programmer’s Dependency on LLMs

Iván Garza Bermea — Mon, 20 Apr 2026 07:00:00 +0000

How many of you are using AI as a coding assistant? Most importantly, how many of you have felt a newfound dependency on these tools?

Whether it is Claude Code, Cursor, Copilot, or any other coding assistant whose name may start with the letter ‘C’—or doesn’t—leveraging these tools really brings a boost of productivity. As engineers, working better, faster and stronger, is preferable, as opposed to working harder.

But, have you felt the dependency on these tools creeping in?

Let me paint a scenario for you:

You start your coding session, you boot up your preferred coding assistant, and for the first hour or two, everything is going great: You’re switching models for different tasks, you’re planning ahead, and consciously taking care of that precious token count. You’ve got a flow-state going, the feature is basically writing itself through this freshly modern superpower. And then, you encounter something like this:

Claude usage limit reached. Your limit will reset at <later>

Suddenly, doubt inundates your mind. You hear a voice in the back of your head announcing “this session is over.” You find yourself in an impasse, a fork in the road: Continue working by hand, or wait for the usage limit to reset.

This is the dependency I’m talking about. That feeling of laziness, sloth, perhaps even partial impotence that arises when we have to get back to working by hand, instead of reaping the benefits of the thinking machine. This is the frustration that arises when our instrument of labour is suddenly retracted, and we are forced to rediscover our own capacity.

The dependency is real, novel, and I’ve seen it not only in myself, but a few other engineers that I have talked to.

On the Deskilling of the Worker

In his 1st volume of Capital, Marx talks about a similar phenomenon that he observed during the dawn of the Industrial Revolution—He calls this the deskilling of labourers.

“Along with the tool, the skill of the worker in handling it passes over to the machine. The capabilities of the tool are emancipated from the restraints inseparable from human labour-power (p. 545).”

Marx predicted that the over-reliance on tools inevitably makes the workforce dumber, or that it “does away with the many-sided play of the muscles, and confiscates every atom of freedom, both in bodily and in intellectual activity (p. 548).”

He defines the change in the labour relations between humans and machines as being one out of two very distinct options: In the first option, the “worker appears as the dominant subject, and [the machine] as the object.” In the second option, it is the machine that is the subject, and the “workers are merely conscious organs, co-ordinated with the unconscious organs of the [machine], and together with the latter subordinate to the central moving force (pp. 544-545).”

Evidently, we want to keep ourselves as the subject of our own labour; rather than become a mere appendage of these emerging artificial agents.

“The machine makes use of him […] it is the movement of the machine that he must follow (p. 548).”

He also anticipated that through this deskilling of the worker, our ability to sell ourselves and find a job might plummet alongside it. Or more precisely, when “it becomes the job of the machine to handle [the work], the use-value of the worker’s labour-power vanishes, and with it its exchange-value (p. 557).” This would inevitably create competition between the worker and the machine—but I’d rather focus on that topic alone in a future article!

Is There a Solution?

So, how do we fight back this deskilling phenomenon? We stay curious, thirsty, and more importantly, we continue to learn and to grow.

For a seasoned engineer, this prognosis is not new; it’s a requirement we’ve accommodated through our years of experience. But for the younger generation—those that have grown accustomed and build up their careers through the invisible guiding hand of the machine—they might be the ones that need to stay more vigilant.

Therefore, the next time we see this message appear in our Terminals:

Weekly limit reached · resets <later>

We ought to see it as an opportunity to practice the sleight of hand, and resume our hard-fought battle for agency and non-dependency against the machine.

UPDATE ALERT: barK now fully supports iOS for KMP! 🚨 Read all about how to implement barK into your iOS library, and feel free to check out my previous article to learn more about the Android side of things!

Iván Garza Bermea — Tue, 14 Apr 2026 17:49:31 +0000

Iván Garza Bermea

Apr 14

barK: iOS Logging in KMP

#kotlin #kotlinmultiplatform #ios #mobile

Comments

5 min read

barK: iOS Logging in KMP

Iván Garza Bermea — Tue, 14 Apr 2026 17:47:01 +0000

A few months ago I introduced the world to barK, a light-weight KMP logging library I created while I was interviewing through the summer.

In my first article, I used Android to showcase all of the features as well as example usage. Most of the information in that piece is still relevant. But after a few months of development, that initial article starts getting a little bit outdated. And most importantly, I never covered iOS!

Therefore, for this article I will present an updated version of the initial setup — barK has since migrated from Jitpack to Maven — as well as basic usage for the iOS side of a KMP project.

NOTE: barK only works for iOS KMP, and not for regular iOS applications!

Setting Up

Setting up barK for iOS usage in KMP begins the same way as any other KMP library integration: by bringing in the Maven dependency into your gradle.build.kts. Next, we explicitly export the barK library into the iOS framework. Finally, we’ll create a BarkExtensions.swift file inside Xcode so the iOS project has a clean, idiomatic interface.

Gradle Setup

Let’s begin with the Gradle setup. To get started, integrate the barK library in your project using either the a libs.versions.toml or directly in your build.gradle.kts Gradle build file.

// libs.versions.toml
[versions]
...
bark = <version>

[libraries]
...
bark = { module = "com.ivangarzab:bark", version.ref = "bark" }

// build.gradle.kts
dependencies {
    ...
    implementation(libs.bark)
}

Then, find your iOS framework declaration — most likely in the :shared module — and directly export the the library into iOS for access.

listOf(
    iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach { iosTarget ->
        iosTarget.binaries.framework {
            baseName = "Shared"
            isStatic = true
            ...
            export(libs.bark)
        }
    }

This is done so that the iOS app has visibility over the barK types.

NOTE: You’ll probably want to implement the barK library in the same module that you declare your iOS framework!

barK Extensions

The second part of the set up is to create a new file on the iOS project called BarkExtensions.swift as to enable clean and safe usage of the barK library.

The /ios directory inside the barK GitHub repository has further instructions on how this part work. But the gist is to bring in the /ios/BarkExtensions.swift file into the KMP iOS app.

For example, one my side-projects has it located at: iosApp/project/iosApp/BarkExtensions.swift.

Features

With the project set up, let’s take a quick look at the three main features that barK offers: Tagging, Training & Logging. I will make the effort to point out any differences that the iOS implementation may have with Android, as to fully elucidate the iOS capabilities and how it differs to its counterpart.

Tagging

We’ll begin with Tagging. There are two main ways that barK manages log tags for iOS: You can, (1) enable the tag auto-detection feature, or (2) set your own global tag.

Tag Auto-Detection

Differently to Android, barK doesn’t automatically add the class name into its logs on the iOS side. This is actually an optional feature that needs to be enabled manually; at least for iOS classes!

Bark.autoTagDisabled = false

The Bark.autoTagDisabled flag controls whether the iOS version of barK will be automatically including tags or not. The reason why this flag defaults to Off, is because generating tags on the iOS side is rather costly.

Global Tag

On the other hand, barK also accepts a global tag to be set across the board, same as it does on the Android side.

Bark.tag("Global tag")

By calling the .tag() function of the BarkExtensions.swift wrapper, you can set a global tag at any point of the app. It is also possible to .untag() the global instance, and get back to normal usage.

NOTE: Global tags would override the auto-detection feature, so make sure you don’t mix and match!

Training

Moving on to Training, the barK system requires to be ‘trained’ as to know what to log, and where to send these logs. Calling Bark.train(Trainer) will get that done . This function can be called multiple times in order to add multiple trainers to the global instance.

You can also Bark.untrain(Trainer) or Bark.releaseAllTrainers() to clean up Trainercapabilities.

static func train(trainer: Trainer)
static func untrain(trainer: Trainer)
static func releaseAllTrainers()

Logging

Finally, with Tagging & Training taken care of, we can now focus on Logging.

static func v(message: String, throwable: Error? = nil)
static func d(message: String, throwable: Error? = nil)
static func i(message: String, throwable: Error? = nil)
static func w(message: String, throwable: Error? = nil)
static func e(message: String, throwable: Error? = nil)

Logging in iOS works exactly the same as in Android.

Bark.d("Your log")

The log levels that barK uses are Android-centric, in order to better fit the Kotlin shared layer, and avoid overfitting solutions.

Muzzling

BarK also offers a simple way of ‘muzzling’ (or muting) the library during runtime, by simply calling the muzzle() function.

static func muzzle()
static func umuzzle()

NOTE: This function can be particularly useful when dealing with flows containing sensitive data, for example.

Example Usage

With the library integrated, and the features explained, we will now take a look at usage. The following block shows a typical init & implementation of the barK library on iOS.

@main
struct iOSApp: App {

    init() {
        ...
        startLogging()
    }

    private func startLogging() {
        #if DEBUG
        let volume = Level.verbose
        #else
        let volume = Level.debug
        #endif

        Bark.autoTagDisabled = false
        Bark.train(trainer: NSLogTrainer(volume: Level.verbose))
        Bark.v("Bark has been initilized for iOS successfully!")
    }
}

Notice that we’re setting the volumeLevel of the Trainer based on whether we’re running a DEBUG or production build.

Moreover, we’re enabling the autoTagDisabled flag so that we can get automatic tag detection.

Next, we’re doing a simple .train() call using the built-in NSLogTrainer receiving the volume Level from before.

At the end, we’re doing a single .v() call to print our first log, indicating that barK has been initialized successfully!

Afterthought

We have now seen how barK works for KMP iOS applications!

The idea behind barK is not only to make logging easier to client applications, but also for SDK libraries and their integrating clients as well.

Therefore, I will publish another article diving deeper into SDK usage.

And once again, feel free to check out the first article of this series for the Android implementation.

For now, let me know what you think of this little passion project of mine. And keep those Android + iOS apps barking loudly!

barK: Because every log deserves a good home. 🐶🏠

Resources

GitHub: https://github.com/ivangarzab/barK
Maven Central Repository: https://central.sonatype.com/artifact/com.ivangarzab/bark
First barK article: barK: A Lightweight Logging Library for Android

barK: A Lightweight Logging Library for Android

Iván Garza Bermea — Sat, 06 Sep 2025 14:00:00 +0000

Today, I would like to introduce a project I’ve been working on these last few weeks: barK. A lightweight logging library for Android and Kotlin Multiplatform projects.

The idea behind barK came to me very recently while working on an SDK. I noticed that neither android.util.Log nor some of the popular logging libraries, were addressing all of my needs at once:

To be able to turn off logs for release builds;
To call android.util.Log during regular runs, but use print() during unit test runs;
To allow for integrating clients to leverage the logging solution, edit it, or mute it entirely.

As such, barK was conceived: A lightweight logging library, written in Kotlin for Android and KMP projects. This library is capable of being turned off easily for release builds, muted by integrating clients at will, and is able to use print() statements during unit test runs enabling maximal debugging capabilities all around.

In this article, I will introduce barK, while focusing on the Android side of the implementation. I will highlight some of the main features that are currently available, and close it off with an example on how to get started logging with the barK library!

Features

Let’s start talking about features. There are three main aspects behind barK that I intend to cover for this article: Tagging, Training & Logging.

Tagging

We’ll begin with tagging. BarK manages log tags in two different ways: Either you (1) allow the default, auto-detection tag feature to take care of tagging, or (2) you set your own global tag for the entire logging strategy.

Tag Auto-Detection

By default, the barK library automatically detects the calling class, and uses such class’ name as the tag for all the logs inside it.

class MainActivity {
    override fun onCreate() {
        super()
        Bark.d("MainActivity onCreate()") // tag: MainActivity
}

class LoggingRepository {
    init {
        Bark.v("Tag is automatically detected") // tag: LoggingRepository
    }
}

Global Tag

On the other hand, setting a global tag on the barK instance will override the tag auto-detection feature.

class MainActivity {
    override fun onCreate() {
        super()
        Bark.tag("MyApp")
        Bark.d("MainActivity onCreate()") // tag: MyApp
}

class LoggingRepository {
    init {
        Bark.v("Tag is automatically detected") // tag: MyApp
    }
}

On the contrary, calling Bark.untag() will revert the global tag utility, and switch back to detecting the calling class’ tag automatically.

fun tag(globalTag: String)
fun untag()

Training

The Bark system requires being ‘trained’ in order to know how to deal with the incoming logging request.

fun train(trainer: Trainer)
fun untrain(trainer: Trainer)
fun releaseAllTrainers()

Bundled Trainers

As such, the barK library provides a series of pre-made Trainer classes to get started.

// Android-specific Trainers
AndroidLogTrainer() // use android.util.Log to logs
AndroidTestTrainer() // use android.util.Log to log, even on test runs
UnitTestTrainer() // use print() to log
ColoredUnitTestTrainer() // use print() to log with colored levels

All trainers come with bothpack: Pack and volume: Level fields, meant to define what pack they belong to (see below) and how best to discriminate between the different types of logs.

interface Trainer {
    val volume: Level
    val pack: Pack
    fun handle(level: Level, tag: String, message: String, throwable: Throwable?)
}

Trainer’s Pack

Trainers in barK all belong to a Pack, and this field is used to distinguish between the different output types of each logging style.

Where, CONSOLE logs to the environment console using print() statements; SYSTEM logs using the platform’s main logging library, such as Android’s android.util.Log, or iOS’s NSLog; FILE denotes writing to a file; finally, CUSTOM is an open type, envisioned to be used for any other kind of Trainer.

enum class Pack { 
    CONSOLE, // Logs to the environment console [print()]
    SYSTEM, // Logs to the platforms logging library [android.util.Log]
    FILE, // Logs to a file writter system
    CUSTOM // Custom loggers that allow for duplicative trainers
}

The Bark system uses the trainers’ Pack field to avoid having duplicative Trainer objects logging to the same output at once. All but the Pack.CUSTOM type, which is capable of having multiple Trainer instances of the same Pack at once inside Bark; this allows for maximum flexibility and customability for integrating clients.

Custom Trainers

Moreover, barK’s Trainer interface can be implemented to create custom trainers.

// Example: Custom trainer for capturing warnings and errors
class CustomErrorTrainer(
    override val volume: Level = Level.WARNING,
) : Trainer {
    override val pack: Pack = Pack.SYSTEM

    override fun handle(level: Level, tag: String, message: String, throwable: Throwable?) {
        if (level.ordinal >= volume.ordinal) {
            // Handle error
        }
    }
}

// Example: Custom trainer to send Slack messages
class SlackTrainer(
    override val volume: Level = Level.INFO,
    private val webhookUrl: String
) : Trainer {
    override val pack: Pack = Pack.CUSTOM

    override fun handle(level: Level, tag: String, message: String, throwable: Throwable?) {
        if (level.ordinal >= volume.ordinal) {
            // Send to Slack
        }
    }
}

These trainers can belong to any Pack, based on what kind of output they envision to log to, and how they get affected by the rule on duplicate trainers.

Furthermore, custom trainers may also update their volume Level, and handle() their incoming log messages as they see fit.

Logging

Finally, and with the tagging and training taken care of, logging ends up being pretty straightforward with the barK library. Similarly to android.util.Log — or your favorite plant-based logging library — logging consists of calling the Bark class with one of its logging functions.

fun v(message: String, throwable: Throwable? = null)
fun d(message: String, throwable: Throwable? = null)
fun i(message: String, throwable: Throwable? = null)
fun w(message: String, throwable: Throwable? = null)
fun e(message: String, throwable: Throwable? = null)

Muzzling

BarK also offers a simple way of ‘muzzling’ (or muting) the library during runtime, by simply calling the muzzle() function.

fun muzzle()
fun umuzzle()

NOTE: While this function is similar to not training your Bark instance, or untraining, muzzling during runtime could be particular useful when dealing with flow containing sensitive data, for example.

Example Usage

With the main barK API now defined, let’s now see how to integrate the barK system into your own application!

Initialization

First, update your Gradle’s dependency resolution repositories block so that it can fetch from JitPack’s Maven integration.

// dependencyResolutionManagement
repositories {
    maven { url = uri("https://jitpack.io") }
}

Next, add the dependency into your app’s Gradle build file (build.gradle.kts or build.gradle) using the appropriate version of the library.

// build.gradle.kts
dependencies {
    ...
    implementation("com.ivangarzab:bark:<version>")
}

// build.gradle
dependencies {
    ...
    implementation 'com.ivangarzab:bark:<version>'
}

You can find the latest releases and its notes in barK’s GitHub repository.

Logging in Android

With the library’s dependencies settled, we’re now ready to start logging inside our Android app!

Simply, train your Bark instance so that it knows it should start working.

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        // DEBUG builds logs from Level.DEBUG and up;
        // optionally, RELEASE builds log Level.WARNING.
        Bark.train(AndroidLogTrainer(
            volume = if (BuildConfig.DEBUG) Level.DEBUG else Level.WARNING
        ))
        Bark.d("barK has been set up successfully")
    }
}

And start barking those logs!

Bark.d("This is our first log!")
Bark.w("Something is not going well...")
Bark.e("We've found an error!")

Logging in Android’s Unit Test runs

Similarly, barK can be used to log to the console while running unit tests.

In order to set up logs during unit test runs, make sure to train your Bark instance on the test cases that you want to see logs for.

@Before
fun setup() {
    Bark.releaseAllTrainers() // Release all trainers for a clean run
    Bark.train(
        UnitTestTrainer(volume = Level.DEBUG)
    )
    Bark.d("barK has been set up for unit tests succesfully")
}

NOTE: Logging during test runs will print ALL of your logs; that includes the main code’s logs, as well as anything you add for each particular test case. Thus, giving you maximal visibility over your application’s execution.

Afterthought

I have now introduced the barK library, as a lightweight logging solution for Android and KMP projects.

The idea behind barK is not only to make logging easier to client applications, but also for SDK libraries and their integrating clients.

Therefore, I will publish another article diving deeper into SDK usage.

Similarly, barK was also made with console printing in mind for unit test, as well as CI/CD runs. Thus, I shall publish yet another entry focusing on barK’s advantages in unit tests as well.

And lastly, barK is still in development, so full iOS support will have to come at a later time.

For now, let me know what you think of this little passion project of mine in the comments, and feel free to request any features (or fixes!) directly in the GitHub repo.

Thank you all for reading this far 🖤

barK: Because every log deserves a good home. 🐶🏠

👾 My profile 👾 | 🐺 My Website 🐺 | 🔗 All my links 🔗

Resources