dev
Cultivating curiosity for software developers
veganbeef pfp
4 replies
5 recasts
14 reactions

downshift ๐ŸŒนโณ๐Ÿ’€ pfp
0 reply
0 recast
5 reactions

caso pfp
1 reply
0 recast
14 reactions

Arti Villa pfp
3 replies
0 recast
6 reactions

Arti Villa pfp
In most worlds, I would not bother checking what the "Node16" module resolution settings pertain to, but with LLMs, I feel like I just get educated way more. In fact, I actually knew what the resolution change meant, but I didn't know it changed in version 16 and this is the point of entry to read. protip: I've asked LLMs to explain configuration files as I come across them. It would be overwhelming to learn all of them in a single go, but as I read more, I get more familiarity with different project structures. If you think people are getting dumber, don't hate the tool, hate the player. ``` The "Node16" setting in TypeScript: When you set "moduleResolution": "Node16" , TypeScript understands these new rules and will: โ€ข Check your package.json "type" field โ€ข Enforce proper file extensions โ€ข Handle both CommonS and ES modules correctly It's like telling TypeScript: "Hey, use the smart new way Node.js figures out modules, not the old simple way." ```
0 reply
0 recast
3 reactions

Arti Villa pfp
0 reply
0 recast
0 reaction

tani pfp
1 reply
1 recast
5 reactions

Josh Ellithorpe pfp
1 reply
0 recast
4 reactions

tani pfp
4 replies
1 recast
10 reactions

Royal pfp
0 reply
0 recast
2 reactions

Royal pfp
1 reply
0 recast
1 reaction

Royal pfp
0 reply
0 recast
3 reactions

Royal pfp
0 reply
0 recast
1 reaction

rubinovitz pfp
3 replies
0 recast
9 reactions

Stephan pfp
Anyone here building large projects using Claude code? My current approach is to 1. write a context doc describing the problem and solution with product requirements 2. produce a technical specification via a back and forth with a thinking model based on the requirements doc 3. Get a thinking model to develop a daily plan for an engineer 4. Give Claude code the requirements, spec, and plan and tell it to implement one day and write do a write up in a standup doc when itโ€™s done. 5. When itโ€™s done I review the changes and ask it for revisions until Iโ€™m satisfied 6. After that I start another Claude session to implement the next day with all the docs and also include the relevant standup docs. Rinse and repeat This seems to work really well. Curious if others are doing it differently and getting better results Shoutout @jc4p for sharing this approach
9 replies
3 recasts
51 reactions