These aren't simple chatbots anymore—these AI agents access data and tools and carry out tasks, making them infinitely more capable and dangerous.

The post OWASP Drops First AI Agent Risk List appeared first on TechRepublic.

This is the second guest post in a two-part series from José Luis González. José Luis has a PhD in software development and is a JetBrains-certified Kotlin Trainer, who works with developers and engineering teams to deepen their Kotlin skills and apply the language effectively in real projects. At Hyperskill, he runs Kotlin instructor-led training for teams at Hyperskill that focus on advanced topics and practical problem-solving rather than theory.

First post in the series: How Backend Development Teams Use Kotlin in 2025: Insights from a Certified Trainer

I’d probably have to say swallowing CancellationException in general catch blocks (including runCatching). It looks harmless, but it disables cooperative cancellation, so timeouts, parent scopes, and lifecycles keep running “mysteriously.” In recent talks, linters, and guides, you still see this called out as a real-world production bug. Official docs stress that cancellation must propagate, detekt ships a rule warning if you don’t rethrow, and the coroutines library provides mechanisms that avoid catching CancellationException in generic catch-alls.

Use the following pattern instead to always rethrow cancellations (or choose a helper that preserves them):

suspend fun <T> safeCall(block: suspend () -> T, fallback: () -> T): T = try {
    block()
} catch (e: CancellationException) {
    throw e // never swallow cancellation
}
// catch other specific exceptions
} catch (e: Exception) {
    logger.error("call failed", e)
    fallback()
}

If you like Result-style API, mirror the kotlinx approach as follows:

suspend inline fun <T> runSuspendCatching(block: () -> T): Result<T> =
    try { Result.success(block()) }
    catch (e: CancellationException) { throw e }
    catch (e: Throwable) { Result.failure(e) }

This tiny rethrow keeps structured concurrency intact and matches the guidance you’ll hear in the latest coroutine discussions.

2. If a team has only two hours to set up monitoring for their mobile Kotlin app, which specific dashboards should they prioritize?

Begin with metrics that indicate whether users can successfully use the app. Crash-free users and ANR rate by version and device model tell you whether a release is safe to ship.

Firebase Crashlytics handles this out of the box – just tag builds for quick filtering:

FirebaseCrashlytics.getInstance().setCustomKeys {
    key("version", BuildConfig.VERSION_NAME)
    key("commit", BuildConfig.GIT_SHA)
}

As for UI issues, use JankStats to log when and where frames drop, so you know which screens stutter:

val jankStats = JankStats.create(window) { frame ->
    if (frame.isJank) Log.d("Jank",
        "Jank on ${currentScreen()} – ${(frame.frameDurationUiNanos / 1_000_000)}ms")
}
jankStats.isTrackingEnabled = true

Another main concern is performance, of course. With Sentry, you get end-to-end insights into what is actually slowing down your app: startup, navigation, network calls, etc. It correlates frontend and backend timing so you can spot bottlenecks and regressions fast.

Here is a standard setup with tracing and profiling:

SentryAndroid.init(this) { options ->
    options.dsn = "<dsn>"
    options.tracesSampleRate = 0.1
    options.profilesSampleRate = 0.05
    options.release = "${BuildConfig.VERSION_NAME} (${BuildConfig.VERSION_CODE})"
    options.environment = BuildConfig.BUILD_TYPE
}

Now, let’s add some custom transactions for key flows:

val tx = Sentry.startTransaction("screen:${currentScreen()}", "ui.load")
Sentry.configureScope { it.setTransaction(tx) }

val net = tx.startChild("http.client", "GET /api/items")
try { /* network call */ } finally { net.finish() }

val db = tx.startChild("db.query", "SELECT items")
try { /* read */ } finally { db.finish() }

tx.finish()

And auto-tracing for network calls (OkHttp and Ktor):

OkHttp:

val client = OkHttpClient.Builder()
    .addInterceptor(SentryOkHttpInterceptor())
    .build()

Ktor:

val client = HttpClient(CIO) {
    install(Sentry) {
        tracesSampleRate = 0.1
        profilesSampleRate = 0.05
    }
}

Sentry Mobile Insights provides a prebuilt dashboard for this. It groups slow transactions and crash-free rate by release and device model, so you can see exactly where users struggle the most without the need for a custom setup.

Here’s how a real trace looks in Sentry: You can see a cold start (app.start.cold), API calls, and rendering time, all visualized in one timeline, for a detailed breakdown of how much time the app spends on various tasks.

Check these dashboards in Sentry:

• Performance / Transactions: p95 duration for app.start.cold, ui.load, and checkout.
• Traces / Slow spans to find lags in HTTP, database, or main-thread work.
• Releases / Crash-free and ANR: Correlate stability with performance.

Sentry (or Crashlytics) combined with JankStats will give you the full picture. Can users open the app, interact smoothly, and exit without crashes or leaks? Sentry covers both performance and crash tracking, so you can often use it alone, while Crashlytics remains a lightweight alternative many teams already have in place.

3. When a mobile Kotlin application is running slowly in production, what are your top three profiling techniques, and what tools do you use for each?

I wouldn’t say there’s anything groundbreaking here. I usually start with the same baseline we talked about earlier: Crashlytics, JankStats, and Sentry traces. They will provide a comprehensive overview of what’s going on. From there, my top three profiling techniques are pretty straightforward but extremely effective.

Honestly, the standalone Android Studio profiler is still the most powerful and underrated tool out there. I spend most of my time in its CPU and memory profilers, checking which methods block the main thread or which allocations spike during transitions. I always check the Sample Call Stack view, as it’s the fastest way to see where time is actually spent per frame, instead of guessing from logs.

It sounds basic, but it often reveals that a single RecyclerView binding or JSON parser allocates thousands of tiny objects per frame.

Also, I would typically do network profiling. Using the Network Inspector or Sentry’s tracing, I check which requests block rendering or input. If scrolling freezes when images load, you can immediately tell whether it’s an uncompressed call or a missing cache layer without guessing. If you’ve already enabled Sentry Performance in the Monitoring section of the settings menu, it doubles as lightweight production profiling. You can literally see slow transactions by endpoint.

Frame-time profiling is something that comes in handy as well. I like using JankStats or even adb shell dumpsys gfxinfo to see which screens consistently drop frames. Then I pair that with LeakCanary to catch activities or bitmaps that stay alive longer than they should. Together, that tells me exactly what’s slowing the UI down.

In short, you don’t really need fancy tools. CPU, memory, network, and frame-time profiling, all within Android Studio, cover about 90% of the real issues. These profiling tools help identify what’s making the app feel slow, so you can easily fix the underlying problems. 

4. When teams ask about Kotlin Multiplatform, what’s the smallest project they should start with to prove the concept?

I usually remind teams that they’re probably using Kotlin Multiplatform already. Libraries like kotlinx.coroutines or kotlinx.serialization are basically multiplatform under the hood. You’re just using them from Android today, but they work the same on iOS, too.

The smallest realistic project to actually prove Kotlin Multiplatform in your environment is a shared data or utility layer – something both applications can call without touching the UI. A great first step is to share one simple function, like returning the current time or a version string:

// commonMain
expect fun currentTime(): Long

// androidMain / iosMain
actual fun currentTime() = System.currentTimeMillis() // or NSDate().timeIntervalSince1970

Here’s how to connect the Kotlin framework generated from the Kotlin Multiplatform project to your Xcode project:

The embedAndSignAppleFrameworkForXcode task only registers if the binaries.framework configuration option is declared. In your Kotlin Multiplatform project, check the iOS target declaration in the build.gradle.kts file.

kotlin {
    ios() // or iosArm64(), iosX64(), iosSimulatorArm64()
    binaries {
        framework {
            baseName = "Shared"
        }
    }
}

To automatically build a shared module in Xcode, you need to add a script. In the Build Phases tab, add a run script with the following code:

cd "$SRCROOT/.."
./gradlew :shared:embedAndSignAppleFrameworkForXcode

Using the specified script, access the Gradle task to create and embed the library into the native iOS application.

Then you should move the Run Script phase higher, placing it before the Compile Sources phase.

After running the build on the iOS app side or iosApp configuration from the Kotlin Multiplatform project, the compiled xcode-frameworks will appear in the build folder of the shared module.

This will generate the framework at:

Then import it into Swift:

import Shared

let t = currentTime() // works directly from the shared Kotlin code

If that builds and runs cleanly, you’ve already proven that Kotlin code can compile and interop on both sides. From there, you can expand to something slightly more useful. For example, a shared module that fetches and parses a list of items using Ktor and kotlinx.serialization.

Understanding how actions are sequenced when building or customizing Windows Installer (MSI) packages is essential. [...]

Starting with Advanced Installer version 23.0, you can bundle multiple applications into an installer that acts as an application store, allowing your users to choose which app to install. [...]

---

What are the advantages of spec-driven development compared to vibe coding with an LLM? Are these recent trends a move toward declarative programming? This week on the show, Marc Brooker, VP and Distinguished Engineer at AWS, joins us to discuss specification-driven development and Kiro.

Marc describes the process of developing an application by writing specifications, which outline what a program should do and what needs it should meet. We dig into a bit of computer science history to explore the differences between declarative and imperative programming.

We also discuss Kiro, a new integrated development environment from Amazon, built around turning prompts into structured requirements. We examine the various types of documents used to specify tasks, requirements, design, and steering.

Topics:

• 00:00:00 – Introduction
• 00:02:41 – How did you get involved in open source?
• 00:07:23 – How would you describe spec-driven development?
• 00:10:49 – Balancing the desire to start coding with defining the project
• 00:13:06 – What does this documentation look like?
• 00:18:27 – Declarative vs imperative programming
• 00:24:13 – Infrastructure as part of the design
• 00:27:03 – Getting started with a small project
• 00:29:05 – Committing the spec files along with the code
• 00:31:08 – What is steering?
• 00:34:17 – How to get better at distilling specifications?
• 00:38:59 – What are anti-patterns in spec-driven development?
• 00:41:08 – Should you avoid third-party libraries?
• 00:43:16 – Real Python Resource Spotlight
• 00:44:39 – Getting started with Kiro
• 00:51:00 – Neuro-symbolic AI
• 00:55:41 – What are you excited about in the world of Python?
• 00:58:36 – What do you want to learn next?
• 01:00:18 – How can people follow your work online?
• 01:00:57 – Thanks and goodbye

Show Links:

• Kiro and the future of AI spec-driven software development - Kiro
• Marc Brooker’s Blog - Marc’s Blog
• Kiro: The AI IDE for prototype to production
• Beyond Prompts: The Future of AI-Assisted Development | Marc Brooker - YouTube
• Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
• Declarative programming - Wikipedia
• Behaviour-Driven Development - Cucumber
• Steering - Docs - Kiro
• Best practices - Docs - Kiro
• CLI - Kiro
• Does your code match your spec? - Kiro
• Amazon takes on AI’s biggest nightmare: Hallucinations - Fast Company
• Neuro-symbolic AI - Wikipedia
• Spec-Driven Development: The Waterfall Strikes Back
• G-code - Wikipedia
• Marc Brooker (@MarcJBrooker) / X
• Marc Brooker (@marcbrooker@fediscience.org)
• Marc Brooker - LinkedIn

Level up your Python skills with our expert-led courses:

• Getting Started With Claude Code
• First Steps With LangChain
• Building a Neural Network & Making Predictions With Python AI

Support the podcast & join our community of Pythonistas

Download audio: https://dts.podtrac.com/redirect.mp3/files.realpython.com/podcasts/RPP_E277_02_Marc_2.e9e0f5048263.mp3