If it's any consolation, they are full of shit. In the second jhana and above, the factors of initial and sustained attention disappear. In practical terms, this means you cannot direct your thoughts away from the object of concentration once you enter such state. You have to decide beforehand how long you will be in that state and give yourself a mental timer. See Dipa Ma's biography for a case of someone actually entering higher jhanas that way.
This is the reason that anything beyond the first dhyana is not encouraged in Mahayana, as it is impossible to apply vipasyana in a state of concentration so deep that you cannot direct your mind.
The teachers popular in the SF scene are inflating their own achievements and the ones of their students by using very lightweight criteria. I had that experience when I attended a TWIM retreat before their founder died. According to them, I reached the fourth or fifth jhana. I can assure you I did not.
Yeah, agreed, there's a lot of misinformation. I'm always encountering people that say they just started, followed a guided meditation on the jhanas and entered fourth jhana within a week. And then the signs they describe are all just your basic things that arise when you first start having some facility over your practice, probably not even stability in the first jhana. Not to mention that it's impossible to be following a guided, external voice when you're in such a state of absorption.
As Chogyam Trungpa would probably say, they're all practicing spiritual materialism.
There is plenty of proof, just not the type of proof likely to be accepted by people looking for a measurement from an external device, which precludes scientific proof until consciousness can be measured. Given that science cannot identify consciousness in live organisms at this time, you are going to have to wait a long time.
In general, there are three commonly accepted methods in Buddhist epistemology to know if something is true: perception, inference, and testimony. For the specific case of rebirth, common proofs use either perception, or inference.
- Perception: You train in states of concentration and use those to gain direct knowledge of past lives. Maybe some people would find this unconvincing even if they had the experience. Certainly not something likely to be accepted as scientific as Ian Stevenson's research has shown, even if the case presented was iron-clad.
- Inference: This uses Buddhist logic and an understanding of dependent origination. This specific argument comes from Dharmakīrti.
- Every moment of consciousness must have a substantial cause.
- Physical matter can serve as a cooperative condition for consciousness, but it cannot be consciousness's substantial cause, because matter and mind are fundamentally different in nature. Matter is extended, non-luminous, non-aware and consciousness is luminous and aware. If you are a scientific materialist, you will not accept this, but it must be noted that there is no scientific evidence of any kind for dead matter gaining awareness.
- Therefore, each moment of consciousness must arise from a preceding moment of consciousness of similar type.
- Then you trace this chain to the first moment of your present life. The chain must have been preceded by a moment of consciousness of similar type. The same logic applies to the last moment of your present life.
- Therefore, consciousness must be a stream that transcends physical birth and death.
Again, I am aware many people won't find this convincing, but to say that Buddhism does not attempt to prove rebirth and karma is not true.
It is difficult not to dismiss this sort of proof out of hand, because every religion engages in it. Buddhism can probably (?) coexist with many deist religions, but few of them can coexist with each other.
"But the cost of the mindfulness revolution has been Buddhism’s lost monopoly on many of its core concepts. Very few of those using Buddhist practices will ever become Buddhists in a religious sense. California Buddhism is one of the most successful cultural syntheses of the last century; but as far as conversion goes, it seems that it is Buddhism that has embraced California rather than the other way around."
Pretty much. Sad state of affairs. I don't care if people find something positive in Buddhism and offer their own takes, but too many people call their offerings "Buddhism" for the clout. Finding a qualified teacher becomes very difficult if you are actually interested in Buddhism.
On the positive side, I don't actually agree with the first sentence. You still have to find a proper Buddhist teacher if you want to be taught the good stuff. Even if you found the instructions somehow, it either requires proper motivation (at which point you are a buddhist) or a transmission for those methods to actually work.
No need. You just find someone that has a proper transmission, meaning that they were taught by a teacher that also had transmission, and so on. It's sort of like medical school. Your doctor was trained by doctors that trained under other doctors and so on.
People are free to take whatever they want from Buddhism and practice and teach it, even if completely unqualified. There is no dharma police to call. I was just making the point that calling teachings that reject core tenants of Buddhism by the same name is often just done to help them associate with whatever "clout" the word Buddhism has in the popular imagination.
Mindfulness-Based Stress Reduction is an example of how to properly go about this process without overstating what it really is.
I've been trying codex and claude code for the past month or so. Here's the workflow that I've ended up with for making significant changes.
- Define the data structures in the code yourself. Add comments on what each struct/enum/field does.
- Write the definitions of any classes/traits/functions/interfaces that you will add or change. Either leave the implementations empty or write them yourself if they end up being small or important enough to write by hand (or with AI/IDE autocompletion).
- Write the signatures of the tests with a comment on what it's verifying. Ideally you would write the tests yourself, specially if they are short, but you can leave them empty.
- Then at this point you involve the agent and tell it to plan how to complete the changes without barely having to specify anything in the prompt. Then execute the plan and ask the agent to iterate until all tests and lints are green.
- Go through the agent's changes and perform clean up. Usually it's just nitpicks and changes to conform to my specific style.
If the change is small enough, I find that I can complete this with just copilot in about the same amount of time it would take to write an ambiguous prompt. If the change is bigger, I can either have the agent do it all or do the fun stuff myself and task the agent with finishing the boring stuff.
So I would agree with the title and the gist of the post but for different reasons.
Don't you also need to specify the error-cases at each stage and at what level of the system you would like to handle them (Log away, throw ever more up, Inform others, create Tasks, etc.)?
My twist on this is to first vibe code the solution with the aim of immediately replacing it.
I’ve found that two to three iterations with various prompts or different models will often yield a surprising solution or some aspect I hadn’t thought of or didn’t know about.
Then I throw away most or all of the code and follow your process, but with care to keep the good ideas from the LLMs, if any.
I mostly work with existing codebases so I didn't really want to vibecode for real.
The only vibecoded thing was an iOS app and I didn't follow this process because I don't know iOS programming nor do I want to learn it. This only works if you know at least how to define functions and data structures in the language, but I think most PMs could learn that if they set their minds to it.
same, prototyping fast helps me understand what I'm building and the flows I want. It would not be possible to think of all the interactions and restrictions I'd want if I tried to do it on day 1.
I've been working with coding LLMs for almost a year. Here's what I've found works best:
- Do a brainstorming session with the LLM about your idea. Flesh out the major points of the product, who the stakeholders are, what their motivations and goals are, what their pain points are. Research potential competitors. Find out what people are saying about them, especially the complaints.
- Build a high level design document with the LLM. Go through user workflows and scenarios to discern what kinds of data are needed, and at what scale.
- Do more market research to see how novel this approach is. Figure out what other approaches are used, and how successful they are. Get user pain points with each approach if you can. Then revisit your high level design.
- Start a technical design document with the LLM. Figure out who the actors of the system are, what their roles are in the system, and what kinds of data they'll need in order to do their job.
- Research the technologies that could help you build the system. Find out how popular they are, how reliable they are, how friendly they are (documentation, error messaging, support, etc), their long-term track record, etc. These go into a research document.
- Decide based on the research which technologies match your system best. Start a technical document with the LLM. Go through the user scenarios and see how the technologies fit.
- Decide on the data structures and flows through the system. Caching, load balancing, reliability, throughput requirements at the scale you plan to reach for your MVP and slightly beyond. Some UX requirements at this point are good as well.
- Start to flesh out your interfaces, both user and machine. Prototype some ideas and see how well they work.
- Circle back to research and design based on your findings. Iterate a few times and update the documents as you go using your LLM. Try to find ways to break it.
- Once you're happy with your design, build an architecture document that shows how the whole system will concretely fit together.
- Build an implementation plan. Run it through multiple critique rounds. Try to find ways to break it.
- Now you're at the threshold where changes get harder. Build the implementation piece by piece, checking to make sure they work as expected. This can be done quickly with multiple LLMs in parallel. Expect that the pieces won't fit and you'll need to rethink a lot of your assumptions. Code will change a LOT, so don't waste much time making it nice. You should have unit and integration tests and possibly e2e tests, which are cheap for the LLM to maintain, even if a lot of them suck.
- Depending on how the initial implementation went, decide whether to keep the codebase and refine it, or start the implementation over using the old codebase for lessons learned.
Basically, more of the same of what we've been doing for decades, just with faster tools.
I think full literate programming is overkill but I've been doing a lighter version of this:
- Module level comments with explanations of the purpose of the module and how it fits into the whole codebase.
- Document all methods, constants, and variables, public and private. A single terse sentence is enough, no need to go crazy.
- Document each block of code. Again, a single sentence is enough. The goal is to be able to know what that block does in plain English without having to "read" code. Reading code is a misnomer because it is a different ability from reading human language.
Tried to use Show HN for my new project a couple months ago with almost no traction. It's a software literacy tutor, so I guess it's not the right audience, but my intuition aligns with this. For reference, an earlier post showing the practice engine that powers the literacy tutor did pretty well back in 2023 and it was my first post. I've had more success getting sign ups trying to do just the tiniest bit of SEO.
This is completely incorrect. The process of Tukdam has nothing to do with diet.
I can’t say what the actual process involves with too many details because it’s not appropriate to share with outsiders, but it involves meditating through sleep, which is considered a similar process to death.
The people doing this are good enough to practice through the night that they recognize a certain part of the death process and temporarily abide in it. When they stop, they die for real and their body decomposes.
For the past three years, I have been working on Trane (https://github.com/trane-project/trane/), a deliberate practice engine that helps users master complex skills. I showed it in a previous Show HN post. I wanted to build something on top of it that would be useful to a wider audience and showcase its full potential.
I learned about the literacy crisis and figured creating a literacy program would be cost-effective and impactful. After researching the science of reading and writing acquisition, I created Pictures Are For Babies, a literacy program that integrates Trane with a full curriculum to teach literacy to the college level and best-in-class pedagogy.
Two products are being released today. A Lite version available for free with no time limits and no payment required. And a Full version that aims to develop true mastery of literacy at the college level and beyond. The Full version is available via a $1000 one-time payment or a $20/month subscription with lifetime software and content updates included.
The first release of the Full version is the first step to accomplishing the ambitious goal of developing literacy to the highest level. It includes the completed curriculum for reading and writing at the symbol, word, and sentence levels. Upcoming releases will add the remaining tracks of the curriculum, focused on reading comprehension of a variety of text types and explicit writing instruction at the sentence and paragraph levels.
The Lite version includes the first levels of the curriculum. The value of the Lite version goes well beyond its content. By integrating the correct pedagogy from the ground up, it serves as a complete and professional tool for detection, prevention, and remediation of reading difficulties in early readers.
From its very first version, Pictures Are For Babies goes beyond all other literacy programs in its scope, depth, and ambition across multiple dimensions:
- By integrating Trane, the student receives a personalized learning experience that enables them to practice at the edge of their current abilities, all at the click of a button. It enables the student to learn more efficiently and the tutor to focus on delivering instruction and support instead of managing scheduling.
- It is one of the few programs that incorporates the concept of orthographic mapping from the ground up. Orthographic mapping is the process by which words are stored in long-term memory for instant retrieval. Programs that incorporate these findings develop true fluency, fix most reading difficulties, and deliver effect sizes that are multiples of those delivered by phonics-only programs.
- It includes a comprehensive and systematic curriculum that covers the entire journey from learning letter names and sounds to reading and writing sentences of college-level complexity. The initial curriculum contains over 1,200 lessons and teaches over 18,000 unique words.
- It includes no pictures, and does not engage in any form of gamification or other distractions. The choice is not arbitrary. Orthographic mapping research shows that reading and writing acquisition are at their core phonological processes. By removing these distractions and focusing on fostering the conditions for deliberate practice, Pictures Are For Babies shows respect for the science and for students as capable learners who can rise to the challenges and learn to love literacy for its own sake.
Let me know what you think! I am happy to answer any questions about the product and about the science behind it. For screenshots of the software, please visit the user interface page at https://picturesareforbabies.com/manual/user-interface/.
Projects seem broken as well. Does not follow instructions, talks in Spanish, completely ignores my questions, and sometimes appears to be having a conversation with itself while ignoring everything I say. I even typed random key presses and it just kept on giving me the same unwanted answer, sometimes in Spanish.
Finally got access to it. It's so awful. I asked it something, answered in Spanish with something completely different. In another conversation, it kept giving me completely different answers to something I didn't even ask. Telling it to stop doesn't do anything. It ignores it and continues a conversation with itself.
This is the reason that anything beyond the first dhyana is not encouraged in Mahayana, as it is impossible to apply vipasyana in a state of concentration so deep that you cannot direct your mind.
The teachers popular in the SF scene are inflating their own achievements and the ones of their students by using very lightweight criteria. I had that experience when I attended a TWIM retreat before their founder died. According to them, I reached the fourth or fifth jhana. I can assure you I did not.
reply