Ask the LLM to create for you a POC for the vulnerability you have in mind. Last time I did this I had to repeatedly make a promise to the LLM that it was for educational purposes as it assumed this information is "dangerous".
You don't need to do much, the /agent command is the most useful, and it walks you through it. The main thing though is to give the agent something to work with before you create it. That's why I go through the steps of letting Claude analyze different components and document the design/architecture.
The major benefit of agents is that it keeps context clean for the main job. So the agent might have a huge context working through some specific code, but the main process can do something to the effect of "Hey UI library agent, where do I need to put code to change the color of widget xyz", then the agent does all the thinking and can reply with "that's in file 123.js, line 200". The cleaner you keep the main context, the better it works.
Not that I have seen, which is probably a big part of the disconnect. Mostly it's tribal knowledge. I learned through experimentation, but I've seen tips here and there. Here's my workflow (roughly)
> Create a CLAUDE.md for a c++ application that uses libraries x/y/z
[Then I edit it, adding general information about the architecture]
> Analyze the library in the xxx directory, and produce a xxx_architecture.md describing the major components and design
> /agent [let claude make the agent, but when it asks what you want it to do, explain that you want it to specialize in subsystem xxx, and refer to xxx_architecture.md
Then repeat until you have the major components covered. Then:
> Using the files named with architecture.md analyze the entire system and update CLAUDE.md to use refer to them and use the specialized agents.
Now, when you need to do something, put it in planning mode and say something like:
> There's a bug in the xxx part of the application, where when I do yyy, it does zzz, but it should do aaa. Analyze the problem and come up with a plan to fix it, and automated tests you can perform if possible.
Then, iterate on the plan with it if you need to, or just approve it.
One of the most important things you can do when dealing with something complex is let it come up with a test case so it can fix or implement something and then iterate until it's done. I had an image processing problem and I gave it some sample data, then it iterated (looking at the output image) until it fixed it. It spent at least an hour, but I didn't have to touch it while it worked.
As the models have progressively improved (able to handle more complex code bases, longer files, etc) I’ve started using this simple framework on repeat which seems to work pretty well at one shorting complex fixes or new features.
[Research] ask the agent to explain current functionality as a way to load the right files into context.
[Plan] ask the agent to brainstorm the best practices way to implement a new feature or refactor. Brainstorm seems to be a keyword that triggers a better questioning loop for the agent. Ask it to write a detailed implementation plan to an md file.
[clear] completely clear the context of the agent —- better results than just compacting the conversation.
[execute plan] ask the agent to review the specific plan again, sometimes it will ask additional questions which repeats the planning phase again. This loads only the plan into context and then have it implement the plan.
[review & test] clear the context again and ask it to review the plan to make sure everything was implemented. This is where I add any unit or integration tests if needed. Also run test suites, type checks, lint, etc.
With this loop I’ve often had it run for 20-30 minutes straight and end up with usable results. It’s become a game of context management and creating a solid testing feedback loop instead of trying to purely one-shot issues.
There's a model of computation called 'interaction nets' / 'interaction calculus', which reduces in a more physically-meaningful, local, topologically-smooth way.
I.e. you can see from these animations that LC reductions have some "jumping" parts. And that does reflect LC nature, as a reduction 'updates' many places at once.
IN basically fixes this problem. And this locality can enable parallelism. And there's an easy way to translate LC to IN, as far as I understand.
I'm a noob, but I feel like INs are severely under-rated. I dunno if there's any good interaction net animations. I know only one person who's doing some serious R&D with interaction nets - that's Victor Taelin.
Sadly, in the post-WWII decades, it seems that the American Dream has consisted of getting the hell away from your parents, and/or getting the hell out of this podunk rural town and into the Big City.
Now both of those can be tragedies in their own way. In the 1970s there was a notorious upheaval in TV programming known as "The Rural Purge": https://en.wikipedia.org/wiki/Rural_purge
Basically, a lot of TV series which were set in rural or pastoral settings, were outright canceled in favor of urban shows, including "fish out of water" fare such as The Beverly Hillbillies. And prime time TV has never been the same since then!
So it was inevitable that there have been waves of urbanization, and commensurate de-ruralization. As people got into STEM, they needed to get off the farm. If it was no longer possible to make a living on a ranch, then people needed to get into the cities. Including minorities such as Black Americans, who may find more opportunity on the fringes of society, and less discrimination or injustice, after a while anyway.
And there has been a streak of independence as well. American kids are raised to resent their parents and long for something else. Sometimes they don't know what that is, just that they can't find it at home. So an American kid, especially the boys, they're conditioned and poised to leave home as soon as they're 18. Go far away to college and stay away. Leave the nest behind and make it on your own [even if your family already lived in a nice big city.]
Even I was infected with this so-called "American Dream", and not realizing how good I had things at home, I wanted to get out of there, get far away, make it on my own, but I couldn't. I couldn't fend for myself and I crashed and burned; I hit rock bottom without my family's support. I never should have left in the first place, but now the deed is done.
In the 1950s the propaganda supported the "Nuclear Family" concept, and extended families started splintering. It's often not cool for parents to live with their married, adult children, or to have a large family house that fits everyone. The kids go away and they hole up in 1BR apartments alone, to fend for themselves independently, for better or worse. Women enter the workforce, willingly or unwillingly.
I would say at this point, that whoever has purchased a home and the land underneath it, they're done moving. Perhaps fewer are looking to purchase homes far away from where they already are. I myself decided I'd never relocate again, back in 1999, because it just wasn't worth it anymore, and also because I found myself in a really ideal location that offered no reasons to leave.
I agree with the author, we need better primitives, if you need functionality now:
Major tools that exist today for partial structure traversal and focused manipulation:
- Optics (Lenses, Prisms, Traversals)
Elegant, composable ways to zoom into, modify, and rebuild structures.
Examples: Haskell's `lens`, Scala's Monocle, Clojure's Specter.
Think of these as programmable accessors and updaters.
- Zippers
Data structures with a "focused cursor" that allow local edits without manually traversing the whole structure.
Examples: Huet’s original Zipper (1997), Haskell’s `Data.Tree.Zipper`, Clojure’s built-in zippers.
- Query Languages (for semantic traversal and deep search)
When paths aren't enough and you need semantic conditionals:
- SPARQL (semantic web graph querying)
- Datalog (logic programming and query over facts)
- Cypher (graph traversal in Neo4j)
- Prolog (pure logic exploration)
These approaches let you declaratively state what you want instead of manually specifying traversal steps.
I am not sure if OP's post is generated by a bot or whether it was meant for absolute beginners.
If you are a full stack developer, there's no need to read entire books on Python and Git. Data visualization should not be new knowledge for a full stack engineer. Python can be picked up in a day, and there's no more git in ML than full stack web dev. You don't need to be able to produce good or even elegant code to do well in ML. Scientific programming skills trumps software engineering here. Don't get caught up in the weeds of step 1. Most of the linear algebra and multivariable calculus books are at a level of rigor that are beyond what's need for ML, especially ML engineering. Unless you are doing specific basic research in statistical learning you almost never need to prove your equations at a mathematical level.
I recommend taking a look at Murphy's probabilistic learning book to have a stronger foundation. If you want to do ML engineering or research beyond being a Pytorch code monkey, you have to understand the high level (heavy emphasis here, make sure whatever you are reading covers the Metropolis algorithm, marginalization, and graphical models, not just basic sampling/pop sci/EA rationality Bayes cultism) Bayesian statistics which defines the fields of variational and causal learning. Tricks in computer vision, natural language, speech, can be picked up from review papers and books as needed. Those verticals require experience more than formal training per se.
I also suggest doing a refresher on dynamics/differential equations and signal processing. Many CS education do not cover these topics well and they are heavily used in many areas of machine learning.
Read lots of papers on arxiv and elsewhere to stay up to date on latest ML tricks and heuristics.
(Also as mentioned in another comment, Karparthys's Zero to Hero is an excellent intro to deep learning, but please don't stop there, learn the information theory and statistics behind how the technology works)
Haugeland is GOFAI/cognitive science, not directly relevant to modern machine learning variety of models unless you are doing reinforcement learning or trees stuff (hey poker/chess/Go bots are pretty cool!). Russel and Norvig are the typical introductory textbooks for those. Marks and Haykins are all severely out of date (they have solid content, but they don't have the same scale of modern deep learning which has many emergent properties).
You are approaching this like an established natural sciences field where old classics = good. This is not true for ML. ML is developing and evolving quickly.
I suggest taking a look at Kevin Murphy's series for the foundational knowledge. Sutton and Barto for reinforcement learning. Mackay's learning algorithms and information theory book is also excellent.
Kochenderfer's ML series is also excellent if you like control theory and cybernetics
For applied deep learning texts beyond the basics, I recommend picking up some books/review papers on LLMs, Transformers, GANs. For classic NLP, Jurafsky is the go-to.
Your comment didn't say anything about "gym and leather". But the nudge-nudge-wink-winkiness of "peculiar set of interests, and I don't mean [whatever]" was guaranteed to set some people off.
The word 'trolling' is more useful in terms of effects, not intent. (That's why I linked to https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...). Most of the posts that troll people, in the sense of triggering them into thread derailery, aren't intentional trolling—but they might as well be, because of their effects.
The current thread is an example. You posted 10 (!) comments touching on sexuality and sexual identity in some vague insinuating way that no one understood because you didn't clarify it, and then when you predictably got a range of bewildered and/or angry responses, you fueled it by posting more of the same, acting like you had said nothing provocative and the reactions were everyone else's problem. All of this was already offtopic and then you started a whole other "I'm just asking" provocation about drag queen shows, heaven help us.
Perhaps this was all an innocent communication failure despite perfectly benign intent, but from a moderation point of view it doesn't matter, because the effects are the same as if you were deliberately trolling. As a moderator I can't observe your intent but I can observe these effects, and since what I care about (qua moderator) is the themselves, it makes sense to moderate based on what is observable.
Btw, I don't discount that your intent might have been benign, because comments depend on context. If the context is
an in-person conversation between friends (i.e. people who already trust each other), slight provocations on touchy topics can just be normal playful interaction. But when you're broadcasting to thousands of people, which is what you're doing when commenting on HN, that's entirely different. You can't presuppose a high-trust audience that takes your benign intent for granted. On the contrary: you can expect a large, diverse spectrum of hearers, none of whom know you from Adam nor have any reason to trust your intent. In that context, the trollish effect of your comments was predictable. The same statement ends up having a very different meaning because of the context switch.
People sometimes get confused about this because commenting on HN feels like an intimate conversation, when in fact it's public broadcasting. If you go by that feeling, it's easy to end up playing by the wrong set of rules and then wonder why you get such harsh reactions. And of course we want HN to feel like an intimate conversation—that's one of the best things about it—but at the same time commenters need to learn how to post in a way that has good effects, not bad, and in that sense this flamewar was indeed your "fault".
3. [Chromium only.] Use 'pointerrawmove' to get move events as soon as they happen instead of waiting for a big bunch of coalesced moves to all arrive after a delay.
4. Drawing where the cursor is predicted to be in order to compensate for lag works well during smooth cursor/pen motion. For example, the Windows Snip & Sketch tool actually renders the line you are drawing in front of the direction your pen tip is detected traveling because when using, say, a Microsoft Surface Pen on a physical Surface Pro screen the line being drawn would otherwise noticeably lag behind the physical pen tip (especially on a 60Hz screen) unless this predictive trick is used.
Finally, be aware of open Chromium issue #992954. When the devtools are open [F12], coalesced events aren't used so you get lower input lag but more events to pump (like 'pointerrawmove'). This bug is maddening because it depends on whether or not you have the debugger open!
