Felipe Azevedo Bosi — Articles

How an AI assisted coding app works

contato@felipebosi.com — Mon, 05 Oct 2026 00:00:00 GMT

In one of my last LinkedIn posts, I talked about how LinkedId, I talked about how the CodeCrafters' Claude Code path is a great resource for learning how these AI-assisted CLI tools work under the hood. Here I'm going to do a deep dive into its details.

First, any LLM is a tool that takes text and returns text. It calculates what the most probable text output will be, based on the data it has been trained on. In summary, LLMs can't think or be proactive. An LLM is a language model that gets your text, puts it on a series of matrices, and calculates a median answer for you. Not the best, not the worst, the median.

Of course, you would ask how it can search, read, and write in my code? Or even go to Linear or Figma to get information from those services? The answer is that it doesn't do any of that. What does it is the CLI tool.

CLIs like Claude Code and Codex, or even IDEs like Cursor, work with what they call tools. Tools are a series of functions and descriptions that tell the LLM what it can ask for in your environment. If the LLM needs to read a file, it asks the CLI to run the READ tool. Then the CLI will read the file using whatever tool it has in its code and send the result to the LLM, like a regular message, but as a system message instead of a user one.

That is why older LLMs don't know how to use tools. This is a feature that they had to be trained to respond to and ask for. And each new tool has to be coded inside the AI-assisted system itself.

The READ, WRITE, and other tools are just regular code. That is why RTK-ai works so well. In Claude Code's case, it trades Node's file-reading class for regular grep, ls, git, and other bash tools that already have better performance.

Knowing that all LLMs does is calculate text based on what they were trained from is one of the things that separates a dev that is only beginging to use them to a senior one.

From research papers to app

contato@felipebosi.com — Wed, 09 Sep 2026 00:00:00 GMT

In my free time, I've been focused on a very specific problem: how do I know how much caffeine I've consumed? I've built a tea caffeine calculator, a mate one, and now I'm building a mixture of a CLI/REST endpoint/package to help other people calculate the caffeine content of various types of beverages. However, what I want to talk about here is not the app itself, but where and how I got the data in there.

Although we can easily find data telling us about how much caffeine regular beverages have, in reality they can vary a lot. Coffee changes based on the type of coffee bean you are using, where it's from, and how you prepare it. Mate changes a lot based on how finely your mate is ground. Tea changes based on the type of tea and whether you are preparing it Western, gongfu, or grandpa style.

The first problem is that the only way to know how much caffeine we are consuming is to measure the caffeine itself in each cup or mate. But we can still get a better average than most websites give us. As an example, you can search Google right now. It will say that 50g of yerba mate has from 150 to 260 mg of caffeine. However, if you know the exact details of your mate, like if it's a Brazilian Native one, the scientific data tells us that in reality it's near 55mg, while an Argentinian one is near 290mg. With the maximum recommended per day being 400 mg, we can see how much the regular internet average gives us can cause some mistakes, making users drink less or more of their beverage than they want.

The second problem is, if you go to the scientific data, you'll see that most of the research is conducted using very specific parameters. They use controlled temperature, grams, and the tea/mate/coffee comes from a very specific area or even brand or farming. In summary, the data is so detailed and complex that to get the real caffeine we would need to go to the user and collect a sample of what he is really drinking. So, there is a need to simplify the data so that it can be useful to the user, but not so much that we circle back to being as useless as the regular web information is. What I did was select the main information that we can get from the user, like type of tea, grams used, volume, and create an algorithm that calculates a better average caffeine value for it.

To solve all these problems, I had to read and collect data from different articles, select those that make sense, and simplify them. As you can guess, no algorithm can calculate the exact value for natural products. In architecture and urbanism, we even use safety percentages on natural structural materials so we can be safe. The same is true for any natural food or drink. Knowing better what you are consuming can help you make better decisions for your health and enjoy your caffeine in a more mindful way.

For those who want to check, the repo that I'm working on is Caffeine Mega App

Dev routines: Preparing for a good day of work

contato@felipebosi.com — Mon, 13 Jul 2026 00:00:00 GMT

Coding isn’t just what you do while you are in front of a computer. Of course, a good keyboard, monitor, mouse will make your work more comfortable. This won’t make your code better, but surely will make you feel better when you get in front of your computer to do some coding. However, that are just things that you use. Part of what makes programming feels better is what you you do before, while and after coding that enhances that practice for you. Today I’m going to share how I start my day in a way that makes me perform better, but also that makes me happier and more comfortable coding.

The Day Before

All starts with the end of the previous day. I reserve part of the end of my working day to clean any mess I made on my working desk and to plan the next day.

As you can see on the photo above of my desk, there is a teapot, a small cup, some pens, some mechanical pencils and a notebook. That is what I’m using while writing the first draft of this post. I need to clean it before ending my shift, so I can start the next day with a clean desk, an idea shared on my previous post that you can read bellow:

The next step is to define what I’ll be working on the next day. Any type of todo list will do here. I simply write down, on the notebook you saw, a list of meetings that I have to attend to and a list of tasks I want to work on the next day. This list of tasks will include anything that I want to remember, from coding tasks, work, ideas that I want to work on, personal projects or exercises, like programming Katas or yoga nidra.

With this, you end your day with a clean environment and already knowing what you will do on the next day. No time wasted thinking about what could you do or dealing with a mess you created the day before while dealing with a problem or just eating in front of your computer (please, avoid this if you can).

Before Working

Since everything related to planning was done on the day before, I start the day without any worries. I already know what I need to do and when. So I wake up, prepare some tea or coffee and eat my breakfast while reading some book, manga or comic. Reading is a way, for me, to start my day slowly. I would love to say that I’m a person that is totally focused on my tea, coffee and food. But I'm not at that level yet.

After that, I’ll go for a walk or run for half an hour. I prefer to do this without any headset or phone. This is a way to ensure that, at least for an extra half an hour, I won't use any technology. I already work in front of a computer and will be using one for more than 8 hours a day. At least on the mornings I'm tech free.

Not that I hate technologies, video games or anything. It's the other way around. Having some disconnected time makes me value technology more, increase my well being and reserves sometime for me to think over everything I did and everything I want to do during my day. It's a way for my brain to acknowledge and decide what he'll do with every piece of information I accumulated during the day. Be it reading books, articles, just dealing with work or being in social media.

During Work

On working hours, my main challenge is to deal with energy levels. Everything is easy if I’m dealing with an energizing task, but we all know that is not always the reality. We also need to work on tasks that are easier or harder than we wanted it to be. As programmers we need to study, search for solutions and clues, reproduce random bugs that only happens if the user is using a random old browser and a slow 3g connection.

Usually, my working day starts with me looking at messages, reviewing PRs and reviewing my plan for the day. After that, I start working on a ticket or continue the work I’ve left the day before. When it’s midday, I stop for lunch. I do an hour or an hour and a half lunch. I use this time to relax and energize. If I have the time, I also use half an hour to study something or to code something unrelated to work. On the evening I have some meetings. Sometimes it’s just a 15 minutes daily, but sometimes there are other calls. By 6-6:30PM, I’ll go back to the “The Day Before” part of my day again and plan for the next day.

Energy level

We need a routine to deal with different energy levels and tickets that demands more from us. That will change from person to person, because each one of us have different changes in energy during the day. In my case, I start the day slow, but ramp up quickly with the power of caffeine. Then I get slow again around 9-9:30AM. I drink some coffee and get energized again for the rest of the morning. After lunch I can get a bit slower, but around 2PM I’m back up and I feel energized until 5PM. From 5-8PM I’m back on my slow phase, but after that I feel better until 10-11PM.

The example above is what happens during my usual day. However, it’s important to know that everything depends on what I’m doing. If I’m working on a task that I’m really into, I can forget the time, because I’m feeling up. And the same is true the other way around. If I’m forced to work on a boring task for too long, I might feel tired on hours that I wouldn’t.

It’s important to keep tapping into yourself to know your energy level and know what really gives you energy. For me, reading a novel or a manga, meditating, walking without any technology near me and watching anime are things that energize me, while navigating on social media and reading articles on the web makes me feel tired. It is also important that you are truthful with yourself. From the list I added above, I love to navigate on social media looking at memes and laughing and I think meditation is boring, but what they make me after is different than my feelings towards the activity. So keep you eyes up for how they make you feel not only during the activity, but after.

All of this is a work in progress. I still have a lot to learn and a lot to test. So, if you have a different routine, any tips you want to share or anything you wanted me to dive into, feel free to comment bellow.

Quality control and programming

contato@felipebosi.com — Thu, 09 Jul 2026 00:00:00 GMT

5S is a well known quality system developed is Japan after the Second World War to guarantee that the company using it was delivering the best quality products they could while creating a good work environment.

One of the most famous company using the 5S system is Toyota. We could say that the system focus on manufacture companies. However, it also appear, by indirect means, on code quality books like the "Clean Code" and can help tech companies achieve a better code delivery by creating a work system around 5S' principles.

The 5 principles

1. Seiri or “Remove unneeded”

Seiri is sorting all items and removing anything unnecessary by tossing it away. The ideia is to create an environment where is easy to find anything needed, avoiding distraction by unused item and/or trash. Anything unnecessary should be removed from the environment.

Based on this system, we should remove any unused code from our base. That means any code that is commented out (You ain't gonna need it), any comments that doesn't explain anything, and, of course, any code that doesn't do anything or that isn't even called on the rest of the code base. If the commented code is something you know you’ll need on the future, you can create a new branch and commit it; use some good commit messages to know where to find the commit where you removed it; or just put the commit hash on a note that you know where to find.

On the computer side, clean out your editor. Do you have more plugins than you need? Is there any browser tabs that you can close, emails that you can delete? If you are a terminal person, check you dotfiles, alias and folders too. There is always something you can remove to keep things cleaner.

You can also apply this to your working desk. Remove any unnecessary item that could be cluttering your desk. Trash it or put it on a place where it can be accessed when needed, in case it isn’t an item that you used everyday, but you know you’ll need on the future. Keep a clean desk with only the necessary items on it. But keep in mind that only you can decide what is necessary or important to you.

2. Seiton (Set in Order)

This principle aims to organize anything that was defined that is necessary but is out of place or is hard to understand its use. This creates a smoother work flow, where everyone knows what anything is based on a categorized system.

Thinking on a code environment, our folder system should use names that are easy to understand and every piece of code has to be on a folder that is related to the category that code should. The same is valid for file names, functions and classes. That means that we must avoid using names that has lose meaning, like "utils" and "helpers", because it’s like putting it on a bland deposit, who knows what could be inside of it?

This also means creating a system that helps devs to categorize their code. Be it MVC, MVVM, Hexagonal architecture, or any other system. The important here is that the system helps everyone to categorize and then find a piece of code. There is less “I think it would be nice for it to be here” and more “We are using a MVC system and this is a controller, so it should be on the controllers folder” type of thinking.

On my personal projects, I’m more of a person that prefers recursive architectures, where you can separate better what is specific of a subsystem, instead of always using globalized folders. You can imagine it like a project where when you enters a specific feature folder, you see a mini MVC inside of it, and that feature is separated in modules where each module has more mini MVCs.

On your digital space, we can use this principle to categorize the files in you computer or even on social media. Are you mixing up stuff? Is there photos on you videos folder? Did you publish something on the wrong social media? Here is where you recategorize stuff and put them where they should be, or a place where you can find them later.

Now on your physical space, you can use this principle to organize the things that you decided to keep on your room or office, but not on your desk. The ideal is to find a place to store them, but a place that you’ll always know a specific type of thing will always be there. This way you avoid re-cluttering your desk to keep things near you that you fear you won’t be able to find them again when you need them.

A good principle is to keep the items you use the most near you and on an easy place to see and the less and less you use something, the far and hidden you can put them. If you are a pen and paper person, you can keep a single notebook and pen near you, and you can put spare notebook and pens on a box or other place where you know you can find them when you finish using the current ones. My bigger organizing categories are:

Visible on my desk, for things that I use everyday and want to have them on my sight, this goes from the basic computer stuff to teaware, since I like tea. Here I also put some toys that I like to see to remind me of what I like and to try to avoid to take things too seriously
Near my desk, but not visible, I put things that I use a lot, but I don't need them to be visible, like fidget toys, medicine, paper and pens
Visible, but not near my desk, is for things that I use outside of work or that I bring to my desk to use them for a while and them put them back to their places. Here you’ll see books, old notebooks, more teaware, games and different keyboards
Almost hidden. I say almost, because they are boxes that I know what is inside of them. I just don't keep them visible or near me. On them you’ll spare notebooks, more boxes with documents, spare desk pads, spare mouses and keyboard pieces, in case I want to customize one or fix it.

3. Seiso (Shine/Polish)

Seiso is cleaning and maintaining the workplace, equipment and machinery. This helps a company avoid accidents, by keeping everything is place and working as it should. Also, anyone that keeps cleaning their tools, are more able to see when anything isn't working as it was supposed to be.

On a smaller picture, it's our job to keep our code tight, clean and organized. This principle means that you need to make sure you did you best to clean any mess you made while trying to find a solution, fix a bug or implement. Make your code the best you can make before opening a PR.

However, as we keep working, our code will get messier. We'll do some minor changes that shouldn't be made or make some poor choices to solve some bugs that we need to solve that exact moment. This are actions that we take for a reason, but that asks for a bigger and more thoughtful solution to clean them out. If we don't come back and clean all these problems, our code can get hard to read, or lose performance. The natural state of any code is to get "dirtier" as we keep working on it. So, the process of cleaning it is just a natural response that we need to do to keep it clean. We already know this and we, as devs, already gave a name to it, technical debt.

Dealing with technical debt is a problem that happens on every company. Should I open a ticket to solve it on the future? Should I just clean as I see it? Should the company reserve a time to do it on every sprint or week? Those questions are hard to give an answer, because that will depends on a lot of variables. The principle only tells you about the benefit of keeping things clean, that, translating to a software environment, would mean less bugs, security issues and weird behaviors. This needs to be a company and/or team effort to clean past mistakes. The physical equivalent of this is the need that companies have of a cleaning team to deal with bigger things, while you keep your desk clean.

Which brings me to our desks. We also need to keep them clean. Now that we decluttered them, we need to clean them. On the process of clean, notice if anything needs a fix. If you use a mechanical keyboard, check if all keys are good. Clean you keyboard and remove the caps. Check your mouse. See if you need to replace any pens, fill in any fountain pens.

Back to the computer side, take a look at your tools. Is there any where you can make them simpler. A script that can be refactored. A plugin that you can trade for a different one that does the same thing better?

4. Seiketsu (Standardize)

Standardize any process, including the process to maintain the three principles above. On here we can also add standards for tests, for what programming paradigm your company will be using. Add/create any standard that can help programmers code faster and maintain the code base.

Here is where code shines. I like to think that standardize is automatization for the physical world and for us. With it you already know what to do and stop thinking where I should put this. Instead of “where this photo should be” you start thinking “of course the photo should be on the photos folder and categorized by year/place”.

For code, we have linting tools to really automatize that for us. In this case you don't even have to know the standard. The computer will tell you or even fix that for you. You can also create scripts that will help you. Scripts that renames files and put them on the correct folder.

The important thing here is to make all the processes that you made above a rotine. You can automatize some of them and put the rest on a schedule, be it daily, weekly or monthly. It's up to you.

5. Shitsuke (Self-discipline/Sustain)

The last principle, but not less important, is related to self-discipline or to how can we sustain all the other 4 principles. Some people also translate this principle as "doing without being told".

The first part of it is having the discipline to maintain the other four principles. However, this principle also incorporate the study and training that is necessary to be able to always be better. Another important part of this is receive and giving feedback, specially from those that is on the front-line of the work, on our case, the developers and designers.

That is why this is the last principle as it closes the circle. This principle is a way to say to you that you need to go back to the first principle again and do it a little bit better. It not only asks you to simply repeat, but repeat in a mindful way, keeping attention to where you can make it better. The important thing is keep trying and appreciate that you’ll always come back able to be better.

What code can say

contato@felipebosi.com — Wed, 08 Jul 2026 00:00:00 GMT

In my latest article, I talked about literacy and how understanding code makes you see the world in another way. There we uncovered how the ability to read and write code can make you see technology through a different perspective. Like when you learn to read and write, a new world opens to you. Code is a language and as it happens with all languages, there are people trying to get it to the limit. This limit can be technical / logical or poetic.

Continuing my readings of Soon’s and Cox’s Aesthetic Programming book, I was faced with the software artwork Vocable Code made by Winnie Soon, one of the book authors. In this work both the result of the code and the code itself are the final art, where the code functions as a sort of counterpoint to what we get if we run the code. Below you can see the full code and we'll break it and analyze each part of it and the meaning behind each name (the code is also available on Gitlab):

The code above is a js code made to run using p5js, a library whose focus is to help artists and devs trying to create digital art. On the code we can see some functions that the library makes available globally and uses to draw and load data on the browser. The ones that does that are preload, setup and draw. We won't be talking about them here, but you can read more on the links above.

Now, from what Soon created we have some global variables set on the beginning of the code: withPride, whatisQueer, queerRights, makingStatements, speak, voices, and queers. From these variables we already know that she wants to talk about queer pride, queer rights and voices. Other data available globally are the makeVisible, SpeakingCode, speakingNow and notNew functions. From this, one thing that gets attention is that although it's a function, SpeakingCode is written in pascal case, instead of camel case. Another thing is the notNew function that acts as a sort of constructor that has some attributes attached to it.

However, even if the deconstruction above helps to understand better the code, what we have here is also a poem and we'll understand it better if we also read it line by line (poems can be read in different ways, so there is no harm in breaking them, separating and doing your own thing). Now going by parts:

On the preload function, the code is loading the Type with pride font, a font created in honor of Gilbert Baker, the creator of the rainbow flag. It's also loading a json file with a list of statements. In here we see the repetition of the queer theme and a preamble of how it will be treated, by the pride and recognition point of view.

On the makeVisible part, that I cleaned from its comments to make it easier to read as a poetry, we see that making it visible is assigning the queers and make statements until the queer rights are visible and its accepted that there are at least as many genders as there are new queers. On it we can also see that the author avoided to use integers almost everytime a number apears, using float instead. The only case she does that is on the if (gender == abs(2)).

abs is a p5js function that gets the absolute value of a number. In this case the function isn't necessary, since 2 is already its own absolute value, but as the Aesthetic Programming authors says on their book, "Read aloud, the block of code might translate as: 'If gender equals absolute two, speaking code, queers, who is queer, I am, making statements.'". So what we have is that the abs function adds a new layer of meaning to this part of the code saying that while gender is considered absolute two (a.k.a. we only have two genders and nothing else is acceptable), queers need to speak and make statements.

The next part I want to call out is the draw function. This is where the visual part starts. The draw function is called 60 times per second by p5js, making the art piece works at 60 frames per second. It has a for loop the parses for every queerRights and an if statement that calls the makeVisible function that we read above in the case queerRights has less than two members.

Before going on this line by line, I want to call attention to the use of notFalse here and the use of 2.0. Both are here to avoid the use of binary values. In this case true, false, 0, 1, and 2. Since the author is talking about queer and queer rights, she is making another statement about existing more than a binary reality, evoking non-binary logic or many-valued logic, like Paraconsistent logic. However, the main meaning here is that there are more than two possible values and that we need to make them visible.

By the if statement, we also get that we'll never have more than three queerRights. Again, the author could have selected two rights, but decided to go with a number that goes against binary.

Now for the for loop, we get that "queer rights non binary world wide", "queer rights non binary acts", "let support equals queer rights non binary shows". By the text itself, we get that queer rights is something that needs to be thought about in a world wide setting, and to get that, we need to act and show support.

Another thing is that worldWide, act and shows are all functions that exist inside the notNew sort of class thing. If we go back to the makeVisible function we'll see that it instantiates new queers using the notNew function. The idea is to emphasize that, although it may look new to people outside of the queer movement, they aren't new at all, they are just finally making statements, fighting to make themselves visible.

There is more that can be said about this code. However, my focus here was just to show how code can be more than simple rules that a computer must follow. I would even say that code is always more than a set of steps. That is why programmers like to talk about code readability, clean code, coding languages that are easier to read or that it's verbose. A code poem only makes it more visible that there is more than a single layer on the languages that we use to create a digital landscape.

Expanded literacy and the current state of software

contato@felipebosi.com — Mon, 06 Jul 2026 00:00:00 GMT

While reading Soon’s and Cox’s Aesthetic Programming book, I was faced with the “expanded literacy” concept that made me think on how different people see software.

Expanded literacy is the ability to write and read expanded with the ability to understand code. This extra literacy is linked to a better understanding of digital media and how our communication is being enhanced by new forms of writing languages. New languages that communicate both with programmers and that starts an action on a machine or online system.

Understanding how a computer and code works is one of the things that separates people that see software, AI, and similar things as a magical black box that can do anything that you want without any costs from the ones that understand the limits and costs of technology. Any software works on a set of commands that programmers give to a computer and the computer obeys them exactly as it is written. AI If you want to see this in a more visual and comical way, take a look at Josh Darnit’s video:

This is even true to Large Language Model and generative AI. For these cases, you can imagine that we have a program that generates a program/code based on the training data that it receives. This has a large cost on energy and manual work to tell the model what is correct and what is wrong, otherwise you'll end up telling your users that “Doctors recommend smoking 2-3 cigarettes per day during pregnancy.”

Coming back to the expanded literacy idea, programmers know that a code written by a programmer, specially a senior one, has better performance and readability than a machine generated one. In non-coder terms, this means that a code written by someone costs less energy and we can understand better what it means and fix it, not only in terms of bugs that break the app, but also in terms of ethical consequences, like biased AI, people being able to use AI to teach them to build weapons or getting away with crimes ( For more read: "AI has a racism problem, but fixing it is complicated, say experts"and "Could a Chatbot Teach You How to Build a Dirty Bomb?"), or even hallucinations and strait up lies.

AI is a hot topic these days, but let’s focus on expanded literacy and differences between coders and non-coders that impacts everyone.

One thing that you'll see that is common among developers is that the “user doesn't care about the language that is used to build something” or “the best language is the one that pays my bills”, and I would say that both are correct. But that is only because the user doesn't have code literacy. However, the final user is directly impacted by the code, language and technology choices that we make. Even financially. The users start to feel that their computer or phone is “getting slower” and decide to buy a new one. Some of this can be credited to hardware getting older, but a lot more can be credited to these language, framework, paradigm and technology selection.

Although the user doesn't care about how we build the software that they use, this impacts how long a piece of hardware will survive, the amount of energy we use from their battery, and even the speed in which an action will take (for a detailed study, go to "Ranking programming languages by energy efficiency"). While users don't care about how software is made, most companies will try to cut corners and sell slow software as “blazing fast”. A term familiar to programmers, that in reality can mean anything from very slow to really fast, only the programmers that can check what is under the hood can tell which it is.

While users keep avoiding learning how computers and software works, companies will do their best to achieve a better revenue at the cost of the user's own money and our environment. Selling fake promises of a future where anything can be generated using natural language at low cost, while in reality we are forced to buy new computers and phones to keep up with trends we never asked for and that we don’t get any benefits from.