u/Puzzleheaded_Trip374

Hey guys, I often find interesting projects on GitHub. Getting them running is usually fine, but when I want to understand how something works or make my own changes, I get completely lost in the codebase.

Mature projects have so many abstractions, design patterns, error handling, and logic spread across different files that I never know where to start or how deep to go.

I once spent a whole week using AI to walk me through a project starting from main(). I kept diving into details, and by the end, I barely remembered anything.

Someone also suggested drawing flowcharts to understand the code, but the more I drew, the bigger and messier they became.

How do experienced developers approach unfamiliar codebases when they actually want to understand and modify them?

How do you decide what to read, what to skip, and when you understand enough to start making changes? And has AI genuinely helped you with this?

Any advice or personal experiences would be greatly appreciated. Thanks in advance!

I’m a second-year PhD student and will probably be 31 when I graduate. I’d like some advice on how to use the next three years to become employable in web/application security.

My background is a bit unconventional: bachelor’s in software engineering, master’s in computer graphics, then two years working as a CS lecturer. I had been interested in cybersecurity since undergrad, but only have chance to seriously pursue it when I returned for my PhD.

Before starting, I learned common web vulnerabilities, worked through PortSwigger Web Security Academy, and became comfortable with Burp Suite. My current research is also related to web security.

My biggest weakness is real-world experience. I’ve never worked or interned at a security company, done bug bounty seriously, or worked on a real security team.

After graduation, I’d like to work in web/AppSec overseas, with Singapore being one place I’m particularly interested in. I’d be applying as a foreign candidate.

If you were in my position with three years left, what would you prioritize? Internships, bug bounty, certifications, open-source projects, research, or something else?

Also, if doing a proper industry internship during my PhD turns out not to be possible, what would be the best alternatives to demonstrate real-world security skills?

More specifically, what would you want to see on my CV three years from now to consider interviewing someone like me?

I’m also genuinely worried about my age. I’ll be around 31 when I graduate, potentially entering the security industry with very little professional security experience. Is that considered relatively late for an entry-level or junior AppSec role, especially as a foreign applicant?

If so, what could I realistically do over the next three years to make up for that disadvantage?

Thanks in advance to anyone willing to share their experience or advice. I’d really appreciate it.

I'm currently studying LLM-based automated penetration testing, especially how agents manage memory during long penetration tasks.

One thing I've been thinking about is that memory compression in penetration testing may be quite different from general-purpose conversation summarization.

For example, an agent may generate huge amounts of output from Nmap, web requests, fuzzing, exploitation attempts, etc. Obviously we don't want to keep all of that in the LLM context forever, so some form of summarization/compression is necessary.

But a generic summary might accidentally remove details that seem small linguistically but are important operationally — for example:

• exact open ports and service versions
• credentials and where they came from
• previous failed payloads or parameters
• confirmed vulnerabilities vs. unverified hypotheses
• current privilege/access level
• hosts or services that have already been tested
• scope/authorization constraints

This made me wonder whether penetration-testing agents need a more domain-specific memory compression strategy rather than simply asking an LLM to "summarize the previous interactions."

I don't have enough real-world pentesting experience to confidently decide which pieces of information have the highest cost of being forgotten, so I'd really like to hear from people who have done longer or more complex engagements.

When you're working on a penetration test:

1. What information do you make sure you never lose track of?
2. What kinds of details are usually safe to compress or discard?
3. Have you ever forgotten a small earlier finding that later turned out to be important?
4. Do the important things change between recon, exploitation, privilege escalation, and lateral movement?

I'm not looking for a ready-made taxonomy — I'm mainly trying to understand how experienced testers mentally distinguish "temporary noise" from "state that must survive for the rest of the engagement."

Any examples from your own workflow would be really helpful.