标签：#beginners

What working on real systems taught me about maintainable code. My second job was the first time I worked with an international team where everyone had ten or more years of experience. I had maybe two. It was also the first time I was part of proper code reviews, branching strategies, and pull request workflows. Everything felt new and slightly intimidating. One of my first tasks was adding spacing between two elements. It should have been a simple margin or padding change, but I added a <br> tag instead. The feedback on that PR was polite but clear, and it made me a little embarrassed. That moment, along with dozens of similar ones, made me want to get better. I started reading about clean code and caring deeply about how my code looked. Small functions, no repetition, everything abstracted and organized. For a while, that served me well. It helped me grow from a junior developer into someone who could write code that passed review without a wall of comments. But over time, as I worked on larger systems with real users and real constraints, I started noticing that the rules I had learned didn't always hold up. Sometimes the "clean" approach made things worse, and sometimes messy-looking code worked better than the elegant version I would have written. This post is about how my definition of clean code expanded. I still believe in the principles I learned early on. I'd just add a few things to them now. What I thought clean code meant When I first started paying attention to code quality, my idea of clean code was mostly about appearances. If the code looked organized and followed certain patterns, it was clean. If it didn't, it wasn't. I believed in small functions for everything. If a function was longer than fifteen or twenty lines, something was wrong. I would extract pieces into helpers even when they were only used once, just because the parent function felt "too long." I was strict about DRY. Any time I saw similar logic in two places, I would immediately pul

Most developers building frontend applications spend a lot of time writing code that communicates with their backend due to the traditional approach (using APIs). This is not because the logic is hard to implement, but because the communication itself is complex. When using standard APIs, we build routes, define request and response models, generate clients, and keep multiple layers on track with application updates. Instead of exposing backend functionality through REST endpoints and consuming it through HTTP clients, Graftcode exposes backend methods directly and generates packages that applications can install and use as dependencies. The result is a communication model that is like you are calling a library rather than consuming an API with strongly typed clients. Working with Graftcode is very simple: install your library and call its functions. In this article, we'll be building a simple task tracker or to-do list application using React and a TypeScript backend to see what working with Graftcode looks like. In this blog post, we will learn the following: Why API layers require you to maintain APIs manually How Graftcode exposes backend functionality through Graftcode Gateway How Graftcode Vision helps discover backend capabilities Familiarity with APIs and fetch() requests How React applications can use TypeScript backend logic without building API routes Why strongly-typed backend packages can improve developer experience Prerequisites Let’s get our hands a bit dirty, but before we do, there are some need-to-haves to get you started. Let’s have a look at that in this section: Latest Node version installed on your machine Basic knowledge of React and TypeScript Familiarity with how APIs and fetch requests work (for understanding how easy Graftcode’s approach is) A Graftcode account Graftcode gateway installed on your local machine With these prerequisites, you’ll first understand why most to-do list applications rely heavily on APIs for their logic and what c

Faz mais de 5 anos que eu não abria um PR ou issue técnica no Github, mas essa semana tenho aprendido algumas boas práticas e termos que reuni neste artigo. Introdução Essa semana eu fiz uma coisa simples: atualizei o README de um projeto open source, o 4noobs , da comunidade He4rt. Troquei um badge, ajustei o contraste de um logo, organizei umas pastas e adicionei um índice pra facilitar a navegação. Nada muito complexo no fim das contas. Só que antes de chegar no "nada muito complexo", eu passei um tempo enrolada com uma pergunta boba: "E se eu mandar isso direto pra branch principal e bagunçar tudo?" Se tu já sentiu esse friozinho na barriga antes de mexer num repositório que não é só teu, esse artigo é pra ti. Não importa se tu é dev há anos ou se nunca abriu um terminal na vida... A lógica por trás de "como contribuir sem quebrar nada" é a mesma e bem mais simples do que parece. Definição de Git Colaborativo Quando eu aprendi git há uns anos, aprendi somente o versionamento e a enviar os arquivos pra dentro do Github, mas ele é bem mais que isso, né? É através dele que times enormes interagem a respeito de um mesmo projeto de forma organizada, comentando, gerenciando tarefas, sugerindo melhorias e conhecendo o que os outros envolvidos estão fazendo. Isso é a parte do Git Colaborativo . O Git resolve isso com um conceito central: branches (ou "ramificações"). Cada branch é tipo uma cópia paralela do projeto, onde tu pode mexer à vontade sem afetar a versão "oficial" (geralmente chamada de main ou master ). Quando tu termina sua parte, tu propõe que essas mudanças sejam incorporadas de volta pelo Pull Request (PR) . Ou seja, o fluxo básico é: Tu cria uma branch nova a partir do projeto principal Faz as alterações lá, no seu espaço isolado Envia ( push ) essa branch pro repositório remoto Abre um Pull Request pedindo pra essas mudanças serem revisadas e, se aprovadas, unidas ( merge ) à branch principal Ninguém mexe direto na versão "de produção" do projeto. Isso

Adapted from the Command Line Essentials Companion Guide . You install something, open a fresh terminal, type the command, and get bash: python3: command not found — or on Windows, 'python3' is not recognized as an internal or external command . The installer said it finished successfully. You can probably even find the program in your applications folder. And yet the terminal insists it doesn't exist. The instinct at this point is usually to reinstall, or install a second copy from somewhere else, hoping one of them "takes." That almost never fixes it, because reinstalling doesn't address what's actually wrong. What the error is actually telling you When you type a command, the shell doesn't scan your whole computer looking for it. It checks a specific, ordered list of directories — stored in an environment variable called PATH — and stops at the first match it finds. command not found doesn't mean the program doesn't exist anywhere on your machine. It means none of the directories in that list happen to contain it. That distinction matters, because it splits into three genuinely different problems: A typo. gerp isn't a command; grep is. This is the most common cause by a wide margin, and the easiest to rule out first. It isn't installed at all. The program genuinely doesn't exist on this machine yet. It's installed, but not somewhere the shell is looking. This is the one that catches people off guard — the software is sitting on disk, correctly installed, just outside every directory PATH currently checks. Reinstalling only ever fixes cause 2. If your actual problem is 1 or 3, a second install just gives you a second copy of a program that was never the issue. The fix, step by step Check for a typo first. Read the command back character by character. It sounds too simple to be worth a step, but it resolves this error more often than everything else combined. Confirm whether it's installed at all , independent of whether the shell can currently find it: which pytho

Subnetting errors rarely announce themselves as "bad math." More often, two devices make different decisions about whether a destination is local, a route points at the wrong boundary, or a cloud/VPN design contains two networks that cannot be unambiguously routed. These five failure modes are worth recognizing in live configurations. 1. The two hosts use different masks Consider Host A at 192.168.10.10/24 and Host B at 192.168.11.10/16 . A calculates that B is outside 192.168.10.0/24 , so A sends the packet to its default gateway. B calculates that A is inside 192.168.0.0/16 , so B treats A as local and tries ARP directly. The result can be asymmetric: one direction follows a router, while the reply is sent directly or never reaches the expected gateway. Check the actual prefix on both interfaces, not just the dotted decimal mask shown in a diagram. ip -br addr ip route ping -c 3 192.168.11.10 Correct the prefix so both endpoints agree, or intentionally route between two correctly defined subnets. 2. Overlapping subnets are assigned to different networks Suppose a branch uses 10.20.0.0/16 , while a cloud VPC or VPN peer also uses 10.20.0.0/16 . The problem is not that either mask is mathematically invalid. The problem is that a router cannot distinguish "the branch's 10.20.5.0/24 " from "the cloud's 10.20.5.0/24 " if both are reachable through different paths. Symptoms include traffic taking the wrong tunnel, routes that cannot be installed, or a VPN that connects but cannot reach some subnets. Inventory both sides of a tunnel and compare the complete network/prefix pairs. A longer, more specific route may make one destination appear to work while hiding the underlying overlap. ip route ip route get 10.20.5.25 traceroute -n 10.20.5.25 The durable correction is renumbering or using an intentional translation/design boundary. Adding increasingly specific routes is usually a brittle workaround. This is also why I prefer teaching subnetting inside routing and troublesh

If you’re juggling multiple Copilot sessions, use the My work pane to track what's in flight, what's done, and what's next. The post GitHub Copilot app for Beginners: Managing your work appeared first on The GitHub Blog .

Traditional monitoring rests on one quiet assumption that nobody ever writes down: the same input gives you the same output. Something breaks, you replay the request, you watch it break again, you fix it. Now send the same request to a model twice. You get two different answers, and neither one of them threw an error. AI observability is the practice of recording what happened inside an AI system on every request: the prompt, the model version, tokens, cost, latency, tool calls, and a judgement of whether the output was any good. Monitoring tells you the service is up. Observability tells you why it answered that way. That gap is the whole story here. Why your current monitoring stack misses all of this Your existing setup is watching for crashes. Status codes, error rates, p99 latency, memory. All of it is designed around the idea that a broken thing looks broken. An AI feature failing looks nothing like that. It returns HTTP 200 in 900ms, with grammatically perfect prose that happens to be wrong, or that quietly ignored the document you retrieved for it, or that called the refund tool when the user only asked a question. Your dashboard sees a healthy service, because by every measure it has, the service is healthy. And there are whole categories of failure your stack has no field for. It has nowhere to put "this response cost 14 cents", or "the model version changed under us last Tuesday", or "the retrieved context was garbage". Those are not infrastructure facts, and standard telemetry was never built to carry them. Something has to hold those fields instead, which is the entire reason this tooling exists. My team uses Bifrost , so I will use it as the example throughout this post. It's an open-source AI gateway from Maxim, so anything I claim about what it records per request is something you can go check line by line. Most tools here put their telemetry story on a marketing page and stop there. What one AI request actually looks like when you trace it This is t

What Is Software Testing? 🧪 Software testing is the process of checking software to make sure it works correctly and does what it is supposed to do. For example, when we use a login page, we can test: Correct username and password Wrong password Empty username Empty password Forgot password option The goal is to find bugs and problems before the software is used by customers. Why Is Testing Important? Testing helps developers and companies: Find bugs Improve software quality Provide a better user experience Prevent problems after release Even a small bug can sometimes cause a big problem, so testing is an important part of software development. Manual Testing In manual testing, a tester checks the application manually without using automation scripts. For example, a tester can open a website, enter different inputs, click buttons, and check whether the expected result appears. Automation Testing In automation testing, we use tools and programming to test software automatically. Some popular tools are: Selenium Playwright Cypress Automation is useful when the same tests need to be performed many times. Conclusion Software testing is an important part of creating reliable software. If you are a beginner, you can start with manual testing , then learn SQL, API testing, and automation testing .

🌐 Network Devices Explained The Foundation Every Cloud & DevOps Engineer Needs Series: Networking Fundamentals for Cloud & DevOps — Part 1 of 6 Before VPCs, subnets, route tables, and security groups make sense, you need to understand what's happening beneath them. This series builds that foundation — starting with the devices that make networks work. Why Networking Before Cloud? I hit a wall during my AWS VPC sessions. Route tables, subnets, gateways, NACLs — the concepts existed in isolation. I could follow steps in the console, but I couldn't reason about why traffic was or wasn't flowing. The fix wasn't more AWS documentation. It was going back to networking fundamentals. Once I understood what a router actually does — how it makes forwarding decisions, what a routing table really is — the AWS route table stopped being a mysterious config screen and became something I could think through. That's what this series is. Six posts covering the networking concepts that directly underpin Cloud and DevOps work. No exam prep framing, no CCNA depth. Just what you actually need. 1. What is a Host? A host is any device that participates in network communication by sending or receiving traffic. That's broader than most people assume. Examples: your laptop, your phone, an EC2 instance, a web server, a virtual machine. The word "host" doesn't imply a server — your laptop is a host just as much as a data center machine is. 2. Client vs Server — Roles, Not Hardware A client is a host that initiates a request. A server is a host that responds. The critical point: a server is not a special type of computer . It's just a computer running software that listens and responds. Your Browser (Client) │ │ HTTP Request ▼ Web Server (Server) │ │ HTTP Response ▼ Your Browser (Client) The same machine can be a client in one communication and a server in another. Your EC2 running a web app is a server to users hitting it — and a client when it queries RDS. 3. IP Address — The Network Identity

If you have generated a pure tone in code and played it back, you may have noticed a small click at the start, the end, or both. The tone itself is clean, but the edges are not. That click is not a bug in your sine wave. It is a real and well understood artifact, and the fix is a technique you will reuse in every sound you ever synthesize: an envelope. This piece builds directly on generating a basic tone from scratch . We take a tone that clicks, look at the actual sample values to see why, and apply an envelope to smooth it. Everything is plain C++ with no libraries, and every number here is captured from a real run of the code. Where the click comes from A tone is a list of samples tracing a sine wave. A speaker turns those samples into sound by physically moving: the sample value sets the position of the speaker cone at each instant, where 0 is its resting position and larger values push it further forward or pull it back. Playing the tone moves the cone in and out 44,100 times a second to recreate the wave. When playback starts, the cone is at rest, at position 0. But the first sample of the tone is usually not 0. It is wherever the wave happens to be at that instant, and if that value is far from zero, the cone has to move from rest to that position in a single sample step, about 22 microseconds at this sample rate. That near instant movement is the click. A cone moving gradually pushes the air smoothly and produces a smooth sound. A cone forced to a distant position in one sample makes a sharp, abrupt movement of the air, which your ear hears as a click or pop. You can see it directly in the numbers. Here are the first six samples of a plain 440 Hz tone at half amplitude: n=0 raw=0 n=1 raw=1026 n=2 raw=2048 n=3 raw=3063 n=4 raw=4065 n=5 raw=5051 The wave leaves zero and climbs fast. Between the silence before playback and sample 1, the signal jumps by 1026 in one step. The same thing happens at the end: if the tone stops while the wave is partway through a cy

By the end of this page you can pick the right chart in about five seconds, by asking one question: what comparison must the reader make? The four possible answers each map to one chart, and you will also know the two miscasts that cause most bad charts, the axis rules that keep bars honest, and the escape hatch for when one chart holds too much. It is about twenty minutes. Here is what to actually do with it today. Open the last chart you made. Say out loud what the reader is supposed to compare in it. If the chart type does not match that comparison in the table below, remake it. It is usually a two-minute fix. The short version: comparison across categories takes a bar. Change over time takes a line. Relationship between two measures takes a scatter. Part of a whole takes a bar too, once you pass a few slices. One picture carries the fork, so it comes first. The original carries a diagram here. In words: A decision fork. On the left, a single rounded node contains the question: compare what? Four lines branch from it to four small chart pictures on the right, stacked vertically. The first branch, labelled categories, leads to a miniature bar chart with four vertical bars of different heights. The second branch, labelled time, leads to a miniature line chart with a single rising line over an axis. The third branch, labelled relationship, leads to a miniature scatter plot of dots drifting upward to the right. The fourth branch, labelled parts, leads to a miniature horizontal stacked bar divided into segments, drawn next to a small crossed-out pie, meaning that for part-of-whole comparisons a bar is preferred over a pie. The picture says that the single question of what the reader must compare selects one of four chart types. Every number on this page is computed. The example tables are shown in full, and every total, percentage, and correlation was verified by running the arithmetic in Python before it went on the page. 1. The one question, and the decision table B

By the end of this page you can read a budget vs actual table without being fooled by it, and build one in Excel that does not fool anyone else. You will know the variance formula, why analysts write F and U instead of trusting plus and minus, the two ways percent variance lies, and how to say the whole table in one sentence. It is about twenty minutes. Here is what to actually do today. Open the last variance table you were sent and find its biggest percentage. Then find its biggest dollar amount. If they are different rows, and they usually are, you now know which row deserved the attention, and it is probably not the one that got it. The short version: variance is actual minus budget. On a revenue line, positive is good. On a cost line, positive is bad. So analysts label every line F for favorable or U for unfavorable, rank by dollars, and flag by percent. The sign flip is the trap people fall into first, so it gets the picture. The original carries a diagram here. In words: Two panels, each showing a pair of vertical bars rising from a shared baseline. In the left panel, labeled revenue, a shorter bar marked budget stands next to a taller bar marked actual. The extra height of the actual bar above the budget level is shaded in the accent color and marked with the letter F and a check mark, because collecting more revenue than budgeted is favorable. In the right panel, labeled cost, the bars have the same shapes: a shorter budget bar next to a taller actual bar. But here the extra height above budget is shaded in the warning color and marked with the letter U and a cross, because spending more than budgeted is unfavorable. A dashed horizontal line runs across each panel at the budget height. The two panels are geometrically identical, and only the meaning of the line decides whether the overshoot is good or bad. That is why the sign of a variance cannot be read without knowing the line type. Every number on this page is verified. The worked example is a small dep

By the end of this page you can say, out loud and in your own words, what every core operations number does. What the unit of work is. Throughput, and why a count on its own answers nothing. Cycle time, and the rule that ties it to how much work is sitting open. Backlog. Utilization, and why aiming for 100 percent makes everything slower. Error rate, rework and first pass yield. Service levels, and why the average hides the customers you are failing. That list is most of what an operations analyst job, a technical screen, and a first real dataset will ask of you. Here is what to actually do with it. Go through once end to end without stopping, just for the shape. Then come back to the retrieval sheet near the bottom, cover the right-hand column, and try to say each answer before you read it. That second pass is where the learning happens, and there is measured evidence for it further down. The short version: operations analytics is the study of how work moves through a process. Every number in it is either how much, how fast, how much is stuck, or how much was wrong. One idea decides more of your operations work than any other, so it gets the picture. Work arrives, waits, gets done, and leaves. How much is in progress and how long each item takes are two different spans over that same picture, and they are locked to each other. The original carries a diagram here. In words: A left-to-right process diagram. On the far left an arrow labelled "arriving" points into a row of three small stacked boxes labelled "waiting", representing a queue. An arrow leads from the queue into a single larger rounded box labelled "working", representing the person or machine doing the job. A final arrow leads out of that box to the right and is labelled "done". Above the queue and the working box, a bracket in a strong accent colour spans both and is labelled "in progress", showing that work in progress includes everything waiting as well as everything actively being worked on. Below, a

When this workbook is finished, you can change one number and watch the whole thing follow. Move a cut-off from 65 to 70 and every row re-bands, every fill recolors, every count updates, and the legend still matches the map. Nobody can color a cell by hand, because no cell has a color of its own. That is the whole trick, and it takes about twenty minutes to build. The example here is a security risk index across twenty sites. The same shape works for vendor scoring, lead scoring, incident triage, or any list where a number has to turn into a label and a color. The fault, and where it actually comes from You have met this file. A scored list, colored by hand, that nobody quite trusts any more. Look closely and the same faults turn up every time: Two rows score 61.4. One is amber, one is yellow. The same band is drawn in two shades, because two people picked from the palette on two different days. A row sits below the cut-off and is colored red anyway, because somebody knew that site was a problem. A score lands exactly on 65, which appears in two bands, so the answer depends on who typed it. One row has no band at all. It quietly drops out of every count. These look like five separate mistakes. They are one mistake, five times. The rule lives in the formatting instead of in a column. A color is not a value you can test. You cannot write a formula that asks "is this row the right shade of amber," so nothing checks it, and it drifts. The test: can you sort by band? If the band is only a color, you cannot sort it, count it, or filter it, and neither can anybody else. That is the tell. The chain: score, then band, then color Everything below is one idea applied three times. Each thing is derived from the thing before it, and only the first one is typed. Layer Where it lives Who decides it Sub-scores Four columns, one per category Your source data. Typed once. Composite score A formula, from the sub-scores and the weights The weights row Band A formula, from the score The

I don't star GitHub repositories just because they are popular. A repository earns a star from me when I can see myself returning to it later. Maybe it solves a real engineering problem. Maybe it introduces a new architecture. Maybe the code teaches me something. Or maybe it represents where AI development is heading. I've been spending a lot of time exploring AI repositories around agents, workflows, RAG, MCP, browser automation, model training, and API development. These are seven repositories that stood out to me recently. Not because you need all seven. But because each one represents an important direction in AI development. 1. OpenAI Cookbook Repository: https://github.com/openai/openai-cookbook If you're building with the OpenAI API, this is one repository I would keep bookmarked. The OpenAI Cookbook contains practical examples and guides covering common API development tasks, with many examples written in Python. What I particularly like is the implementation-first approach. Instead of spending hours reading theoretical explanations, you can study working examples and adapt them to your own application. It's useful for: API integration Structured outputs Embeddings Agents Evaluations Multimodal applications For beginners, it can also serve as a bridge between understanding an AI concept and actually implementing it. 2. LangChain Repository: https://github.com/langchain-ai/langchain LangChain remains one of the most important repositories in the LLM application ecosystem. But I don't recommend it simply because it is popular. I recommend understanding it because it exposes you to the building blocks behind modern AI applications. Models. Tools. Retrievers. Agents. Integrations. Structured outputs. If you're serious about AI engineering, studying how these components fit together is valuable even if you eventually choose another framework. 3. LangGraph Repository: https://github.com/langchain-ai/langgraph This is probably one of the repositories I would recomm

Every programmer wants to improve. We all dream about becoming the person who can look at a...

This is a submission for Weekend Challenge: Dog Days Edition What I Built Dogs have...

var is one of the ways to create a variable in JavaScript. A variable is a place to store a value, like a name or a number. var is mostly seen in old JavaScript code, written before 2015. Today most people use let and const instead, but it still helps to know var , especially when reading old code. Creating a Variable var name = " Abishek " ; var age = 22 ; console . log ( name ); console . log ( age ); Here, name stores "Abishek" and age stores 22 . We Can Change the Value var age = 22 ; age = 23 ; console . log ( age ); The output is 23 . The value inside age got updated. We Can Also Create it Again We can create the same variable a second time with var , and JavaScript does not give an error. var name = " Abishek " ; var name = " Abi " ; console . log ( name ); The output is Abi . It just overwrites the old value. It Works Across the Whole Function A block is a small part of code inside { } , like an if statement. var does not care about these small blocks, it only cares about the function. function test () { if ( true ) { var x = 10 ; } console . log ( x ); // works fine } test (); Even though x was created inside the if part, we can still use it outside the if , as long as we are inside the function. Hoisting console . log ( x ); var x = 10 ; You might expect an error here, but the output is undefined . This is because JavaScript moves the var declaration to the top before running the code. This is called hoisting. Why var Isn't Used Much Now Most people use let and const instead of var , because var can cause confusing bugs like accidental redeclaration and hoisting. let is used when the value can change, and const is used when it should not change. In Short var was the first way to create variables in JavaScript. It can be changed, redeclared, and it works across the whole function instead of one block. Once you understand var , let and const become easier to learn.

When I decided that I wanted to seriously start learning Artificial Intelligence, I quickly realized that one of the hardest parts wasn't finding resources. It was figuring out where to start. There are countless courses, YouTube playlists, roadmaps, tools, frameworks, and technologies to learn. Every time I looked at what other people were doing, I felt like there was something else I should be learning. So instead of trying to learn everything at once, I decided to create a roadmap for myself. This isn't a roadmap written by an AI expert or someone who has already mastered everything. It's simply the roadmap I'm following as a B.Tech Computer Science (Artificial Intelligence) student who is still learning. And I'm sharing it publicly because I want to document what works, what doesn't, and how my understanding changes along the way. Why I Decided to Learn AI Seriously I'm studying Computer Science with Artificial Intelligence, so AI has naturally become one of the areas I want to explore deeply. But for a long time, I didn't really know how to approach it. I knew that AI was important. I knew that Machine Learning, Deep Learning, and other AI technologies were becoming increasingly relevant. But knowing that something is important and actually learning it are two completely different things. After spending a lot of my first and second year without doing as much as I wanted, I realized that I couldn't keep waiting for the "right time" to begin. I had to start somewhere. So I decided to stop worrying about learning everything at once and focus on building my foundation first. Step 1: Strengthening My Programming Foundation Before jumping deeply into Machine Learning, I want to become more comfortable with programming. Python is one of the main languages I'm using for my AI journey because of how widely it is used in data science and Machine Learning. Alongside Python, I'm also learning C++ for Data Structures and Algorithms and working with Java for my college studi

Let's get something out of the way first. Having data is good. Having a database full of reviews, commits, and org activity sitting there quietly, untouched, unread, never once glanced at by a human being with a coffee and an opinion? That's not "having data." That's a very expensive data graveyard. At LiveReview , we build what we call a Blast-Radius Aware AI Code Review for Business-Critical Systems . Which is a fancy way of saying: we review your code, we figure out how bad it would be if a change goes wrong, and we don't shut up about it until someone fixes it. Along the way we accumulate a review data: who reviewed, how much, how fast, how often, which repos are on fire. And for a while, that pile just sat there. Engineering leaders would ask "is adoption increasing?" and get back a vibe, not an answer. So we built Livi , a chat bot that answers real questions about that data with real charts, not paragraphs of hedging. This post technically about how Livi draws those charts. Specifically: why we never let the LLM touch a pixel, how the same chart definition ends up as both a live interactive graph in your browser and a flat PNG in a Slack thread, and why teaching a language model to pick the right chart shape is a surprisingly deep rabbit hole. The core decision: don't ask the LLM to draw, ask it to describe The tempting, wrong idea is: "let's have the LLM generate an image." Please don't. Image-generating models are a different beast entirely, and even if you got one to draw a bar chart, you'd have no way to verify the numbers on it are real. You'd be trusting a model that hallucinates plausible-sounding review counts to also render them faithfully into pixels. That's not a chart, that's chart-shaped fan fiction. The actually good idea, and the one every serious LLM-charting integration eventually converges on, is: the LLM writes Vega-Lite , a JSON grammar for describing charts declaratively. You don't say "draw a blue bar going up." You say: { "mark" : "bar"