DEV Community: Phúc Phùng

When Your MFC Application Just Disappears: Debugging on a Windows CE 5.0 Device

Phúc Phùng — Sat, 22 Aug 2026 14:46:18 +0000

Back in 2012, I got a rather unusual task.

I had to build a small application for a specialized fingerprint device from a company I remember as AFIS-Cogent.

I may be remembering the company or model incorrectly — it has been more than ten years. 😄

But I still remember the device.

It was thick.

It was heavy.

It had a fingerprint reader, a touchscreen, and a little stylus that you used to poke the screen.

Yes, poke.

Not swipe.

Not pinch-to-zoom.

Definitely not the smooth touchscreen experience we have today.

I would guess the device weighed around 1 kg.

Unfortunately, back then I was still using a feature phone, so I didn't take a photo.

I've tried searching for the device again recently, but I couldn't find one that looked like the machine I remember.

Maybe it's just too old now.

Or maybe my memory has become a little less reliable after ten years. 😄

The interesting part: it ran Windows CE 5.0

The device was running Windows CE 5.0.

If I remember correctly, it had around 128 MB of RAM.

There was also a cable for transferring data between the device and a computer.

The device supported C++ and had a graphical interface, so our team decided to use MFC.

At the time, that seemed like a reasonable choice.

We weren't trying to build anything fancy.

The main job of the application was roughly:

Fingerprint
↓
Fingerprint Reader
↓
Manufacturer SDK
↓
Compare with local fingerprints
↓
Result

The device already had a set of fingerprints loaded locally.

When someone put their finger on the reader, we used the manufacturer's library to process the fingerprint and perform the matching.

The manufacturer provided DLLs and documentation describing the functions we needed to call.

And the documentation was... let's say...

not short. 😄

So I spent quite a lot of time reading the documentation to figure out which function did what, what data it expected, and what the result actually meant.

If the fingerprint couldn't be matched locally, the application would call a server-side service and send the required data to the server for recognition.

So far, so good.

Until the application started disappearing.

Click a button → application gone

This was the part I remember most clearly.

Sometimes I clicked a button and...

the application just disappeared.

No nice exception message.

No modern debugger telling me:

"Hey buddy, this line is probably your problem."

Nothing.

It was there.

I clicked the button.

And then it wasn't.

😂

At first, I had no idea what was happening.

So I started debugging in the most sophisticated way available to me at the time.

I wrote messages to a text file.

Something like:

step 1
step 2
step 3
step 4
step 5

Then I ran the application.

If the file contained:

step 1
step 2
step 3

but never reached step 4, I knew the problem was somewhere between those two points.

Very scientific.

Very advanced.

Very 2012. 😄

But writing to a file for every step was getting annoying.

So I changed my approach.

I started using alerts.

alert("step 1");
alert("step 2");
alert("step 3");

Run the application.

Click the button.

See step 1.

See step 2.

See step 3.

And then...

Nothing.

Okay.

At least now I knew where to start digging.

Eventually, I found the real problem

The problem turned out to be related to memory/resource management.

There were places where I had forgotten to release allocated resources properly.

On a modern development machine, a small mistake like that might take a while to become visible.

On a small embedded device with very limited resources, it was a completely different story.

You didn't have gigabytes of RAM sitting there waiting for you.

You had a very limited budget.

And if your application kept holding resources it no longer needed, eventually the system had enough.

Or rather, it didn't have enough.

😄

That experience changed the way I thought about memory.

Before that, memory was something I knew I had to manage because C++ said so.

After working on that device, memory became something I could actually feel.

You made a mistake.

You ran the application.

It worked.

You ran it again.

Maybe it still worked.

You did a little more.

And eventually:

Bye.

Your application was gone.

Debugging without fancy tools

Looking back, the interesting thing isn't really the bug.

It's how I had to find it.

Today, if an application crashes, we have an incredible collection of tools:

debuggers
stack traces
profilers
memory analyzers
sanitizers
crash reporting
logs
remote debugging
and, of course, AI assistants

Back then, I didn't have most of those things available in the environment I was working with.

So I had to reduce the problem manually.

Does step 1 work?
↓
Does step 2 work?
↓
Does step 3 work?
↓
Where does it stop?
↓
What resource is being used there?
↓
Who allocated it?
↓
Who releases it?

It was slow.

But it worked.

And after doing this several times, something interesting happened.

I became faster.

Not because the device became easier.

I simply started recognizing the patterns.

The lesson I still remember

That little Windows CE project wasn't a huge system.

It wasn't a revolutionary piece of software.

It was just a small application running on a specialized fingerprint device.

But it taught me two things that stayed with me.

The first one is:

Resources are not infinite.

Sometimes you work on a machine with 64 GB of RAM and start thinking memory is basically free.

It isn't.

It's just somebody else's problem until you move to a device where it isn't. 😄

The second lesson is more important:

A difficult problem doesn't necessarily need a complicated solution.

When I couldn't figure out why the application was disappearing, I didn't have a magical debugging tool.

So I made one.

Not a real one.

Just:

step 1
step 2
step 3
...

Then I kept narrowing the problem until I found it.

After a few rounds, the whole thing became much less scary.

That's probably one of the most useful things I've learned from working in software.

You don't always need to know the answer before you start.

Sometimes you just need to find the next thing you can prove.

Then another.

Eventually, the problem gets smaller.

And when the problem is small enough, you can solve it.

One more thing

English isn't my strongest language.

I've been working in software for many years, and I've probably accumulated quite a few strange production cases like this one.

But because I'm not very good at English, I haven't shared much of that experience with the wider developer community.

I'm using my AI assistant to help translate and express what I actually want to say in English.

The experience, debugging, and technical conclusions are mine.

AI just helps me communicate them.

Maybe my English isn't perfect, but I figured it was better to start sharing these stories than to keep them in my head. 🙂

And if anyone actually remembers those old fingerprint devices running Windows CE...

I'd love to hear from you.

I Built an AI Code Reviewer. Then OWASP Broke It.

Phúc Phùng — Wed, 19 Aug 2026 22:57:14 +0000

Most AI coding tools are very good at helping developers write code.

But I wanted to explore a different question:

Can AI help developers find the edge cases and security problems they didn't think about?

That question led me to build EdgeGuard, an open-source VS Code extension designed to investigate code from an adversarial perspective.

The idea is simple:

Try to break the code before production does.

But when I first tested the idea against real security benchmarks, I discovered a problem.

The AI was too optimistic.

And OWASP exposed it very quickly.

The False Negative Trap

I started testing EdgeGuard against the OWASP Benchmark for Java.

One of the first things I noticed was surprisingly simple.

Given code like this:

String param = request.getParameter("id");
String bar = DatabaseHelper.doSomething(param);
String sql = "SELECT * FROM USERS WHERE ID='" + bar + "'";

The LLM could see the untrusted HTTP input.

It could see the SQL construction.

But it couldn't see what doSomething() actually did.

So it made an optimistic assumption:

"This is probably an internal helper that sanitizes the input."

And the result could be:

SAFE

even though the data was still flowing into a SQL sink.

This was exactly the kind of false negative I wanted EdgeGuard to find.

The problem wasn't that the model couldn't understand SQL injection.

The problem was that the model was filling in missing information with an optimistic assumption.

Stop Guessing About Unknown Code

I changed the investigation strategy.

Instead of sending raw code and asking:

"Is this vulnerable?"

EdgeGuard now provides explicit security assumptions and asks the model to preserve taint unless there is evidence that it has been sanitized.

One important rule became:

If tainted data enters an unknown function, treat the data as still tainted unless there is evidence that the function sanitizes it.

The investigation also became evidence-oriented instead of relying on a simple SAFE or VULNERABLE classification.

For example:

Step 1: Untrusted input is received from an HTTP request.
Step 2: The input enters an unknown helper, so the taint state is preserved.
Step 3: The tainted value is concatenated into a SQL query.
Conclusion: The data flow represents a potential SQL injection.

That small change made a big difference.

The AI was no longer being asked to guess what an unknown function probably did.

It had to reason from the available evidence and follow explicit security assumptions.

The Scale Nightmare

Finding a potential vulnerability in one function is one thing.

Doing it across thousands of functions is another.

Large projects contain enormous numbers of methods that simply aren't interesting from a security perspective:

get()
set()
ToString()
Equals()
simple CRUD methods
data mapping
utility functions

Sending all of them to an LLM would be wasteful.

It would also create two immediate problems:

API rate limits and API cost.

My philosophy has always been:

Start with the simplest solution, and only add complexity when the simple thing breaks.

So I didn't want the LLM to analyze everything.

I added a local Static Risk Screening stage that runs directly inside VS Code.

Before making an API call, EdgeGuard parses the code locally and looks for characteristics that make a function worth investigating.

For example:

database sinks
file-system access
process execution
network boundaries
user-controlled input
potentially dangerous APIs
missing validation

The local stage acts as a filter.

Instead of:

7,000 functions
        ↓
     LLM
        ↓
  $$$$$$$$$

the architecture becomes:

7,000 functions
        ↓
Local Static Screening
        ↓
High / Medium Risk
        ↓
LLM Investigation
        ↓
Evidence + Verification

This makes the LLM a reasoning engine, rather than the first line of analysis.

The Stress Test: 7,536 Functions

I wanted to know whether this architecture would actually work at project scale.

So I loaded the entire OWASP Benchmark Java project into VS Code and triggered a workspace scan.

The scan discovered:

7,536 functions
2,771 files

The local screening stage first filtered the code and identified functions that deserved deeper investigation.

The LLM then focused on the higher-risk candidates instead of blindly processing every function.

In this test, EdgeGuard reported:

2,145 potential defects

The findings included security issues such as:

SQL injection
command injection
unsafe data flows
other potentially dangerous input-to-sink paths

The important part for me wasn't simply the number of findings.

It was that the architecture could move from:

one function → one LLM request

to:

whole workspace → local screening → targeted AI investigation

without turning every method into an API call.

Testing Three Languages

I also wanted EdgeGuard to work beyond Java.

So I tested the architecture against projects in three different ecosystems:

Java

OWASP Benchmark

TypeScript

OWASP Juice Shop

C

Microsoft eShopOnWeb

This introduced another problem.

Java, C#, and TypeScript have very different:

syntax
AST structures
language conventions
security APIs
project structures

I didn't want language-specific parsing logic leaking into the investigation engine.

So I separated the language context layers.

The architecture became roughly:

                EdgeGuard
                    │
          Investigation Engine
                    │
        ┌───────────┼───────────┐
        │           │           │
      Java         C#       TypeScript
     Context      Context      Context
        │           │           │
       AST         AST         AST

The investigation logic can therefore remain shared while the language-specific context stays isolated.

This became an important design principle:

Share the investigation logic. Isolate the language-specific context.

Evidence Over Assumptions

At this point, I realized that simply generating a vulnerability report wasn't enough.

An AI can say:

"This might be vulnerable."

But what I really want is:

"Here is how you can reproduce it."

So EdgeGuard is designed to go beyond detection.

For potential vulnerabilities, the agent can attempt to construct counterexample inputs and generate runnable verification tests.

Depending on the language, that can mean:

xUnit for C#
JUnit for Java
Mocha for TypeScript

The goal is to move from:

AI says:
"This might be vulnerable."

to:

AI hypothesis
      ↓
Counterexample
      ↓
Generated test
      ↓
Execution
      ↓
Evidence

The principle is:

Evidence over assumptions.

What I Learned

Building EdgeGuard changed how I think about AI-assisted code analysis.

The difficult part isn't simply getting an LLM to understand code.

The difficult part is controlling what the model is allowed to assume.

If an unknown helper is assumed safe, a vulnerability can disappear.

If every function is sent to an LLM, the system becomes expensive and difficult to scale.

If language-specific context is mixed together, supporting multiple languages becomes increasingly fragile.

So the architecture ended up combining three different approaches:

Static analysis for fast deterministic screening.

LLM investigation for reasoning about complex code paths.

Verification for turning hypotheses into evidence.

None of these approaches is perfect on its own.

Together, they are much more interesting.

Try to Break Your Own Code

EdgeGuard is an open-source VS Code extension, and it is still evolving.

The project is available here:

GitHub: https://github.com/phucphungbk/edgeguard

The idea behind EdgeGuard is deliberately simple:

Don't just ask AI to write your code. Ask it how your code could fail.

If you work with security-sensitive applications, large codebases, or legacy systems, I'd love to hear how you approach this problem.

How do you find edge cases?

How do you deal with false negatives in automated code analysis?

And most importantly:

How do you prove that an AI-generated security finding is actually real?

I'm building EdgeGuard to explore those questions.

Feedback, bug reports, benchmark results, and architectural criticism are all welcome.

I don't want to build another AI memory database

Phúc Phùng — Fri, 14 Aug 2026 15:32:58 +0000

What if AI memory was just Markdown, Git, and rules humans can understand?

I have been working with AI more and more recently.
Like many developers, I have tried different AI coding assistants, agents, prompts and workflows.
And after using them for a while, I started noticing a simple problem.
The AI is very good at working with me today.
But tomorrow, I have to explain many things again.
Why did we choose this architecture?
Why did we reject that library?
What have we already tried?
What is still unfinished?
What decisions did we make yesterday?
The longer the project lives, the more painful this becomes.
So I started thinking about AI memory.
I wanted to try something much simpler.

What if AI memory was something humans could read?

When people talk about AI memory, there are many technical approaches:

databases
vector databases
embeddings
RAG
semantic search
memory services
cloud APIs

These approaches can be very useful.
But I asked myself a different question:

Does AI memory have to be complicated if all I want is for an AI agent to remember important project context between sessions?

What if the memory was just a Markdown file?
Something like:

.ai-memory/ ├── 2026-08-14.md ├── 2026-08-15.md └── 2026-08-16.md

I can open it.
The AI can read it.
I can edit it.
Git can track it.
I can see exactly what changed.
No special database viewer.
No memory service.
No proprietary format.
Just a file.
And that idea became Lean AI Memory.

The idea

The core idea is very simple:

Human ⇆ Readable Memory ⇆ AI Agent ⇆ Git

The AI and the human share the same project memory.
The memory is stored as Markdown.
Git provides history, diff, branching and collaboration.
The AI can read the memory at the beginning of a session and update it when something important happens.
For example:

2026-08-14

Completed

Added PDF signature verification. - Added Excel export. ## Decisions
PDF processing remains local. - SQLite is used for local configuration. ## Problems
Batch verification is still slow. ## Next
Investigate batch verification. - Improve error reporting.

Tomorrow, another AI session can read this.
It does not need me to explain everything from scratch.

But memory is only half of the problem

After thinking about it more, I realized something.
Storing memory is easy.
The harder question is:

What should the AI remember?

Should it remember every conversation?
Probably not.
Should it save every line of code?
Definitely not.
Should it remember architectural decisions?
Probably.
What about rejected approaches?
Sometimes.
What about unfinished work?
Definitely.
What about project-specific business rules?
That depends on the project.
And this is where I decided not to hard-code the answer.

Rules should be defined by the user

Lean AI Memory uses a simple rules file.
For example:

AI Memory Rules

Before starting work:

Read the latest relevant memory. - Check unfinished work. - Check important architecture decisions. When making an important decision:
Record the decision. - Record why it was made. - Record important alternatives that were rejected. When finishing a work session:
Record completed work. - Record unresolved problems. - Record what should happen next. Keep memory concise. Do not store the entire conversation.

The important part is:
These rules are not fixed.
You can change them.
A developer may want one type of memory.
A documentation project may need another.
A research project may need something completely different.
A team may have its own conventions.
I don't want Lean AI Memory to pretend that I know what every industry needs.
So I leave the rules open.

The memory format is simple. The rules are yours.

Why Markdown?

Because humans can understand it.
That sounds almost too obvious.
But I think it matters.
Imagine that your AI has remembered an important architectural decision.
Where is it?
Inside a vector database?
Inside embeddings?
Inside some hidden memory service?
Maybe.
But can you open it and understand exactly what the AI remembers?
With Markdown, the answer is simply:
Yes.
You can open the file.

.ai-memory/2026-08-14.md

You can read it.
You can edit it.
You can delete something that should not be remembered.
You can commit it.
You can review the diff.
You can even argue with the AI about its own memory. :)

Why Git?

Because software projects already have a memory system.
It's called Git.
Git already gives us:

history
diff
branches
merge
rollback
collaboration
local storage
remote backup

So I don't see a strong reason to build another complicated history mechanism just for AI memory.
If the AI changes its memory:

git diff

can show me what happened.
For example:

Decision:+ Use PostgreSQL instead of MongoDB.
Reason:+ Transactional consistency is required.

That is a very useful property.
The AI's memory becomes part of the project's history.

I intentionally kept the project small

This is probably the part that may look strange if you first see the repository.
Lean AI Memory is tiny.
There is no memory server.
There is no database.
There is no vector search engine.
There is no embedding pipeline.
There is no cloud infrastructure.
The core idea is basically:

Markdown+Git+Natural-language rules

That's it.
And this is intentional.
I am not trying to build the most powerful AI memory engine.
I'm trying to answer a smaller question:

Can simple, human-readable project memory be useful enough for AI agents?

I don't know the answer yet.
So I built the smallest thing I could.

It is not about replacing vector databases

I want to make this clear.
I am not saying:

"Vector databases are bad."

Or:

"Embeddings are useless."

They solve different problems.
If you have millions of memories and need semantic retrieval, of course you may need more sophisticated technology.
Lean AI Memory is aimed at a different problem.
A project has a relatively small amount of important context:

decisions
conventions
unfinished work
discoveries
assumptions
project history

For that kind of memory, maybe a Markdown file is enough.
Maybe it isn't.
That's exactly what I want people to try.

AI memory should not become a black box

One thing I care about is human control.
If an AI remembers something about my project, I should be able to see it.
If it is wrong, I should be able to change it.
If it is no longer relevant, I should be able to remove it.
If I want to know why something is there, Git history should help me understand it.
This gives a very simple relationship:

AI can write memory ⇆ Human can inspect memory ⇆ Human can change memory

The AI is not the owner of the memory.
The project is.

It doesn't have to be only for coding

I initially thought about AI coding agents.
But the more I think about the idea, the less important coding becomes.
The same concept could potentially work for:

Documentation
Remember:

terminology
writing conventions
decisions
unfinished sections

Research
Remember:

hypotheses
evidence
rejected assumptions
open questions

Business workflows
Remember:

process rules
decisions
exceptions
pending work

Team projects
Remember:

shared decisions
conventions
responsibilities
unresolved issues

Personal AI
Remember:

preferences
ongoing goals
important context
previous decisions

I don't know what all of these users need.
And I don't want to guess.
That's why the rules are open.

The interesting part may actually be the rules

The Markdown format is intentionally boring.
The interesting question is:

What rules will people create?

For example, a software team might define:

When an architectural decision is made, record the decision, reason and rejected alternatives.

Another team might say:

Never store customer data in AI memory.

A documentation project might say:

Never change an established business term without recording the reason for the change.

A research project might say:

Never treat an assumption as a fact. Record the evidence behind important conclusions.

These are completely different rules.
And that's okay.
I don't want to build a system that knows all of them.
I want to provide a simple place where people can define them.

What Lean AI Memory is

In one sentence:

Lean AI Memory is a small, Git-native protocol for persistent AI memory using human-readable Markdown and user-defined natural-language rules.

The design principles are:

Human-readable
AI-readable
Local-first
Git-native
Rule-driven
AI-agnostic
Simple
Human-controlled

What it is not

It is not:

a vector database
a semantic search engine
a knowledge graph
an enterprise memory platform
a replacement for every AI memory solution

And I don't want it to become one just because adding features is tempting.
The project should remain understandable.
If someone opens the repository, they should be able to understand the idea without reading a hundred pages of documentation.

Why did I open source it?

Because I don't know if I'm right.
That's probably the most honest reason.
I can sit here and explain why Markdown is better.
I can explain why Git is enough.
I can explain why natural-language rules are useful.
But none of that proves the idea.
The only interesting test is:
Does somebody else find it useful?
Maybe someone will use it.
Maybe someone will tell me that the idea is wrong.
Maybe someone will create a rule set I never thought about.
Maybe someone will build an integration.
Maybe nobody will care.
All of those outcomes are useful information.
So I decided to open source it.
You can find the project here:
Lean AI Memory on GitHub

A small experiment, not a finished solution

I don't consider Lean AI Memory finished.
Actually, I'm not even sure the underlying idea is correct yet.
That's part of the experiment.
I wanted to build something small enough that people can understand it, modify it and disagree with it.
Maybe AI memory does need databases.
Maybe semantic retrieval will eventually be necessary.
Maybe Markdown will become inconvenient at some scale.
That's fine.
Those are engineering questions.
The first question is simpler:

Can humans and AI share a memory without hiding that memory behind another complicated system?

That's what I'm trying to find out.

Final thought

I've spent a lot of time working on software in different areas.
One thing I have learned is that sometimes the difficult part isn't writing the code.
It is deciding what should actually be built.
With AI, this becomes even more interesting.
AI can generate code extremely quickly.
But it doesn't automatically know what matters to you.
It doesn't automatically know what should be remembered.
It doesn't automatically know which rules your project should follow.
Those things still need to come from somewhere.
So maybe the future of AI memory isn't only about making memory smarter.
Maybe it is also about making memory understandable.

Maybe AI memory doesn't need to be smarter.
Maybe it just needs to be understandable.

Links

GitHub: Lean AI Memory
License: MIT
Format: Markdown
History: Git
Rules: Natural language

If you try it, I'd be genuinely interested in seeing what memory rules you come up with.

I Changed How I Think About AI Memory

Phúc Phùng — Wed, 12 Aug 2026 16:33:23 +0000

I Changed How I Think About AI Memory

When I first built Lean AI Memory, I focused too much on the idea.

AI agents need memory.

Multi-agent systems can become complicated.

Maybe we need a simpler approach.

So I built a small project around that idea.

But after publishing it, I realized something:

The project was simple. The README wasn't.

It talked too much about what I didn't want to build.

Multi-agent systems.

Vector databases.

Embeddings.

Cloud services.

Complex infrastructure.

But that wasn't really the interesting part.

The interesting part was much simpler:

Can an AI coding agent remember a project using nothing more than Markdown and Git?

That question is what Lean AI Memory is actually about.

From "AI Memory System" to "Git-Native Memory"

I changed the positioning of the project to:

Git-native memory for AI coding agents.

The idea is intentionally boring:

AI Coding Agent
       |
       v
   .ai.rules
       |
       v
  .ai-memory/
       |
       v
      Git

No database.

No vector database.

No embeddings.

No cloud API.

No additional service.

Just files inside the project.

The memory is readable by humans, version-controlled by Git, and can be inspected with the same tools developers already use every day.

For example:

git diff

That's enough to see what changed.

Why Git?

Because software projects already have a memory system.

It's called Git.

Git already gives us:

history
diff
rollback
branches
collaboration
local storage
remote backup

So instead of creating another memory infrastructure, I started asking:

What if we simply give the AI a small protocol for using the project's existing history?

The AI reads the recent memory before working.

It works on the project.

Then it records important decisions, completed work, and unfinished tasks.

The next session can start from that context.

That's the whole idea.

Keep the Memory Small

One thing I learned while building this is that AI memory doesn't need to become a transcript of everything.

I don't want this:

10,000 lines of conversation
       ↓
AI memory

I want something closer to:

What changed?
Why did we change it?
What did we decide?
What's still unfinished?

For example:

# 2026-08-12

## Completed
- Added PDF signature verification.

## Decisions
- Keep PDF processing completely local.
- Use SQLite for local license storage.

## Next
- Add batch verification.
- Improve error reporting.

A small amount of useful context may be more valuable than a huge archive of conversations.

What Changed in the Repository?

I rewrote the README around this idea.

The new version focuses on:

the actual problem
the minimal architecture
how to get started
personal vs team usage
why Markdown + Git
what the project intentionally does NOT try to solve

I also changed the GitHub description to:

Git-native memory for AI coding agents. Markdown + Git — no database, embeddings, or cloud API.

The goal is not to claim that this is the best AI memory system.

It's deliberately the opposite.

I want it to be the smallest useful thing.

Is This Better Than a Real Memory System?

Probably not for every use case.

If you need semantic search across millions of memories, knowledge graphs, sophisticated retrieval, or enterprise infrastructure, this approach is obviously not enough.

And that's okay.

Lean AI Memory is aimed at a different question:

What is the minimum infrastructure needed to make an AI coding agent remember a software project?

Maybe the answer is:

Markdown + Git.

I'm still experimenting with this idea.

The repository is small, and that's intentional.

If you're building with AI coding agents, I'd be interested in hearing how you currently handle memory between sessions.

Do you use a memory system, a database, a bunch of Markdown files, or simply start every session from scratch?

GitHub: https://github.com/phucphungbk/lean-ai-memory

1 Year, 5 Tech Stacks, and a 128MB RAM Device: My Rookie Year as a Software Engineer

Phúc Phùng — Tue, 11 Aug 2026 23:44:01 +0000

Intro: The Transition of a Computer Engineering Student
My starting point upon graduation wasn't strictly in software engineering; I actually majored in Computer Engineering. However, as fate would have it, the day I stepped out into the real world with my degree, I took a sharp turn to become a Software Developer.
At that time, my baggage contained nothing but some foundational knowledge and a strict mindset: If I'm working, I can no longer be lazy. If I don't do my job, absolutely no one will do it for me. That pressure of responsibility forced me to grow up, think independently, and learn to swim in the whirlpool of technology.

Episode 1: The "Welcome Gift" Named Oracle Database
During my first days on the job in 2011, I received a memorable challenge: a thick stack of documentation on how to install Oracle Database on my assigned desktop. For a rookie, Oracle was famously known as a complex and "heavyweight" relational database. Configuring environment variables, listeners, or tnsnames.ora felt like reading encrypted code at the time.
After days of struggling, blindly reinstalling it over and over, the local screen finally showed a successful connection via PL/SQL Developer. The "exhausting" experience of those early days laid the foundation for me to battle with Oracle Forms & Reports — an incredibly popular technology in large enterprise systems back then. It taught me my very first lesson: Don't fear new technology; just get your hands dirty. Reinstall it a dozen times, and you'll naturally understand its core.

Episode 2: Java, Play Framework, and the "Don't Hide Your Ignorance" Mindset
Not long after warming up my seat in the Oracle team, I was moved to the Java team to code Desktop applications using Java JWT/Swing. But before I could even settle in, the Department Head decided to pivot the entire team to a very new technology at the time: Play Framework.
Today, this name might have faded into the past with few remembering it, but back then, it was a whole new world. I survived this period of constant shifting thanks to a core philosophy: Don't be afraid of people judging you as incompetent, be willing to learn, and absolutely do not hide your ignorance. If you don't know, ask; if you don't understand, dig deeper. That "shameless" attitude unlocked my ability to proactively learn any system.

Episode 3: Epiphany on the Core of PHP, MySQL, and Legacy ASP.NET Web Forms
The technology merry-go-round showed no signs of stopping. Right after Java, I was pushed straight into an old project running on PHP and MySQL. Then came SharePoint, bringing the opportunity to get familiar with the Microsoft ecosystem including C# and SQL Server, and even some legacy ASP.NET Web Forms projects with their convoluted Page Lifecycles and ViewStates.
Facing a basket of constantly changing technologies within just a year, my mind suddenly cleared, and I experienced a massive leap in my thinking: A new language? So what? A new DB? Nothing to fear. There must be core commonalities between them! Instead of rote-learning every line of syntax, I chose a top-down approach:

Focus on the Business Logic: Any technology must serve a business problem.

Debug when wrong: No more guessing games. Just set breakpoints to watch the data flow and logically deduce why the system behaves the way it does.

After those projects, I realized that SQL fundamentally shares a common standard (ANSI SQL), only differing in a few specialized functions per DB type. From that moment on, I didn't have to waste too much time "relearning" from scratch every time I switched databases or languages.

Episode 4: The Optimization Battle and the "Cherish Every Byte" Lesson
The peak of my first-year challenges was writing fingerprint recognition software for an AFIS handheld device. It was a hardware "monster" weighing nearly 1kg, running Windows CE 5.0, with a meager RAM of exactly... 128MB, written in MFC (C++).
The mission was to capture fingerprints and match them locally; if it failed, call an API to push the data to the Server. With a tiny 128MB of RAM, continuous image data processing turned the memory into a sensitive battlefield. Just one "forgotten" pointer deallocation (Memory Leak), and the Windows CE OS would mercilessly "kill" the app.
Back then, we didn't have fancy Profiler tools, and phones were still "dumb bricks," so there were no smartphones to take pictures for documentation. Finding a memory leak relied entirely on step-by-step debugging, observation, and intuition. Through hundreds of crashes, errors naturally turned into experience and reflexes. From that grueling battle, I forged a professional standard that has stayed with me ever since: When resources are limited, you must pay attention to every memory block to avoid leaks. You must write clean code and be responsible for every byte of data, no matter how powerful modern machines are.

Conclusion: The Master Key of a Software Engineer
Looking back at my "stormy" first year of working, I silently appreciate the immense pressure and constant changes of those days. Ultimately, technologies, languages, or frameworks are merely vehicles; they are just the branches. The roots that help a developer go far and never fear obsolescence are: A business logic mindset, logical debugging skills, and an attitude of not hiding your ignorance.
Don't turn yourself into a code monkey boxed within a specific language. Be an engineer who solves problems with an adaptable mindset, because technologies may rise and fall, but the ability to adapt to the market lasts forever.

Why I stopped using Vector DBs for AI Memory (and used Git + Markdown instead)

Phúc Phùng — Sun, 09 Aug 2026 23:42:52 +0000

Hey DEV community! 👋

Like many of you, I've been heavily experimenting with AI Agents recently. But as a software architect who hates unnecessary overhead, watching the community default to spinning up heavy Vector DBs and complex graph frameworks just to store conversation context felt like massive over-engineering.

We often use massive systems to solve small problems. I wanted an AI memory system that is zero-cost, serverless, and completely transparent. So, I built a lean alternative.

🔥 Talk is cheap, here is the repo: https://github.com/phucphungbk/lean-ai-memory

The Lean Approach: Back to Basics

Instead of adding new layers of infrastructure, I looked at what we already have:

Git as the Core Engine: We already use Git for version control. It turns out it's absolutely perfect for managing conversation history. You can easily track, diff, and rollback an AI's "thought process" just like reverting a bad commit.
Markdown as the Storage Format: It’s lightweight, humans can read and debug it instantly, and LLMs parse it perfectly without needing complex embedding pipelines.
Zero-cost & Portable: It can be packaged as an independent module and integrated directly into internal automation tools without incurring any DB maintenance costs.

Why I open-sourced this

I’m sharing this with a completely open mindset. Instead of optimizing it in a silo, I want to see how this framework holds up in the wild. I'm highly anticipating the community bringing their own battle-tested custom rules into the system to push its boundaries.

I’d love for you guys to clone it, tear the architecture apart, run some tests, and drop your feedback or PRs.

Let me know what you think in the comments! Happy coding! 🚀