DEV Community: Kostya Malinovskiy

You Probably Don’t Need an AI Coding Course

Kostya Malinovskiy — Wed, 01 Apr 2026 11:58:51 +0000

Recently I’ve seen many blog posts and videos about AI coding workflows — how people build them, how productive they are, and often a mention that a course is available (or coming soon) to teach the same system.

I think it’s great that people share their knowledge and experience with fellow developers.

At the same time, I believe much of this knowledge is not that hard to obtain on your own, especially given how powerful modern AI tools are for learning.

Before buying a course, it may be worth trying to explore the topic yourself first.

My approach

When I want to quickly understand a new topic, I often use a “Fisherman’s prompt” — a prompt template designed to generate structured learning paths.

You can find the template here:

https://gist.github.com/disler/cad56b41fb614a4e394f7b719bca5273

(There is a lot of great material in that repository.)

For example, here is a prompt I used to explore AI-augmented coding workflows:

I'm a Senior software Engineer and I want to learn AI augmented coding so I can utilize Open Claude to help me with engineering. Follow the RULES below to generate a comprehensive yet concise mini-course for rapid learning. The course should contain chapters that teach me about these SUB_TOPICS. Make sure the chapters fit my level, profession and topic. Ask for clarification if you need more information about my knowledge.

SUB_TOPICS

- Mental Models of LLMs for Engineers
- Effective Claude Code Usage for Software Development
- Context Engineering (efficient context management)
- Task Decomposition for AI Agents
- Designing Agent Skills (Markdown capability files)
- Sub-agents and Task Delegation
- Agent Loops (ReAct / Reflection / Self-correction)

RULES

- Use concrete examples to explain every concept
- Use emojis to add expression
- Generate one chapter at a time
- Ask for feedback at the end of each chapter
- Ask if I need clarification at the end of each chapter
- With each concept, explain real world use cases
- After we complete every sub topic, present a list of additional topics we can explore that align with my level, profession, topic and objective.

You can also adjust the topic list depending on what interests you most.

Using the generated course as a starting point, together with resources like the Anthropic skills repository, https://github.com/anthropics/skills/blob/main/skills/skill-creator/SKILL.md
gives you a very fast way to get hands-on experience.

From there, experiment with workflows that work for you, iterate on them, and refine your approach.

After that, you’ll have a much clearer understanding of the field — and you’ll know whether you actually need a course or not.

Pipes Won't Let Me Go

Kostya Malinovskiy — Wed, 07 Jan 2026 15:42:35 +0000

Some time ago when I was working on codecrafters shell challenge I hit a problem.
The problem was that behaviour of my shell if use it via terminal was different from when use it in test environment.
When use it via terminal emulator the prompt was shown, however in tests it wasn't there. It appeared that readline works a bit different if communicating with it throug Stdin Stdout programatically.
I managed to overcome the problem, i wrote about it in one of my previous posts, but i think it is quite interesting and important to understand how this 2 ways work.

What is tty?

In unix system everything is a file including any device, tty is not an exception. It is a special character device. It means that it is a device that it streaming data as it receives it in real time byte by byte.

As it is a file it can be open for read or read with cat, or it can be written to with echo >. There is something confusing though. Suppose we use /dev/ttyp0 we want to write some data to it so it would be picked up somwhere, also we want to receive feedback from the device. But there seems to be a problem, if it is a file, how what is written on our hand is not mixing up with what is sent from the other hand?

At this point I found that instead of saying "in unix everything is a file" it would be better to say: "in unix everything looks like a file". What it means that file and tty device have same interface: read, write, close, but for diferent things it behaves differently differently. You see file descriptor no only a pointer to a file, it includes some additional info, and among other things it includes info on what drivers to use. For File read and write will use same destination, for tty read and write would use different buffers.

The Two-Way Pipe

TTY it is a 2 way-pipe (full-duplex). When any tty device would be represented by master end and slave end - two different entries at /dev/ptmx and /dev/pts/4.

Master end is held by usef facing app, when app receives typed charecters it writes them to master.
Slave end is held by a shell application and used slave as a stdin, and stdout.

When something is written to master, it appears on slave reader, and directed to a shell app stdin. When a shell app writes something to its stdout, whidh is slaves write, it is transfered to masters read.

TTY vs PTY

TTY is actual hardware(e.g /dev/ttys0), so the other end of the pipe is actual device
PTY is a pseudo-terminal, it is pair of files used to build TTY like interaction between software apps.

There is also such thing as line discipline, this is a kernel layer that echoes typed characters back to master, buffers input until Enter is hit. It also intercepts special symbols and key sequences like ^c or ^z and act on them accordingly. While this is an important piece, I will not focus on it at this post.

how to find out if app interacts with tty?

it can be easialy done with IsTerminal(fd int) from "golang.org/x/term", but how does it work under the hood?

// x/term/term.go
func IsTerminal(fd int) bool {
    return isTerminal(fd)
}

// x/term/unix_term.go
func isTerminal(fd int) bool {
    _, err := unix.IoctlGetTermios(fd, ioctlReadTermios)
    return err == nil
}

// x/term/term_unix_bsd.go
    const ioctlReadTermios = unix.TIOCGETA
// x/sys/unix/ioctl_unsigned.go

func IoctlGetTermios(fd int, req uint) (*Termios, error) {
    var value Termios
    err := ioctlPtr(fd, req, unsafe.Pointer(&value))
    return &value, err
}

ioctlPtr makes a syscall with a file descriptor and unix.TIOCGETA request, and writes result to value, it errors if file under fd is not tty. Presnse of error in the upstream code is interpreted as current file descriptor does not point to a tty device.

unix.TIOCGETA is read:
TIO - terminal Input/Output
C - control
GET - read/retrieve operation
A - attributes

Actual unix.TIOGETA value of course is not an arbitrary integer. But as I think it would be to deep in the rabbit hole for now, and I'll get to it somewhere in the future.

Pipes

Kostya Malinovskiy — Tue, 30 Dec 2025 19:57:05 +0000

In my journey to master Go my next objective was to update my shell to be able to handle commands that look like:

tail -f test.log | head -3

First idea was to collect command 1 output and then invoke command 2 with the collected output as argument. But as you may notice command 1 is tail -f which does not exit on its own and it means that it would block the execution.

More over if you try to test it:

echo line1 > test.log
tail -f ./test.log | head -3

then in another terminal window you try

echo line2 >> ./test.log

You'll see that the line2 was printed out. It could mean that head -3 does not wait for tail -f test.log to exit and to collect its output, instead it receives the output and prints it realtime.
Then if you read the docs you'll find confirmation for this hypothesis:

The output of each command in the pipeline is connected via a pipe to the input of the next command. That is, each command reads the previous command’s output.

Each command in a multi-command pipeline, where pipes are created, is executed in its own subshell, which is a separate process

Then if in another terminal window you try:

echo line3 >> ./test.log echo line4 >> ./test.log

you'll see that your command printed out line3 and exited.

What happens here is: 

On the third write to test.log, tail picks up the line and writes to stdout, which is the write end of the pipe 
head receives the line through its stdin, the read end of the pipe. 
As head was instructed to print only 3 lines, it exits and closes its end of the pipe 
On the 4th write, tail tries to write to stdout, but fails to do so as other end of the pipe is closed. This triggers a SIGPIPE signal, which terminates tail.

With all this understanding what can be done in Go to mimic the behavior? 

Create the commands:

cmd1 := exec.Command("tail", "-f", "./test.log")
cmd2 := exec.Command("head", "-n", "5")

Connect the commands:

outPipe, err := cmd1.StdoutPipe()
cmd2.Stdin = outPipe
cmd2.Stdout = os.Stdout // the go program stdout which is the terminal where it was executed

Start the commands:

cmd1.Start()
cmd2.Start()

 
func (*Cmd) Start() start command processes and doesn’t wait for them to finish.  Wait for the commands to finish:

  

cmd2.Wait()// remember head exits before tail
cmd1.Wait()

…and it appears that tail never exits… 

This is where I learned an interesting thing. You see, exec.Command spawns a child process, which receives its own copies of all File descriptors of original process. So when head command finishes, it closes it stdin, but its original in the parent process(my program) remain open. This means that in order to close the read end of the pipe I also have to close it in the parent process.

cmd2.Wait()
outPipe.Close()
cmd1.Wait()

The whole program:

package main

import(
    "fmt"
    "os/exec"
    "os"
)

func main(){    
    cmd1 := exec.Command("tail", "-f", "/Users/skuf_love/study/go/test_pipes/test.log")
    cmd2 := exec.Command("head", "-n", "5")
    outPipe, err := cmd1.StdoutPipe()
    if err != nil {
        fmt.Printf("Err1: %q", err)
    }
    cmd2.Stdin = outPipe
    cmd2.Stdout = os.Stdout

    err = cmd1.Start()
    if err != nil {
        fmt.Printf("cmd1 start error: %v\n", err)
    }
    err = cmd2.Start()
    if err != nil {
        fmt.Printf("cmd2 start error: %v\n", err)
    }

    cmd2.Wait()
    fmt.Println("cmd2 wait done")
    outPipe.Close()
    cmd1.Wait()
    fmt.Println("cmd1 wait done")
}

Reading readline

Kostya Malinovskiy — Mon, 22 Dec 2025 13:13:48 +0000

CodeCrafters verifies each challenge step by running test suit on their side on each push to the main branch. The problem with that is that for free membership tests are not always run instantly and can end up waiting in queue. In addition, even if test runs start right away, they still take considerable amount of time. After I started working on the Shell challenge, I quickly realized that I need to have local test suit. I found that Golang provides testing infrastructure right out of the box, so started building on top of it.  For go test, you need to implement at least one function with name Test - example. In my case I wanted to have an integration tests, so I needed some additional setup around. Go testing package allows you to do so by implementing TestMain function, that will run once per suite run.

func TestMain(m *testing.M) {
    err := exec.Command("go", "build", "-o", "testapp").Run()
    if err != nil {
        fmt.Fprintf(os.Stderr, "failed to build app: %v\n", err)
        os.Exit(1)
    }

    exitCode := m.Run()
    os.Remove("testapp")

    os.Exit(exitCode)
}

Here I build my shell app, run the suite and remove the app afterwards.

Then in a test function I have to run the shell, get stdin, stdout and stderr handlers to be able to send commands to my shell and receive and verify output. I’ll omit these details as it is not the subject of this blog.

Initially I implemented shell as a for loop that runs indefinitely, print prompt, read user input and print the output like this:

for {
  fmt.Print("$ ")
  input, _ := rl.Readline()
  out, _ := executeCmd(input)
  fmt.Println(out)
}

Then in test setup I do:

cmd := exec.Command("./testapp") // create cmd Struct for my shell
stdout, err = cmd.StdoutPipe() // connect to the shell stdout pipe
stdoutReader := bufio.NewReader(stdout) // wrap stdout pipe with the buffered reader, to get ReadString(), ReadByte() methods

 
Then in tests I used bufio.ReadString('$') to get the tested command output, as I knew that $ means that the new prompt is there and all output has already been printed. Of course I would be in trouble if a tested command output would include $ somewhere in the middle, but as I control command output and test data, this thing was working for me.

It was fine until I reached the step where in the challenge description it was recommended to use readline library. This is when my tests started to fail, It appeared that readline doesn’t print prompt when enclosing app is not used through TTY.

My tests were hanging as ReadString was blocking execution because it was waiting for $ to appear in the shell stdout, which was not happening.

After several hours of trial and error I came up with idea to read output by byte in a goroutine, send each byte through a channel to the calling function. In its turn the calling function would return whatever it had collected to the upstream code on a timeout. But I had to be sure that the goroutine finished before next shell command is tested, otherwise there is a risk that it will start collecting input from the next command and stealing it from the proper reader groutine. To solve this I decided to sent some special character to the shell stdin so it would appear in the stdout, and groutine could read it and know that is has to exit. At first I tried to send \x04 which means EOT(end of transmission), and felt semantically correct. By doing so I learned 2 things: 1. I needed to use echo so something could get to stdout 2. \x04 was read by readline(or is by something else), and was interpreted as signal to finish execution. 
Instead I went with echoing %, and It worked for me. Again if a command output includes % this would cause me troubles, but I’m ok with such a tradeoff while I’m in control of test data. When it will not be the case I’ll figure out better solution.  Here’s how function to get a command output looks:

func (c ShellTestContext) ReadUntilPrompt() (string, error) {
    var result strings.Builder

    t := c.T
    reader := c.StdoutReader
    buf := make(chan byte, 1)
    done := make(chan struct{})
    c.log("About to start goroutine")
    go func(){
        c.log("Goroutine started")
        var b byte
        var err error
        defer close(done)
        for {
            b, _ = reader.ReadByte()
            if err != nil {
                c.log(fmt.Sprintf("Inside goroutine error: %v", err))
                t.Fatal(err)
                close(buf)
                break
            }
            if b == byte('%') {
                c.log("Inside goroutine closing the channel")
                reader.ReadByte() // read \n after %
                close(buf)
                break
            }else{
                buf <- b
            }
        }
    }()

    for {
        select {
        case anotherByte := <- buf:
            result.WriteByte(anotherByte)
        case <- time.After(220 * time.Millisecond):
            c.log(fmt.Sprintf("Timeout goroutine, received result: %v", result.String()))
            c.Stdin.Write([]byte("echo %\n")) // use % symbol to signal goroutine to stop reading and finish
            <- done
            return result.String(), nil
        }
    }
}

P.S.
While putting these post together I learned that technick with looking for specific character is called Sentinel. Also I learned that TTY or not can be determinded to by inspectint file descriptor that is used for STDIN, STDOUT or STDERR. It can be done via syscall or via https://pkg.go.dev/golang.org/x/term#IsTerminal.

Learning Go the Hard Way

Kostya Malinovskiy — Mon, 22 Dec 2025 08:04:33 +0000

So, I’ve recently found myself with some free time and the opportunity to tackle my "backlog of wannados."
At the top of that list is Golang. I believe diving into it will broaden my engineering outlook and deepen my systems-level expertise.

Why "The Hard Way"? In my experience, the best way to truly internalize new knowledge is to struggle and hit the wall. You have to fail first to create a "knowledge vacuum" that pulls the skills in.

To make this happen, I'm starting with the Shell Challenge at CodeCrafters.io.

"Hard Way" in my world looks this way:

🚫 No AI coding assistants.
🚫 No LSP for navigation or completions. I’m going to do everything by hand to build muscle memory and be more mindful of how I organize my code.
📖 Docs First. The official documentation is my primary source. LLMs are the absolute last resort when nothing else makes sense.

Expect several wheels to be reinvented and plenty of bad practices to be implemented along the way. It’s all intentional—a way to gain a deep, firsthand understanding of why best practices and patterns exist in the first place.

I’ll be posting updates here about the specific problems I struggle with most.
See you around!

P.S. I’m not an AI doomer. I think LLMs are great tools for building things efficiently. However, when the goal is learning, they often stand in your way by providing shortcuts where there should be deep thought.