DEV Community: Jay-Em

The Fog: What 6 Months of AI Coding Did to My Brain

Jay-Em — Mon, 06 Jul 2026 14:46:42 +0000

I've been writing code for about five years professionally. If you count the years where I was just Googling "why is my div not centering" at 2am, it goes back to 2017. I started my first real job in 2020. And for most of that time, it was just me and the editor. No autocomplete magic, no chat window, no "here's your entire feature, boss." Just me, the docs, and a lot of console.log.

Then AI happened to me. Slowly, then all at once.

This is the story of how I got faster than I've ever been in my life, and somehow started feeling like a stranger to my own code.

The Copilot warning I ignored

My first taste was GitHub Copilot. And look, it was cool. It finished my thoughts before I finished them. It felt like pair programming with someone who never took a lunch break.

But something weird started happening. I noticed I was forgetting syntax I used to know cold. Small stuff. The exact shape of an array method. How to write a reduce without staring at it. I'd start typing, wait for the gray text, and just... tab.

Wait, am I getting dumber?

I was. Not really dumber, but my muscle memory was quietly rotting. The stuff I built over years was fading because I stopped using it. So I did something that felt insane at the time: I turned it off. Went back to raw typing. Felt slow. Felt good.

I thought that was the whole lesson. Turns out it was just the trailer.

The job that made AI non-negotiable

This year I landed a full-time role as a full stack dev building internal AI tools. And here's the twist: using Claude Code wasn't optional. It was the job.

So for the first time, I wrote an entire feature with AI. Spec to feature to production. And I'm not gonna lie to you, it blew my mind. The speed was unreal. Stuff that used to take me a month was landing in days.

I was hesitant at first. This feels like cheating. But it works, and it ships, and when something ships that fast, guess what happens next?

The expectations move to match the speed.

Suddenly it's two features a week. Two. Features. A week. The kind of pace that, doing it by hand, would've been a month minimum. And the only way to hit that number is to lean all the way in. So I did.

Reader, I leaned so far in I fell over.

The fog

Weeks passed. Then more weeks. And one day I realized I couldn't remember what I wrote.

Not "I forgot a detail." I mean I couldn't remember the parts. The spec of the tools I built. How they fit together. I'd open a PR with my name on it and read it like a tourist. I was writing prompt after prompt after prompt, shipping the whole time, but not really understanding any of it.

It felt like floating. Like the work was happening next to me instead of through me.

And it hit me how different this was from before. Back in 2020 to 2025, when everything was manual, I knew every single line. The code felt like mine. Now? I felt detached from the thing I supposedly built.

So I stopped. I said, okay, I need to figure out what's actually happening to me here.

And yeah, I know how this sounds, but I consulted the AI about my AI problem. Fight fire with fire, I guess.

What we actually figured out

Here's the part that reorganized my brain.

My first instinct was to blame the typing. Like the value of the old way was the physical act of writing the code. Muscle memory, keystrokes, all that.

But that wasn't it.

The real thing manual coding did was force a prediction out of me on every single line. Before I ran anything, I had already guessed what it would do. I had to. That constant loop of "I expect this to return X" and then watching to see if X actually happened, that's what quietly built the model in my head. The typing was never the point. The typing was just the delivery mechanism for the guess.

And AI removes the guess.

It hands you working code before you've formed a single expectation about it. So the prediction step goes from mandatory to optional. And here's the brutal part: anything optional gets skipped under a deadline. Especially a two-features-a-week deadline.

So you ship correct code without ever having predicted what it would do. Which means the understanding never gets built. Which is the fog.

It's not that I got lazy. It's that the one moment that used to compile understanding into my head got quietly deleted from the loop, and nobody sent a memo.

Why it feels like detachment specifically

Because my understanding stopped living in my head and moved into the AI and my notes.

That's why I kept asking things like "wait, what did we do yesterday?" and "is this one done?" and "is it logged?" I was reconstructing my own work from session summaries like I was investigating a stranger.

Here's the distinction that stuck with me: understanding-on-demand is not the same as retained understanding. I could retrieve it. I couldn't hold it. And holding it is the whole reason work feels like yours instead of something you supervised.

You don't own what you can only look up.

The fix (I'm not going back to manual, relax)

I want to be clear, the answer is not "delete Claude and suffer." That's cope. The speed is real and I'm not giving it up.

The answer is to put the prediction back in on purpose, since it's not forced anymore.

So now, before I read the AI's answer, I guess what it's going to say. Before I accept a diff, I state what I expect it to change and why. Out loud, in my head, in a comment, doesn't matter.

When I'm right, that's a rep. The model in my head gets stronger.
When I'm wrong, that's the exact spot the fog would have formed, and now it doesn't.

It's slower. Obviously. Which is exactly why a deadline murders it. So I don't do it on everything. I'm not predicting the outcome of "change this button to pink." I do it on the work that actually matters, the stuff I need to own six months from now.

That's the trade. A little friction on purpose, in exchange for staying the author of my own work.

The one-liner I'm leaving with

AI didn't make me a worse developer. It made the moment where I become a better one optional.

The fog isn't the price of using AI. It's the price of using it without guessing first.

So now I guess first. Every time that counts.

And if you felt seen by any of this, that's your sign to go predict your next diff before you tab.

neovim-final-final: Why I Can't Stop Tinkering With My Dev Environment (And Why That's Okay)

Jay-Em — Fri, 05 Jun 2026 19:13:33 +0000

Let me paint you a picture.

It's a perfectly good Saturday afternoon. You had plans. Real plans. Maybe you were going to finish that side project, maybe finally write some tests (lol), or at the very least touch grass for twenty minutes.

Instead, you're 4 hours deep into your Neovim config, you've rewritten your keymaps.lua for the third time this month, your lazy.nvim plugin list has grown by six plugins you don't fully understand yet, and your repo—God help you—is named neovim-final-final.

Not neovim-config. Not dotfiles. neovim-final-final.

Because the one before it was final, and that was a lie, and you knew it was a lie when you named it, and you did it anyway.

Hi. My name is Josh, and I have a configuration problem. I'm not in recovery.

"Just Use VS Code" — A Eulogy

I did use VS Code. For a long time, actually. It's fine. It's great, even. It has extensions for everything, it works out of the box.

But at some point, something shifted. I'd be in the middle of coding and I'd think: this editor doesn't feel like mine. It felt like renting an apartment versus owning a house. Everything worked, but none of it was mine. I couldn't knock down a wall. I couldn't rewire the kitchen. The landlord (Microsoft) was always one update away from rearranging the furniture while I slept.

So I did what any completely normal, well-adjusted developer does.

I nuked it. Installed Neovim. And fell into a rabbit hole I haven't climbed out of since.

Credit where it's due: a big part of what pushed me over the edge was ThePrimeagen. If you've never watched him, he's a developer who moves through code so fast it looks illegal, and he does it all in Neovim. Watching him work made me feel like I was using a tricycle when I could be riding a motorcycle. He didn't just inspire me to switch editors — he inspired me to tinker. To care about the tools. To never just accept the defaults.

The First Config Is Always a Disaster (And That's the Point)

Here's what nobody tells you about switching to Neovim: the first week is a humbling experience.

Honestly, my first encounter with Vim wasn't even intentional. I made a git commit without the -m flag, and suddenly I was staring at a screen I did not ask for. I had no idea what it was. I just knew I was stuck. Couldn't type, couldn't exit, couldn't do anything. I literally Googled "stuck in commit can't exit" — not even "how to exit vim" — because I didn't even know it was Vim. That Stack Overflow question with 2 million views? I am one of those 2 million people.

And yet, somehow, that cursed moment planted a seed.

Fast forward to actually switching to Neovim full time: you forget how to save files. You accidentally enter some mode you've never seen before and the only way out is to close the terminal and pretend it never happened.

But then something clicks. You learn that every single thing—every keybind, every behavior, every color on your screen—is a choice you made. Nobody pre-packaged it for you. When your LSP starts working and Telescope fuzzy-finds a file in 0.1 seconds and your statusline shows exactly the info you care about and nothing else...

That feeling? That's ownership. That's craftsmanship. That's the closest thing a programmer gets to carving their name into something.

The Configs That Taught Me More Than Any Tutorial

Here's the dirty secret about tinkering with your dev environment: it's not actually about the tools.

Sure, I love my which-key setup. I love that I've bound <leader>\ to Telescope and <leader>gg to NeoGit and my fingers just know where to go without thinking. I love that my Neovim is fast—genuinely, disgustingly fast—in a way that VS Code on a good day can only dream about.

But what I actually learned from all of this:

How Lua works, because your Neovim config is just a Lua program. You are literally programming your editor.
How LSPs work—like, actually work. What a language server protocol is, why it exists, what mason.nvim is doing when it installs one.
How terminal multiplexing works, because once you go Neovim you inevitably end up in Tmux, splitting panes, managing sessions, and feeling like a wizard in a movie about hackers.
How to read documentation, because Neovim will teach you patience or it will break you. There is no middle ground.

None of that came from a course. It came from breaking things, reading the source code of plugins at 1 AM, and occasionally nuking the whole config and starting over.

Which brings me to something important.

The Nuclear Option Is Not Failure. It's a Feature.

I've deleted my Neovim config and started from scratch multiple times.

Every time, I told myself this is the final one. Every time, I was wrong. Hence: neovim-final-final. (Spoiler: there will be a neovim-final-final-v2. I've made my peace with this.)

And you know what? Each restart made my config better. Because I stopped copying configurations I found online wholesale and started understanding why things were structured a certain way. I stopped installing plugins because some YouTuber had them and started asking "do I actually need this, or does it just look cool in a demo?"

The tinkering is the learning. The mess is the process.

There's a certain type of programmer who looks at someone like me and says "that's a waste of time, just use the defaults." And look, I get it. Pragmatism is a virtue.

But there's something those programmers are missing: the act of configuring your environment forces you to understand it. You can't set up an LSP without learning what an LSP is. You can't write a keymap without thinking about your own workflow. You can't structure a Lua config without picking up at least some programming instincts.

Tinkerers aren't wasting time. They're learning sideways.

Tmux: The Part Where I Become Insufferable at Screen Shares

I need to talk about Tmux for a second.

Tmux is a terminal multiplexer, which is a fancy way of saying "multiple terminals in one terminal, with sessions that persist even when you close everything." It sounds niche. It sounds unnecessary. Every person I've shown it to in a screen share has said some variation of "wait, what just happened" followed by either genuine curiosity or quiet concern for my mental health.

I love it.

I have a Tmux session for every project. I detach, I reattach, I split panes horizontally and run my dev server on one side and my Neovim on the other. My workflow is a single terminal window and nothing else. No alt-tabbing. No losing focus. Just me, my keyboard, and a black screen full of text that somehow builds web applications.

Is this more efficient than having a normal setup? Genuinely, yes. I think so.

Is part of the appeal that it looks like I'm doing something extremely technical and impressive at all times?

...also yes. I'm not a saint.

There's also this other thing that happens during screen shares that I didn't expect: occasionally, someone will see my setup and just light up. Not confusion — recognition. They'll say something like "wait, are you using Neovim and Tmux?" and suddenly we're talking like old friends. It's happened with developers I've never met before, halfway across the world — and as a Filipino working remotely, that moment of unexpected connection hits different. It's like stumbling into a secret club. The terminal is the handshake. It's a small community, but it's ours.

Why You Should Try It (Even If You Don't Stick With It)

Here's my honest take: you don't have to use Neovim or Tmux forever. You don't have to commit. You don't have to throw away VS Code or Cursor or whatever IDE is paying your rent right now.

But you should tinker with something outside your comfort zone. Configure something from scratch. Break it. Fix it. Break it again. Name the repo something embarrassing like neovim-final-final because that's just the natural endpoint of caring about your tools.

Because here's what I've found: programmers who understand their environment write better code. Not because Vim makes you smarter (it doesn't, I've tested this on myself), but because the curiosity that drives you to customize your editor is the same curiosity that drives you to understand your codebase. It's the same instinct.

The tinkerers are the ones who ask "why does this work this way?" instead of accepting it.

And that question—why does this work this way?—is the most important question in this entire profession.

Go Break Your Config

Stop using default settings for everything (unless you have a deadline, in which case: godspeed, use VS Code, no judgment).

But when you have a free Saturday? Crack open a Neovim config. Spend four hours on a keymap. Name the repo something ridiculous. Feel the specific joy of your editor doing exactly what you want it to do.

It's worth it. I promise. And if you nuke the whole thing and start over, that's fine too.

That's just neovim-final-final-v2 waiting to happen.

Enjoyed this? Follow me for more programming blogs where I justify my terrible life choices with technical reasoning.

Catch you in the next one. 🚀

I Built an ORM That Starts With JSON So You Can Stop Overthinking Your Database

Jay-Em — Thu, 19 Feb 2026 03:36:05 +0000

You know that thing where you have a project idea at 1am, you're hyped, and then you spend the next 2 hours setting up Postgres, writing migrations, configuring connection strings, and by the time you're done your motivation is gone and you go to bed?

Yeah. That kept happening to me. So I built something about it.

What is SeedORM?

SeedORM is a Node.js ORM that stores everything in local JSON files. No database server, no Docker, no connection strings. You define your models and start building immediately.

Then when your project is ready for the real world, you migrate to Postgres with one command. Same models, same queries, same API. Nothing changes except where the data lives.

npm install seedorm

The Problem

Every side project I start follows the same pattern:

Cool idea hits me
Create new folder, npm init
Okay now I need a database
Do I use Postgres? MongoDB? SQLite?
Spend 30 minutes setting up Docker, env vars, connection pooling
Write migration files
I'm tired now
Abandon project

I wanted something where step 3 is just... skip.

How It Works

Define your models like you normally would:

import { SeedORM, FieldType } from "seedorm";

const db = new SeedORM();
await db.connect();

const User = db.model({
  name: "users",
  fields: {
    name: { type: FieldType.String, required: true },
    email: { type: FieldType.String, unique: true },
    age: { type: FieldType.Number },
  },
});

await User.init();

That's it. No database running. No config file pointing to localhost:5432. It just writes to JSON files in a data/ folder.

Now use it like any ORM:

// Create
const user = await User.create({ name: "Josh", email: "josh@hey.com", age: 24 });

// Query
const adults = await User.find({ filter: { age: { $gte: 18 } } });

// Update
await User.update(user.id, { age: 25 });

// Delete
await User.delete(user.id);

Relations

It supports the relation types you'd expect:

const Post = db.model({
  name: "posts",
  fields: {
    title: { type: FieldType.String, required: true },
    body: { type: FieldType.String },
  },
  relations: {
    author: {
      type: "belongsTo",
      model: "users",
      foreignKey: "authorId",
    },
  },
});

hasMany, belongsTo, manyToMany. They all work the same way when you eventually switch to Postgres.

The Studio

I got tired of opening JSON files to check my data, so I built a visual browser for it. Run seedorm studio and you get a web UI at localhost:4200 where you can browse collections, search across fields, paginate through documents, and edit records.

It's nothing fancy. It's just nice to have when you're building and want to see what's in your database without writing a query.

Per-Collection File Storage

One thing that bugged me early on was that everything was stored in a single seedorm.json file. With a few thousand documents across multiple collections, that file gets massive.

So now each collection gets its own file:

data/
  users.json
  posts.json
  comments.json

Each file is minified (single line), writes only happen for collections that changed, and if you have an old seedorm.json from a previous version it auto-migrates on startup. You don't have to do anything.

When You're Ready for Postgres

Your project took off. Congrats. Time for a real database.

seedorm migrate to postgres

Your models stay the same. Your queries stay the same. You just change the adapter config:

const db = new SeedORM({
  adapter: {
    adapter: "postgres",
    url: "postgresql://localhost:5432/myapp",
  },
});

That's the whole point. Build fast with JSON, switch when it matters.

What It's NOT

Let me be clear about what SeedORM is not:

It's not a Prisma replacement for your production app with 10 million users
It's not meant for high-concurrency workloads
It's not trying to be the last ORM you'll ever use

It's for prototyping, side projects, hackathons, and that 1am idea that deserves to exist without a 30 minute setup ritual.

Try It

npm install seedorm

GitHub
npm

If you try it, I'd genuinely love to hear what you think. What's missing? What's annoying? What would make you actually use this?

Thanks for reading.

Dart Extensions: Unleashing the Power of Your Code! 🚀

Jay-Em — Sat, 18 May 2024 02:04:50 +0000

Hello everyone! Welcome to another exciting post. I hope you'll find this one just as useful!! Arigatogozaimasuuu! 🎉

Have you ever felt limited by the built-in methods in Dart? Ever wished you could add your own methods to existing classes? Well, you're in luck because today I'm going to show you how to harness the magic of Dart extensions! 🌟

Extensions allow you to add new functionality to existing libraries. They're a game-changer for making your code cleaner and more readable. Let's dive right in!

Prerequisites

Dart SDK
A Dart project setup

Getting Started with Dart Extensions

First things first, make sure you have Dart installed. If you don't, you can download it from Dart's official website.

Creating Your First Extension

Let's say you want to add a new method to the String class. Here's how you can do it:

Open your Dart project and create a new file called string_extensions.dart.
Inside string_extensions.dart, add the following code:

extension StringExtensions on String {
  bool isPalindrome() {
    return this == this.split('').reversed.join('');
  }
}

What did we just do? We created an extension on the String class that adds a method called isPalindrome. This method checks if a string reads the same backward as forward. Cool, right? 😎

Using Your Extension

Now, let's use this new method in our project.

Import your extension into your main Dart file:

import 'string_extensions.dart';

Use the new method on any string:

void main() {
  String word = 'level';
  print('Is "$word" a palindrome? ${word.isPalindrome()}');
}

Run your Dart program, and you should see the output:

Is "level" a palindrome? true

Boom! You've just extended the String class with a custom method. 🚀

More Practical Examples

Let's explore some more practical examples to get you comfortable with extensions.

Example 1: Adding a `toCapitalized` Method

Sometimes you might need to capitalize the first letter of a string. Let's create an extension for that.

extension CapitalizedString on String {
  String toCapitalized() {
    return this.length > 0 ? '${this[0].toUpperCase()}${this.substring(1)}' : '';
  }
}

Example 2: Adding a `num` Extension

You can also extend numeric types. Let's add a method to double a number.

extension NumExtensions on num {
  num doubled() {
    return this * 2;
  }
}

Using the New Extensions

Don't forget to import your extensions and use them in your code:

import 'string_extensions.dart';

void main() {
  String name = 'dart';
  print('Capitalized: ${name.toCapitalized()}');

  num value = 42;
  print('Doubled: ${value.doubled()}');
}

Conclusion

That's it! You've just learned how to create and use Dart extensions to make your code more powerful and expressive. 🎉

Extensions are a fantastic way to add custom functionality to existing classes without modifying their source code. Use them wisely to keep your code clean and maintainable.

I hope you've enjoyed this post and found it useful. Stay tuned for more exciting content! 🚀

Auto update React app in Heroku upon git push on GitHub

Jay-Em — Sat, 16 Jul 2022 12:28:45 +0000

Hello everyone! This is going to be my first ever post here. I hope you'll find this useful!! Arigatogozaimasuuu!

Update: Heroku is not free anymore, these tutorial is outdated and will be updated soon

Have you ever wondered if it is possible to just push your application update in your Github repo and then it will auto re-deploy your app in Heroku? Well, stop wondering because today I will share you the process on how to setup one in your React app project and save you the hassle of searching it on your own!

We will utilize the use of what we call, "the magical" Github Actions. This is the main key that will unlock the possibility on how to make this idea come true.

I will assume that you already know how to create a Github repo, create an application in Heroku, and know the basics of Git. With that in mind, let us now start doing it!

Prerequisites

Setting up Github and Heroku

1) First, you need to create a Github repository and push your React project there. In my case, I just pushed the default React app created by using npx create-react-app.
2) After that, you can now create an app in Heroku. Just leave the tabs open for the moment ;)

Setting up your React app

3) Now in your project's root directory, create a new folder or a directory if that's what you want to call it, name it as server and then create a new file inside naming app.js and paste this code.

const path = require('path');
const express = require('express');
const port = process.env.PORT || 3000;
const app = express();

const publicPath = path.join(__dirname, '..', 'build');
app.use(express.static(publicPath));

app.get('*', (req, res) => {
res.sendFile(path.join(publicPath, 'index.html'));
}); 

app.listen(port, () => {
console.log(`Server is up on port ${port}!`);
});

What in the world does this code do? Well, if you read it carefully, it's just serving your app's public folder to the browser.

4) The project should look something like this.

5) Now open your favorite terminal, navigate inside the server directory of your React app, and initiate node.js by

npm init --y

6) Now from here, I recommend using yarn, and then install express.js by

yarn add express

7) After installing express you should probably add a .gitignore file containing node_modules inside. You don't want to push it in Heroku because of its massive size. It should look like this.

8) Navigate back to our project's root directory and create a Procfile file and paste this inside

web: node ./server/app.js

It should now look something like this.

Setting up the Github action

9) After adding that, open a new terminal and login to Heroku by typing

heroku login

If heroku is unknown to your system, you should install the Heroku cli first. It will open a login prompt in your browser. Just follow the instructions there and if it works, you should see something like this.

10) After successfully logging in, switch back to your previous terminal or open a new one and navigate back to your project's root directory. Commit all of your changes to your local branch, and add a remote branch for Heroku by typing in

heroku git:remote -a [name of your app]

It should look like this.

11) Now push your React app to Heroku by typing

git push heroku [your master branch]

My master branch is main so it should look like this.

12) After pushing it to Heroku successfully, from your project's root directory, create a new directory following this structure.

13) In the newly created file main.yml, paste this code inside.

name: Deploy

on:
  push:
    branches:
      - [gitmainbranch]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12 # This is the action
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: "[herokuappname]" #Must be unique in Heroku
          heroku_email: "[emailloggedinheroku]"

Replace [gitmainbranch] with your master branch or main branch.
Replace [herokuappname] with your Heroku app name.
Replace [emailloogedinheroku] with the email you use in your Heroku account.

This code is just a simple Github workflow that tells Github to auto update Heroku upon changes in the main branch of your React application.

With my setup, it should look like this.

14) In your Heroku account, go to account settings and reveal your API key, and guess what? Copy it.

15) In your Github repo, go to your repository settings and add a new secret named HEROKU_API_KEY and paste the API key you copied from Heroku.

16) We're almost done!!! Now save all files, commit all the changes and push it to your Github repo by

git push origin main

It should be something like this.

You're done! Congrats!

17) Hooray!! We're done! Try making some changes in your app and push it on Github repo by

git push origin main

or by merging a certain branch to your master branch. This action will be triggered whenever there's a change in your master branch. Once you've pushed a change, you'll see something like this in your action tab.

You'll also gonna see the logs in your Heroku app

Thanks!

That's it! You have now successfully setup your Github-Heroku workflow that will auto update your deployed React app on the go.
I hope you've liked my first content here at DEV! I will post more in the future! Please see my website to know me more! Thanks!

DEV Community: Jay-Em

The Fog: What 6 Months of AI Coding Did to My Brain

The Copilot warning I ignored

The job that made AI non-negotiable

The fog

What we actually figured out

Why it feels like detachment specifically

The fix (I'm not going back to manual, relax)

The one-liner I'm leaving with

neovim-final-final: Why I Can't Stop Tinkering With My Dev Environment (And Why That's Okay)

"Just Use VS Code" — A Eulogy

The First Config Is Always a Disaster (And That's the Point)

The Configs That Taught Me More Than Any Tutorial

The Nuclear Option Is Not Failure. It's a Feature.

Tmux: The Part Where I Become Insufferable at Screen Shares

Why You Should Try It (Even If You Don't Stick With It)

Go Break Your Config

I Built an ORM That Starts With JSON So You Can Stop Overthinking Your Database

What is SeedORM?

The Problem

How It Works

Relations

The Studio

Per-Collection File Storage

When You're Ready for Postgres

What It's NOT

Try It

Dart Extensions: Unleashing the Power of Your Code! 🚀

Prerequisites

Getting Started with Dart Extensions

Creating Your First Extension

Using Your Extension

More Practical Examples

Example 1: Adding a toCapitalized Method

Example 2: Adding a num Extension

Using the New Extensions

Conclusion

Auto update React app in Heroku upon git push on GitHub

Prerequisites

Setting up Github and Heroku

Setting up your React app

Setting up the Github action

You're done! Congrats!

Thanks!

Example 1: Adding a `toCapitalized` Method

Example 2: Adding a `num` Extension