DEV Community: saleemha

Beyond Static Notes: Building an Agentic AI "Second Brain" That Actually Works

saleemha — Tue, 15 Sep 2026 15:14:11 +0000

Most developer knowledge bases and "Second Brain" systems eventually rot.

You spend hours setting up complex folder structures, tagging markdown files, or configuring Notion databases by topic (e.g., Docker, Kubernetes, Cryptography, Frontend). Fast forward three months, and it’s just a digital graveyard. You spend more time organizing information than actually building things.

The fix isn't a better folder hierarchy. It’s shifting from static storage to actionability, supercharged by Agentic AI.

1. The Core Flaw of Traditional Note-Taking

Traditional systems fail because they rely on a topic-based approach. They ask: "What category does this snippet belong to?"

Tiago Forte’s PARA/CODE framework completely flips the script by organizing information based on actionability right now.

CODE Workflow: Capture $\rightarrow$ Organize $\rightarrow$ Distill $\rightarrow$ Express
PARA Structure:
- Projects: What you are actively coding/building right now (has a deadline).
- Areas: Ongoing responsibilities (no end date, like infrastructure maintenance or security patches).
- Resources: Reference material, code snippets, and docs you might need later.
- Archives: Completed projects or deprecated tech stacks.

When Meta rolled out an AI second brain for over 60,000 knowledge workers (read their engineering case study here), it succeeded because it wasn't a fancy wiki—it directly reduced repetitive busywork and sped up technical decisions.

2. Why You Need Agentic AI, Not Just a Chatbot

Standard LLMs are passive. You paste a chunk of code or a system design doc, ask for a summary, and wait for your next command. That’s an intern in a box.

An Agentic AI system introduces execution loops (relying on reasoning, planning, and tool use) that turn your second brain into an active co-pilot. Instead of just holding your files, an agentic system actually drives your workflow:

Autonomous Housekeeping: If an active project in your PARA structure hasn't been touched in a month, the agent flags it, prompts you to archive it, and auto-extracts reusable code snippets into your Resources.
Contextual Cross-Pollination: As you drop a new note about a containerization setup or a data pipeline, the agent scans your graph and automatically bridges it to related architecture notes you saved months ago.
Multi-Step Execution: You give it a high-level goal ("Prep the migration brief for next sprint"), and the agent loops through your tools—pulling past project logs, drafting technical specs, and checking your active tickets without manual hand-holding.

3. Designing the Stack

If you're looking to build or wire one of these systems together, your architecture needs three layers:

The Ingestion Layer (Capture): Automated scrapers, CLI hooks, or browser extensions that feed raw markdown/data into your system.
The Structured Layer (PARA + Graph): A vector database or local markdown vault (like Obsidian) structured strictly by actionability.
The Execution Layer (Agents): Custom loops (using tools like LangChain, LlamaIndex, or custom Python scripts with tool-calling APIs) that monitor your vault and execute automated tasks.

Your Second Brain should do one thing exceptionally well: help you ship code and produce work that matters. Anything else is technical debt.

How are you currently managing your technical notes and snippets? Are you experimenting with local RAG or AI agents to automate your workflow? Let's discuss in the comments below!

Threat Modelling Using Threat Dragon

saleemha — Mon, 14 Sep 2026 12:06:33 +0000

I have tried to use a tool from OWASP called Threat Dragon for threat modelling. It took me 6 hours honestly in total. But if you follow my guide, you can see if it worths to try.

Security expert Adam Shostack, a leading authority on threat modeling, emphasizes the importance of understanding the system before assessing risks. Which means, you can't draw it, you can't secure it.

What Governance, Regulators, auditors like to see: Nice graphs, signatures, dates. Jokes aside. Let's break down who, should own what.

1- At Tribe (product) level: The tribe architect draws the diagram. Security engineer should always be part of it (not optional). Three model lives in wiki / confluence/ documented.

2- Company Level (yearly): This is the main document that auditors like to see the threat landscape and the threat modelling exercise, owned by security engineer. Make sure, the mitigations for the risks are actual and not out of date.

3- After incidents, suggest to go through the threat model document and update it after incidents hit if applicable.

Now, back to engineering.. What did I do?!

Remember the rule, you have to draw it so you can secure it.

Start with Data Flow Diagram: In Data Flow Diagrams (DFDs), external entities are typically represented by rectangles, processes by circles, and data stores by parallel lines.

The tool was not very much user friendly, as I run it on virtual machine, so it was super slow. The outcome of the DFD (Data Flow Diagram was as below).

The diagram is a simple application (for abstract only) to understand the idea how we would make the threat model.

Content Delivery

From → To What Happens

2 CDN → User Browser Delivers static content
3 Web Frontend → User Browser Returns web app responses

Authentication Flow

From → To What Happens

4 Web Frontend → External IdP Redirects user to log in
5 External IdP → API Gateway Sends back auth response
6 API Gateway → Auth Service Requests token validation
7 Auth Service → Credentials DB Checks user credentials
8 Credentials DB → Auth Service Returns validation result
9 Auth Service → API Gateway Issues session token
10 API Gateway → Web Frontend Returns authenticated session

Product Data Flow

From → To What Happens

11 Web Frontend → API Gateway Requests product data
12 API Gateway → Product Service Forwards the request
13 Product Service → Product DB Queries product info
14 Product DB → Product Service Returns product data
15 Product Service → API Gateway Sends product details
16 API Gateway → Web Frontend Returns product data

The result of the Data Flow Diagram as follows (The tool is not user friendly, and it was lagging a little on the virtual machine, thus the outcome):

Later you can click on each object and open a threat as follows, with the suggested mitigation and identify the status:

By the end of this excersise, you would be able to identify all the threats and the mitigation controls for each threat tied to an object in the Data Flow Diagram (DFD). The process of the threat modelling is not a one time, it keeps updated, and each time a threat is identified, it needs to be communicated.

Next, you need to identify for each threat, the threat source and the impacted assets.

For each component you need to ask STRIDE:
STRIDE = Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, Elevation of Privilege.

To get even more out of it, we can use Threat Composer

The threat model at the end will contain all impacted assets with linked threats, and each threat linked to mitigation. You will also have the list of mitigations (called mitigation pack).

Certain points and challenges that I found in threat modelling:

1- A threat model is useless if you don't verify it. Write tests for every mitigation. Run those tests before deployment and yearly in audit. If reality doesn't match the model, update the model.

2- Assumptions, in cybersecurity are dangerous. You assume things are true but they are not.

3- Third party dependencies, for example the rate limiting you do for API is handled by third party Cloudflare, and the rate limiting silently stops working.

The above would give you the know-how, key takeaways, the minimum, main challenges for threat modelling.

AWS WAF: Lets configure it

saleemha — Sat, 08 Aug 2026 17:21:19 +0000

Background:

Sharing some intro about AWS WAF. If you are designing applications on AWS eco-system it worths to explore to use WAF.

Usually AWS suggests to use application load balancer and configure WAF.

Below are the technicalities:

1- Always, make sure if you have admin page on your website, /admin ensure there is access control preventing unauthorized users from reaching the page.

2- A fast test to ensure if your website accepts malicious user. A very nice tool that you can use which can ensure you have WAF in place or if you want to trigger the logging and test is below two commands:

Leveraging curl and sqlmap:

curl -v -H "User-Agent: sqlmap/1.5" "http://globomantics-alb-576723268.eu-west-1.elb.amazonaws.com/"

Sqlmap: Familiarize yourself with SQLmap it is a free, open-source penetration testing tool that automates finding and exploiting SQL injection flaws in web applications.

-v: for verbose

Leveraging the internal address that AWS gives http://169.254.169.254/ for finding internal metadata

curl "http://<ALB_DNS>/search.php?q=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

Ok for the above if you are getting responses: 200 then your WAF is not configured:

So, for the sake of understanding I will just add the points, they are generic and usually it can be configured through infrastructure as a code.

But below are the main points to keep in mind:

1- WAF is firewall, and firewall has rules so you need to add them (rules and rule groups).
2- AWS WAF Managed Rule Groups: AWS has managed group rules and you can utilise them:

a) Core Rule Set: Catches common general attacks like SQL injection, XSS, and malformed requests — it's the baseline "seatbelt" protection almost every app should have.
b) Known Bad Inputs: Blocks specific request patterns already known from real-world exploits, like SSRF payloads (e.g. 169.254.169.254) or log4j-style strings.
c) Admin Protection: Blocks public access to admin/management paths (like /admin or /wp-admin) that shouldn't be reachable from outside.

3- Build your own rules. For the /admin rule you can go to rule builder and add your own rules, string match / admin.

Conclusion:
Validate, test and validate and check logging also what things are kept in the log. Traffic overview and traffic metrics are also important to keep in mind.

Regulators, auditors always ask for these rules that they are configured, logged and periodically reviewed. So make sure you have the evidences at least for a period of 1 year depending on the criticality.