Forem: DHg

AI Wrote My Code. I Couldn't FEEL It.

DHg — Wed, 08 Apr 2026 13:51:28 +0000

I've been using AI to write code for a while now. It's fast, it's getting more accurate, and the spec-first workflows are genuinely good. But I keep running into this feeling that I can't shake: when I let AI do too much, I feel disconnected to the codebase. I posted about this on r/ExperiencedDevs and the response confirmed something I was hoping for. It's not just me.

TLDR: Going fully agentic with AI coding made me faster but left me unable to understand my own codebase. I built a workflow where I write the skeleton and core logic by hand, let AI handle the deterministic stuff, and iterate on specs until they become the feature documentation. When I posted about this, hundreds of devs showed up with the same feeling, different coping mechanisms, and some sharp counterarguments that made me think harder. This post is everything I learned from that conversation.

The Disconnect

When I let AI go fully agentic on a feature, even with a good spec, I feel disconnected from the codebase. The code is there. It works. But I don't generally get how it works. I just know the result. I don't know what it actually does. And that bothers me.

That's a weird place to be as a software engineer. You shipped the feature, tests pass, PR got merged. But if someone asks you why you chose this table structure, or what happens when this edge case hits, you're reading your own code like it's someone else's.

One commenter nailed it better than I could. They said there is none of your own intention in the codebase that you are reading. If code was something you could just "prompt, then review," then reviewing until you feel ownership would work outside of generated code too. But anyone who has been forced to maintain monolithic legacy codebases they didn't create will tell you that's not true.

That hit me. Because what they're really saying is: reviewing is not the same as understanding. You can read every line and still not have the mental model. The intention gap is real.

The Burn

I got burned once. Wrote a short prompt, let AI implement a whole feature, went to test it, and the thing totally diverged from what I wanted. I couldn't even course-correct because I had no idea what it built. Had to scrap everything and start over.

The Workflow I Landed On

Since the burn, I've been doing spec-first, but with my hands in it. I generate a spec, then I argue with it, poke holes in it, point out flaws, architect it myself. Once it's workable I implement the skeleton by hand. The schema, the core logic, the architecture. Then I feed it back to improve the spec more. As I implement I find more flaws, keep iterating, and eventually the spec becomes the documentation of the feature itself.

The deterministic functions, the boilerplate? AI can have those. But the core stuff, I need to touch it. I need to write it. Otherwise I don't feel ownership of it. When the shit hits the fan in production, I need to be able to jump right in and know where the logic goes and where it breaks.

When working with the spec, I generally provide it more context and ask it to come up with 2 or 3 aspects of the problem, then I need to really think about that. To sum it up: AI is my assistant.

The Speed Tradeoff

I know my approach is slower than the folks throwing unlimited tokens at the latest models Claude 4.6 1M context windows. I accept that tradeoff. I feel all the f*cks that I did, and I want to keep feeling them.

That matters. Maybe not on the sprint board this week. But it matters when production goes down and your team is looking at you.

The Machine Spirit

There's this concept in Warhammer 40k called the machine spirit. Tech priests pray to the machines, wave incense before them, maintain a spiritual connection to the technology. Before AI I never thought about "connection to the codebase" as a thing. I coded 100% by hand so the connection was just there. Now that I have the option to lose it, I can actually feel it. I need to feel the machine spirit of my code.

What the Community Told Me

I posted this on r/ExperiencedDevs. 324 upvotes, 154K views, and a comment section full of people who either feel the same thing or have strong opinions about why I shouldn't.

Here's what stood out.

"You Throw the First One Away"

One senior dev described a workflow that's almost the inverse of mine. They let agentic AI build the throwaway iterations on greenfield stuff, learn from the mistakes, then take a couple days to refactor into something reasonable. Their least favorite part of a project is when they don't know what they don't know, so they let AI eat that discovery phase.

But in an established codebase, they flip. They use AI as a rubber duck: following existing patterns, debating current design, working through alternatives. They said AI is not super helpful when you have a complex and working system, but it keeps them engaged with the codebase and thinking through refactors.

That's a useful frame. Greenfield vs. established codebase might need completely different levels of AI autonomy.

Building in Stages, Not Blobs

One developer described exactly why full agentic output feels wrong. When they write code manually, they build in stages. Write the most basic thing. Test it. Add the next layer. Test it. Wire up the data. Test. Each cycle lets you grow the code from nothing to something functional.

AI bypasses all of this. It just spews out a big blob, and sometimes it isn't even the blob you want. You're stuck debugging something that appears to have been written by a drunk intern who has no clue.

Their solution: have AI write in stages too. Same iterative approach, but with AI sketching each layer. Some steps are simple enough to just code yourself. The point is to build incrementally, not to receive a finished product you don't understand.

Review Fatigue is Real

Multiple people brought up review fatigue. It's more work to review code than write it a lot of times. When you write it, you understand the intent. AI does silly things like adding a bunch of fallback code because it doesn't have enough info, so it implements cautiously. You tell it what not to do, but there's always something you forgot to include.

I felt that. There is definitely some review fatigue where I have to read too much code.

One dev pointed out there's no mandate at their workplace to go super-fast. Their team would rather they wrote high-quality code than a lot of code. If they need to spend a couple hours reviewing their own generated code, nobody holds it against them. They're already going twice as fast as they used to.

That's a healthy take. The speed pressure is partly self-imposed.

Another dev called this "busy waiting," borrowing from scheduling theory. The CPU is technically running instructions but producing zero useful output. With AI: you're generating code, accepting code, reviewing code, debugging code. Lots of motion. But comprehension is built through friction, not throughput. The commit history shows progress. Your mental model doesn't.

Productivity is measured in problems you understand, not tokens consumed.

The Flip-Flop Problem

Someone raised a point I've been thinking about: when code is from a colleague, I already adjust my expectations and read it carefully. If something is unclear, I can poke my colleague and they'll explain why they did it that way.

With AI, you ask why, and it says "Absolutely, that is my mistake..." It flip-flops. You point out the error in its backtrack and it backtracks again. A human sometimes does this too, but at least both parties learn something in the process.

That matters more than it sounds. The dialogue you have with a human about code intent is fundamentally different from the dialogue you have with AI. A colleague can say "I copied from Stack Overflow and I don't fully understand it either." That honesty is more useful than AI's confident backtracking.

One Manual Task Per Session

One dev shared a practical rule: keep one task per session that you do fully manually, usually the thing closest to actual system behavior. It keeps the mental model alive. If they go fully hands-off for a week, they lose track of what the code actually does vs. what they think it does.

Simple. I like it.

The Navigator Mode Approach

Another dev wrote a Claude skill called Navigator mode. It's instructions for AI to act like a pair programmer sitting next to you. You look at the ticket together, it asks clarifying questions, it tells you what to do, and you drive. It cuts throughput way down, but everything that goes into the editor has to pass through your eyeballs and out your fingertips.

That's an interesting middle ground. AI as navigator, you as driver. Not the other way around.

The Sharpest Counterpoint

The comment that made me think the hardest came from a retired engineer. They said: back when third-party libraries started becoming widely available, a lot of devs were on the NIH (Not Invented Here) struggle bus. "How can I trust code written by people I don't know to do these important foundational things?" The concerns weren't unfounded. Some libraries were bad, all contained bugs. But in the long run, productivity gains won out, libraries got better, and now none of us think twice about it.

You don't feel ownership of those third-party libraries, nor should you. You feel ownership for what you build with them. They think AI code will eventually fall out the same way.

That's a strong argument and I genuinely appreciate them taking the time to write it out. I think they might be right about the long arc. But right now, today, with AI at this level, I still need my hands in it. Maybe that changes. Maybe I'm the dev in 2003 insisting on writing my own string parsing library. I'll accept that possibility.

I asked them if they're having fun in retirement. They said being retired is the bomb, and they're pretty sure they were born to sit around playing games and reading books in the sun. May we all get there someday.

A Good Project Isn't One You Know by Heart

The last piece of wisdom that stuck with me came from a dev who said: a good project isn't the one that you know by heart so you can change it with ease. A good project is one where a stranger can come into the codebase and find the relevant piece of code with ease. The stranger doesn't need to know the entire repo in order to make their fix.

That reframes the whole question. Maybe the goal isn't "I must understand every line." Maybe the goal is "the codebase must be structured so that understanding is possible." If AI-generated code is clean, well-documented, and navigable, then maybe my feeling of disconnection is a signal to improve the code's structure, not to write more of it by hand.

I'm still chewing on that. It's hard, and it points in a different direction than my instincts.

What AI Taught Me About Caring

Before AI, I honestly didn't think about the connection to the codebase as something important. I coded 100% by hand, so the connection was just there by default. I never had to think about it because I never had the option to lose it.

Now I can feel that feeling. The difference between code I understand and code that just exists in my repo. AI didn't just change how I write software. It made me realize I actually care about the craft in a way I couldn't articulate before.

I feel all the f*cks that I did. And I want to keep feeling them.

This is solvable. I'm trying to solve it. My workflow is one answer, not the answer. The community showed me there are a lot of different ways to keep your hands in it while still getting the speed benefits. The retired dev showed me this might all look different in ten years. The 40k fans reminded me that humans have always had a complicated relationship with the machines they depend on.

The only wrong move is to stop caring about what your code does.

I'm Hung, a fullstack developer building tools to help bring purpose to your life. You can follow my journey at dhung.dev.

1GB VM. How do I pack whole production stack to it.

DHg — Sun, 05 Apr 2026 16:47:56 +0000

I'm running a full production backend on GCP's free-tier e2-micro: 2 vCPUs, 1GB RAM. Fastify, PostgreSQL 18, Redis, nginx, systemd, TLS, the whole thing. It works, it's fast, and it costs me nothing while I validate the product.

TLDR

A 2-vCPU, 1GB VM is way bigger than you think. With some tuning you can fit a real stack on it, handle hundreds of users, and not pay a dime until you have revenue. Define the playbook once, and you can scale up or migrate to any provider by replaying the same sequence.

What I'm running

The app is Inner Anchor. It's a productivity app: daily management, task management, focus mode with a floating DPIP (Document Picture-in-Picture) button that reminds you what you're doing, and a purpose bar to remind you why you're doing it. The backend is Fastify with PostgreSQL and a small Redis. Right now it's pre-revenue with a few dozen beta testers.

Why a raw VM instead of Railway or Render

I want to deploy on the server the same way I would scale the server. I want to define the process once and then reuse the whole process when migrating. If I need more power, I just upsize the VM and the whole stack stays. If I need to switch providers, I bring the script to another provider and run the exact sequence and I replicate the environment exactly like that.

Define once, use forever. That's the play.

A managed database on DigitalOcean, which is the cheapest I've found, is minimum $15/month. I can host this entire stack for free because I don't have many users yet. I'm not going to burn money on infrastructure before I find product-market fit.

Squeezing 1GB

At my company I usually deploy on 2GB or 4GB VMs or more. I have never deployed anything serious on 1GB of RAM. So we have to squeeze out the most of the performance here.

ZRAM

Since it's 1GB of RAM, we have to crank up the ZRAM almost to double. One gig of RAM and one gig of compressed swap. So basically we can use about 1.8 gigs of RAM before it OOMs. And we have to turn up the swappiness to 180 to actually utilize all that compressed swap.

ALGO=lz4
PERCENT=100
PRIORITY=100

vm.swappiness=180
vm.vfs_cache_pressure=500
vm.dirty_ratio=5
vm.dirty_background_ratio=1

PostgreSQL and Redis on the same box

I install both directly. No Docker. Docker alone has 100-200MB of overhead. On a 1GB box, that's a lot. I don't even use PM2 to manage the Node process. I just spin up systemd. Prune down everything that's unnecessary and keep the core.

PostgreSQL is tuned for the constraint:

shared_buffers = 128MB
work_mem = 4MB
maintenance_work_mem = 32MB
effective_cache_size = 256MB
max_connections = 20

Redis gets capped at 64MB with allkeys-lru eviction. Both services get OOM score adjustments so the kernel kills the app process before it touches the database.

Frankly, I have never tweaked any database params in my professional work. I found it surprisingly easy. The whole process of installing a raw database and tuning it is just some install commands and it works. I did not expect that.

Why not split them out?

Because I want to scale vertically the same way. Just put in more RAM and more vCPU and it should magically scale. Eventually I'll move to a managed database, but until we have revenue, no.

What it actually looks like in production

I just pulled up htop. Memory is at 361MB used out of 965MB. Swap is at 147MB out of 965MB. CPU hovers at about 1%.

When one user hits the API, both cores spike to about 6% and then drop back to 1%. Memory doesn't move much. For 10+ users spread across the day, this holds up fine.

Response times from the server journalctl (processing time only, not counting latency between the US instance and Vietnam client):

Average GET: ~4ms
POST (update daily purpose): ~21ms

21 milliseconds server-side for a POST is pretty damn good if you ask me.

Security without overcomplicating it

I block all ports except what's needed. I moved the SSH port off 22. fail2ban watches both SSH and nginx. There are firewall rules at both the GCP level and UFW. Root login is disabled, password auth is disabled, deploy user is key-only.

I listed Tailscale as a future addition but haven't implemented it. The current setup is good enough. I don't have a reason to add it yet.

The deploy script is dumb on purpose

git pull origin develop
pnpm i
pnpm run migrate:deploy
pnpm run prisma:generate
pnpm run build
sudo systemctl restart app

No Docker, no blue-green, no rollback. This is intentional. For an early stage where I have to move fast, and the beta users are very forgiving, this is fine. I'll add proper deployment when I have about 100 users or more. But right now they are forgiving.

The full playbook

This is the sequence, in order. Each step is idempotent and you can replay it on any Debian-based VM from any provider.

Update base system, install essentials (openssh, curl, git, htop, ufw)
Create a deploy user with key-only SSH, disable root login
Set up ZRAM (lz4, 100% of RAM, swappiness 180)
Install PostgreSQL 18 from the official repo, create database and user, tune for 1GB
Install Redis, cap at 64MB with LRU eviction
Install nginx as a reverse proxy to your app port
Install fail2ban for SSH and nginx
Move SSH to a non-default port
Set OOM score adjustments (nginx > postgres > redis > app)
TLS with certbot
UFW: deny all incoming, allow your SSH port, 80, 443
Set up deploy key for GitHub
Install nvm, Node, pnpm
Create systemd service with a 300MB memory guard
Write the deploy script

That's it. The whole thing takes maybe 30-45 minutes if you're following along. And the next time you need to do it, you have the playbook.

When to leave

This setup can't handle everything. If you need horizontal scaling, background job workers eating memory, or you're getting serious traffic, you'll outgrow it. But for a solopreneur validating a product with no revenue, this is the right level of infrastructure. You're not paying for capacity you don't need, and when you do need more, you just upsize the machine and everything stays exactly where it is.

I'm Hung, a fullstack developer building tools to help bring purpose to your life. You can follow my journey at dhung.dev.

Axios got compromised. They attacked the human, not code.

DHg — Sat, 04 Apr 2026 09:30:19 +0000

On March 31, 2026, two malicious versions of Axios were published to the npm registry through a compromised account. Both versions injected a dependency called plain-crypto-js@4.2.1 that installed a remote access trojan on macOS, Windows, and Linux. The malicious versions were live for about three hours before being removed.

TLDR: The Axios npm compromise wasn't a code vulnerability. Attackers social-engineered the lead maintainer with a cloned company, a convincing Slack workspace, and a fake Microsoft Teams meeting that tricked him into installing a RAT. Open source is being attacked through humans first, not code.

I was spooked

I was spooked a little bit because that night, I installed 1.14.0, not 1.14.1. God damn it, I was very anxious and went straight to checking the current version in my lockfile of my Inner Anchor.

If you're not sure, check yours:

grep -E "axios@(1\.14\.1|0\.30\.4)|plain-crypto-js" package-lock.json yarn.lock 2>/dev/null

If anything comes back, treat that machine as compromised. Downgrade to axios@1.14.0, delete node_modules/plain-crypto-js/, rotate every fucking secret, and check your network logs for connections to sfrclak[.]com or 142.11.206.73 on port 8000. If this happened on a CI runner, rotate any secrets that were injected during the affected build.

What happened

The attacker gained access to the lead maintainer's PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions.

In my opinion, open source is being attacked through humans first. Recently, and especially with AI helping, they are attacking more human than the code itself. That's what I see.

The timeline

Jason Saayman, the lead maintainer, said he doesn't have the exact timeline for when the initial compromise occurred, but here's the sequence for the package itself:

About two weeks before March 31: social engineering campaign initiated against the lead maintainer
March 30, 05:57 UTC: plain-crypto-js@4.2.0 published to npm
March 31, 00:21 UTC: axios@1.14.1 published with the infected plain-crypto-js@4.2.1
March 31, around 01:00 UTC: axios@0.30.4 published with the same payload
March 31, around 01:00 UTC: first external detections. Community members file issues reporting the compromise. The attacker deletes those issues using the compromised account.
March 31, 01:38 UTC: Axios collaborator DigitalBrainJS opened a PR to deprecate the compromised versions, flagged the deleted issues to the community, and contacted npm directly
March 31, 03:15 UTC: malicious versions removed from npm
March 31, 03:29 UTC: plain-crypto-js removed from npm

The whole thing happened from about 00:21 UTC to about 03:15 UTC. About 2 hours and 30 minutes. That is fast.

How they got the lead maintainer

This is the part that matters most. Jason Saayman confirmed how the attack worked in the post-mortem thread. The attack vector mimics what Google has documented in their threat intelligence report on UNC1069 targeting cryptocurrency and AI through social engineering. But they tailored it specifically to him.

They reached out masquerading as the founder of a company. They had cloned the company founder's likeness as well as the company itself. Then they invited him to a real Slack workspace. The workspace was branded to the company's CI and named in a plausible manner. The Slack was thought out very well. They had channels where they were sharing LinkedIn posts. The LinkedIn posts, he presumes, just went to the real company's account, but it was super convincing. They even had what he presumes were fake profiles of the team of the company, but also a number of other open source maintainers.

They scheduled a meeting with him on Microsoft Teams. The meeting had what seemed to be a group of people involved. Then the meeting said something on his system was out of date. The UI in the Microsoft Teams web version popped up saying it was missing something and he had to install it. He installed the missing item because he presumed it was something to do with Teams. That was the RAT.

In his own words: "everything was extremely well co-ordinated looked legit and was done in a professional manner."

What's changing

Resolution was a complete wipe of all lead maintainer devices, resetting all credentials across all accounts, irrespective of platform, both personal and all other capacities.

Going forward: immutable release setup, proper adoption of OIDC flow for publishing, improvement of overall security posture, and updating all GitHub actions to adopt best practices.

The key lesson from the post-mortem: publishing directly from a personal account was a risk that could have been avoided. The OIDC flow and immutable release setup should have been in place before this happened. There was no automated way to detect an unauthorized publish. Detection depended entirely on the community noticing.

Open source maintainers are the target now

This is similar to previous attacks targeting open source maintainers. They exploit the human, the crucial part of it. We haven't really heard about code-level exploits as much, but the social engineering is really, really dangerous. Open source maintainers with high-impact packages are active targets for sophisticated social engineering. Hyper vigilance is needed both on the registry and in a personal capacity.

Shoutout to DigitalBrainJS for acting fast when the compromised account had higher permissions than his own, and for getting npm to take action. The community response was fast. The attack was faster. That's the problem.

I'm Hung, a fullstack developer building tools to help bring purpose to your life. You can follow my journey at dhung.dev.

I Migrated to a Monorepo in 2 Days. Things Broke.

DHg — Thu, 02 Apr 2026 16:58:49 +0000

I migrated my side project, Inner Anchor, from two separate repos to a monorepo. It took two days, things broke in production, and my users saw a white screen. But I'd do it again because I don't have to worry about accidentally causing a bug from mismatched contracts anymore.

TLDR: Multi-repo meant I had to define the API contract in two places. I missed it once and shipped a bug to production. So I migrated to a monorepo with Turborepo and pnpm. It was more work than I expected, things broke, but now I define a contract once and it works everywhere. That alone was worth it.

Some context on the project

Inner Anchor is a daily management app where people manage tasks with their purpose. It helps you start your day with the right task and adhere your tasks to a purpose. It has task management, focus mode, daily purpose, rollover, settings, user management. I started listing the features and realized, oh, that's a lot. But it's still relatively small. I was managing two repos: one for the API, one for the web app.

Why I did this

Let me go to the past a little bit. In my company, we have a tradition to do multi-repo. We just create multiple repos and develop them separately, navigating through VS Code workspaces. At most I manage four workspaces at the same time. And I felt some of its shortcomings: I have to copy the contract of the API to two places. I have to redefine it. Sometimes I miss it, and that causes a bug in production.

I did cause a bug when I mismatched the contract between the front-end and the back-end. That was the breaking point. I wanted to try a new approach in my personal project, so I tried monorepo.

Picking the tools

I did a little bit of research on Turborepo and NX, and I asked Claude what the best tool for it was. It said Turborepo is simple with pnpm. So I just went with it, because tooling picking is not important. Just go there, use one of the two most popular, and figure out what you need later. That's my philosophy.

And honestly, the tooling was easier than expected. It took me a few good minutes to get familiar with turbo.json. I had to Google to pull up the terminal UI for the monorepo, and that's it. The tool is very pleasant.

The actual migration process

Here's the real sequence:

First, enable pnpm. Create an apps folder. Move the API folder inside the apps folder, then move all the source code of the API into it. That's one.

Second, copy the whole git tree of the front-end to a web folder inside apps. That's basically the restructure done.

Then the tweaking: get both of them to build and dev first. Copy the env files to each. Build them to make sure it works.

After that, install a universal git lint-staged at the root, and each repo gets a separate lint-staged config so each of them stages their own code. That adheres to the best practice of the lint-staged official doc.

Clean up, prune down, and it should be done.

It should be.

What broke

After the restructure was "done," the real work started.

First, I had to switch Cloudflare from the old front-end repo to the new monorepo. Second, I had to SSH into the VM to manually pull the new code, manually build and run it to see if it broke or not. Third, I had to rewrite the GitHub workflow and GitHub Actions to point to the new location of the deploy script. And fix the deploy script too.

There's no way to do a zero-downtime migration on this, I think.

And then the second thing that broke: after I migrated, I went to the web, and it's white. Something didn't build. I had to go back to the repo, turn it up, build, preview it to find the source of the bug. It was a DayJS extend call where the import wasn't right. I had to add .js to the file path of the duration plugin to make it work again.

That was real panic, because the project has users now. If someone was using it right then and it just went poof, white screen. I'm sorry. If you experienced this, sorry.

I expected the migration to be smooth, just redirect and restructure files. I was wrong. There were multiple points of pain: restructuring, redirecting Cloudflare to the new repo, rewriting the CI to make sure it worked again. That was too much work.

What it looks like now

Now I have a shared package called contract. It's a shared contract between the front-end and back-end. I use Zod schema for schema parsing for both the UI forms and the back-end, so they share the same validation. That's it. We don't over-engineer it. It's just a simple contract package.

Right now I'm implementing the payment workflow and I see it. It's kind of pleasant where I define once and it works in both repos and I don't have to worry if I break something. "I don't have to worry about breaking something" is the most worthy moment of the monorepo that I think made it worth it.

The tradeoffs

The sidebar of the folder structure is longer now. I have a hard time scrolling. And I have to filter the API and the web in my terminal commands now, so that makes my commands longer. Mild inconvenience.

I haven't experienced the monorepo long enough to feel the real downsides. I could pull up Google and tell you 10 points of downside of monorepo, but I won't. I don't experience them right now. Maybe I'll revise this blog in the future, but not now.

Who this is for

This is for solo devs with side projects. Small teams can do this too, and honestly small teams need this most because the source of bugs is often the mismatched contract. The bigger the team, the more you need the monorepo.

If you're on the fence

It will be a lot of work. But I'm happily enjoying it now because I don't have to worry about accidentally causing a bug. I don't have to worry about that anymore.

I'm Hung, a fullstack developer building tools to help bring purpose to your life. You can follow my journey at dhung.dev.

Why Budget Apps Don't Work (And What to Do Instead)

DHg — Sat, 14 Mar 2026 10:08:50 +0000

Most budget apps are the same product wearing different clothes.

You download the app. You log every coffee. You categorize every snack. At the end of the month, the app shows you a chart that says: "You spent money."

Then next month, you stop logging.

If you keep trying expense trackers because you want to save more but can't sustain daily tracking, this post is for you. Here's the core idea:

If a system requires daily discipline to work, it fails precisely for the people who need it most.

Instead of tracking everything, I'll walk through a simpler setup: a fixed monthly spending allowance plus automatic saving. Your budget works even when you're tired.

TL;DR

Tracking expenses is measurement, not control. It reports after the money is already gone.
The real bottleneck is consistent human effort, not app features.
Use tracking only as a short diagnostic sprint (2 to 4 weeks), not a lifestyle.
A better default: "pay yourself first" plus one spending allowance account.
You check one number ("how much allowance is left?") instead of 120 transactions.

Why expense tracking doesn't work for most people

The pattern everyone recognizes

You download a budget app. You track for a few days. Maybe two weeks if motivation is high. Then life happens:

A brutal week at work
A trip you didn't plan for
A few late nights
"I'll catch up later"

Now you have a backlog of unlogged transactions and the whole system collapses.

The discipline paradox

People adopt expense tracking because they struggle with spending control.

But expense tracking only works if you already have strong discipline, because it demands:

Constant attention
Repeated daily decisions
Friction on every purchase

So the exact weakness that makes you want tracking is the thing that breaks tracking.

That's the paradox, and no amount of UI polish fixes it.

Expense tracking is measurement, not control

Tracking answers one question: "What did I spend?"

But by the time you need that answer, it's already too late. The money is gone.

If your problem is overspending, you don't need a better ledger. You need constraints that act before the spend happens, not analysis after.

Think of it this way:

Tracking is a speedometer. It tells you how fast you're going.
A real budget is a speed limiter. It prevents you from going too fast.

Most budget apps sell you a pretty speedometer and call it financial control.

The hidden cost no one talks about: category labor

Expense trackers quietly turn you into an unpaid accountant.

Even with auto-import from your bank, you still end up doing real work: categorizing ambiguous transactions, splitting shared purchases, renaming merchants, handling cash, reconciling errors.

This work doesn't create value. It creates the feeling of being financially responsible.

And the moment you stop doing that work, the entire system dies. Your data gets stale, the categories drift, and you stop opening the app.

So the question is: why build a financial system that only works when you do daily paperwork?

Why detailed spending data is a trap

A lot of tracking is fake progress.

Knowing you spent $18 on snacks versus $22 doesn't change your financial outcome. What actually moves the needle is usually one of these:

Total discretionary spending for the month
Big recurring costs (rent, subscriptions, debt payments)
Your automatic saving rate
Income versus lifestyle creep

Most people don't have a data problem. They have a system design problem.

Adding more granularity to your spending data is like adding more decimal places to a wrong answer.

When expense tracking actually makes sense

I'm not saying tracking is useless for everyone. There are real cases where it helps.

Short-term awareness building

Tracking can be powerful as a diagnostic tool. Track for 2 to 4 weeks, learn your actual spending patterns, then switch to a lower-effort system.

Use it like a blood test, not a daily vitamin.

External requirements

Some situations genuinely require transaction-level records:

Business expenses and taxes
Reimbursement claims
Shared household budgets with a partner
Tight debt payoff plans
Irregular income with zero buffer

If tracking has a concrete external purpose, do it. Just don't confuse recordkeeping with behavior change. They're different activities.

Auto-import reduces friction (but doesn't solve the core problem)

Bank syncing makes logging easier, yes. But you still have to review, interpret, and adjust consistently. Lower friction improves adherence, but it still relies on your attention.

Defaults beat attention. Every time.

A better system: the one-number budget

Here's what to do instead of tracking every purchase.

The principle is simple: make saving automatic, and make overspending visibly impossible.

You do that by separating money into two buckets:

Money you're allowed to spend
Money you don't touch

Not "in your head." In actual, separate accounts.

Instead of tracking 120 transactions, you check one number: how much allowance is left this month?

How to set this up in 30 minutes

Step 1: Pick a fixed monthly allowance

This is your guilt-free discretionary spending for the month.

Example:

Income: $4,000/month
Fixed costs (rent, utilities, subscriptions): $1,600
Savings goal: $800
Allowance: $1,600

Your allowance is the money you can spend on anything without categorizing it.

Step 2: Create two accounts

Account A: Bills + Savings
Account B: Spending (your allowance)

If your bank supports sub-accounts or "buckets," great. If not, a second checking account works fine.

Step 3: Automate transfers on payday

This is the core of the system:

Transfer savings first to a "do not touch" account
Pay fixed bills
Move the allowance to Account B

Now your month is pre-decided. You made one disciplined choice (the transfer), and the system handles the rest.

Step 4: Follow one rule

If the allowance account is getting low, slow down. If it hits zero, stop discretionary spending until next month.

No categories. No transaction backlog. No guilt charts.

Just one number. That's it.

Why this works when budget apps don't

Budget apps ask you to be disciplined every single day.

This system asks you to be disciplined once a month: on payday, when you set up the transfers.

That's a fair trade.

Compare the failure modes:

Tracking failure: "I stopped logging." Now the system is blind and you have no data.
Allowance failure: "I ran out early." The system still worked. You just learned something.

And that second failure mode is useful, because it tells you exactly what to adjust:

Was the allowance too low?
Was the savings goal too aggressive?
Did a fixed cost spike?
Was there one big unplanned expense?

You debug at the budget level, not the receipt level. That's a fundamentally different (and more sustainable) feedback loop.

Common problems and fixes

"I have irregular income"

Switch to a weekly allowance. Put all income into a buffer account, then pay yourself a fixed weekly amount (every Monday, for example). Build a 1 to 2 month cash buffer if possible.

"I blow through it early in the month"

Split the allowance into weekly chunks. A monthly lump sum invites impulsive front-loading. Weekly amounts add friction in the right place.

"I still want some visibility into my spending"

Track only the big stuff, lightly. Audit your subscriptions once a month. Review your top 10 merchants. Keep one "miscellaneous" category.

Don't track 200 transactions. Track the 10 things that actually matter.

The best compromise: a tracking sprint

If you genuinely enjoy tracking, keep doing it.

But if you're tired of starting over every few months, try this: run a 2 to 4 week tracking sprint once or twice a year. Get the awareness. Learn the patterns. Then go back to the allowance system for the other 48 weeks.

That gives you insight without the permanent labor.

Quick-start checklist

Choose your monthly allowance number.
Open a separate spending account (or sub-account).
Automate: save first, then bills, then move the allowance last.
Check your allowance balance once a week.
If you run out early, adjust one lever: reduce the allowance, reduce savings temporarily, cut a fixed cost, or switch to weekly allowance.

Frequently asked questions

Is expense tracking a waste of time?

For most people trying to save more money, yes. Daily expense tracking creates busywork without changing spending behavior. The effort-to-outcome ratio is poor compared to automating your savings and using a fixed spending allowance. The exception is short diagnostic sprints (2 to 4 weeks) to identify patterns.

Why do budget apps fail?

Budget apps fail because they depend on sustained daily effort from users who adopted the app specifically because they lack that consistency. The app can't hold you accountable. It can only report what already happened. The better approach is building constraints into your accounts so overspending becomes structurally difficult.

What is the "pay yourself first" method?

Pay yourself first means automatically transferring money to savings and investments before you spend on anything else. Instead of saving whatever is "left over" at the end of the month (which is usually nothing), you save first and spend from what remains. This flips the default: saving becomes automatic, spending becomes the constrained variable.

What should I do instead of tracking expenses?

Set up a two-account system: one for bills and savings (automated), one for discretionary spending (your allowance). Check one number each week: how much allowance is left. This replaces daily transaction logging with a single glance.

Does the allowance method work with variable income?

Yes. Use a buffer account that collects all income, then pay yourself a fixed weekly allowance from that buffer. This smooths out income swings and gives you a consistent spending rhythm even when earnings fluctuate.

The one takeaway

Budget apps fail because they bet on daily discipline. Build a budget that works even when you're exhausted.

Stop tracking every expense. Decide your allowance once. Automate the rest. Then live your life.

Modern password policy 2026: stop Password@1

DHg — Tue, 10 Mar 2026 16:46:18 +0000

If you remember one thing from this post: password security is mostly won by (1) length + uniqueness and (2) server-side defenses. Complexity rules and forced rotation mostly make people choose more predictable passwords.

This is for devs building or fixing a login system. A copyable policy and the reasoning behind each rule.

TL;DR: the policy you can ship today

Min length: 12 when password is the only factor, 8+ if used alongside MFA.
Max length: allow at least 64 characters.
No composition rules. Don't force "upper + lower + number + symbol."
No periodic rotation. Only reset on compromise evidence.
Blocklist: reject common, expected, and compromised passwords.
UX that helps: allow paste, support password managers, offer "show password."
No password hints, no security questions.
Rate-limit failed logins.

These align with NIST SP 800-63B. Not a loose interpretation. This is what the standard actually recommends.

Why legacy rules fail

You've probably inherited a policy like this: minimum 8 characters, must include a symbol and uppercase letter, expires every 90 days, security questions for recovery.

It looks secure on paper. In practice, it trains users to do exactly the wrong thing. They pick a base password like Password@1 and increment the number every quarter. They reuse it across services. The "complexity" is a pattern attackers already guess early.

When I built auth for Inner Anchor, I could have gone with the standard 8-char-plus-symbol approach. But I'd seen what that produces in real systems: a wall of P@ssw0rd variants in breach dumps. So I went a different direction.

The rules, and why

1. Minimum length: 12 characters

NIST's baseline is 8. I recommend 12 for password-only auth because it pushes users past the "single word + mutation" pattern and into passphrase territory. Something like mycat sleeps a lot is 20 characters, easy to remember, and orders of magnitude harder to crack than C@tLover1.

For Inner Anchor, I set the minimum at 12. No complaints from users. Most password managers generate 16+ anyway, so the floor rarely matters for people doing the right thing. It mainly catches the people who would otherwise submit hello123.

If your app requires MFA, 8 is a reasonable floor since the password isn't the only barrier.

2. Max length: at least 64 characters

Password managers generate long random strings. Passphrases are naturally long. If you cap at 16 or 20 characters, you're punishing the users with the best security habits.

Allow at least 64. Set an upper bound you can afford to hash (128 or 256 is reasonable) so nobody can DoS your server with a 10MB password.

3. No composition rules

When you force "must contain uppercase, number, and symbol," users converge on the same patterns: capital first letter, number at the end, ! at the end. Attackers know this. They try those patterns first.

Drop the rules. Require length and a blocklist instead. You get less predictability, not more.

Some security teams will push back on this. Point them to NIST SP 800-63B, which explicitly says not to impose composition rules.

4. No periodic forced rotation

Expiring passwords every 90 days creates incrementing passwords and more reuse. Users treat passwords as disposable when they know it's temporary.

Instead, force a reset only when you have evidence of compromise: a breach match, a suspicious login, a leaked credential report. This means you need monitoring and an incident response flow, but you needed those anyway.

5. Blocklist checks

Reject passwords that appear in breach corpuses, common password lists, dictionary words, and context-specific terms (your app name, the user's email handle, obvious derivatives).

This is the hardest part to implement well. You can check passwords against the Have I Been Pwned API using k-anonymity (you send a partial hash, not the actual password). For a local check, a bloom filter over a breach corpus works. Either way, keep a generic rejection message like "this password is too common" rather than revealing why it was blocked.

6. Support password managers

This means: allow paste in password fields, set proper autocomplete attributes (new-password for signup, current-password for login), and offer a "show password" toggle.

Password managers are one of the few things that reliably improve password security at scale. Blocking paste actively prevents your best users from doing the right thing.

7. No hints, no security questions

"What was your first pet's name?" is guessable, researchable, and probably already in a data breach somewhere.

Use real recovery flows instead: email magic link with device confirmation, recovery codes generated at signup, or authenticator-based recovery. Recovery is usually the weakest link in any auth system. Removing security questions forces you to build something better.

8. Rate-limit failed attempts

Even a perfect password policy falls apart if attackers can try unlimited guesses. Rate-limit by account and by IP.

Prefer progressive delays over hard lockouts. Hard lockouts let attackers lock out real users on purpose. A backoff curve (short delay after 5 failures, longer delay after 10, CAPTCHA after 20) protects accounts without creating a denial-of-service vector.

Hash passwords with Argon2id

This isn't optional. If your database leaks and passwords are in plaintext or weak hashes (MD5, SHA-256 without salt), every account is compromised instantly.

Use Argon2id. It's memory-hard, which means attackers can't just throw GPUs at it. OWASP has a cheat sheet with recommended parameters.

For Inner Anchor, I use Argon2id with tuned parameters for my server's resources. The key idea: pick settings that take around 200-500ms on your hardware. That's invisible to a user logging in once, but brutal for an attacker trying millions of hashes.

If you're currently on bcrypt, that's still acceptable. But if you're building from scratch in 2026, go with Argon2id.

What you trade off

Longer minimums can frustrate some users. Mitigate this with passphrase examples during signup ("try a short sentence instead of a complex word") and password manager support.

Blocklists require maintenance. You need to update your breach corpus periodically and handle the privacy implications carefully. Never log raw passwords, even rejected ones.

No forced rotation means you must actually detect compromise. If you drop rotation without adding monitoring, you've made things worse, not better.

Rate limiting can be weaponized. An attacker could trigger delays for a real user. Risk-based scoring (device fingerprint, geo, behavior) helps, but adds complexity.