DEV Community: Lucy

I Built a Tool That Turns Any GitHub Repo Into an Interactive Dependency Graph: Here's Exactly How It Works

Lucy — Wed, 22 Apr 2026 21:16:47 +0000

A deep dive into the real pipeline behind CodeAtlas: AST parsing, import resolution, force-directed graphs, and everything in between.

When I join a new open source project, I do the same thing every time. I open the entry point, follow an import, open that file, follow another import, lose track of where I started, open the entry point again. Fifteen minutes later I have eight tabs open and a vague understanding of what the project does.

This is the default experience of reading code. It is also completely unnecessary.

Code is not text. Code is a graph. Every file has edges: its imports, pointing to other files. Every module sits inside a dependency structure that has a shape, and that shape tells you almost everything you need to know about how the codebase is organised. But virtually every tool we have forces us to experience that graph one node at a time, linearly, like reading a book.

I built CodeAtlas to fix this. It takes any GitHub repository URL, clones it, parses every file using two separate AST parsers, resolves every import to an actual file, builds a dependency graph, and renders it as an interactive force-directed visualisation. You can see the entire structure of a codebase in seconds, click any node to read the file in a Monaco editor, filter by depth, and understand architecture that would otherwise take hours to infer.

This post goes through every layer of how it actually works, using the real code.

GitHub: CodeAtlas

(link to live demo on GitHub page)

The Architecture at a Glance

CodeAtlas has three distinct layers:

Backend (server.js) — receives a GitHub URL, clones it with simple-git, indexes the file tree, resolves imports, and returns a graph JSON object via a REST endpoint.

Parsers (parser.js, parser_py.py) — two separate parsing pipelines: one using Babel’s AST for JavaScript and TypeScript files, one using Python’s standard library ast module for Python files.

Frontend (App.tsx) — React application that calls the API, formats the graph data, runs a BFS traversal for focus mode, and renders everything via a D3 force simulation with Monaco editor for file inspection.

Let me go through each in detail.

The Backend: Cloning, Indexing, and Graph Construction

Cloning

The entry point is a POST /analyze endpoint in server.js. The first thing it does is clone the repository:

async function cloneRepo(repoUrl) {
  await fs.remove(TEMP_DIR);
  await fs.mkdir(TEMP_DIR);
  await simpleGit().clone(repoUrl, TEMP_DIR, ["--depth", "1"]);
}

The --depth 1 flag is critical. A shallow clone fetches only the latest commit, not the full history. For large repositories this is the difference between a 2-second clone and a 45-second clone. CodeAtlas never needs git history: it only needs the current state of the files, so shallow cloning is always correct here.

fs-extra‘s remove call before mkdir ensures the temp directory is clean before each clone. Without this, a previous failed run could leave stale files that contaminate the new analysis.

File Tree Indexing

After cloning, buildIndex walks the file tree and builds a map of every relevant file and its raw imports:

function buildIndex(dir) {
  const index = {};

  function walk(folder) {
    const items = fs.readdirSync(folder, { withFileTypes: true });

    for (const item of items) {
      if (IGNORE.has(item.name)) continue;

      const fullPath = path.join(folder, item.name);

      if (item.isDirectory()) {
        walk(fullPath);
        continue;
      }

      if (!item.name.match(/\.(js|ts|tsx|py)$/)) continue;

      try {
        const content = fs.readFileSync(fullPath, "utf8");

        const imports = [
          ...content.matchAll(/from\s+['"](.*?)['"]/g),
          ...content.matchAll(/require\(['"](.*?)['"]\)/g),
        ].map(m => m[1]);

        const rel = path.relative(dir, fullPath);
        index[rel] = { imports: imports.slice(0, 30) };
      } catch (e) {}
    }
  }

  walk(dir);
  return index;
}

The IGNORE set is doing important work here:

const IGNORE = new Set([
  "node_modules", "dist", "build",
  ".git", "coverage", ".next", ".cache"
]);

node_modules alone can contain tens of thousands of files. Including it would make the graph useless… you’d be visualising the entire npm ecosystem rather than the project’s own code. dist and build are generated code that duplicates the source. .next contains Next.js build artefacts. None of these contain information about the project’s architecture.

The withFileTypes: true option on readdirSync is a performance detail worth noting. It returns Dirent objects which already know whether each entry is a file or directory, avoiding a separate stat call per entry. On repos with thousands of files this is meaningfully faster.

Import Resolution

Raw import strings like ./utils need to be resolved to actual files. The resolveImport function handles this:

function resolveImport(file, imp, allFiles) {
  if (!imp.startsWith(".")) return null;

  const base = path.dirname(file);

  const possiblePaths = [
    path.normalize(path.join(base, imp)),
    path.normalize(path.join(base, imp + ".js")),
    path.normalize(path.join(base, imp + ".ts")),
    path.normalize(path.join(base, imp + ".tsx")),
    path.normalize(path.join(base, imp, "index.js")),
    path.normalize(path.join(base, imp, "index.ts")),
  ];

  for (const p of possiblePaths) {
    if (allFiles.has(p)) return p;
  }

  return null;
}

The first thing it does is discard any import that doesn’t start with .. This filters out all third-party packages (react, lodash, express) which live in node_modules and aren’t part of the project’s own dependency graph. Only relative imports (starting with ./ or ../) represent relationships between the project’s own files.

The resolution order tries the import path as-is first, then appends common extensions, then checks for index files inside a directory of that name. This mirrors how Node.js’s own module resolution works, so it produces the same result as the runtime would.

allFiles is a Set: each resolution check is O(1). Multiply that across potentially thousands of imports in a large repo and the total resolution step stays fast.

Graph Construction

Once the index is built, indexToGraph assembles the final data structure:

function indexToGraph(index) {
  const fileList = Object.keys(index);
  const fileSet = new Set(fileList);

  const nodes = fileList.map(id => ({ id }));
  const links = [];

  for (const file of fileList) {
    for (const imp of index[file].imports) {
      const resolved = resolveImport(file, imp, fileSet);
      if (resolved) {
        links.push({ source: file, target: resolved });
      }
    }
  }

  return { nodes, links, backLinks: {} };
}

The graph format: nodes, links, backLinks, is designed specifically for D3’s force simulation on the frontend. nodes is an array of objects with an id. links is an array of { source, target } pairs using those same ids. backLinks is the reverse dependency index: for any given file, which files import it.

The JavaScript/TypeScript Parser: Babel AST

parser.js is the more powerful of the two parsers. Instead of regex, it uses Babel to parse source files into full Abstract Syntax Trees and then traverses those trees to extract imports.

An AST is a tree representation of source code where every construct e.g. a function declaration, an import statement, a variable assignment, becomes a typed node. Parsing text into an AST is the first step every compiler and linter performs. Using ASTs means the parser understands code structure rather than matching text patterns.

Parsing Files

export function parseFile(filePath) {
  try {
    const code = fs.readFileSync(filePath, "utf-8");

    const ast = parser.parse(code, {
      sourceType: "unambiguous",
      plugins: [
        "typescript",
        "jsx",
        "dynamicImport",
        "classProperties",
      ],
      errorRecovery: true,
    });

    const imports = [];

    traverse.default(ast, {
      ImportDeclaration({ node }) {
        imports.push(node.source.value);
      },
      CallExpression({ node }) {
        if (
          node.callee.name === "require" &&
          node.arguments.length === 1 &&
          node.arguments[0].type === "StringLiteral"
        ) {
          imports.push(node.arguments[0].value);
        }
      },
    });

    return imports;
  } catch (err) {
    return [];
  }
}

Several configuration decisions here are worth explaining.

sourceType: "unambiguous" tells Babel to figure out whether the file is a CommonJS module or an ES module by looking at whether it contains any import/export statements, rather than requiring you to specify upfront. Real codebases are messy and mix both styles.

errorRecovery: true is essential in practice. Real codebases contain files that don’t parse cleanly: files with experimental syntax, partially written code, or syntax errors that have been introduced but not yet caught. Without error recovery, one bad file would crash the entire parsing pipeline for the whole repo. With it, Babel does its best and returns whatever AST it can construct from the valid portions.

The CallExpression handler catches require() calls. These show up differently in the AST than import statements - they’re function calls rather than declarations - so they need their own handler. The check that node.callee.name === "require" and that the single argument is a StringLiteral ensures we only capture simple require('./path') patterns and not dynamic requires like require(getModuleName()).

Walking the Folder

parseFolderJS handles the file tree walk and graph construction for the JS/TS parser:

export function parseFolderJS(folderPath) {
  const graph = { nodes: [], links: [], backLinks: {} };
  const filesMap = {};

  function walk(dir) {
    const entries = fs.readdirSync(dir, { withFileTypes: true });
    for (let entry of entries) {
      if (IGNORE.has(entry.name)) continue;
      const fullPath = path.join(dir, entry.name);
      if (entry.isDirectory()) {
        walk(fullPath);
      } else if (entry.isFile() && fullPath.match(/\.(js|ts|jsx|tsx)$/)) {
        filesMap[fullPath] = fullPath;
      }
    }
  }

  walk(folderPath);

  for (let fullPath in filesMap) {
    const fileId = toRelative(fullPath);
    graph.nodes.push({ id: fileId });

    const imports = parseFile(fullPath);

    for (let imp of imports) {
      if (!imp.startsWith(".")) continue;

      let resolved = path.resolve(path.dirname(fullPath), imp);

      const possible = [
        resolved,
        resolved + ".ts",
        resolved + ".tsx",
        resolved + ".js",
        resolved + ".jsx",
        resolved + "/index.ts",
        resolved + "/index.tsx",
        resolved + "/index.js",
        resolved + "/index.jsx",
      ];

      const found = possible.find((p) => filesMap[p]);

      if (found) {
        const targetId = toRelative(found);
        graph.links.push({ source: fileId, target: targetId });

        if (!graph.backLinks[targetId]) graph.backLinks[targetId] = [];
        graph.backLinks[targetId].push(fileId);
      }
    }
  }

  // Deduplicate links
  graph.links = Array.from(
    new Set(graph.links.map((l) => `${l.source}->${l.target}`))
  ).map((str) => {
    const [source, target] = str.split("->");
    return { source, target };
  });

  return graph;
}

The filesMap object serves a dual purpose: it stores all file paths so they can be looked up during resolution, and its keys are exactly the absolute paths we need to check against during the possible.find() call.

Building backLinks inline during the main loop is efficient: each time a link is added forward (source → target), the reverse index is updated simultaneously. By the end of the loop, backLinks[file] contains every file that imports file, with no second pass needed.

The deduplication at the end handles a real edge case: a file might import from the same module in multiple ways, a static import at the top and a dynamic import inside a function, or two different named imports from the same module in separate import statements. Both would produce the same source → target edge. The Set-based deduplication collapses these into a single edge before the data reaches the frontend.

The Python Parser

parser_py.py handles Python repositories using Python’s own ast module:

def parse_file(file_path):
    with open(file_path, "r", encoding="utf-8") as f:
        try:
            tree = ast.parse(f.read(), filename=file_path)
        except Exception:
            return []

    imports = []

    for node in ast.walk(tree):
        if isinstance(node, ast.Import):
            for name in node.names:
                imports.append(name.name)
        elif isinstance(node, ast.ImportFrom):
            if node.module:
                imports.append(node.module)

    return imports

Python has two import syntaxes that map to different AST node types. import os produces an ast.Import node where node.names is a list of alias objects (there can be multiple: import os, sys). from pathlib import Path produces an ast.ImportFrom node where node.module is the module name being imported from.

The folder parser maps module names to file paths:

for imp in imports:
    target = imp.replace(".", "/") + ".py"

Python uses dots as namespace separators: from utils.helpers import something maps to utils/helpers.py. Replacing dots with slashes converts the module path back to a filesystem path. This is a heuristic: it works correctly for relative project imports but doesn’t distinguish between standard library imports (os, sys) and project files. Standard library modules simply won’t exist as files in the repo, so they produce dangling target nodes in the graph rather than edges to real files. This is an area for future improvement.

The Frontend: React, BFS, and D3

State Architecture

App.tsx is the application root and manages all state:

const [graphData, setGraphData] = useState<GraphData>(null);
const [selectedFile, setSelectedFile] = useState<string | null>(null);
const [fileContent, setFileContent] = useState<string | null>(null);
const [focusMode, setFocusMode] = useState(true);
const [depth, setDepth] = useState(2);
const [loading, setLoading] = useState(false);

graphData holds the raw graph from the API, the complete set of nodes and links for the entire repository. displayData is a derived version, computed by useMemo, that represents what’s actually shown in the graph at any given moment based on focus mode and depth settings. Separating raw data from display data means toggling focus mode or changing depth never triggers a new API call… it just recomputes the view over the existing data.

The API URL switches automatically based on the Vite environment flag:

const API = import.meta.env.DEV
  ? "http://localhost:8080"
  : "https://codeatlas-production-e4f8.up.railway.app";

API Response Normalisation

The handleAnalyze function contains some defensive normalisation worth explaining:

const graph = raw.graph ?? raw;

const formattedGraph: GraphData = {
  nodes: graph.nodes.map((n: any) =>
    typeof n === "string" ? { id: n } : n
  ),
  links: graph.links.map((l: any) => ({
    source: typeof l.source === "string" ? l.source : l.source?.id,
    target: typeof l.target === "string" ? l.target : l.target?.id,
  })),
  backLinks: graph.backLinks || {},
};

The raw.graph ?? raw fallback handles two different response shapes from the backend, one where the graph is nested under a graph key, one where it’s the root object. This kind of defensive normalisation is common when a frontend is evolving alongside its backend.

The source/target normalisation in the links map addresses a D3 behaviour: D3’s force simulation mutates link objects during the simulation, replacing string ids with references to the actual node objects. So after the simulation runs, link.source is no longer the string "src/App.tsx" but the node object { id: "src/App.tsx", x: 123, y: 456 }. The frontend normalises both forms everywhere it needs to compare or display link endpoints.

Focus Mode: BFS Traversal

The most technically interesting part of the frontend is the focus mode implementation using useMemo:

const displayData = useMemo(() => {
  if (!graphData) return null;
  if (!focusMode || !selectedFile) return graphData;

  const visited = new Set<string>();
  const queue: { id: string; level: number }[] = [
    { id: selectedFile, level: 0 },
  ];

  while (queue.length) {
    const { id, level } = queue.shift()!;

    if (visited.has(id) || level > depth) continue;
    visited.add(id);

    for (const l of graphData.links || []) {
      const source = typeof l.source === "string" ? l.source : l.source?.id;
      const target = typeof l.target === "string" ? l.target : l.target?.id;

      if (!source || !target) continue;

      if (source === id && !visited.has(target)) {
        queue.push({ id: target, level: level + 1 });
      }
      if (target === id && !visited.has(source)) {
        queue.push({ id: source, level: level + 1 });
      }
    }
  }

  return {
    nodes: (graphData.nodes || []).filter((n) => visited.has(n.id)),
    links: (graphData.links || []).filter((l) => {
      const s = typeof l.source === "string" ? l.source : l.source?.id;
      const t = typeof l.target === "string" ? l.target : l.target?.id;
      return s && t && visited.has(s) && visited.has(t);
    }),
    backLinks: graphData.backLinks || {},
  };
}, [graphData, focusMode, selectedFile, depth]);

This is a bidirectional BFS: it traverses both forward edges (files that the selected file imports) and backward edges (files that import the selected file) up to depth hops away. The level counter on each queue entry tracks how many hops from the origin each node is, and nodes beyond depth are not enqueued.

The result is a subgraph centred on the selected file that shows its immediate neighbourhood in the dependency graph. Depth 1 shows only direct imports and importers. Depth 2 shows imports of imports. Depth 5 shows almost everything reachable.

Using useMemo with [graphData, focusMode, selectedFile, depth] as dependencies means the BFS only re-runs when one of those values changes. The computation is pure: same inputs, same output, so memoisation is safe and effective.

File Inspection

Clicking a node triggers both a local state update and an API call:

const handleNodeClick = async (id: string) => {
  setSelectedFile(id);

  const res = await fetch(`${API}/file?path=${encodeURIComponent(id)}`);
  const data = await res.json();
  setFileContent(data?.content || "");
};

The encodeURIComponent call is important: file paths can contain characters like +, #, or spaces that would corrupt a URL query parameter without encoding.

The file content is passed to Monaco editor, which provides VS Code-quality syntax highlighting and navigation in the browser:

<Editor
  height="100%"
  language={getLanguage(selectedFile)}
  value={fileContent}
  theme="vs-dark"
  options={{
    readOnly: true,
    minimap: { enabled: false },
    fontSize: 13,
  }}
/>

Language detection is handled by file extension:

const getLanguage = (file: string | null) => {
  if (!file) return "plaintext";
  if (file.endsWith(".ts") || file.endsWith(".tsx")) return "typescript";
  if (file.endsWith(".js") || file.endsWith(".jsx")) return "javascript";
  if (file.endsWith(".py")) return "python";
  return "plaintext";
};

Monaco uses this to apply the correct grammar for syntax highlighting, bracket matching, and token colouring.

The Sidebar

The sidebar shows imports and dependents for the selected file:

{/* IMPORTS */}
{(graphData.links || [])
  .filter((l) => {
    const s = typeof l.source === "string" ? l.source : l.source?.id;
    return s === selectedFile;
  })
  .map((l, i) => {
    const t = typeof l.target === "string" ? l.target : l.target?.id;
    return <li key={i}>→ {t}</li>;
  })}

{/* DEPENDENTS */}
{(graphData.backLinks?.[selectedFile] || []).map((f, i) => (
  <li key={i}>← {f}</li>
))}

Imports are computed by filtering graphData.links for edges where the selected file is the source. Dependents come directly from the backLinks index: a O(1) lookup rather than a scan over all links. This is why maintaining backLinks during graph construction matters: the sidebar is queried on every node click, and a linear scan over potentially thousands of links on each click would be noticeably slow.

What the Graph Reveals

Running CodeAtlas on real repositories produces genuinely interesting results.

The React source graph makes immediately visible what would take an hour of reading to infer. react-dom has the highest in-degree of any node, more files depend on it than anything else in the codebase. The reconciler (react-reconciler) sits nearly isolated, with very few incoming edges from the surrounding code. This is good architecture: the reconciler is the most complex part of React’s internals, and its isolation means changes to it have limited blast radius.

Codebases with tight coupling produce visually chaotic graphs… a dense hairball where every node connects to many others with no clear structure. Modular codebases produce the opposite: distinct clusters connected by sparse bridges, making module boundaries immediately visible.

Entry points are always obvious. The main entry file typically has the lowest in-degree (almost nothing imports it) and the highest out-degree (it imports everything else). It sits at the edge of the graph rather than the centre.

Current Limitations

JS/TS/Python only. The parsing pipeline is language-specific. Adding Go, Rust, or Java requires a different parser for each, though the rest of the pipeline is language-agnostic.

Import-level only. The graph shows file dependencies, not function-level dependencies. You can see that fileA depends on fileB, but not which specific functions in fileB are called. Function-level graphs are significantly more complex - you need to track symbol exports and resolve them across files - but would make the tool much more powerful.

Large repo performance. Repos above roughly 800 files start to lag in the browser because the D3 force simulation has to handle thousands of nodes and edges simultaneously. Chunked parsing on the backend is already in place. Frontend performance is the next bottleneck to address: lazy loading, only simulating the visible subgraph, is the planned approach.

Concurrent requests. The current backend uses a single shared TEMP_DIR. Two simultaneous requests would overwrite each other’s cloned repo. Per-request directories using unique IDs is the fix.

Why This Approach

The shift from reading code to exploring systems matters because the linear reading model scales poorly as codebases grow. A new contributor to a 500k-line codebase cannot read their way to understanding; they need tools that let them navigate at the right level of abstraction.

Code intelligence tools (language servers, linters, type checkers) have improved dramatically over the last decade. But they are all file-centric: they tell you things about the file you currently have open. What is mostly missing is a system-level view: how does this file relate to everything else? What does the codebase look like as a whole?

That is the gap CodeAtlas is trying to fill.

The repository is open source. If you try it on a codebase and the graph looks wrong, imports are missing, or something crashes, open an issue. The project is actively being developed.

If you found this useful, starring the repo is the best thing you can do: it helps other developers find it.

GitHub: CodeAtlas

(link to live demo on GitHub page)

Developers don’t have a productivity problem. They have a memory problem.

Lucy — Mon, 13 Apr 2026 22:07:49 +0000

Every developer knows this feeling. You’re deep in a build, everything is going well, you’re in flow state… then suddenly you need something you’ve already written before. A snippet, an idea, a fix, a link, anything.

You know you’ve seen it somewhere. You just don’t know where. So you stop coding and start searching. Discord, Notion, old projects, random files, browser bookmarks. Tabs start to pile up, whilst your focus slowly disappears while you try and retrace you own steps.

And when you find it, the momentum is gone. I used to think this was an inevitable part of being a developer, but over time I realised something important: I wasn’t losing code, I was losing context. And that is a much bigger problem.

The real issue isn't writing code. Developers don’t usually struggle because they can’t build things. Most of the time, the actual coding isn’t the hard part. The real issue is everything around it: the fragments of information that never stay in one place. Snippets end up in Discord messages or random files. Ideas get dumped into notes apps, just to be forgotten, or useful links are buried in your browser history. Fixes live inside old projects you never think to open again.

We don’t have a skill issue: we have a fragmentation problem, which quietly is slowing everything down. Not obviously, but through small, constant interruptions that break focus and force you to rediscover things you’ve already solved before.

At some point, I did what most developers end up doing: I tried to fix my workflow, using Notion, Obsidian, GitHub Gists even bookmarks, folder systems and even “just being more organised”. They all worked at first. But they all broke for the exact same reason. They require you to put in effort at the exact moment you don’t have any.

When you’re in flow, you’re not thinking about organisation, you’re thinking about solving the problem that’s in front of you. So, everything gets dumped wherever it’s fastest to continue, eventually turning temporary storage into permanent chaos. So, you don’t end up with one perfect system, you end up with 10 half-broken ones.

The real shift occurred when I realised I didn’t need another notes app, with more structure, or stricter habits. I needed something that could work with the way developers actually think whilst working: something that could capture context without interrupting it. This is how DevFlow came about.

DevFlow is a developer-focused second brain that is designed around one simple principle: your work should have a memory layer. Not a separate system that you have to maintain, but something that sits quietly underneath everything you do, capturing what matters as you go.

DevFlow lets you save snippets, notes, ideas and links instantly without breaking your flow. Everything you capture is automatically organised by project, so your work stays grouped naturally, instead of scattered across multiple unrelated folders.

You can search everything you’ve saved in milliseconds, filter by project, and quickly retrieve anything you’ve written before. The goal isn’t to add another place to store things, it is to remove the friction between thinking something and saving it. Think of it like Notion, GitHub Gists and Recast combined, but rebuilt specifically for developers who want to stay in flow state.

Most tools assume that you have time to organise your thoughts properly. Developers don’t. Notion is powerful, but it’s too slow and structured for quick capture. Gists are useful but isolated. Notes apps are flexible, but can become messy very quickly.

The problem isn’t that these tools are bad, but that they aren’t designed for real-time thinking while coding. They sit outside of your workflow instead of in it.

This isn’t just about saving snippets, or organising notes, it is about protecting your flow state, removing the moment where you have to step back and ask “Where did I put that?” It is about ensuring ideas don’t disappear just because you had to focus on something else, because in development, the biggest loss isn’t bad code, it’s forgotten progress.

Right now, DevFlow is in its early stage. I’m building the MVP around a few core ideas: projects, instant capture, fast search, and a clean dashboard. But my long-term vision is much bigger.

DevFlow is moving towards becoming a full memory layer for developers, which includes semantic searching across everything you’ve ever saves, automatic tagging, deeper connections between ideas and integrations with tools like VSCode and browsers, so you can capture anything instantly.

I’m currently validating the idea and building the first version of DevFlow. If you’ve ever lost something you knew you saved, or felt like your workflow is more scattered than it should be, you probably understand why this matters.

I’m opening up early access as I build, so if you want to follow along or try it when it’s ready, you can join the waitlist here.

DevFlow

We don’t need more tools to store information, we need better systems for remembering it. That is what DevFlow is trying to become: a memory layer for developers so you can stay focused on building, not searching for what you already built.

I Built A Full-Stack App in 7 Days: Here’s Day 1

Lucy — Mon, 06 Apr 2026 16:23:47 +0000

I decided to challenge myself in a way that I have been considering for a while now. Build a full-stack application in only 7 days, completely from scratch, to completely real and usable. Not just a tutorial project, a clone of something that already exists, but something that I have designed, created, and shipped by myself.

There’s something about coding projects like these that make them feel almost deceptively simple in the beginning. You think the hard part will be writing the code, but in reality, the hardest part is normally finishing them. Most people don’t fail because they can’t write the code… they fail because they never fully complete anything. They always stop somewhere between ‘idea’ and ‘almost done’.

So, I wanted to remove that entirely. I stuck to no over-planning, no perfect architecture diagrams, and no time wasted endlessly researching the ‘best possible’ stack. Just 7 days of building, documenting and continuing on forwards no matter what happens. This is Day 1.

Day 1 started almost exactly like you would expect. I was staring at my laptop’s blank screen, trying to decide what I was going to build. This part is always more difficult than people admit. Not because it is necessarily difficult to think of ideas, but because it feels like you have to have the perfect idea before you even begin.

However, I forced myself to follow one simple rule: if I couldn’t explain the project in one sentence, and why I wanted to build it in one more, then I wasn’t allowed to build it yet. That alone removed a lot of the noise. After cutting everything down, I ended up with a relatively simple direction: build a full-stack app that is actually useful, is small enough to build in one week, but also flexible enough that I can expand it later.

It was nothing revolutionary, just something real that I could actually build and improve on. So, once I had that clarity, I stopped planning and started building almost immediately.

For the first day, I didn’t focus on building features. I focused instead on setting up my foundations properly so I wouldn’t regret it later on down the line.

I chose a stack that prioritised both speed and simplicity: Next.js for both the frontend and backend, Supabase for authentication and database, and TailwindCSS for styling. I decided not to waste time deciding about tools; I just picked what let me move quickly.

I created the project, set up the basic structure, connected Supabase, and got the environment variables working. It doesn’t sound like a lot on paper, but this is the stage, when developing something new, that everything either goes smoothly or starts to become a mess later on.

There always happens to be a moment during the setup where things feel slightly messy and fragile, like one wrong configuration could break everything. But, after a bit of trial and error, I got it running cleanly.

That moment when the app finally boots without errors is always underrated. It is the point, where for the first time, the project stops being an idea, and begins to transform into something real.

My biggest win on Day 1 wasn’t building a feature, or writing some complex logic. It was simply getting everything to connect properly. The front-end loaded correctly. The backend responded. The connection to the database worked. There were no errors flooding my terminal.

It sounds basic, but these small confirmations mattered more than anything else early on to me. They were the things that gave me momentum. Without that, each of the next steps I took would have felt uncertain. Instead, everything felt possible.

Of course, my Day 1 wasn’t completely smooth. Even on Day 1, I ran into the usual setup issues: Environment variables wouldn’t load properly, there was some confusion over my Supabase setup, and some smaller decisions about folder structures that, looking back, I probably spent way too long thinking about. Nothing too major, just enough to slow things down only a little.

What I found most interesting was that most of these problems weren’t actually problems related to coding. They were setup problems. And setup problems always feel worse than they actually are, because they block everything else from moving forwards. Once I had that realisation, it became a lot easier to stay calm and focus on fixing things one by one, instead of overreacting and panicking.

Looking back at the first day, the main lesson I took from it wasn’t technical at all. It was all about my speed and momentum.

It reminded me that planning is only useful up to a certain point. After that, it becomes a delaying tactic cleverly disguised as productivity. Progress only really starts when you begin to build something that exists outside your head.

It also reinforced something that I have noticed before: that getting something running, even if it is in its most basic form, is far more important than making it perfect. Perfection can come later, but functionality has to come first.

Most importantly, it showed me that momentum is everything. Once the project is alive, even in a basic form, it becomes much easier to continue.

Day 2 is where things will start to get interesting.

Now that the foundation is in place, I will start to build actual features: real UI components, authentication flows and the first real pieces of functionality that turn my project from just a setup into something users could actually interact with.

Right now, I have the scaffolding. By Day 2, it starts to become a product.

If you enjoyed this post, make sure to subscribe so you can follow everything I’m building in real time.

Also, check out My SubStack, where I am turning this into a 7 part weekly series.

👉 lucybatten.substack.com

If you have any questions, connect with me on LinkedIn:

👉lucybatten

If you want to see how ideas turn into real apps (and what ends up happening along the way), check out the rest of the posts in this series.

More builds, more problems, and more fixes… coming every week.

Make Your CSS Look 10x More Professional with These 11 Underused Tricks You Might Be Missing

Lucy — Sat, 04 Apr 2026 13:28:43 +0000

I think a lot about CSS... not because I enjoy suffering, but because I enjoy when things finally look right.

CSS is one of those things that looks simple on the surface… until you try to build something that doesn’t look like it was designed in 2009.

But here’s the thing: most people only learn the basics: margin, padding, display: flex, then stop there.

And that’s exactly why a lot of websites feel… average.

If HTML is the skeleton of the web, CSS is the personality. It’s the difference between “this works” and “this actually looks like a real product.”

So let’s fix that.

Here are 11 CSS tricks that instantly make your projects feel more professional, more modern, and way less “tutorial-like”.

1. aspect-ratio: stop fighting image sizing

Instead of hacking around padding tricks, just define proportions.


.box {
  aspect-ratio: 16 / 9;
}

Perfect for cards, videos, and responsive layouts.

2. clamp(): responsive sizing without media queries

h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

It scales smoothly between a minimum and maximum value.

3. scroll-snap-type: make scrolling feel premium

.container {
  scroll-snap-type: x mandatory;
}

Great for carousels and full-screen sections.

4. backdrop-filter: instant glassmorphism

.glass {
  backdrop-filter: blur(10px);
}

Gives that frosted glass effect you see in modern UI.

5. :is(): cleaner selectors instantly

:is(h1, h2, h3) {
  margin-bottom: 1rem;
}

Less repetition, more readable CSS.

6. gap (with flexbox): stop using margins for everything

.container {
  display: flex;
  gap: 1rem;
}

Cleaner than manually spacing children.

7. object-fit: fix image distortion forever

img {
  object-fit: cover;
}

No more stretched or squished images.

8. position: sticky, gives underrated layout power

nav {
  position: sticky;
  top: 0;
}

Feels like JavaScript magic, but it’s pure CSS.

9. min() / max(): smarter responsive sizing

width: min(90%, 600px);

Prevents layouts from getting too big or too small.

10. will-change: smoother animations

.card {
  will-change: transform;
}

Helps the browser optimise animations ahead of time.

(Use sparingly... don’t spam it everywhere.)

11. accent-color: style native inputs instantly

input {
  accent-color: #6c5ce7;
}

Checkboxes, radios, and sliders finally match your design.

Most developers don’t lack creativity.

They just don’t know what CSS is already capable of.

These features don’t require libraries, frameworks, or hacks—they’re built into the browser.

And using them properly instantly separates “beginner-looking UI” from “this feels like a real product”.

🚀 Thanks for reading!

If you enjoyed this post, feel free to connect and follow me for more content on web development, CSS, and programming in general.

Stay consistent, keep building, and don’t be afraid to experiment with things you haven’t used before.

Let’s connect:

GitHub → https://github.com/lucyb0207
Substack → https://lucybatten.substack.com
X (Twitter) → https://x.com/lucyb0207
LinkedIn → https://linkedin.com/in/lucybatten
Website → https://lucyb0207.github.io

What I Would Do If I Had To Learn Programming Again

Lucy — Sat, 04 Apr 2026 09:21:04 +0000

If I had to learn programming again completely from scratch, I wouldn’t start with tutorials. Not because they are necessarily bad, but tutorials make everything feel much clearer than it actually is.

When you’re following a tutorial, it feels like you understand what’s happening. Your code you write works, and everything makes sense in that moment. however, as soon as the tutorial is gone and you try to do something on your own, that understanding instantly disappears.

I didn’t realise this at first. i thought my confusion meant I needed to learn more, by watching more tutorials, reading more documentation and going through more courses. However, overtime, I began to notice that I wasn’t actually struggling because I didn’t know enough. I was struggling because I wasn’t actually thinking.

If I had to start again, I would’ve began to build things much, much earlier. I wouldn’t have started just because I ‘felt’ ready, or because I had ‘learned enough’. I would have started as soon as I had learned the basics, even if everything felt messy.

Because actually building something yourself forces you to think in a different kind of way. You aren’t just mindlessly following steps anymore, you are aking decisions. You are trying things, breaking things, fixing things, and beginning to realise why things work the way they do.

A lot of the time, you won’t fell productive. In fact, most of the time you will feel slow, confused, frustrated. But that is where the real learning happens.

Also, I would focus far less on syntax and more on structure.

When you begin to learn programming, it becomes easy to just think programming is about remembering how to write things, such as keywords, syntax and how you structure a function. It feels like that is what is needed to fully understand programming.

But, in reality, that syntax is the easiest part. You can just look it up.

What’s a lot harder, and also more important, is being able to understand how things connect. For example, how different parts of projects relate to one another, or how data moves through a system, or how changing one line of code will affect something somewhere else in the program. This is the part of programming that feels confusing or complicated, not because the code is impossible to read, but because the structure isn’t immediately visible.

If I had to start again, I would also stop trying to avoid feeling lost.

That feeling shows up right from the start, and it never really disappears, it just changes slightly as you progress. At the beginning, you feel lost because everything is new to you. As you improve, you feel just as lost because what you’re working on is so big, you can’t fully comprehend everything at once.

In both cases, the instinctive reaction is exactly the same: get out of that feeling as fast as you can, by searching frantically for another explanation, another tutorial, anything that makes it feel easy again.

But that moment when things aren’t automatically clear is usually the moment when your understanding is just about to shift. If you stay in that moment for long enough, something begins to click. Not instantly, but gradually.

I would also be a lot more intentional about what I build.

A lot of advice for beginners focuses on building projects, which I agree is good, but they often leave out something important. Not all projects teach you things in the same way, or even focus on the same skills. Building something just for the sake of building it often doesn’t make things stick.

The times where I learnt the most came from trying to solve something that actually frustrated me. Something that didn’t make sense, or that slowed me down, that I genuinely wanted to fix. When you care about the problem you are solving, you approach it differently. You become more patient, and go deeper, meaning you don’t just move on when something breaks, you try to understand why and fix it yourself.

This is the process that teaches you a lot more than following something that you know will end up working.

If I had to start again, I would also share what I was doing much earlier.

Not because I expected people to pay attention to what I was doing, but because it forces you to understand what you are doing properly. When you try to explain something to someone else, even in simple terms, you are able to realise what you do and don’t understand very quickly.

Sometimes you think something makes sense or you understand something until you try to put it into words, and that gap in knowledge shows you exactly where you need to focus. Over time, sharing will also bring in new perspectives. Other people are more likely to notice what you missed, or explain something in a way that makes it click faster. It also makes it feel less isolating and more collaborative.

Looking back, learning programming actually isn’t at all about learning programming.

It is about learning how to deal with confusion, how to continue trying even if things don’t quite make sense yet, and how to build something even if you aren’t sure if you are doing it ‘right’. If I had to start again, I wouldn’t try and learn absolutely everything.

I would just start. I’d pick something that feels frustrating enough to care about, and try to understand it just a fraction better each day. And that would be enough.

Thank you for reading! If you enjoyed my writing:

Subscribe for more articles like this

View my coding journey → My GitHub

Connect with Me → My LinkedIn My X (Twitter)

My Website → lucyb0207.github.io

ToxicAI: An AI That Emotionally Damages Developers 💀

Lucy — Fri, 03 Apr 2026 18:48:29 +0000

This is a submission for the DEV April Fools Challenge

What I Built

ToxicAI is an AI-powered code reviewer that doesn’t help you improve... it judges you.

When you paste your code, you will receive brutally honest roasts, developer metrics and a final verdict that feels slightly personal.

Instead of being useful, it evaluates your code like a disappointed senior developer who has lost patience with humanity.

You can choose a personality (brutal, passive, or overly supportive) and adjust the intensity from light teasing to full emotional damage.

The result is a completely useless but highly entertaining tool that turns bad code into entertainment.

Demo

toxic-ai-code-reviewer.vercel.app

Code

lucyb0207 / toxic-ai-code-reviewer

An AI-powered code reviewer that provides brutally honest and completely useless feedback.

💀 ToxicAI Code Reviewer

An AI-powered code reviewer that delivers brutally honest, emotionally damaging, and completely unnecessary feedback.

Built for the DEV April Fools Challenge.

What It Does

Paste your code → get instantly judged by an AI that behaves like a senior developer who has lost patience with humanity.

ToxicAI analyses your code and responds with:

a brutal roast
fake developer metrics
a dramatic final verdict

All completely useless. All completely intentional.

Features

AI Code Roasting (Gemini-powered)
Brutality Intensity Slider (Soft → Emotional Damage)
Personality Modes:
- Brutal
- Passive-Aggressive
- Overly Supportive (somehow worse)
Fake Developer Metrics:
- Vibe Score
- Ego Risk Level
- Stack Overflow Dependency
Dramatic Loading System (“AI is judging your life choices…”)
One-click Copy Roast
Structured Output:
- Roast
- Metrics
- Verdict Line

Tech Stack

React (Vite)
TypeScript
Gemini 2.5 Flash API

Why This Exists

This project solves absolutely nothing.

It exists purely to:

demonstrate AI integration
emotionally evaluate developers for…

View on GitHub

How I Built It

ToxicAI is built as a React app using Vite and TypeScript for fast development and performance.

The core AI functionality is powered by the Google Gemini 2.5 Flash API, which generates both the code roasts and structured fake developer metrics.

The app sends user-submitted code along with a dynamically generated prompt that changes based on:

Personality mode
Intensity level

The response is parsed and displayed in a formatted output panel, including:

AI-generated roast
Vibe Score
Ego Risk Level
Stack Overflow Dependency
Final Verdict

The focus of the build was on prompt engineering, response structuring, and creating a humorous AI interaction rather than traditional code analysis.

Prize Category

Best Google AI Usage:

This project makes direct use of the Google Gemini API to generate dynamic, personality-driven code roasts and developer metrics in real time.

It uses Gemini to act as a sarcastic code reviewer that adapts tone and intensity based off of user input.

The integration goes beyond simple text generation by:

dynamically adjusting prompts based on personality mode
controlling response tone via intensity scaling
structuring outputs into roast + metrics + verdict format

It showcases how generative AI can be used not just for utility, but for interactive, entertaining, and highly opinionated user experiences.

I built a Developer Tool at 16 (CodeAtlas)

Lucy — Thu, 02 Apr 2026 17:58:46 +0000

I built a developer tool at 16, and it didn’t start as anything impressive or serious. It started simply because I was frustrated - which I didn’t even realise at first, as I just assumed it was all just part of programming.

Every time I opened a new codebase, especially anything larger than a school project, it felt like I was reading something that was barely understandable for most humans. Files depended on other files, functions called things that were buried deep in completely different folders, and I would be constantly jumping between tabs trying to properly visualise how everything worked together.

It wasn’t that I couldn’t understand the code. It was that it took way to long to understand what should be a simple task, and i felt like I was rebuilding a mental image of what the codebase looked like every time I reopened a project. After a while, I began to wonder: there has to be a better way to do this.

That’s where I got the idea to build CodeAtlas. I didn’t consider it to be a startup or even a project that I could share with other people at the time. It was more like a challenge I had set for myself: what if I could find a way to visualise a codebase instead of just seeing files and folders?

At the start, I built the simplest version I could have possibly thought of. It was just a script that scanned a repository, checked the import statements and tried to draw lines between files. No fancy interface, or real structure behind it, I was just trying to see if the idea made sense outside of my brain.

The first time it actually worked, even though it was messy and broken, it flt weirdly different from what I had built before. It felt useful, like something people would actually want to use.

But this version was far from useful. It constantly broke, especially on anything that was even slightly complex. Bigger projects took an eternity to load and created chaotic webs where everything overlapped and it was impossible to tell what was going on.

Still, instead of starting over, I continued to improve it, bit by bit. I worked on improving the accuracy of detection, I added features like search bars and code viewers, and over time, it began to feel more and more like something that could actually help people understand real-world codebases.

The turning point wasn’t when I added a new feature, or I finally got something to work. It was when I showed my project to someone else for the first time. I expected them to comment on the visuals of the graph, or how interesting it looked, but instead, they came back to me and said this had helped them onboard new developers to their codebases.

That moment stuck with me more than anything else whilst creating this project.

This was when I realised I wasn’t simply drawing lines between files, but I was helping people reduce the complexity of repositories into something more abstract that people can actually understand and hold in their mind.

After this moment, I started thinking about CodeAtlas differently.Every change I made form then on wasn’t about making it more visually appealing, it was about making understanding faster. I started rebuilding parts that didn’t scale properly. I change how relationships were displayed.

And like most projects that begin to get real, i eventually ran into the part that nobody talks about enough: it is easy to continue improving a project forever, but it is much harder to actually finish it.

I always had an ongoing list of features that I could add, and improvements that would make it feel slightly more complete. But I stopped waiting for it to feel finished and I uploaded it to GitHub. It wasn’t perfect, and it still isn’t. But people could use it, load real repositories and actually get something useful out of it.

Looking back now, what I built hasn’t just been a developer tool for visualising dependencies. It has changed how I see code entirely: I don’t just see files anymore, I see relationships, structure, and how it all connects together under the surface.

And, weirdly, CodeAtlas wasn’t just something that helps me to build repositories better. It taught me how to see code from a different perspective.

Thanks for reading.

I’m curious... what’s the most confusing part of a codebase for you when you join a new project?

Drop it in the comments. I’ll read through them and it might shape what I build next.

Try CodeAtlas → GitHub
More writing → Substack
Follow the build → X (Twitter)

I Tried to Learn Coding Fast. It Almost Made Me Quit.

Lucy — Fri, 27 Mar 2026 21:46:11 +0000

For the longest time, I treated coding like a race I was already behind in. Every day, I’d fall into the same loop: searching for the fastest way to learn, the best roadmap, the most in-demand language. I convinced myself that if I could just find the perfect path, everything would click. So I jumped from Python to JavaScript, from web development to algorithms, from one course to another. Each new start felt exciting, like I’d finally cracked the system. But after a few days, the excitement faded, things got difficult, and I’d move on again — thinking the problem was the path, not my approach.

After a few months of this, I had nothing real to show for it. I wasn’t a complete beginner anymore, but I wasn’t competent either. I had fragments of knowledge — syntax here, concepts there — but no ability to actually build something on my own. That was the most frustrating part. I could follow along with tutorials and understand what was happening, but the moment I tried to create something from scratch, I’d freeze. It felt like staring at a blank page with no idea how to begin. That’s when the doubt started creeping in: maybe coding just wasn’t for me.

The turning point wasn’t dramatic. There was no breakthrough moment, no sudden surge of motivation. I just got tired of restarting. Instead of searching for another roadmap or switching languages again, I made one simple decision: I was going to build something small and actually finish it. Not something impressive, not something I could show off — just something complete. I picked a basic project, a simple to-do list app, and committed to working on it every day until it was done. That was the only rule.

At first, it was uncomfortable in a way tutorials never were. There was no step-by-step guide telling me what to do next. I had to figure things out on my own, and that meant getting stuck constantly. I’d spend 20 minutes trying to fix a single error. I’d search things I felt like I “should” already know. It was slow, messy, and honestly a bit discouraging. But something different was happening this time: I wasn’t quitting when it got hard. I was staying with the problem until I found a way through, even if that meant taking small, imperfect steps forward.

That’s when I realised why tutorials had been holding me back. They gave me the illusion of progress without forcing me to think deeply. When you follow a tutorial, you’re not really solving problems — you’re just replicating solutions. It feels productive because you’re typing code and seeing results, but you’re not building the mental frameworks needed to handle things on your own. When I started working on my own project, even something as simple as structuring the code or deciding where to start became a challenge. But those challenges were exactly what I needed.

To keep myself consistent, I made the process almost ridiculously manageable. I set a rule: I would code for at least 30 minutes every day, no matter what. It didn’t matter how tired I was, how busy the day had been, or whether I felt like it. The goal wasn’t to have perfect sessions or make huge progress — it was just to show up. Some days, I’d go far beyond 30 minutes because I got into the flow. Other days, I’d do the bare minimum and stop. But the key difference was that I never broke the chain.

Over time, the results started to compound in a way that felt almost invisible at first. I didn’t suddenly become an amazing developer, but things that used to confuse me started to make sense. Errors became less intimidating because I’d dealt with similar ones before. I stopped panicking when something didn’t work and started approaching problems more methodically. Most importantly, I began to trust myself — not because I knew everything, but because I knew I could figure things out if I gave myself enough time.

After a few months, I noticed a shift that’s hard to explain but easy to feel. I no longer saw myself as someone trying to learn coding. I was just someone who coded. That identity change made everything easier. I didn’t need to rely on motivation or wait for the perfect time to start. It became part of my routine, something I did without overthinking. And once that happened, progress stopped feeling forced and started feeling natural.

Looking back, the biggest mistake I made wasn’t choosing the wrong language or following the wrong roadmap — it was constantly restarting. Every time you restart, you reset the discomfort, the confusion, and the early-stage struggle. You never stay in one place long enough to push through it. Real progress comes from sitting with that discomfort and working through it, even when it feels slow and unproductive.

If you’re in that phase right now — jumping between tutorials, feeling stuck, wondering if you’re cut out for this — try simplifying everything. Pick one language. Pick one small project. Work on it every day, even if it’s just for 30 minutes. Don’t worry about doing it perfectly or efficiently. Just focus on finishing. Because finishing something, no matter how small, does more for your growth than consuming hours of content ever will.

Coding isn’t about finding the fastest path. It’s about staying on one path long enough for it to actually take you somewhere. And once you understand that, everything starts to change.

Building CodeAtlas: A Public Dev Journey (Hosting, Apps, and Scaling Challenges)

Lucy — Wed, 25 Mar 2026 14:48:59 +0000

I’ve been working on a project called CodeAtlas, something I’m building from scratch while learning, improving, and sharing the process publicly. The goal is simple: build useful software, ship it consistently, and document everything as I go.

Right now, I’m still early in the journey, but I’m at a point where I can build and iterate quickly. The main challenge isn’t coding anymore — it’s the resources needed to keep everything running smoothly.

Things like hosting costs, app deployment fees, certifications, and learning resources all add up. I also rely on certain tools that help me build faster and improve the quality of what I’m making. That’s the part that’s currently limiting how fast I can move.

CodeAtlas itself is a project focused on organising and visualising code and ideas in a more structured way. The idea is to make development feel more intuitive by linking concepts together, almost like building a “map” of a codebase or system. It’s still evolving, and I’m shaping it step by step as I build it.

I’m also building in public for a reason. I want to improve my skills, learn how real-world software is developed and shipped, and stay consistent with long-term projects. Every update, bug fix, and feature is part of that learning process.

If you want to support what I’m building, you can do so here:
👉 Buy Me A Coffee

Any support goes directly into hosting, app releases, certifications, and tools that help me keep building. Even small contributions genuinely make a difference and allow me to focus more time on development.

If you want to explore the project or follow development, here’s the GitHub repo:
👉 CodeAtlas

I’m actively updating it as I build, so feel free to star it or follow along.

I’d also really appreciate feedback. If you’re reading this, I’d love to know what you think — what would make a tool like CodeAtlas actually useful for you? What features would you want to see? I’m actively shaping the project based on input from people who are interested in it.

Thanks for taking the time to read this. I’ll be sharing more updates as I continue building — both the progress and the challenges along the way.