Forem: Ted Hagos

The 5 Rules for Not Breaking Production with AI

Ted Hagos — Sat, 31 Jan 2026 13:07:01 +0000

Look, we've all done it. You ask ChatGPT for a "quick helper function," it dumps 50 lines of code that looks legit, you paste it in, and—boom—CI is red and your PR is getting roasted.

I've been writing about AI tooling for my book, and I've definitely learned some of this the hard way. Here's what's been keeping me out of trouble (mostly) when working with these tools:

1. AI suggestions are drafts, not gospel.

Think of them like that one coworker who's really confident but wrong 30% of the time. It's a starting point. That's it.

2. Ignore the confidence.

AI doesn't second-guess itself. It'll hallucinate an entire API that doesn't exist and sound completely sure about it. Don't fall for it.

3. Small changes beat big rewrites.

Debugging 5 lines you tweaked? Easy. Debugging 500 lines of AI slop you don't fully understand? That's how you spend your weekend.

4. If you don't understand it, don't merge it.

Seriously. If the logic feels like magic, it's not clever—it's a time bomb. You can't maintain what you can't explain.

5. You own the commit.

The AI isn't getting paged at 3 AM when the site's down. You are. Act like it.

Bottom line: AI makes typing faster, but it doesn't make thinking optional.

So—what's your vibe check process for AI code? How are you catching the sketchy stuff before it ships? Drop your war stories below.

I'm not Sure, but Here's a Guess

Ted Hagos — Mon, 06 Oct 2025 14:52:38 +0000

Sometimes AI reminds me of my younger self — confidently wrong.

I once asked an AI to explain something it clearly didn’t understand.
It replied with total certainty, fancy words, and zero hesitation.

To be fair, that’s exactly how I sounded in my first decade of coding.

Maybe the upgrade we need isn’t more data — it’s teaching AI to say,
“I’m not sure, but here’s a guess.”

Do you think humility belongs in machine learning?

Recipe: Immutable Data Updates with Kotlin

Ted Hagos — Mon, 29 Sep 2025 15:40:15 +0000

Got a data class? Great! They give us a magical copy() method for free. Combine that with Kotlin's awesome scope functions like apply or also, and you've got a super-clean way to modify objects without actually modifying them. This means fewer bugs and safer concurrency!

Let's say we have a User with a profile image.

data class User(
    val id: String,
    val name: String,
    val email: String,
    val profileImageUrl: String? = null, // Can be null
    val isActive: Boolean = true
)

Now, imagine we need to update a user's profile image and perhaps deactivate them. Instead of directly changing properties (which is fine for var but less safe), we can create a new User instance with just the changes.

fun main() {
    val initialUser = User(
        id = "user123",
        name = "Alice Wonderland",
        email = "alice@example.com",
        profileImageUrl = "http://old-image.com/alice.jpg"
    )

    println("Initial User: $initialUser")

    // --- The Recipe ---

    // 1. Update profile image and deactivate using copy() + apply
    val updatedUser = initialUser.copy(
        profileImageUrl = "http://new-image.com/alice_v2.jpg"
    ).apply {
        // 'this' refers to the NEWLY CREATED user object
        isActive = false // Note: 'isActive' would need to be 'var' for this direct assignment
    }

    // Better for val properties: use another copy() or constructor if needed
    // For val properties, if you truly want to make multiple changes to the *new* object
    // within a single flow, you might do something like this (more lines but fully immutable):
    val fullyImmutableUpdatedUser = initialUser.copy(
        profileImageUrl = "http://new-image.com/alice_v2.jpg"
    ).copy(isActive = false) // Chaining copy() calls for multiple immutable updates


    println("Updated User: $fullyImmutableUpdatedUser")
    println("Did initialUser change? ${initialUser.isActive} (No, it's still true!)")

    // Let's activate someone else with a simpler update
    val inactiveUser = User(id = "bob456", name = "Bob Builder", email = "bob@example.com", isActive = false)
    val activatedUser = inactiveUser.copy(isActive = true)
    println("Activated User: $activatedUser")
}

What happened here?

initialUser remains unchanged thanks to data class and copy().
copy() creates a brand-new User object, letting us specify only the properties we want to change.
The original initialUser is still isActive = true, proving the immutability!

This pattern is fantastic for maintaining state in complex apps, especially when dealing with databases, network responses, or multi-threaded environments. Embrace immutability for cleaner, safer code!

If I knew then what I know now

Ted Hagos — Fri, 05 Oct 2018 02:24:15 +0000

Yesterday, there's a discussion (here at dev.to) on "What is your best advise to a junior software developer".

Article No Longer Available

I responded with 15-item, somewhat, tounge-in-cheek, list. Apparently, some people liked it. So, here it is now in post form, shareable and all.

Ted Hagos • Oct 4 '18 • Edited

If I have Doc Brown's DeLorean, this is what I would advise my younger self

Keep your head down during code reviews. Humility goes a long way. They're not criticizing you, it's your code they're after. It's not personal
Do the required reading before you get knee-deep in the code. You have a propensity to shoot from the hip, curb that enthusiasm. Don't read the manual only when you're in trouble
Design patterns are nice, but you don't have to use all of them, all the time in every code you write
Learn Python early. Get to the Python REPL and type import this. Learn it by heart, then read no. 3 (above) again
Coffee, pizza and chips are nice now, but 20 years from now, you're gonna wish you didn't eat those
In a couple of years, social media is gonna be big. Stay out of it
Those math subjects you hated, better get more comfortable with them. There's gonna be a thing called "machine learning", it's gonna be big, you're gonna need them maths
Stop wondering when you will graduate from being a junior, you'll know it when you're out of it. When you start making technical choices and you recognize that there are choices to be made; then you're not so junior anymore
Be polite when asking questions. If you don't want to get the RTFM response (a lot), read Eric Raymond's guide on how to ask smart questions
When you go to a meeting, always bring a pen and paper. Write your notes
If it's taking you more than 3 hours to figure out something, ask for help, tell your tech lead what's eating you up (but make sure that before you do this, you've read no. 9 above)
If you promised your tech lead (client, coworker or boss) you will deliver the thing on Friday, and you're not gonna make it, tell them early. Don't tell them on Friday
Exercise. You're brain (and your blood pressure) will love you for it
When the book "Pragmatic programmer, journeyman to master" comes out. Read it
From time to time, write a program in LOLCODE, don't lose your humor

There's a lot more, but these are my big ones

Don't forget to visit the original post by Sergio Tapia, there are other comments in there; it's still going, I think.

Ripping Youtube vids on the cmd line

Ted Hagos — Thu, 04 Oct 2018 07:17:09 +0000

Going through my old linux and macOS cheatsheets, I found this, youtube-dl; it lets you rip youtube vids and download them.

sudo apt-get update && sudo apt-get install youtube-dl
youtube-dl <youtube vid URL>

It's also available on macOS. If you use brew, you can get it with this

brew update
brew install youtube-dl

youtube-dl <youtube vid URL>

I think you can also do this in Windows with Cygwin, but I haven't tried that.

UPDATE:

Rishabh GuptaFollow

I'm a software developer interested in programming language theory, system architecture and security.

added in the comments. Windows users can also get this via a Python package. You can get the EXE from rg3/youtube-dl

macOS mojave

Ted Hagos — Thu, 04 Oct 2018 06:25:16 +0000

I just downloaded macOS Mojave upgrade, but I haven't pulled the trigger yet. Is there anything I should watch out for; things it would break? If you've installed it already, anything weird going on? In case it didn't break anything, did it improve anything (speed, battery usage etc)

Thanks

You can pass variable arguments in a Kotlin function

Ted Hagos — Tue, 02 Oct 2018 04:28:00 +0000

Functions in Kotlin, like in Java, can also accept an arbitrary number of arguments. The syntax is a bit different from Java, instead of using three dots after the type ... , we use the vararg keyword instead.

fun<T> manyParams(vararg va : T) {  // (1)
  for (i in va) { // (2) 
    println(i)
  }
}

fun main(args: Array<String>) {
  manyParams(1,2,3,4,5)  // (3)
  manyParams("From", "Gallifrey", "to", "Trenzalore")  // (4) 
  manyParams(*args) // (5) 
  manyParams(*"Hello there".split(" ").toTypedArray()) // (6)
}

(1) The vararg keyword lets us accept multiple parameter for
this function. In this example, we declared a function that has a typed
parameter; it’s generic. We didn’t have to declare it as generic in order to
work with variable arguments, we just chose to so that it can work with a
variety of types

(2) This is a simple looping mechanism so that we can print each item in the argument

(3) We can pass Ints, and we can pass as many as we want because manyParams accepts variable number of arguments

(4) It works with Strings as well

(5) Like in Java, we can pass an array to a function that accepts variable arguments. We need to use spread operator * to unpack the array. It’s like passing the individual elements of the array one by one, manually

(6) The split() member function will return an ArrayList, you can convert it to an Array , then use the spread operator so you can pass it to a vararg function

Reified generics in Kotlin

Ted Hagos — Fri, 28 Sep 2018 07:52:17 +0000

Let’s deal with the meaning of reify first. It means to make something real, and the reason we’re using reify and generics on the same statement is because of Java’s type erasure.

Type erasure means exactly what you think it means. Java, and Kotlin as well, erases generic type information at runtime. There are good reasons for this, but unfortunately, we’re not going to discuss those reasons why the language design is like that — but we will discuss its effects. Because of type erasure, you can’t perform any reflection activity and you can’t do any runtime check on a type. So, the following code won't work.

fun checkInfo(items:List<Any>) { 
  if(items is List<String>) {   // (1)
    println("item is a list of Strings")
  }
}

(1) This line won't compile, the error is "Cannot check for instance of erased type"

The is keyword doesn’t work on generic types at runtime, the smart cast breaks because of type erasure. If you have some confidence about what the runtime type of the List will be, you can make a speculative decision and cast it using the as keyword, like this

val i = item as List<String>

The compiler will let you through, but this is a dangerous thing to do. Let’s consider one more example where we can build a stronger case as to why we need to retain type information at runtime.

Let’s say I have a List of objects, Programmer and Tester objects. I want to create a function where I can pass a type parameter and filter the list using that type parameter. I want the function to return the filtered list.

The following code shows us sample on how this might be done — it won't work of course, because of the type erasure issue, but just read through it first, we will fix it later.

fun main(args: Array<String>) {
  val mlist = listOf(Programmer("Ted"), Tester("Steph")) // (1)
  val mprogs = mlist.typeOf<Programmer>() // (2)

  mprogs.forEach { // (3)
    println("${it.toString()} : ${it.javaClass.simpleName}")
  }
}

fun <T> List<pass:[*]>.typeOf() : List<T> { // (4)

  val retlist = mutableListOf<T>() // (5)
  this.forEach {
    if (it is T) {  // (6)
      retlist.add(it) // (7)
    }
  }
  return retlist  // (8)
}

open class Employee(val name:String) {
  override fun toString(): String {
    return name
  }
}
class Programmer(name:String) : Employee(name) {}
class Tester(name:String) : Employee(name) {}

(1) Let’s create a list of Programmer and Tester objects

(2) Let’s call an extension function (of the List type) called typeOf. We’re passing Programmer as a type argument, which means, we want this function to return only a list of Programmers objects

(3) We’re just iterating through each item of the list. We print the name property and the Java simpleName

(4) Now we come to the definition of the extension function. We’re defining a type parameter , we’re using T as the return type of this function. Also, we want this function to work with any kind of List, hence the syntax

(5) Let’s define a mutable list, we’ll use this to hold the filtered list

(6) This is the code that won’t compile because we don’t know what kind of List is this anymore at runtime. Kotlin, like Java, erases the type information. But let’s assume for a moment that Kotlin does retain generic type information; if that’s the case, then this code is okay

(7) If the condition is okay, let’s add the current item to the return value

(8) Finally, let’s return the filtered list

That last code sample would have worked perfectly if only List.typeOf can remember (at runtime) what kind of list it is. As it turns out, Kotlin can actually make generics types remember these kinds of things at runtime. We just need to use a couple of special words, like inline and reified. Let's see how to do this in code.

inline fun <reified T> List<pass:[*]>.typeOf() : List<T> { // (1)

  val retlist = mutableListOf<T>()
  this.forEach {
    if (it is T) {
      retlist.add(it)
    }
  }
  return retlist
}

(1) Make the function inline and use the reified keyword before the type parameter. After doing this, the function can retain type information at runtime

You can only reify inline functions. When you inline a function, the compiler will replace every call to that function with the actual its actual bytecode (not just the address of the function). It’s like copying and pasting the bytecode of the function wherever the function is called. This is how the compiler knows the exact type that you used as the type argument. Hence, the compiler can generate the bytecode for the specific class that was used as the type argument.

If we reverse-engineer the bytecodes that compiler will generate for our reified function, it might look like the following code.

val retlist = mutableListOf<Programmer>()
this.forEach {
  if (it is Programmer) {
    retlist.add(it)
  }
}
return retlist

As you can see, we’re not testing if it is T anymore, we’re testing if it is Programmer. The generated bytecode references a specific class (Programmer) not a type parameter like <T>. This is the reason why reified functions are not affected by type erasure. This, of course, will increase the size of your runtime program, so use it sparingly.

In case you want to try this by yourself, here's the full code listing

fun main(args: Array<String>) {
  val mlist = listOf(Programmer("Ted"), Tester("Steph"))
  val mprogs = mlist.typeOf<Programmer>()

  mprogs.forEach {
    println("${it.toString()} : ${it.javaClass.simpleName}")
  }
}

inline fun <reified T> List<*>.typeOf() : List<T> {

  val retlist = mutableListOf<T>()
  this.forEach {
    if (it is T) {
      retlist.add(it)
    }
  }
  return retlist
}

open class Employee(val name:String) {
  override fun toString(): String {
    return name
  }
}
class Programmer(name:String) : Employee(name) {}
class Tester(name:String) : Employee(name) {}

Photo credit: yenwen / E+ / Getty Images
Disclaimer: no copyright infringement intended

Kotlin's when is switch, on steroids

Ted Hagos — Wed, 26 Sep 2018 14:13:00 +0000

Kotlin doesn’t have a switch statement, but it has the when construct. It looks a lot like the switch but it packs a lot more punch. In its simplest form, it can be implemented like this

val d = Date()
 val c = Calendar.getInstance()
 val day = c.get(Calendar.DAY_OF_WEEK)

 when (day) {
   1 -> println("Sunday")
   2 -> println("Monday")
   3 -> println("Tuesday")
   4 -> println("Wednesday")
 }

The idea is to match the argument (the variable day) against the branches 1, 2, 3 or 4 . The test is carried out from top to bottom (1, then 2, then 3 then 4) and when a match is made the statement (or block) to right of the thin arrow -> is executed. Unlike in switch statements, when a match is found, it doesn’t flow through or cascade to the next branch, so, you don’t need to put a break statement.

The when construct can also be used as an expression, and when it’s used as such, each branch becomes the returned value of the expression. See the code example below.

val d = Date()
 val c = Calendar.getInstance()
 val day = c.get(Calendar.DAY_OF_WEEK)

var dayOfweek = when (day) {
   1 -> "Sunday"
   2 -> "Monday"
   3 -> "Tuesday"
   4 -> "Wednesday"
   else -> "Unknown"
 }

Just remember to include the else clause if you use it as an expression. The compiler thoroughly checks all possible pathways and it needs to be exhaustive, which is why the else clause becomes a requirement.

You’re not limited to numeric literals, you can use a wide variety of types for the branches, like this code below.

fun main(args: Array<String>) {

  print("What is the answer to life? ")

  var response:Int? = readLine()?.toInt()  // (1)                                                 
  val message = when(response){
    42 -> "So long, and thanks for the all fish"
    43, 44, 45 -> "either 43,44 or 45" // (2)   
    in 46 .. 100 ->  "forty six to one hundred" // (3)    
    else -> "Not what I'm looking for" // (4)   
  }
  println(message)
}

(1) readLine() reads an input from the console. Don’t worry about the questions marks for now, we’ll get to that in the coming sections

(2) The branch conditions may be combined with a comma

(3) We can check if it’s a member of a range or a collection

(4) The else clause is required when when is used as an expression

You can also use when without an argument, like this

val a = 3
val b = 2
val c = 1
val str = "str"

when {
  a > b -> println("a is greater than b")
  b > c -> println("b is greater than c")
  b == 2 -> println("b is equal to 2")
  str == "str" -> println("str is actually equal to $str")
}

Which effectively makes it the equivalent of an if-elseif structure; it looks much cleaner though. But hold on a minute, read the sample code above again, and this time, examine it closely. Have you noticed that all the conditions in all the branches should evaluate to true? They do. However, if you run code above, it will only print the first branch, a > b. Like the if-elseif, when one branch evaluates to true, the rest of the succeeding branches are ignored. They will no longer be evaluated. Best to take note of that.

You can also use the is operator in a when construct. If you do that, you get the benefit of smart casts as well. See the following code for an example.

when (arg) {
  is Int -> println("The square of $arg is ${arg * arg}")
  is String -> println("Hello" + arg)
  is IntArray -> println(arg.sum())
}

Another (slightly more complicated) example of using the is operator in a when construction.

fun <T> fooBar(arg:T) : T {   
  var retval:T = 0 as T
  when (arg) {
    is String -> {           
      retval = "Hello world" as T   
    }
    is Number -> {
      retval = 100 as T
    }
  }
  return retval
}

Here's how you might use it in an Android app.

class MainActivity : AppCompatActivity() {
  val Log = Logger.getLogger(MainActivity::class.java.name)

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
  }

  override fun onCreateOptionsMenu(menu: Menu?): Boolean {
    Log.info("onCreateOptionsMenu")
    menu?.add("File")
    menu?.add("Exit")
    return super.onCreateOptionsMenu(menu)
  }

  override fun onOptionsItemSelected(item: MenuItem?): Boolean {
    when (item?.toString()) {
      "File" -> {
        Log.info("LOG File menu")
      }
      "Exit" -> {
        Log.info("LOG Exit menu")
      }
    }
    return true
  }
}

Kotlin Exception handling

Ted Hagos — Wed, 19 Sep 2018 05:40:00 +0000

Kotlin's approach to exception is similar to Java. Somewhat. It uses the try-catch-finally, just like in Java. So, your knowledge about how try-catch works commutes nicely to Kotlin. The code below should be very familiar. It shows a typical code on how to open a file

import java.io.FileNotFoundException
import java.io.FileReader
import java.io.IOException

fun main(args: Array<String>) {
  var fileReader: FileReader
    try {
    fileReader = FileReader("README.txt")
    var content = fileReader.read()
    println(content)
 }
  catch (ffe: FileNotFoundException) {
    println(ffe.message)
  }
  catch(ioe: IOException) {
    println(ioe.message)
 }
}

So, what's different? Well, in Kotlin, everything is an unchecked exception. Which means, the try-catch block is optional. It's up to the programmer if you want to use it. So, the code above, can be written like this (in Kotlin).

import java.io.FileReader  

fun main(args: Array<String>) {
  var fileReader = FileReader("README.txt")  
  var content = fileReader.read()  
  println(content)
}

So how do you know if you need to use try-catch. You might not like the answers now, but in the long run, these are good advice to follow ;

You have to know the API's you're using. I know that this is not great news for beginners, but look at it this way, you won't be a beginner for long. And you really should know the API's you're using. TL;DR won't serve you well in this area
You have to get into the habit of unit-testing your code. This is a good habit to develop anyway

if-then, a statement in Java; but an expression in Kotlin

Ted Hagos — Wed, 19 Sep 2018 05:38:00 +0000

The if construct in Kotlin works almost the same as in Java.

val theQuestion = "Doctor who?"
val answer = "Theta Sigma"
val correctAnswer = ""

if (answer == correctAnswer) {
 println("You are correct")
}

Another example, this time, let's use the else if and else clause.

val d = Date()
val c = Calendar.getInstance()
val day = c.get(Calendar.DAY_OF_WEEK)

if (day == 1) {
 println("Today is Sunday")
}
else if (day == 2) {
 println("Today is Monday")
}
else if ( day == 3) {
 println("Today is Tuesday")
}
else {
  println("Unknown")
}

So far, it looks a lot like how you would you do it in Java. Doesn't it? What's different in Kotlin is, the if construct isn't a statement, it's an expression. Which means, you can assign the result of the if expression to a variable. Like this

val theQuestion = "Doctor who"
val answer = "Theta Sigma"
val correctAnswer = ""

var message = if (answer == correctAnswer) {
 "You are correct"
}
else{
 "Try again"
}

If you have only one statement (each) on the if and else block, you can even shorten the code, like this

var message = if (answer == correctAnswer) "You are correct" else "Try again"

A really really basic intro to Kotlin's functions

Ted Hagos — Wed, 19 Sep 2018 05:33:00 +0000

Kotlin functions are defined using fun keyword, followed by the name of the function, a pair of parentheses, optional parameters, the return type of function and then the body of the function, which is pair of curly braces. It's pretty much like a Java function, except that in Java, we have no fun (pun intended) and the type of the function is written to the left of the function (in Java), while in Kotlin, the return type of the function is to the right of function name.

When a function declares a return type, the type and the function's name must be separated by a colon. Like this function that takes in a Float argument and returns a Float value

fun inchesToCm(inches:Float) : Float {
  return inches * 2.54
} 

fun main(args:Array<String) {
  println(inchesToCm(10))
}

If a function has a single statement in it's body (like the previous code sample), you can write it as an expression. Like this

fun inchesToCm(inches:Float) = inches * 2.54

In a function expression, you don't have to write the return type because Kotlin can infer it from the RHS (right hand side of the assignment operator).

When a function (that isn't written as an expression) doesn't specify it's return type, the compiler will assume that it returns the Unit type. Think of Unit as the equivalent of Java's void, like this

fun talk() {       // (1)
  println("Hello") // (2)
}

(1) Our function doesn't have a declared return type. Hence, it's automatically Unit

(2) The body of a function whose return type is Unit cannot have any return statement in it; just like void methods in Java

Functions can be written in 3 places; as a top-level (which you've seen already) inside classes (which you've also seen) and inside another function.

fun foo() {                 // (1)
  fun baz() : String{       // (2)
    return "Bar"
  }
  println("Foo ${baz()}")   // (3)
}

fun main(args:Array<String>) {
  foo()
  baz() // (4)
  println("${Person(lastname="Doe", firstname = "John").fullname()}")
}

class Person(val firstname:String, val lastname:String) {
  fun fullname() = "$firstname $lastname"  // (5)

(1) foo() is a top level function. It isn't nested in a class or another function

(2) bazz() is nested inside function foo(). Which means, baz is scoped with foo; which means, it can only be called within the body of foo()

(3) This call is ok, baz() is callable within foo()

(4) Not OK. This call will fail, baz() is not callable from main() , you can only call baz() from within foo()

(5) Like Java, you can put functions inside a class

Default function arguments

You can assign default values to function parameters, like this

fun connectToDb(hostname: String = "localhost",
                username: String = "mysql",
                password:String = "secret") {
}

And because there are default parameters, you can call this function without passing any arguments. Like this

connectToDb()

Or you can pass only two arguments, like this

connectToDb("mycomputer", "ted")

"mycomputer" is the hostname, "ted" is the username. The two arguments that we passed corresponds to the first two parameters that were defined in the function.

Named params

In addition to default function arguments, we can also call the function by naming the arguments at the callsite.

fun main(args:Array<String>) {
  connectToDb(hostname="neptune",
              username="saturn")
}

In the example above, we only passed two arguments, but since our function has default parameters, that's okay.

Some related content to this are;

Kotlin - Extension Functions

Ted Hagos ・ Sep 30 '18

#kotlin #beginners