Stage 1. Scripts in the ChatGPT window

When it all started, I remember showing my friends how ChatGPT can write simple Python functions only by getting the function description in the chat window. The first reaction was, “Well, I don’t see any magic. I can do it myself without any AI!”

“Exactly!” my answer was. “That’s the whole point. Don’t let the AI assistant do something you couldn’t do yourself.”

That was the early stage of AI-assisted development. I would open the ChatGPT website, ask it to write a function, copy the function into our editor, and run it. Something is not working? Copy the error message to the same ChatGPT window and ask to fix the code. Copy the fixed code into your editor and repeat.

Easy, right? Very often, it worked, and you got the function you wanted. Sometimes, after four or five iterations, you would say, “Enough!” and start fixing the code yourself.

Even then, ChatGPT was enormously helpful. You could ask to add comments to the existing functions, create tests, and even produce a draft for the README file.

But it was a tedious process: going back and forth between ChatGPT and my editor, not being able to see what exactly was changed in the code. Mostly, I relied on my visual code inspection, my smart IDE, and my compiler. Smart developers also added tests to that mix.

Stage 2. IDE extensions

Pretty quickly, I switched to an extension for VS Code called Codeium. I have to admit I tested the early version of GitHub Copilot when it became available and was free. I wasn’t impressed. I remember saying, “I’d better write it myself instead of looking at what Copilot generated and deciding if I want to accept it.” I decided I didn’t want the subscription and stopped using Copilot.

With Codeium, it was different. Maybe their way of adding code was less intrusive, or maybe their code quality was better. After all, it’s been six months later, which is ages in the AI timescale. But I tried it and was hooked immediately.

Codeium can not only write code according to the description, but it can also look at your existing code and suggest changes. It’s extremely helpful if you have to make many similar changes in multiple files.

Codeium understands your codebase pretty quickly and can add functions that seem to be missing. For example, if it sees that in your package, you just added a function CreateUser(), it will suggest adding functions GetUser(), DeleteUser(), and ListUsers(). It’s pretty smart, and usually, its suggestions are what you expect. I would say eight or nine times out of ten, I agreed with the Codeium suggestions and accepted them.

I was pretty happy with Codeium and recommended it to everybody, especially to AI skeptics. “Just add it to your VS Code and try,” I would tell my friends. “It’s free, and if you don’t like it, remove it.”

I liked it and definitely, I wasn’t going to remove it. But sometimes, I wanted to write something myself, without help from AI. Sometimes, I wanted to learn a new topic or a new language, and I wanted to develop muscle memory. Sometimes, Codeium tried to write Markdown documentation or articles for me, but I didn’t like its suggestions. A good thing is that you can disable Codeium and enable it again. You can also disable it for certain languages; this is what I did for Markdown and AsciiDoc. You can snooze its autocomplete suggestions for an hour and work uninterrupted on your paper or code.

Codeium served me well and helped me a lot, and I’m very thankful for that. Then I heard about Cursor.

Stage 3. AI-based IDEs

Cursor was one of the first IDEs built to be used with AI. Cursor is not a VS Code extension; instead, it’s a fork of VS Code with additional UI features that help them to be more involved in the development process. They follow VS Code versions very closely, so you won’t feel left behind in terms of VS Code features. Even more, you can import all the VS Code extensions you are so attached to and use them in Cursor, too.

Switching to Cursor changed the way I develop code a lot. In addition to generating new code and editing existing code, I can now chat with AI and get explanations and suggestions. Pretty often, our dialogue starts with a question like, “I want to add logging to this project. What approach would you recommend?” Cursor gives me an overview of two or three possible options, giving pros and cons and suggesting the optimal path. You can add other conditions, like, “I understand that logrus is a popular library, but I’d like to stay with the standard library and use log/slog.” And Cursor will adjust its recommendations based on this new information.

The new capability that completely blew my mind was the ability to talk to your whole codebase. Imagine being able to say in the Cursor chat, “@Codebase Please review my codebase and write a good README file explaining this project.” And it performed beautifully! I had to add a couple of corrections, but overall it was a perfect README created for my project in a matter of seconds.

That encouraged me, and I asked the next question, “Please suggest which ADR (architecture decisions record) documents I should create for this project.” It answered with seven or eight topics that should be covered in ADRs: the choice of language, the logging structure design, the choice of the database, etc. Needless to say, I asked it to write all those documents and place them in a separate directory for ADRs.

Asking Cursor to write tests for my project was a no-brainer after that. All these boring test cases with a log of boilerplate were created in seconds, alongside mock services and tests for those services (to make sure they are good mocks), too.

After all this help from Cursor, having a project without tests and docs is inexcusable these days.

I got used to all these features recently and even started feeling a bit lazy. Of course, I can write this conversion function easily, but why should I spend 20 minutes if Cursor and Claude can write it in seconds? Cursor is not lazy when it comes to adding all those if err != nil in Go that are usually the first reason of frustration for people first exploring Go. With Cursor, it’s done almost automatically. More than that, if it notices that you prefer one format for error messages, it will use it in the future.

On the other hand, having such great help from AI made me more open and creative in new projects. When thinking about adding a new feature, the “human” me would think about the time I need to implement it and would decide, “This can wait.” The “AI-assisted” me would tell Cursor, “Please add this function to the code,” and it will happily do it for you. A minute or two to analyze what it has written and voilà, a new feature has been added.

So far, working with Cursor and other AI assistants before it, I felt that I was pretty much in control of what was happening with my codebase. But what I witnessed just yesterday with the new version of Cursor and the new Claude Sonnet 3.7 model has changed that.

Stage 4. AI-driven development

Yesterday, I worked on my project, which used two other open-source projects ¹. Something wasn’t working properly. The client (the first open-source project) was giving me timeouts when accessing my server, which was built using another open-source project.

I asked Cursor for help and it suggested adding logging to my code to see what’s going on. I generously allowed it to do so, but the logs didn’t show anything suspicious. The requests were accepted by my server and forwarded to the library. It looked like I had to fork the library’s repo and add logging to their code. But I am not familiar with it, and it will take me a while to figure out how to do it. That’s what I thought.

So I went ahead, forked and cloned the repo, opened it in Cursor, and asked it, “Please add logging to the code so I can track the request as it goes through the server.” And it did it. It understood what I was trying to solve here and suggested adding logging in other places.

Adding logging calls required using a log file (see the explanation in the footnote). Using logging required adding a new Go interface and that required changes in several other files.

At that point, Cursor decided that it was not a good idea to make significant changes without adding proper tests. It added tests, made changes and asked me to run tests. No, not switching to the terminal and running commands. Just press the button “Run command” in the same dialogue window.

I pressed the button, and saw that some tests failed. Cursor said, “Okay, let me figure it out…” and made some more changes. I noticed that my editor marked some function calls and variables with red wiggly lines telling me, “that won’t compile.” Before I was able to tell Cursor about that, it noticed it itself and said, “Yes, I see problems with the compiler. Let me fix that.”

And that repeated several times. I was just sitting with my jaw dropped and watching what the magic Cursor (with Claude’s help) was doing with the codebase. It was adding more logs, fixing compilation issues on the fly, and asking me to press the button to run tests again until it found the issue.

“Ah, now I see the issue!” it said. If you haven’t used Cursor before, don’t be deceived by this phrase. Cursor says this pretty much every time when it thinks it found the issue. Very often it’s just the beginning of the journey that leads to even more turns and twists. But this time, it was indeed the issue. The library expected the ID variable to be an integer, but the CLI client used a string. Which part should we fix?

“Let me see,” Cursor said. “In the JSON-RPC 2.0 specification, which I just pulled from the Internet, it says pretty clearly that the ID can be a number, or a string, or NULL. So, we have to fix the library.”

Before I was able to say anything, the library was changed. Of course, you understand that you can’t just replace an integer with a string. The library should support all three options described in the specification. “No problem,” Cursor said. “I’ll create a structure and a wrapper that will preserve backward compatibility but also will support all the options described in the spec.” And it continued working, making changes.

At some point, I lost track. It worked so fast, explaining all the changes and making me accept them that I couldn’t follow at its speed. The scariest moment was when, in the middle of that stream of changes, it stopped and said, “Usually, we limit the run by 25 tool calls.” My heart sank. Do I have now to figure it out myself and continue making the changes Cursor started?

Luckily, Cursor said, “To continue, press this button.” I did, and it continued making changes until it finished after two or three more steps. It ran unit and integration tests (that it created) one more time and said, “Now it should work with your application.”

And it did! All I had to do now was to commit the changes to my branch and push it to my forked repo on GitHub. I’ll work with the library developers to explain what Cursor was able to find and how it fixed it.

Conclusion

I have to admit, I’ve been very enthusiastic about AI-assisted software development so far. It helped me a lot, and I was able to finish several projects much faster than I would have done without AI. But what I saw yesterday with Cursor was literally magic. I wasn’t in control of the process anymore. And I was scared by the possibility that I would be left with all these changes in the middle of the journey.

On the other hand, I don’t have any doubt that I wasn’t able to figure out that issue in somebody else’s code. Most likely I would give up and switch to another library. AI helped me to continue working on this project. And it took Cursor only an hour or two to find the problem and fix it.

No doubt, I will continue using AI in my development process. I just have to learn how to tame this beast.

It’s fascinating to reflect on how my own attitude towards this debate has evolved. When I first arrived in America, I had to adapt to these unfamiliar measurements, and I initially resisted. “What’s with all these illogical units?” I thought. It wasn’t even the individual measures that bothered me most — after all, what’s inherently wrong with an inch, and how is a centimeter radically better? No, it was the seeming lack of logic in the system as a whole that irked me. Why are there 12 inches in a foot but three feet in a yard? And then 16 ounces in a pound? It all seemed arbitrary and inexplicable.

And don’t get me started on the obsession with fractions — all those sixteenths and thirty-seconds, it’s maddening! I remember a real-life problem I encountered at the post office: I needed to choose a box for a package. Two boxes cost the same, but their sizes were different: one was 11" x 8–1/2" x 5–1/2", and the other was 11–7/8" x 3–3/8" x 13–5/8". The question was: which one has a larger volume? Try calculating that in your head! I began to wonder if American schoolchildren were taught some secret techniques for multiplying fractions, which were unknown to us decimal users. Spoiler alert: they aren’t.

Then there’s Fahrenheit! In Celsius, it seems so straightforward: zero is when water freezes, and 100 is when it boils. But Fahrenheit? The zero point seems arbitrary (it was actually the coldest temperature Fahrenheit could achieve in his laboratory, about -18°C). The distance from zero to the water’s freezing point is divided into 32 degrees. Then, he set the boiling point of water at 212 degrees because the 180-degree span between freezing and boiling is conveniently divisible by many fractions. Again, with the non-decimal fractions!

As time passed, however, my perspective began to shift. One summer, I dove into various woodworking projects — building flower beds, decking, etc. Suddenly, I realized it felt natural to think about lumber in feet and inches. The width in inches is expressed in single-digit numbers: boards 4, 6, or 8 inches wide are standard, occasionally 10 inches. Lengths of 6 or 8 feet are also convenient, single-digit numbers. Using meters and centimeters would have been far more complicated. I surprised myself with this realization.

The same goes for bolts and nuts. Inch and half-inch bolts make sense, but what about the tiny ones? Surely we don’t resort to thirty-seconds of an inch? It turns out we don’t need to. Small bolts are simply numbered: #2, #4, #6, up to #12. After that, it’s a quarter-inch and up. Sounds crazy, right? But once you get used to it, it’s not so bad. You learn to visualize what a #6 bolt looks like — just a tad smaller than #8. It becomes second nature.

I had another epiphany during a trip to Canada. I’d always claimed that miles bothered me least of all American measurements — the speedometer shows miles, and road signs display distances in miles. You look, you calculate, and you’re done. But in Canada, I discovered that I wasn’t calculating at all — I had developed an intuitive feel for miles. I’d see a road sign saying “20 km ahead” and suddenly arrive at my destination, thinking, “That was quick!” I realized I had been estimating distances in miles without even thinking about it.

The issue of fractions deserves special attention. When comparing metric and American systems, we often conflate two distinct aspects: the units of measurement themselves (length, weight, etc.) and how these units are subdivided. The metric system uses decimal division throughout. Convenient, right? There are 100 centimeters in a meter and 1000 grams in a kilogram. Converting between units is a breeze. The American system, however, is built on halves: halves, quarters, eighths, sixteenths, and so on. At first glance — through our decimal-tinted lenses — it seems horribly inconvenient. Adding and subtracting become cumbersome: what’s three-quarters minus seven thirty-seconds? You need to find a common denominator, and… ugh. Multiplication is even worse.

BUT — and this is a big but — it’s actually quite practical for everyday use. Think about it: even we “decimal people,” when we see 0.5, think “half,” and when we see 0.25, we think “quarter,” right? We don’t mentally divide the whole into 10 parts and take five of them. We just take half. For daily life, simple fractions often feel more intuitive than decimals. For calculations, decimals win hands down, but for practical applications, fractions have their merits.

Or do they? Let’s take another look at the fractions common in the American system: halves, quarters, eighths, sixteenths… Ring any bells? It’s essentially a binary system beloved by computers and programmers alike! Those in the know understand the computational gymnastics required for a computer to convert binary numbers to the decimal system we humans prefer.

Now, back to Fahrenheit. It seems like a bizarre temperature scale, not clearly anchored to anything tangible and decidedly non-decimal. Celsius appears much more logical, right? That’s why Fahrenheit is only used in three countries, while Celsius is the global standard. But let’s consider this from an everyday perspective: do I really care about water’s boiling point when I’m checking the weather? I just want to know if it’s hot or cold! In Fahrenheit, I know that zero is bone-chillingly cold, and 100 is swelteringly hot. Everything else falls between these extremes. In Celsius? Zero degrees is an ambiguous, slushy mess — neither truly cold nor warm. And 100 degrees? That’s not even a real-world temperature for the weather. Sure, scientists in labs might care about when water boils (and why water, specifically?), but for the average person, isn’t a weather-centric scale more practical?

So, what’s the takeaway here? Living in a different country opens your mind to new perspectives on things you once thought were set in stone. It challenges your assumptions and broadens your horizons. In my view, it’s an excellent workout for your brain and your ability to reason.

P.S. Don’t try to conclude from this text that I’m “for” or “against” either system. I’ve grown to appreciate them both! 🙂

My dad gave me a book by Martin Gardner describing a simple game and a machine for playing it. He called the game Hexapawn because it used just six pawns on a 3x3 board.

The game and rules

The rules are simple. Here is how Martin Gardner describes them (https://gwern.net/doc/reinforcement-learning/model-free/1991-gardner-ch8amatchboxgamelearningmachine.pdf ):

Only two types of move are allowed:

(1) A pawn may advance straight forward one square to an empty square; (2) a pawn may capture an enemy pawn by moving one square diagonally, left or right, to a square occupied by the enemy. The captured piece is removed from the board.

These are the same as pawn moves in chess, except that no double move, en passant capture, or promotion of pawns is permitted. The game is won in any of three ways:

1. By advancing a pawn to the third row.
2. By capturing all enemy pieces.
3. By achieving a position in which the enemy cannot move.

The project

Creating a board and finding the pieces to play was the easy part. After that, I had to create the machine itself. Martin Gardner called it HER: Hexapawn Educable Robot.

The whole game never lasts longer than six moves. I, the human, was playing white, and the robot was playing black. So I had to give it (HER?) instructions for each even move.

I split twenty-four matchboxes into three groups: for moves 2, 4, and 6. Each box had a picture describing the position and the possible moves for that position for black. Each box contained several colored cherry pits according to the number of possible moves.

So, I had two boxes for the second move because there were two different positions after the first move by white (three if you count the symmetrical one). I had 11 boxes for the fourth move and another 11 boxes for the sixth move.

Time to play and learn

Now, the game begins! You move your white pawn, take the matchbox with your current position, shake it, and pick one colored cherry pit from it (don’t look! Pick it randomly!). You make a move for the robot using the arrow of the cherry pit’s color and put it back in the box.

After six moves, either you or the robot wins.

Now begins the learning part. If the robot loses, you “punish” it by removing the colored pit responsible for the last move. For example, in box six above, if the last move for black was “green,” then black would lose. If that was the case, you remove the green pit from the box, leaving only the winning moves. If there is only one colored pit in the box, you “punish” the box responsible for the previous (fourth) move. That way, you ensure the robot never reaches the box with only one losing move.

Are the rules clear? Let’s start playing and teaching the machine!

The machine learns surprisingly fast. If you teach it correctly, it becomes invincible after 30–40 games. Don’t believe me? Try it!

New generation

Forty years later, I found that book by Martin Gardner.

(https://www.amazon.com/Colossal-Book-Short-Puzzles-Problems/dp/0393061140/ ) and rebuilt the machine with my son.

Of course, we used a computer to create the board and move diagrams. We found colored beads in a nearby store (no need to paint cherry pits!). But the fun was the same!

My son published the instructions with the ready-to-use printouts you can download, cut, and glue on your matchboxes: https://www.instructables.com/Matchbox-Mini-Chess-Learning-Machine/

They look more polished now!

Machine learning ideas

I hear you saying, “I thought it was a serious article about Machine Learning, but you are talking about child games with pencils and colored beads!” Let’s see if we can find the basic machine learning ideas in this game.

Input and output

We begin with some input — the starting position. We must find the right output — the sequence of moves that will bring the machine to win the game. We must help the robot choose the right move at every possible position. Some moves are better than others, and we inform the robot about them using weights.

Weights

In each position, we have several options for the next move. Depending on the game’s outcome, we can make certain move options more or less preferable for the next game (learning pass). Isn’t it similar to the weights we assign to certain neurons? Only in this case is it binary: you either leave the bead in the box (1) or remove it (0).

These days, we call it quantization, i.e., reducing the number of bits used by weights (e.g., from float32 to int8 and lower). In this case, each weight is exactly one bit, which tells us whether the bead is in the box or not.

Reinforcement learning

Each time the machine gives you a wrong result, you adjust its weights. What is it, if not reinforcement learning? Environment, State, Agent, Action, Reward, right?

Backpropagation

Remember what you must do if only one bead is left in the box responsible for the last move? You can’t leave it empty, so you must apply the Reward (or, rather, the punishment) to the box responsible for the previous move. And so on and so forth. It looks like backpropagation, doesn’t it?

Going further

It’s pretty easy to play 30–40 games with the machine to make it invincible. Each game takes a few minutes, so we can achieve that result in less than an hour. But what if we could automate it? What if we could create a program to play the game and make two programs play against each other like they did with the Alpha Go program?

This sounds like a fun project that would be pretty easy to implement. But we are talking about ML and AI here, right? Why don’t we use AI to help us write this program?

I didn’t expect much when I entered the following prompt into ChatGPT.

You are a Go programming expert. I will upload a file describing a simple chess-like game called Hexapawn. I want to write a program to implement this game. I must choose the data structures to store board positions and available (legal) moves in each position. Then, I have to implement the move and the whole game functions. Finally, I have to implement the learning procedure. Please help me develop this program. I have attached the PDF file with the game description.

And I uploaded the 15-page PDF that I linked at the very beginning.

I’ll tell you what happened next in the following article. Sorry, I couldn’t resist using this phrase. Also, ChatGPT told me that this article’s length is ideal and that I should stop writing immediately.

Other works

I discovered that I’m not alone in making parallels between this simple game an Machine Learning principles. After a quick search I found many interesting articles about using this game in teaching. Here is a short list of articles.

Pomona College uses it in the computer science labs

Proceedings of Machine Learning Research directly addresses the idea of using the Hexapawn game in teaching Machine Learning: Using Matchboxes to Teach the Basics of Machine Learning: an Analysis of (Possible) Misconceptions.

Computd calls it “The accessible physical machine learning model”.

University of Wisconsin-Madison recommends Hexapawn as the Introduction to Machine Learning for students ages 11 and higher.

Digital Business Development calls it a machine-learning teaching tool. They implemented a version of the game in JavaScript but the game is not available online anymore. Feel free to take the code and deploy it yourself.

Mark Lawler wrote a story about showing this game to kids. He even recorded several videos of them playing the game and explaining it.