Written today
I think the government should give out Claude subscriptions for free and impose a tax AI tokens.
Assume that two things are true in the future. The first assumption: intelligence means more production. This means the more an economy spends on intelligence compute, measured in tokens (roughly $30 per 1M tokens), the more the economy produces. AI replaces job on a mass scale, further making jobs less valuable and humans more replaceable. Unemployment increases. Secondly, assume that the more intelligence compute you do, the more energy you require and the more environmental harm you cause. Sure, we are optimizing it right now such that one token means less environment damage but assume we cannot get that to a negligible number. There's very well documented claims of water usage, pollution, power grid strain, etc. being adversely affected by data centers. Power usage causes nuclear waste to be generated, pollution from fossil fuels. Fusion turns out to be non-viable.
There is good reason to believe all three of these assumptions will be true. The first claim is probably the biggest question mark. However, with more intelligence compute, people are already more productive: a Stanford study[1] shows people gain 76-176% more productivity from using AI. Some estimate that number to be lower, but it is arguably more productive than not having AI. People use AI to learn. Increasing universal intelligence could mean lower-income individuals get more access to education. Barriers to entry would be lower for jobs as people could research skills on their own.
Social welfare exists to serve those who have less access to certain resources. California's SNAP provides families with better access to more nutritious food. FAFSA provides lower barriers to education via student loans. Doesn't it make sense to provide intelligence to lower income individuals too?
There exists a lot of latent production in the economy: people who do not have skills cannot go into a high skill job. Because someone can just talk to AI, it is very easy to use. One can reasonably create capital (an application, a program) that others use to become more optimized. This in turn increases the production of the economy.
The problem is that intelligence will scale beyond belief. Intelligence is finite as due to assumption 2: there are real costs to scaling intelligence. A reason that governments exist is to manipulate money and resolve market failures. Intelligence compute is clearly has negative externalities due to its pollution. This means that we should think of compute as a finite resource: we cannot scale it infinitely, even if xAI's Colossus works out and the billions of capital expenditure spent in AI produces infrastructure at a great scale.
Progressive taxes exist to distribute money more equitably: it can be used to distribute intelligence fairly too. It makes sense to impose taxes on the wealthy to redistribute the intelligence to less wealthy. This also incentivizes the smart people to use tokens more efficiently. More tokens will be taken from the rich and given to the poor.
[1] https://siepr.stanford.edu/publications/working-paper/household-impact-generative-ai-evidence-internet-browsing-behavior
Written 4 days ago
This is how I got into the Software Engineering (SWE) industry in 2026 as a newly-grad: and no, I can't do LeetCode to save my life. I am writing this for new graduates or college students who are considering going into SWE: I hope if this is you, it helps you. This is not written by AI.
TLDR:
- Do things that don't scale (Cold email, ask for jobs, don't be shy)
- Keep trying (be OK with getting experience for lower-than-optimal pay)
- Immerse yourself in the world of whatever you're interested in
I will back up why I think these points are important with my own personal experience: in more detail than I think other people cover it.
You can find my resume here for reference. Keep in mind that I am just one datapoint, you should consult many other datapoints. Obviously, this is not a flex but just an overabundance of data: I will share more data in excessive detail.
- Do things that don't scale
Paul Graham, a co-founder of Y Combinator, a prestigious startup venture capital firm, said that to be successful, you need to do things that do not scale. In my own words, I take this to mean "do unconventional things." In my summer of junior year, I was unable to secure an internship: I applied to 96 positions. My GPA was 3.6. I heard from a SWE professional that people often apply to 400 positions for their real jobs. A friend who is very successful of mine applied to 4,000. I received only three OAs, and only one interview with a real life person who proceeded to not even show up to the interview at all (Ampure Charging Systems!). This is a 4.2% interview rate. Out of all of those, I did not get to the second round. I was ghosted by 62.5% and rejected by the rest. One summer camp did accept me though: but it was clearly not a SWE job.
During June, when most of my friends already had internships, I started cold emailing out to YC startups via the YC startup directory page. I got a surprising 10-20% reply rate: it is a numbers game so I sent out a lot of emails. You just have to go into their website and, nine times out of ten, their names or Calendly link will be on the website. One company interviewed me twice and rejected me within a week. Another interviewed me for four rounds and I was in San Francisco. The next year, my other cold email was picked up by a Claude Code agent -- the CEO asked Claudius Codus to sift through his emails and find good recruits -- and I was interviewed and given a position at another YC startup.
Competition is often fierce at these startups. A company I worked at had over 400 applicants and just one opening. Some vibe-coded programs which were similar to the company's product just to show during the interviews. Unfortunately none of them were hired: they did not fully understand the interview questions given to them by the company. I'll talk more about interview questions in the next section.
The logic behind this is that startups are very volatile companies: go from initial contact to hire/no-hire decision within two weeks on average (from my experience). I never had a startup ghost me after an interview. Founders are taught to be extremely proactive, responsive and risk-prone as that's what is required to succeed in the startup field. This is why I believe so much in cold emailing, especially to startup founders. Cold emails are trending down, as I've been told by a founder in SF, as more AI agents flood inboxes with spam.
Learn the importance of a killer cold email: personalize the first sentence, and end it with a Calendly link and a call-to-action. The easier it is for a hiring person to 1) find how you generate value from them and 2) proceed to get you, the higher your chances of success. The subject is created to maximize attention for them to click and open the email. The email must be incredibly short too (5 sentences max) or else people will not read it.
Here is a cold email that landed me a position:
subject: Unpaid intern?
Dear [founder names]
Hi, I love your product at [company name] and wanted to learn from the greats. Do you have an unpaid internship position?
For context, I am a rising fourth year Computer Engineering student at UCLA. I've grown my own startups to attract Fortune 500 companies and generated $20k in revenue. At UCLA, I've led engineering teams of 10+ people in neurotech, cube satellite and AI labs and organizations. Please find my resume attached.
Can I schedule a call with you?
Best,
Chai
UCLA
Sometimes, sheer controversy can land you a reply. This landed me a reply (but no interview).
subject: [competitor's name] just told me to rotate my API keys
[competitor's name] just told me rotate my AI provider keys because of a security incident.
I want you guys to build something better than them. I’ve interned at two YC startups -- [name 1] [name 2]-- both in SF and have a startup of my own making $30k ARR. I will graduate next month with a BS in Computer Engineering at UCLA.
I'd love to work with yall, would you be down for a 5 min coffee chat?
[Calendly link]
Best
Chai
[LinkedIn link]
=====
subject: Re: [competitor's name] just told me to rotate my API keys
Great outreach! What’s the future plans for your own startup?
[CEO]
- Keep trying
I initially worked at a internship in Thailand (my home country) which I was nepo'd in and I made around $180 dollars by the end of two months. This was far, far lower than the average pay in America, but I still was happy to do it. In my third internship, I was offered $6k per month as a graduate (I was one quarter away from graduating!) for three months: I took it. It is better to do something than to do nothing and wait for the right opportunity. Not only do you have to do unscalable things: you need to do A LOT of it.
From talking with CEOs in startups, I learned a lot -- I would usually send them requests to talk with them over LinkedIn. These usually are low conversion rates and nothing happen from them though. Some people will say they might offer you a job verbally but unless they are a go-getter startup, they will often times not respond. To contradict this point, that's how I got the company that I am currently in: through a LinkedIn message, then a call and then an on-site and then an offer.
It is also a skills based game: you must know what you're doing. I heard from a YC founder friend of mine that LeetCode is the highest ROI activity you can do. I never did it, but because startups specialize in more architecture problems, I did not need to learn it. I'm sure if you want to go into Big Tech, you need to know it. I had three interviews with startups. I was asked to create a persistent (filesystem-based) key-value store. I was asked to debug a Python weather app. Both without the use of AI but with Google. The third company asked me: "how do you design a coding agent?" No coding was required and I sketched out my answer using Excalidraw: no AI nor Google was allowed for that. Obviously, more experience you have, the better your chances of getting a position and the higher your compensation. Therefore, the earlier you start trying to get experience, the better.
- Immerse yourself in the world of whatever you're interested in
I am very interested in startups. I have my own startup which I scaled by myself. I obsess to a pretty high degree: I try to go on sources which peers in my first startup go through (HackerNews, Hugging Face Papers, etc.). I looked at the first internship's code in a lot of detail and studied terminologies they talked about (service oriented architecture, declarative vs. imperative functions, etc.). Try to put yourself as much into the popular culture of the niche you're going to as much as possible: try to talk to others who are already in industry. Oftentimes, you'll realize how far behind you are and try your best to catch up. That's how i learned about Cursor -- one of my friends who had an internship introduced it to me. You'll pick up new concepts that make your skills even better.
Think of yourself as a craftsperson: for coding, learning Vim is akin to improving your craftsmanship said a colleague of mine. You should read the code that Claudus Codus creates because you can learn from it. Do it for the love of the game. When you get into an internship, move as fast and as early as possible. A good first impression is key.
If you have a hobby, you probably know what is like to obsess over something to a high degree. I know people who play chess who know not only all the technical details of the game but they know grandmasters' names and popular culture in the chess world: like Magnus Carlsen's wedding for example. Even though you may know news which are unrelated to being a good programming, sometimes immersing yourself in that community leads you to become a better software engineer or at least be able to talk to the interviewer and seem intelligent.
It must be recognized that in this era of AI that the frontier moves extremely fast. Half a year of lag could kill you. I see many undergraduate labs trail severely behind the frontier of industry: labs and research are only good for your industry-oriented career if you're grad/PhD students are in industry in my opinion. Some do not use git even and just email source code around. You MUST use AI. You SHOULD try the latest tool or gadget -- it is literally pressing buttons on a screen.
In the end, computer science is a made up job that if you told a person from a hundred years ago "oh I look at a screen and press buttons" they'll think you're dumb. Something something scale something something helps humanity. The end. Good luck.
Written 8 days ago
From observing the AI frontier closely in the past few years, a few patterns are emerging on how models are improving:
- Your AI company must first produce a big, powerful, high compute-cost model like
claude-mythos-5 (DeepSWE[1], CursorBench[2]). In some cases, like o1, a pioneering method like Chain of Thought is used too.
- You must then hype it up by finding X vulnerabilities in Y program[3] that millions use or a security incident[4]. Gatekeeping your latest model to researchers because it is "too dangerous" adds to this hype: release
claude-fable-5 instead.
- Then, once the model releases, competitors will attempt to compete with your frontier:
kimi-k3, qwen-3.8, grok-4.5. Some will beat it (gpt-5.6-sol). They could possibly distill your model against your ToS OR they're just slightly behind your frontier: it's suspicious so many models emerge above your previous flagship model's performance so fast right after your better one drops.
- Then, your own company will be able to distill it and improve smaller models to match the pioneer model's performance at a lower compute-cost (
gpt-5.6-luna from gpt-5.6-sol, claude-opus-5 from claude-fable-5, o3-mini from o1).
Learning from this, I think you should throw a massive amount of compute at something at the beginning. Then you make it more efficient. This has been a long-standing law in engineering.
[1] https://deepswe.datacurve.ai
[2] https://cursor.com/cursorbench
[3] https://www.anthropic.com/research/glasswing-initial-update
[4] https://openai.com/index/hugging-face-model-evaluation-security-incident/
Written 1 month ago
There are three skills which are becoming increasingly more important as a software engineer in 2026: the ability to context switch, the ability to comprehensively read and the ability to ask questions. I define the word "ability" as the act of doing something fast AND with high quality. We must accept some things are not yet be able to be done by AI. It is still essential that humans are looped in either due to lack of context, sensitive information or human communications.
LLMs are functions: they take an input and provide an output. Humans can be thought of functions too: we also do the same things as these LLMs, except we have better context management, an understanding of responsibility if things go wrong and worse general knowledge. The problem is one person cannot work in parallel like an AI: we must be able to sequentially context switch around the AI to be optimal. One signal of being optimal is us having as little idle time as possible. A skill we need to learn is to be able to switch contexts with as little switching time and as little context loss as possible. This means running multiple AI's at the same time and switching between them as they process their data. An important thing is also knowing what to context switch to next. Does this lack of idle time truly lead to higher quality and quantity output by us?
Secondly, a skill which is becoming more useful for human SWE is reviewing code manually. A friend talked about knowledge debt: the fact that we do not know what our code does is dangerous. They say Mean Time To Recovery increases drastically if we do not know what our code does. Knowledge debt leads to technical debt.
These two points above hinges on one major factor: reading fast and actually understanding what you read. The third skill is curiosity: asking questions and probing in the right places. LLMs some time do not think of everything, but probing them in the right places (which means not having knowledge debt) causes them to realize things they haven't recognized, either due to their lower intelligence or bias.
Written 1 month ago
Inspired by Hao Xiang Liew.
This is in order of importance, if any rule contradicts one another, always adhere to the lower number rule first. When making engineering decisions, please reference these rules explicitly in your plan. (e.g., "Chai's Law of Good Coding #1")
- Code must be correct, reliable & secure
2. All edge cases should be accounted for.
3. Write performant code, however do not prematurely optimize.
4. Write secure and defensive code. Fallbacks don't have to be elaborate but should at least fail-closed and keep a failure knowable to the user or developer (not silently swallowed), without leaking security or PHI. Storing user data securely is of utmost importance.
- Code must be maintainable
6. A human who doesn't know the codebase who comes to adjust your code must be able to know what they are doing.
7. Write high cohesion, low coupling code: related behaviors grouped together inside the same module, different modules kept independent.
8. Don't Repeat Yourself (DRY): but don't over-apply it. The wrong abstraction costs more than a little duplication, so prefer duplicating until the shared shape is obvious.
9. Don't write "just in case" parameters or features when creating something the user requested. This creates bloat.
- Code must be consistent
- Code should be consistent with the other code in the repository. If you implement a flag in a CLI script, then it should look like how other flags are implemented inside a CLI script. One exception: match local conventions, but don't copy a clear anti-pattern just because it's already there -- flag it instead.
Written 1 month ago
OCD is a disorder. The things it tells you to do is not real. Axiomatically, you know it is not real and you do not have to act on the compulsions. These axioms are based in scientific fact: many people have it and they go through their own cycle of obsession and compulsion. It is well studied that your feelings are derived from a mental disorder. It's like a rollercoaster where you know you're safe but you feel like you are not.
An empirical observation: the more you OCD, the worse you get. It is like you are on a hill with very steep gradients on both sides. The moment you start slipping, the harder it gets to recover. Combined with the two axioms: you should not act on the compulsions, because the more you do it, the worse it gets. The only way to improve is to act like the fear does not exist: do not act on it as it is not real. Even if you are anxious, do not do anything to alleviate the fear. Let the fear be present as it will subside. Breathe. There are times when the anxiety is high, especially due to lack of sleep. So get a lot of sleep. But due to the fact that the more you OCD, the worse it gets, it is better to not perform the compulsions in those times of anxiety: still resist it.
Not believing in it is exceedingly difficult. Not to mention the spikes of anxiety that come from not believing in it. But it must be done. You can give yourself negative punishments whenever you do it. For example, you can pay $1 to charity if you follow it. But, if you are paying $1 to charity, the moment you don't do it, then you're worrying about removing the punishment and therefore lapsing back into OCD. It could be a step to easing the OCD though, to get to a state that is manageable enough whereby you can just stop. Conversely, if you set these goals often, it will undermine the goals if you fail to follow it and lapse back to OCDing.
I think the best way to stop is to show yourself that you can stop under any scenario. This goal needs to be set just once. It's set as a goal on my birthday: an important day. Once it is declared on that day, then there is a special reason to believe it. Any other new rules or "i won't do it after this moment" will degrade that. Being able to stop in any scenario, regardless of how triggering, is the more surefire way that, in the future, you can stop. If you feel like you need to be clean to be in a state to make decisions whether you should or should not OCD, you don't need to: because you said it on your birthday.
It becomes a balance of not making the lapse catastrophic and not making it costless. The $1 thing makes a lapse more catastrophic, but not costless. The birthday thing decreases catastrophic-ness but also decreases the costliness. The ideal solution would be not to assign a price at all to the lapse. When you have the urge to lapse, you should just avoid lapsing: you don't need to consider the cost of "what does this cost me if I do it" -- just don't do it. You can stop under any scenario. It's unreasonable to worry about worrying (or lapsing). If the lapse does not exist (i.e., you do not act), this does not become an issue. So do not act.
Sometimes, the more you reason with OCD, the more surface it can grab on to. Don't reason with it. Just don't do it. You don't need to deliberately face the worst fears, but just face those which appear in your day-to-day life. You know what is right by science. Just stop.