I was at the center of Lazada’s peak in 2017. I worked on team 911, which oversees escalations from business offices in 7 south east asian countries, as well as the one cross-border business we had in Hong Kong. I was also part of the migration to bring the Lazada platform onto Alibaba tech in early 2018 and worked inside Alibaba’s Global Operation Center (GOC), under Ali core infrastructure. This was before the crackdown on Jack Ma. Back then, Alibaba was the center of Chinese e-commerce. and GOC oversees all aspects of business within Alibaba. It’s the C-level single point of entry into all things worth paying attention to: critical government office onboarding to Aliyun (Alibaba Cloud), the sales of Taobao and Tmall on 11-11, the growth of Alimama, or the acquisition of Hema Fresh, ele.me. We are also quite close to the integration post-acquisition of Alibaba’s strategic international assets: PayTM in India, Trendydol in Turkey, Daraz in Pakistan, and Nepal. If you look at it from Google Maps (or Alibaba’s Amap), you can almost pin them exactly to how the Belt and Road initiative was being pushed forward around that time.

Long story short, I think I am uniquely qualified to tell you how advanced China was in 2018, and they haven’t stopped getting better for the last 8 years. Their cars are now in the EU, selling with a huge margin. Their solar and battery tech is second to none. And let’s not forget to mention how most electronics, smartphones, are still coming out of Shenzhen today despite waves and waves of trade war.

Knowing all these, one of the things I tried to explore during my 46-day trip in Vietnam was what it would be like to start a business in Vietnam, knowing these advantages. Little did I know that many Vietnamese did exactly that for the last decade.

Past Attempts

While exploring different ways of taking advantage of the relatively open trade between Vietnam and China, I stumbled upon 2 product branches that are absolutely unique in terms of quality, quantity, and price. One was office equipment: ergonomic chairs, tables, mechanical keyboards, mice, you name it. Second was audio equipment: headphones, speakers, DAC, microphones, etc…

Having a two-year-old simply means that the time I can spend on an over-ear pair of headphones would be absolutely minimal. So I decided to try buying a mechanical keyboard as a way to get a feel of the products.

My journey started with several threads on ChatGPT filtering for options. A couple of years back, I tried to buy the split keyboard. My requirements are:

• Wireless. This is important front and center. My current keyboard is an Anne Pro 2 using Low-powered Bluetooth. Not having the wire helps so much with my desk setup. My posture improved as well since I can move the 60% keyboard to all different places.

• Swapable. I do prefer to experiment with different types of switches and keycaps, so hotswap is a big deal for me. And that brings me to the next requirement, which is also quite hard:

• Fully assembled. With a toddler on my hand and AI Coding agents on my neck, I don’t have the time to solder and socket the raw board. Whatever I am getting needs to be fully assembled out of the box.

In the Western world, I tried to solve these constraints several times:

• Kinesis Advantage360 Pro. I actually tried to place an order on this a few years back, and they were completely out of stock back then. I had an option to buy it through some trusted contact in US and pick it up there in person when I visit, but (a) the price was bonkers ($500 before shipping and tax) and (b) some reviews came back stating the Bluetooth connection can run into issues from time to time. So I never pulled the trigger.

• Aurora Lily58. This was when I found out that the folks at splitkb.com are actually based in the Netherlands, where I live. It was an absolute joy for me to learn that I can put battery and Bluetooth modules on the 2 halves of the Lily. I spent my hackathon prize on half of the kit, and bought the rest out of my own pocket. I got my soldering kit from Amazon.nl. But then reality hits hard: I would rather spend time with my 1-year-old daughter at the time, helping her crawl and walk, rather than in a room by myself soldering the board. I tried hitting up some splitkb community members in NL for a soldering/assembly service, but nobody responded. The boards, plates, and cases are still sitting in a box behind me today, unopened.

The Shop

After uploading my keeb brain into ChatGPT, it was very helpful in pointing me toward a keyboard shop located in Ho Chi Minh city with the QK Alice Duo available. The shop is about 30-40 minutes scooter ride from where I live, so not too bad.

But before I went to the shop, I was able to hit them up on Facebook Messenger and ask questions about stock availability. They were able to give me a price and time estimation for a fully assembled board, all without having to leave my bedroom.

So the stock kit is 9.2mil VND, which is 300 EUR / 350 USD. Assembly, mod stabilizers, switches, and keycaps will push the damage to around 11mil VND, 355EUR / 420 USD.

Let’s recap: a kinesis is a plastic-built, not hot-swappable, and comes at the risk of Bluetooth unsynchronized, and is priced at 500 USD. Alice Duo had a full metal frame (3KG) and came with its own high-polling rate wireless buck. You get to pick the keycap and switches you want, the color you need, and the cost is still almost 20% cheaper. Absolutely crazy.

I decided to drive to the shop in person. Later, my wife reminded me that it’s relatively rare nowadays to do so. Most of these shops do shipping with high reliability. Some would even book a Grab driver to ship the goods to you within minutes, so you never have to leave the house yourself. But knowing mech keebs, I want to experience things in person, and I went anyway.

Turns out it was a good decision. The shop has several choices of switches, and they insisted on knowing the switch heights beforehand to assemble to stablelizers. While I could not find a set of keycaps to my liking, I was able to settle on the “WS BigLucky Switch-Tactile” switches.

I do prefer tactile over linear, as I don’t game much nowadays. But what won me over was how solid the round cylinder is. Unlike typical cherry switches, where the stem can wobble around the housing of the switch, this cylinder design evenly distributes the down force to all the edges of the outer box; thus, no wobbly feeling. And you may have guessed it, WS is https://shop.wuquestudio.com/, a Chinese brand. The tactile of these switches is definitely a bit lacking vs the traditional MX/Gat brown though. I think I may switch these out for a set of Kailh Pro Purple in the future to get a bit more bump. I also checked out several of their keycap sets, but I feel a bit disappointed with the print quality.

With that set, they gave me the final bill, and I put half the money down to get things started.

So that’s 335 EUR / 393 USD for the A-Z product and service.

The keeb

A few days later, I got a call from the shop that the keyboard was ready to pick up, and I made my way there. And to my horror, it’s not just the split keyboard but a giant box with a ton of goodies inside.

Ditching the giant cardboard box is a long orange QK case. It’s taller than my backpack, which has my MacBook Pro inside. The case contains the 2 assembled halves of the keyboard, the wireless buck, as well as a pair of metal-frosted acrylic height-adjustable palm rests, and some misc goodies like key pullers, screw driver, stab-mods leftovers.

I prepared a cheap, 250kVND (9.5 USD / 8EUR), PBT blank grey keycap set. The nice thing about this set is that it has all the special space keys needed for a split setup. This acts as a temp space holder until my endgame is shipped.

Here is the final product on my desk back in NL.

The keyboard takes a day to get used to. Blank keycaps definitely made discovering the keys a bit more challenging, but once I got the official QK Notion documentation opened, things got going pretty quickly.

Vibes

Built quality: 10/10.

This is not my first metal case keyboard, but hand carried these through 2 flights back to the EU because the battery inside definitely put some pain on my and my wife’s shoulders. W wife!

Key layout: 7.5/10.

The curve is easy to get used to for my hand size. But the stepped caplocks are a bit annoying, especially when you consider the stem position is determined by the switch position, which is not adjustable. I dislike the extra column on the left of the L half. I often reach for them accidentally while trying to locate CTRL / Shift / Caps.

Tenting: 9/10.

The strong metal frame made the angle feel solid like a brick. The palm rests can also be configured to switch between flat and tented positions, very clever.

Connectivity: 9.5/10.

This is not running on Bluetooth. The 2 halves connect to the buck using a custom wireless, and the buck connects to the PC using USB. As a result, they are relatively more reliable to operate with the Framework Desktop sketchy Bluetooth stack on Linux. The Buck design is also clever: a volume knob with some LEDs exposed from the naked board is a cheap but cool-looking solution.

Damage: I feel incredibly good spending 400 bucks on this as opposed to 500 bucks on the Kinesis. I used the saved money on a new keycap group buy: GMK Cherry Love

This is expected to ship in Q2 this year, and I cannot wait to put it on my QK Alice Duo.

Is this endgame yet?

Close.

Not about keyboards

I should also mention that during the trip, we found that Lazada is now shipping Taobao and Tmall goods directly from China to Vietnam. Game changer! We got our in-laws a coffee grinder from China. The in-laws live in Vinh, Nghe An, not one of the major cities, but they still get it shipped to them within a week. There was a bit of damage to one of the add-ons due to shipping, but that’s irrelevant to their use cases. And according to my wife, the price was amazing for the quality. Similar to Alibaba-Lazada, Tiktok, and Shopee, e-commerce platforms all have their own cross-border strategies to compete in the South East Asia market, an absolute win for the local consumers.

All of these were very different back in 2018. The Vietnamese government back then shielded the domestic markets from Chinese goods. While working in Lazada, I vividly recalled that Tmall/Taobao were able to penetrate Thailand and Malaysia but not Vietnam due to the strict import policy at the time. I recall we struggled a lot to ask our Chinese counterparts to help us shop for the latest Xiaomi laptop during 11-11 sales back then.

All these guardrails are now gone. The trade between China and Vietnam got a lot easier, and it does not stop at just keyboards, headphones, and coffee. It’s also real estate, tech, battery, energy, rails, and EVs, some of the core foundations for the ambitious GDP target.

Did you know that Tesla is not the only battery manufacturer in town? Here in the EU, we are getting spammed with ads about buying solar and a house battery solution to weather the future energy crisis. I actually looked into a few options to start a residential/commercial energy backup solution business in Vietnam and was surprised by how many sourcing options there are compared to the West. I do think my thesis could be a strong hedge against the global rise in energy demand, but I am not based in Vietnam to execute it. Excuses, excuses.

It’s where my parents are still living. My in-laws as well. My extended family, including my grandmother, the last of her generation.

It’s where 3 of my 4 grandparents were buried. Just visiting the graves to pay my respect took 5 hours, and that’s already skipping the more distant ones.

Between my wife and me, we have cousins, aunties, and uncles: doctor, department head, architect, landlords, engineers, business owners, consultants, unemployed moms, widows, students … It was great to meet them all again, but this time, with our 2-year-old daughter. It was a joyful occasion, not without hardship from the weather and the environment, but we were all very happy.

But that’s not what I want to talk to you about today. What I want to write down is a bigger macro picture that I observed: a newly transformed Vietnam. Things are moving fast, and I don’t think most people are aware of it.

Ambitious growth

Forefront and center is the current targeted growth of the Vietnamese economy. Right now, Vietnam is targeting a 10% in GDP growth for 2026. To put that in perspective, China’s target is 5%, and India is 6.5%.

Ten percent is nothing but bonkers.

At home, I am seeing incredible growth: Roads and highways are being built at an incredible speed. The houses along “Quoc Lo 13” (Country’s Roads 13) where I lived are being relocated to expand the key commute drive way, and the price for this relocation effort is going up like no other. We are not talking just a few percentage points, but 2-3x, sometimes 5-10x the usual price for a house in that area is being paid out by the government to support these efforts. I suspect it’s the same elsewhere as well, because not only Ho Chi Minh city, but the entire country is going through a giant transformation.

In the news, you hear about new high-speed railroads being built. Some projects are supported by EU, but we do expect China and Japan to enter the picture soon (more on that later).

Over in Thu Thiem (old District 2), a new city center is under construction. Together with it are high-end luxury apartments being advertised to Chinese and Korean investors. New bridges are being built. New highways as well. Many drivers are reporting under 5 hours travel time to Da Lat, the Lake Tahoe of Vietnam. The new international airport in Long Thanh airport in Dong Nai is expected to open later this year and is about 50 km2 (19.3 miles2 for my US readers). Amsterdam’s Schiphol is 28km2 and Dallas/Fort Worth is about 70km2 for comparison.

How

Underlying this growth are tectonic geopolitical shifts in a global state, as well as a regime shift internally. While you will not be hearing my comment about Vietnam’s politics, I can give you some factual information about 2 recent events to demonstrate how things are going.

DOGE-like Movement

As the US went through a phase of DOGE where they tried to slim down the size of their government and cut spending, Vietnam also started doing the same thing around 2023-2025.

What this entailed was 2 restructuring movements of the government.

First, Vietnam reduced its formal local-government structure. Previously, the structure was roughly: commune/ward/township → district-level unit → province or centrally run city → central government. From 1 July 2025, Vietnam abolished the district level, so the formal structure became: commune/ward/special zone → province or centrally run city → central government.

Second, Vietnam merged many province-level administrative units, reducing the country from 63 provinces/cities to 34 province-level units — 28 provinces and 6 centrally run cities. As a result, many of the remaining provinces and cities now cover much larger administrative areas.

Follow these: 2 restructures led to massive waves of layoffs among government administrative workers. As districts become the new wards, the old ward workers are being let go. Replacing them were attempts to digitize the administrative works throughout many verticals: tax, social insurance, land zoning, IDs, you name it. Laws are being updated and supposedly simplified. Don’t get me wrong, not all of these were perfectly executed; you can definitely find a lot of criticism among those who were impacted. But the bottom line was that they, the new government, got things done. And this created a bottom line to harbor future growth.

Navigating the oil crisis

As the conflict in the Middle East intensified right at the beginning of my trip back to Vietnam, I couldn't help but get drawn into headlines when I first arrived: Vietnamese airlines are running out of jet fuel, flight tickets are doubling their price, and the cost can go up even further. To my surprise, the Vietnamese government got it done.

• 9-16 Mar: Vietnam started showing domestic fuel stress. Gov decided to cut the tax on gasoline to temporarily lower the price pressure.

• 20 Mar: Vietnam PM at the time announced that he would be visiting Russia from 22-25

• 22-25 Mar: Official visit where they signed several energy deals, including a nuclear power plant totalling 2400MW and an LNG supply deal as a cherry on top.

Now I would have stopped here for readers to take a moment to understand the impact of this. As US applied several tariffs on Chinese exports, various manufacturing has been moved to Vietnam and India as a secondary solution. This places Vietnam in a unique position: bordering on China, yet trade-dependent on US. And underlying all of these production is gasoline, LNG, and fertilizer (to power the human labor), all impacted by the events in Hormuz.

The event did not stop there, however, throughout my trip, these also happened:

• In the middle of this was the National Assembly election in Vietnam, with the result announced on 21 Mar. Mr. To Lam now holds both the Party General Secretary and the State President roles. US, EU, India, and China all congratulated him on a 97% result. A new PM was also elected as a result.

• 14-17 Apr: To Lam made a state visit to China, where he met with Xi Jinping. Two sides signed some cooperation agreements with potential investment from China into Vietnam’s future high-speed train system.

• 21-24 Apr: South Korean President Lee Jae Myung made a state visit to Vietnam. Samsung previously announced a 4B chip fab in Vietnam on the 10th of April. Lots of non-binding documents were signed, including energy, tech, and security, according to Reuters.

• 1-3 May: Japanese PM Sanae Takaichi visits Vietnam with a focus on energy, minerals, AI, semiconductors, and space. Additional support for crude supply for Vietnam’s refinery is being discussed as well.

Many of these visits and events are well-reported by different news outlets. Pretty banquets, dresses, ceremonies, and university talks happened, so I won’t reiterate them here. What I want to emphasize is the overall macro picture: Vietnam is gearing up to be the new China: unprecedented growth thanks to strong domestic execution, talent pool, and international support. The geopolitical events in 2023-2025 were merely accelerating this trend.

Worth noting that while all other nations started hugging Vietnam, the US is putting Vietnam on a watch list with a warning on trade:

USTR released its 2026 Special 301 Report on the effectiveness of U.S. trading partners’ protection and enforcement of IP rights, identifying Vietnam as a Priority Foreign Country and placing 25 countries on the Priority Watch List or Watch List.

This further distances the 2 sides, further pushing Vietnam toward other allied countries.

Implications

I think the geopolitical events have pushed Vietnam away from US, EU, and toward Russia, China, and India. From the Vietnamese perspective, it’s not just economic necessity but also national security: the livelihood of billions of people is at stake here, and among them are my parents, in-laws, and distant relatives. The Vietnamese government made a pragmatic and strategic choice to make all of this happen, and it’s enjoyable to watch.

In Vietnam, you can now find a lot of Russians, Chinese, Koreans, and Japanese living in the biggest cities, with dedicated services being spun up for these expat customers. I even found several hacker houses, startup accelerators, and VC funds taking root in HCM city and Da Nang. Going to any Highland Coffee store, the Viet Starbucks, and you would find a ton of nomadic hackers, remote office workers camping inside.

It’s a vibrant place to be if you are a builder. It’s a critical place to watch if you are an investor. Vietnam itself is entering the Emerging-Market Index through FTSE Russell in September 2026. It is also about to launch a regulated crypto exchange pilot in Q2 this year.

In a sense, Vietnam’s plan resembles that of the US in recent years: cutting down government layers, accelerating growth, crypto stuffs (which I don’t understand)… And the result is here to show. It’s not all perfect, and I could be looking at things through rose colored glasses, but I think the final numbers will speak for themselves.

End notes

These are a ton of information to process. Especially when you are on the ground, people would tell you about different zoning plans, different trends in local EV adoption, coupled with the push toward solar and clean energy. But the overall vibe I observed was super optimistic. The giant hotels in Da Nang are resuming construction again as tourism continues to rise in the post-COVID era.

Growth, disruption, growth. The country is young and vibrant, and I think you definitely should give it a visit when you have the chance.

Oh, and check out the drinks and the food. I personally recommend this avocado shake with Vietnamese coffee blended inside. It’s a strong pick-me-up for all the hackers out there

But that was pretty much my February: trying to cope with the short-term future outlook that I need to evolve myself. It’s exhausting, tiring, and lots of stress. I still need to put food on the table, pay my mortgage, take my kid to school, all while trying to find a way to swim up the current to find a new stable place to rest. My head was burrowed in AI, LLM, MCP, Skills, automation, etc, and it’s suffocating.

But there were a few “interesting” experiences that I encountered last week. Human experiences. They dragged me out of the flooding, depressing thoughts, and made me rethink where the new value is in the age of agentic AI. So let me walk you through some of them.

Goodbye Stuart

The week started with sad news. I got a message on Telegram from my old HR guy:

Ex-lzd from SG tech team passed away.

Attached to the message is a LinkedIn URL that notified us of the passing of Stuart Remphrey.

Stuart sat 2 steps away from my desk in the cramped office at Lazada in the now-demolished Axa Tower in 2019. He was kind and quiet. He was knowledgeable and resourceful.

I still have with me a souvenir, an unfinished lightsaber handle, that was shipped to Stuart's desk accidentally, and he gave it to me. I still have it on a shelf behind my worktable. It always reminds me of him.

And fuck cancer.

May you rest in peace, Stuart.

Strong Naranjo

Last year, my friend, my ex-colleague at Booking.com, BazelCon speaker, Manuel Naranjo, found out that his firstborn son had a rare-but-terrible genetic disease.

Lucca Naranjo is still barely a few months old, yet he has been battling with CHAMP1 for his life. His parents also went through a lot while caring for their baby.

I chat with Manuel occasionally to catch up on life. His son is now getting better, no more hospital bed with endless tests and sleepless nights. He has started physiotherapy and is growing well. Lucca turned 7 months old last Sunday.

My daughter turned 2 recently, and my heart skips a beat every time I imagine being in Manuel’s shoes. Manuel and his wife went through a lot. They are brave and strong.

March 20th is the Champ1 awareness day. I would encourage you all to give it a read and consider donating to the relevant foundations to support the scientific research.

Human Values

As I wandered through the streets of Amsterdam to find my way to the first Codex in-person meetup in town, I found a super interesting Odd Lots podcast episode.

Lloyd Blankfein, the former CEO of Goldman Sachs, recalled a story where Michael Bloomberg was calling him directly to offer support for the Bloomberg Terminal.

He asked.

Lloyd: Isn’t that a very ineffecient use of your time? Because here you are, calling me and I wasn’t a senior guy?
Michael: No, no. We learned a lot about the business…

And then Lloyd reflected.

I realized now, that was a very stupid comment.
Because here I am.
First of all, everybody on our floor knew that Mike would called and that he cared.
The guy, whose name was on the door, cared about whether we were using it or not.
And not only laterally across that dimension, everybody knew, but here I am, 35 years later, telling the story, and now you are hearing about it.

That was a very good use of three minutes of Michael Bloomberg.

It was a good story that teaches you: care matters, human touch matters. These values and qualities are increasingly rarer in the agentic age. When things are automated away, things that cannot be automated will be priced higher.

Increasingly, I see folks ask some forms of these questions:

Is this GitHub project AI slop?

Is this article AI generated?

Are there human with taste standing behind this brand? Or is it completely LLM generated?

If the answer is AI, the trust automatically goes down. People no longer care about the outputs regardless of quality. Those who care would ask for the prompts instead of reading the generated slops.

A human-driven brand matters.

Human Values matter.

Agentic Arm Race in SaaS

With the thoughts above, I realized that the future of SaaS is not as doom and gloom as most people are picturing.

Despite the cost of developing software converging to zero, it will take a long time for us to get there. Tokens are still costing dollars, so are GPU, memory, SSD, and power. It will take a decade for us to solve the token scarcity, if not more.

Most folks are comparing companies that have adopted Agentic Development versus those that have not done so. But once all the players equalized by adopting the latest agents and models, then the new competition becomes taste: taste in product direction, taste in customer dedication, taste in picking tastes. These tastes dictate how you spend the tokens, the quality of the token outputs, and the “yield” of your token pipeline.

Software Engineering, as we know it, is a dying breed. It’s the typing machine mechanics of the modern age. But replacing that career path is a much leaner, much more action-driven line of Agentic Engineering. I think this is a huge opportunity for early-career, fresh-grad folks to make a breakthrough.

Smart companies should hire fresh graduates a lot more. Especially now that it’s relatively easy to hire. Couple them with a few experienced engineers who are open to agentic workflows, and you will have a great team.

I opened this blog post with grief, pain, and exhaustion.
I hope to end it with optimism, strength, and resiliency.

I think, despite all the advancements in the Agentic toolings, the future economy is still largely driven by humans, for humans. The agents, once equalized, will be treated merely as a new class of tools, just like the cars in the industrial age, or the keyboards and mice during the internet boom.

My Software Engineering job is changing fast. But that’s what I signed up for, in trade for higher pay. I am learning fast, and so are my colleagues. And as long as the learning and self-improvement keep on going, then we should not be afraid of losing our jobs.

I will finish the new “Picking The Hard Ways” post so that I can get it off my mind. I have more exciting topics to write about, such as my personal playbook of how to replace GitHub.

If one started building a coding agent/harness last year and their product is completely made obsolete by the new generation of models this year, then didn’t they waste 1 year and fail to find product-market-fit? Or to put it differently, is the market, the ecosystem (and to an extent, the economy), moving too fast for any product to fit?

It’s early 2026, and everyone is now trying to build the new Agentic GitHub, the new Heroku of Clankers (Clankoruuu, as I like to think of it. And yes, you do need many ‘u’-s in that name). What is stopping the next generation of models from just one-shotting all these attempts and rendering them ineffective?

This begs a question: what should I build now? What is durable despite AI Advancements? In fact, what would thrive as the models get better? This is exactly the answer Sam Altman gave in the recent OpenAI Town Hall:

Will your company be happy or sad if GPT 6 is a wildly impressive update?

It is now clear that we are in the middle of an AI arms race. A new Gold Rush.

And in the new Gold Rush, one would want to sell shovels. And shovels were sold! Sam cooked this well by unlocking all the bottlenecks available: chips, data center, energy,… He is exceptionally good at “thinking in exponential”.

With that thought, I wonder if I could build something so ahead of the curve that it would give me a sufficient moat for multiple waves of AI models to come. Something that will get better and better as the progress increases.

A Future-proof Pitch

What if we build “Prescience”?

One crazy way to think about the Coding Agents today is that they synthesize the code from the past to create a map of probable futures. And by giving it inputs and a bit of random seeds, we help the model pick which future to realize.

As we advance from text models to pictures, from pictures to movies, we are increasingly capable of producing “world models”. In fact, some early versions of world models already exist today in a very primitive form among self-driving car companies. They use this engine to help teach EVs how to drive, self-correct, and improve over time.

To build these world models, we need an exceptionally large amount of data. Data to emulate real world physic, chemistry, and biology. With sufficient data, we can properly emulate and provide a map of probabilities of transformation within a small sandbox. External factors that may influence the outcome inside that sandbox can be mapped and emulated the same way as coding agents building a context graph. The ultimate goal is not to perfectly predict the future, but to provide contextual underwritings and actuarial modelling for transformations inside a tightly confined space.

There are plenty of paths to commercialization for such a product. You can earn serious cash by just operating as an algorithmic quant firm on top of existing prediction markets today. Or you can be a personal assistant, telling your users the number of red lights they may encounter in today's commute. It can be an improved actuarial modelling process that powers all the banking, insurance, and healthcare companies. It can be an autonomous defense system, which most dystopian sci-fi stories, movies, and games have been describing for decades.

In fact, “Prescience” is one of the main threats to humanity in Dune. After the rise of the “thinking machines” and their defeats in the Butlerian Jihad, it was “Prescience” which drove humanity into stagnation.

Good Reads

Logan from Google tweeted this about compute needs

which I think echoes how the top AI orgs were at making the effort to secure the needed computes for their companies for the last 2 years. There will soon be a “Rich Token, Poor Token” split among the labs, and the poor ones will find themselves competing against the Chinese competitors for the bottom portion of the market share.

Latent Spaces has been putting out stellar content recently:

1. Cooking with Dylan Patel

2. Interview with Doug O'Laughlin

I think the core takeaways for me are the constant time lag between when the next set of computes (new chips, new datacenters) goes online and the release of a new generation of models (6-8 months). They are strictly correlated.

As the adoption of agentic applications (coding being the first among many) increases, we will start to feel the squeeze on these tokens in both quality (training) and quantity (inference), which shall ultimately result in price pressure on a supply-side bottleneck market.

It’s a bit insane to see how fast all of these are moving. It’s even more insane to realize how, in some parts of the world, there is no movement: no energy built out, no new datacenter, no incentive to attract talent. Vietnam, my home country being one of them, and I suspect many of the IT outsourcing companies there are heading toward a pretty significant disruption.

ZML and Bazel

What the guys at ZML are doing is hugely impressive and underrated: they managed to bootstrap everything from scratch: the clang compiler, lld linker, the Zig language toolchain, so that they can build everything from scratch and live on the bleeding edges. They coupled this with “1-to-many split transitions” to transform a single Bazel action graph into multiple copies, each targeting a specific platform (OSes, CPU Architectures, GPU Kernels, etc). All of these build in massive parallelization using BuildBuddy Remote Cache and RBE offering.

If AWS, Nvidia, or AMD start to put out any of the interesting features, these guys will be able to build an inference solution for that platform within minutes. I still don’t fully understand how this is relevant to the current AI labs, but I suspect hardware vendors would be very much interested in adopting this framework to iterate faster.

I plan to write more about this in the future, but I need to educate myself about GPU Kernels first. Thankfully, the guys at Modal do have really good documentation about this.

This weekend has some crazy geopolitical news, as well as some fresh dramas among the AI labs. This blog post intentionally ignores all of it because I drafted most of this before any of the news happened.

Instead of boring you with the reactionary posts about the models like a typical tech influencer, I will be sharing some thoughts and observations on the direct and secondary effects on the field.

Younger Teams

Despite getting more capable models, all the AI players are hiring like crazy. The The Codex team in particular is shouting on Twitter about how they need more people to expand their team. Anthropic is hiring various different Go-to-market positions to transition into different verticals. These are great signs that our jobs are still here to stay. But the nature of the job is no longer about the design patterns or the algorithms. It’s much higher level now: a complete E2E architecture vision to wield the coding agents and realize such a vision.

But it’s not just the AI labs who are hiring; the consumer end is hiring as well. The interesting part about this portion of the job market is that enterprises realize younger, fresh grad candidates adopt AI much better and faster than their grumpy decades-old sysadmins. Newer Agentic Experience teams are being spun up with 1 experienced engineer leading groups of 0-2 years of experience with multiple coding agents running either on their laptop or on a cloud. Newer “cloud prompting” platforms are being spun up from these teams to create more secure, easier-to-use AI co-workers.

And the application is not limited to just coding!! It’s also office works like Business Intelligence, Marketing, Logistics, etc.

Deep Blue, Spark Orange

From Simon Willison’s blog

We coined a new term on the Oxide and Friends podcast last month (primary credit to Adam Leventhal) covering the sense of psychological ennui leading into existential dread that many software developers are feeling thanks to the encroachment of generative AI into their field of work.

We’re calling it Deep Blue.

On Lobsters, I advocated for an opposite term: “Spark Orange”.

It’s the joy of getting shits done.

No more the long-dreaded backlog of toils and ideas that you never have the time to build.
No more the back-and-forth design discussions that take hundreds of engineering hours.

Now, the moment you have a spark of an idea tinkled in your head, the coding agent will help you realize it immediately.
Ship your ideas! Now!

It’s never been a better time to build things.

Good Reads

There are a few interesting contents in the last few weeks:

1. Russ Cox commented on how Go project should handle AI-generated PRs.
   The “Legal Concerns” section in particular is a fascinated read.

2. Dwarkesh Podcast:

   1. Interview with Elon on the necessity of Datacenter in Space.
      My take from this is that Solar Energy is the most viable path toward sustainable (and green) energy in the next decade.

   2. Interview with Dario on the economic of LLM.
      It’s very interesting to hear how Dario is so focusing on drug discovery and bio-risk. I think they are among many level of applications and risks that AIs have opened the door to, not entirely sure why he is worried about this specific set of ideas.

3. Latent Space interviewed Jeff Dean. Much more technical than the 2 interviews above. I need to watch this again a few more times, but I don’t think there is anything too surprising. I think it’s very clear that unlike other labs, Google are much more cost-conscious because they serve these models at a much bigger scale as they are rolling out the LLMs to more verticals. Those constraints spawned lower level innovations and Google is an absolute powerhouse at that.

4. OpenAI - Harness engineering: leveraging Codex in an agent-first world.
   The blog opened with “Over the past five months, our team has been running an experiment: building and shipping an internal beta of a software product with 0 lines of manually-written code.” which is a wild statement. I personally suspect this is their Codex-tangent team cooking a GitHub replacement, but I have no insider info on this.

5. Cursor - Towards self-driving codebases.
   Tangent to this, the small paragraph about “Synchronization overhead” is what I have been thinking about at the back of my head the last few weeks. Let’s say I have 100 agents running in parallel and one of them decided to refactor //common/lib/foo → //common/lib/bar, then how do the other 99 agents know about this refactoring to adjust accordingly? When do they do a pull/rebase? What if there are conflicts? etc…

6. Using go fix to modernize Go code.
   Go team essentially created a tool to help the AI labs modernize their training data corpus. This means that the newer models can be trained with the latest Go versions syntax and best practices. This is probably the best way for a programming language to stay relevant in the age of LLM-powered coding agents.

7. Peter Steinberger on joining OpenAI and building in EU

Grok translation:

In the USA, most people are enthusiastic.
In Europe, I get insulted, people scream REGULATION and RESPONSIBILITY.
And if I really build a company here, then I get to struggle with things like investment protection laws, employee co-determination, and paralyzing labor regulations.
At OAI, most people work 6-7 days a week and get paid accordingly.
With us, that’s illegal.

Also, mindset. How I found purpose again after 3 years of searching:
USA: "oh man this is so great let's build sth cool!"
AT: "Yeah, but take care of yourself, so you don’t get another burnout, okay? So slow down a bit."

As somebody who is living in the EU and is planning to stay here for the foreseeable future, I will be reflecting on this a lot. At the same time, I got to meet some incredible folks who are relocating to Amsterdam just this week! So I hope things will continue to get better from here on out.

Slow Down

With the current AI waves, I have never felt as much pressure or dread.
Yet come with them are a lot of joy and energy to keep on building new things.

It’s Lunar New Year, Tet for us Vietnamese, the time when we gather as a family and celebrate the past and look forward to the future.

It’s also my dear daughter’s birthday this week. She is turning two, and I am incredibly proud of her, and of my wife, our family, for what we have accomplished in the last 3 years to get where we are today.

I am taking this week off to reflect, to breathe, and to get some quality family time.
And I think you should too.
Pace yourself, for it’s a marathon, not a sprint.

And why not A2H? Because humans always come first.

1:1 - Early Stage

This is where most folks are today.

They are getting their first taste of coding agents.

They have started using agents to finish their day-to-day tasks faster.

They ask the agent questions about their codebase, get the agent to write a feature or fix a bug, and then manually review the change.

Sometimes they do not like the change, so they open the editor and fix things themselves.

1:5 - Crawlers

I think this is where most engineers exposed to frontier coding agents are today. We are talking about folks working at top-notch AI labs and agent labs.

They have learned to context-switch better and started managing multiple agent threads in parallel.

Some of them use separate clones of the same monorepo; others prefer git worktrees. They start with two or three agents in parallel, slowly upgrading their skills.

Once the skill is honed and confidence in the outputs increases, they review implementations less. Instead, they rely on a more deterministic way to validate changes: setting up automated tests, CI, and/or Bazel/Buck2 to describe their intent, then letting the agents iterate against that.

From there, they can easily increase the open thread count to 4-5 as task complexity increases.

1:10 - Sprinters

I do not think most people are here just yet, at least not in February 2026, as I am writing this post. There are a handful of individuals worldwide, but not many.

Going up to 10 agents working in parallel requires a new set of tools: management tools. These are badly needed unless you are okay with burning through your tokens in a single day.

At this rate, a ChatGPT Pro subscription will not be enough; you are going to start switching to a pay-per-token model to keep your horses running.

Manual review is no longer an option. You will find yourself trying to anoint one of the 10 agents as the Reviewer, in charge of integrating code from the other nine.

How does a team of 10 engineers manage 100 agents? How do other tools like PR/CI/CD work with this code volume? Do things start to break?

More importantly, what business model can survive this code volume? Or is your tech company running at a loss, waiting for the next funding round?

I currently have more questions than answers.

1:50, 1:70, 1:100 - Rocket

Going beyond a 10x H2A ratio requires a very special autonomous factory setup.

Agents are now divided into different groups with different roles, perhaps even in a tree-like or matrix-like hierarchy. The factory is given a top-down mandate and mission objectives, which are broken down through layers of reasoning into smaller goals and eventually into implementations.

The management tools from Sprinters now become observability tools for human users. To agents, they become the new Reddit, the new Slack, and the new Gmail to centralize A2A communication and coordination.

What fascinates me more, though, is which businesses have enough margin to sustain this. If Google got where it is today with 80,000 engineers, then a 1:100 H2A ratio would mean an 800-person org could get there. Multinationals, trillions of dollars, data centers, power generators, and data cables spanning multiple oceans. Stripe had about 3,500 engineers as of 2025; 1:100 H2A takes that down to 35. Insane.

1:∞ - Post Human

Unlike many of my colleagues, I do not think we are getting there anytime soon.

Humans are still needed for liability and accountability. Humans are still needed for political movements (AI cannot vote as of 2026). Humans are still at the core of all existing economic models, and it would take decades, if not centuries, to change that.

There is a possibility for a B2B-like model where it’s entirely A2A. But my brain is not willing to go there today. With all the prompt injection attacks still being very relevant today, I think this would require a big leap compared to the existing model architectures and capabilities.

So let’s write a quick recap of the vibes I got from FOSDEM 26, the Hallway Track (including lunches and dinners). For privacy reasons, I will not be naming names nor pointing to any specific companies or individuals (unless it’s already public information or coming from a talk).

Impact of Coding Agents

There is a clear division on AI at FOSDEM.

Many big EU organizations are uncomfortable with adopting Coding Agents (or AI in general). There are several reasons for this, ranging from privacy to environmental concerns. But the most front and center reason was security and sovereignty: they are not comfortable sending their Intellectual Property over the internet to American-owned companies to do the inference. The inference provider (and model provider to some extent) needs to be an EU-entity and won’t be pressured by any state actors in their decision-making.

But the smaller EU startups/hackers are not constrained by these requirements. To them, AI was a blessing. Many folks reported that they have stopped writing code directly and instead, switched to prompting 3-4 agents just in the last few weeks. They experienced faster Proof of Concepts, faster time-to-market, and higher productivity overall. What would have taken them 3-4 months, which they never had the time for and shelved the ideas, is now taking them a few days, if not just a few hours.

This division is a strange inflection point. My take on this is: the demand for AI is there, very real, and has monetary impacts. It calls for EU infrastructure to support AI demand and better funding to retain talent. But while the problem statement is clear, the solution remains murky at best. Some are advocating for deregulation to speed up the private sector, while others prefer more control over software service quality and a more centralized funding model to drive growth.

Version Control

I had to line up 15 minutes to be able to squeeze into Janson's main track, the biggest room at FOSDEM, to listen to Patrick Steinhardt’s talk about recent advancements in Git. The entire lecture hall was fully packed, with some folks standing on the side and at the back. There has never been more interest in version control systems.

In the VCS Bird of a Feather session, attended by engineers from big tech organizations, the problems of Git (and its ecosystem) started to reveal:

Gaming companies need a good solution to track non-source code data (i.e. graphic assets). Same with companies with big data sets that needed versioning. Patrick’s talk mentioned that Git plans to replace LFS with a Content-defined Chunking scheme and multi-tier promisor-based storage backend servers. However, there is no clear timeline for that goal, and it does not seem like all the Git forges (cough hub hub cough) are interested in backing such a project at this moment.

The impacts of Coding Agents were also discussed

• More monorepos: Coding agents work better with a monorepo because file system access is popular in their training data set. Organizations with monorepos need a better solution to narrow down the access control to specific components. I.e. if you have a team of contractors working on /monorepo/project-a, they should not be able to view project-b or project-c. Current git-submodules solutions leave a lot of room for improvement.

• Changes in Forge Designs: bug report, code review, CI, and deployment flows are all under heavy pressure as code is getting cheaper. I wrote about this not long ago.

• First-class merge conflict support: Pierre-Étienne Meunier, author of Pijul VCS, one of the BoF hosts, is definitely a pioneer in this area. But the current rise in Jujutsu also proves that this can work with git in a backward-compatible manner. As we have more code, we will have more conflicts. And we want to preserve the resolution for each conflict so that they can be reused during rebase/merge and save us all from having to repeatedly prompt the agents for a fix.

Other topics, such as better UX, better education for these UX, and “how git is used in Puppet’s r10k” were also discussed in the BoF, but I was not part of those conversations to provide a recap.

Test is King

At FOSDEM, there was a story involving a CTO of a public tech company bragging about how they “vibe coded” a Redis replacement. They told the agent to iterate againt the official test suite to ensure compatibility. The result performs 60x better.

I have repeatedly mentioned in this blog how important it is to ground the Coding Agents with builds and tests. By giving it a way to imperatively validate the result, you are giving it clear acceptance criteria against which it can iterate with Chain of Thoughts.

As I shared with advanced Coding Agents users at FOSDEM about this, I realized that I was partially wrong previously about the post-agentic code review workflows.

Human review for automated tests might still be very desirable in the upcoming years.

Test code is now much more important than the implementation. Implementation is cheap because it can be generated by clankers. Test code is also getting cheaper, but it should still be more expensive than implementation. This is because it is subject to careful human reviews to help steer the implementations. Tests are the human expectation encoded to ground the agents.

These conversations with folks at FOSDEM made me recall a few things.

When Gemini-CLI first came out. I took it for a spin with a medium-sized problem. After a few minutes, it got stuck and started to have self-deprecating thoughts, just to conclude with “I should revert everything” and proceeded to delete all the progress it had made.

• What if the rogue agents started to delete tests to bypass CI checks? Claude Code did that to me in the past.

• What if it flipped the tests from expect.True to expect.False? or just add test.Skip liberally to get the code merged?

Test reviews are still very much needed until the model quality gets really, really good. And even then, there should still be a “critical” e2e behavioral tests that require human review.

SQLite is famous for being “open source, closed test” since the source code is available, but the test code is proprietary and private. This could be a new business model, replacing the existing “open-core” model in the age of Agentic Coding. Without a strong test suite, your competitor will not be able to copy your code and use a code farm of 1000 agents to build a competitive product. Well, at least not as fast and comprehensive as you can using your closed test suite.

Imagine crafting a test for running SQLite on critical infrastructure, such as an airplane or a satellite in space.

“Open Source Closed Test” still offers what people love about the OSS ecosystem: being able to view the code, edit the code, self-build, and self-host the product, while providing a strong deterrent for agentic-enabled commercial competitors from splitting your revenue and competing for margin.

Speed over IPs

This entire situation reminds me of the Chinese tech scene circa 2017-2018, before the Jack Ma crackdown. There were no Intellectual Properties rights. Internet companies such as Alibaba (my previous employer), Baidu, Tencent, etc, constantly copy each other’s features.

Alipay has mini-apps? WeChat Pay also has mini-apps.

Taobao ship livestream sales? Douyin copied and did it even better.

It was not possible to sit on technology and juice out the money for years. Chinese companies compete by shipping fast to get the First-mover advantage. Slower ones shred away the margin by offering a higher quality service at a better price. Ultimately, the Chinese consumer won.

We are seeing similar patterns among the AI labs today: little concern about IP protections. Something Claude Code shipped? Codex, Gemini-cli, Open Code, … all getting it just a few days later. The models also seem to be converging to the same set of capabilities and have started to compete for quality and price.

A New Paradigm

Speaking of speed, the most impressive talk at FOSDEM for me was “Zero-sysroot hermetic LLVM cross-compilation using Bazel” by David Zbarsky and Corentin Kerisit. In there, they showcased a convoluted 4-stages Bazel build graph which bootstrapped the LLVM toolchain for all the popular platforms: they built the toolchain once, then used the result to build different runtimes, then built it again with said runtime.

But they did not stop there, the talk kept on getting crazier

and crazier.

But what does this has to do anything with speed?

Bootstrapping LLVM used to take hours. David and Corentin are doing it in seconds thanks to the help of Bazel and Remote Build Execution that offload the computation to a cloud of machine with hundreds of core.

Seriously, watch the demos in their VODs!!

The project is incredibly polished. Usually, it would take several months, if not years, to get a quality project like this within the Bazel ecosystem. If you didn’t know, Bazel is hard, like hard-hard even for a senior-staff level engineer. These 2 guys did it within weeks. Over lunch, both confessed to me that they are making heavy use of coding agents to help them with various tasks. Which makes a lot of sense because, afterall, both of them are working for companies within the AI industry.

I expect this project to be the first of many. Being able to build LLVM fast is a huge game-changer for many industries to move faster. Did you know that VLC was able to ship its Windows ARM64 build earlier than everyone else, thanks to LLVM-MinGW? Did you know that AMD and Intel, and Google are spending a good chunk of their time improving MLIR, a project under LLVM, to improve their inference software stack? ZML and Modular are among many AI startups that depend on LLVM critically. Oh, and let’s not forget Google’s Tensorflow, TPU, and XLA are all being built with Bazel (or Blaze, it’s internal name inside Google).

Bazel is getting easier to use thanks to coding agents. And the coding agents are getting faster thanks to Bazel.

This has been the most fun in-person event I have attended in years. I came out of FOSDEM 26 coughing like a chicken after talking for 3 days straight. I am thankful for the tiny mint box PostgreSQL booth was giving out for free. It kept my cough manageable until the very last day. Big shoutout to the French startup/hacker community that I gotta meet on Saturday. Many characters, amazing talents.

11/10 would do it again.

Forking Starpls

Starpls project is the language server for the Bazel’s starlark implementation.
The project is written in Rust and compiled down to a single binary which my NeoVim lsp client connects to.

The project covers 85% of the starlark available inside Bazel. But as Bazel ecosystem moves faster, the single volunteer maintainer, understandably, failed to catch up with the latest changes. Moreover, there can be nichehacks made inside the Bazel.git code base that can be really hard to support well as there is no compatibility guarantee across multiple versions of Bazel. These last-miles features are very time consuming to trace down and fix, as one would need to be familiar with both the massive java + C++ code base of Bazel, and the Rust code base of starpls.

But with coding agents, I was able to make dozen of fixes to my own fork of starpls.
These were made only for me as I have to work on several Bazel workspaces, each with their own unique set of issues. Some fixes targets Bazel 8, some targeted Bazel 9, or the bzlmod setup which has been around since Bazel 6.

I tried to upstream some of these patches. Some even managed to land upstream.
But I am perfectly comfortable running and building from my own fork. If there is an upstream improvements/bug fixes, I can simply rebase and resolve the conflict using the agents.

I plan to do the same with some other devtools that I use often: from the protobuf language server to be more bazel-aware, to the new Metal LSP v2.0 which rumored to be really fast for a big JVM monorepo.

Forking Bazel

I don’t have one fork of Bazel. I have 2 forks.

• https://github.com/sluongng/bazel - This is the associated fork which I use to raise pull requests to Bazel.git

• https://github.com/sluongng/bazel-rbe - This is the dissassociated fork.

Why the second fork?

In the second fork, I switched the RBE setup inside Bazel.git to use BuildBuddy toolchains and platform definitions. This includes the following goodies:

• Running 99% of build and test actions on our RBE infrastructure.

• Enable Firecracker MicroVM for integration tests that requires lower-level syscalls (i.e. mount) which are typically not available on container-based solutions

• Add a special Github Action workflow to sync changes from upstream over to my fork while rebasing the stack of patches to keep things fresh.

This git sync workflow design is pretty neat. I kept my stack of commits in a separate branch, which constantly get rebased on top of the latest changes. But to kick off CI, I would create a non-forwarding merge commit so that I can still use the first parent to identify the upstream commit being tested.

Usually it would take me a few hours to iterate against GitHub Action to get my idea properly implemented. Clankers shortened that down to a few minutes.

As a result, I can make changes to Bazel and verify the change by running the entire test suite within a few seconds. This is because most of the build was cached remotely using CI (BuildBuddy Workflows) and I am just re-using the result.

This also mean that I can run Linux tests from my MacOS laptop, which was not possible before, especially the tricky integration shell test targets that often surface the real errors.

And yes, 80% of this setup was created with the help of a coding agent in the span of a weekend.

This provides a great foundation for me to toy around with a couple of different ideas in Bazel:

• Skip stdout/err downloads in Build without the Bytes

• Implement Starlark bytecode compiler in Java (both Go and Rust implementation have their own bytecode representation)

• Shim part of Bazel to Rust?

• Bazel Remote Analysis Cache backed by Git (instead of Google’s piper)

Well… I guess I don’t toy with these directly. I am prompting the agents to do a POC for each of these topics. But the POCs are not just vibe, they are properly verified by all the tests available in the repo automatically by the agents. And because the tests are remotely executed, they run faster, the agent iterate faster, and the POCs came out faster with higher confidences.

I will be honest. I am not yet satisfy with the results just yet.
Even with Codex 5.2 xhigh, I constantly still see the top agents churning through their context tens of times before getting to a decent place. There was a lot of

next
next
follow the plan
next

messages queued up while I was as sleep and the agents keep on churning through their token. But I did learn a lot of new things going through this exercise: prerequisite problems inside Bazel to unblock these changes, agent steering skills, planning skills etc… And I think the agents themselves are improving as well. I have high hope for the next iteration.

Building Git with Bazel

In tune with doing things the hard way, you can now migrate projects from their traditional build tools to Bazel much easier than before. What used to took several months to accomplish with a few passionate engineers can now be done within hours.

Well, perhaps s/hours/days/ if you want to migrate the long tail of tests as well

As an example, I decided to build git with Bazel. Yes, the git.git.
The entire process took me a weekend and is now merged to the Bazel Central Registry so that everyone else can use it out of the box.

It currently includes support for building Git v2.52.0 targeting MacOS and Linux. I also instrumented all the unit tests in C and integration tests in bash shell to help aid future maintenance efforts.

The hardest part of doing this with the coding agents was finding out bugs existed in upstream build setup:

• Some features are properly supported in the old Makefile setup, but not yet in the newer Meson one. My initial prompt guided the coding agent to study the Meson build config hit an eventual dead end until I instructed it to investigate the Makefile setup as well.

• One niched UTF-8 Japanese encoding test was constantly failing on MacOS, which puzzled me a lot. Turns out a typical build tool would link against Homebrew’s installation of lib-iconv while the Bazel build, due to it’s hermeticity improvements, would link against the MacOS system lib-iconv. And it just happens that the system version has been broken in recent MacOS releases. This test will be fixed in Git v2.53.0 with a workaround. Though I have been thinking about converting lib-iconv to Bazel as an alternative option.

All of these works were done on top of the incremental improvements in the Bazel Central Registry, the go-to package registry of the Bazel ecosystem. Instead of having to instrument dependencies such as curl, zlib, openssl, etc… to build with Bazel, we can simply re-use the community contributed modules to speed things up. 🤗

Switched to Linux

I have been an on/off Linux user in the past 10 years. In fact, I pretty much lived and worked the SysAdmin life for at least four of those ten years. But I have never found myself “productive” with Linux.

The coding and troubleshooting are fine. It’s the emails, Slack, Zoom calls, Calendar, and office suite that always kept me away from adopting Linux. Every time I tried it, I got one of these issues:

• Broken font rendering, pixelated. It’s hard to read the news or any article on a freshly installed machine.

• Webcam / Microphone reliability. Every job I have had requires me to work with other people. And part of that is jumping into meetings with co-workers, meeting customers 12-hours timezone away. Having a malfunctioning webcam at 6 AM sucks. You were barely awake and tried to put yourself together for a meeting, and next thing you know, you are deep into the driver updates to see which broke your stuff.

• Bluetooth. Most of my devices are Bluetooth: mouse, headphones, keyboard. I prefer them over the wired options because I don’t need the best latency and am willing to trade it off for a bit of ergonomics in sitting positions and postures, as well as more table space. But Linux definitely made using Bluetooth devices a huge challenge, with too many low-level options, and none of them are sane.

• Software curation. And I would be damn if I know which lock screen option, which window manager, which packages to use with which distro. It’s a big ecosystem, and the discovery process takes time, which I often don’t have.

All of these pain now went away with a coding agent helping me troubleshooting issues. Here are some of the most notable stuffs I did with Claude Code / Codex to fix my stuffs:

1. Installed CachyOS and configure Hyprland. Wild! Without LLMs, I would have stayed with Ubuntu. Now I get a really good windows manager and all the flickering issues got fixed steps by steps. The best part is that I am not afraid of trying newer, better solutions because switching is easy.

2. Bluetooth mostly work. My trackball still having problem reconnecting after a long idle/sleep. But the agents helped me figure out a short 1 line bash to power cycle my bluetooth controller and fixed things. It also helped configured my audio manager to automatically switch to my bluetooth headphone whenever its connected. Imagine these not being the default in 2026 😖

3. Troubleshoot my lockscreen. My lock screen would occasionally just die after I turned off my monitor and left the PC at idle state. I do not get any signal on the monitor after I turned it back on despite the PC stayed active. I can ssh into it and everything. Turn out I needed to switch to tty3 (terminal-only) and did a bunch of shenanigans to revive my tty1 graphic desktop. I would have never figured this out previously, chalked it up to “linux” and reboot. But now I get a fix, a crash dump and I even have the option to fix these program myself and compile them from source.

Share

In the next part, I will write about how I have been running forked software more often as forks are now easier to maintain than ever.

If you missed it, he recently posted a short video commenting on whether GitHub is still alive in a world where coding agents are widely adopted. Here is the transcript

Well, since I have spent countless hours in the last 2-3 years sketching a plan to replace GitHub and GitLab, I obviously have a take on the matter. So let’s dive in.

Monorepo and Mergeability Checks

With coding agents, there is a need to build the context to improve the result. Turns out, it’s really easy to get an accurate context when all of your code is in one single repo. Just a single working copy, no version drift between workspaces, no “superior manifest” of multiple repos patched together to make a virtual workspace. So naturally, monorepo adoption increased.

But if you spend time talking to the AI labs, I think one thing you should ask is if they felt the pain of when using a high velocity monorepo on GitHub or GitLab: the mergeability checks (merge-check for short).

Mergeability check is a check these code forge services often run to check if your Pull Request (Merge Request on Gitlab) has any conflicts with the target branch. It’s triggered often, I’m pretty sure Gitlab used to trigger it whenever an MR was opened in the WebUI recently, or when a new change was merged into the default branch. The check happens by GitHub or GitLab attempting to create a merge commit, annotated with a hidden merge ref, in the repo storage.

But in a post-agentic world where you have thousands of coding agents landing changes per hour, the default branch becomes an information highway that’s constantly invalidating all the merge-check results. Running merge-check becomes computationally expensive, even though the most recent merge-ort algorithm has already improved this by multiple factors.

Worse, code forges often block the merge button when the merge-check result is stale. As a result, fast-moving monorepos have to completely abandon the PR workflow and replace it with a merge-bot account that has permission to push directly to the main branch. The bot will often get equipped with its own merge queue and speculative CI engine to speed up the process.

So a solution to this problem does exist. But imagine paying tens of thousands of dollars to a code forge service monthly just to build half of the most important feature yourself… It does leave a sour taste in the mouth.

Code Review

As the reliability of the coding agents increases, people will trust the result more and more. At one point, it will no longer be possible or efficient for a team of 10 human engineers to review all the changes from 1000 code farm agents running 24/7.

I think code review, as we know it today, will disappear. We should be teaching agents to work in pairs instead: one does the coding, then yields the result to a reviewer agent to judge whether the change is ready to queue for merge. Results are grounded by tests, a lot of tests. unit, integration, e2e, you name it. But human review in the hot loop is no longer economically viable.

So one would take a step back and think: what did we use code review for pre-agentic coders? What problems did it solve?

I can think of the main 3:

1. Increase code quality.

2. Increase code ownership, decreasing the “bus factor”.

3. Compliance checks.

In a post-agentic world, 1-2 are gone. As the models and the harness wrappers(coding agent cli / orchestrators) increase in reliability and quality, code quality goes up. You would not need to worry too much about the bus factor then, because the agent can quickly analyze the problem and fix it. It would make more sense if we just ground all of the coding outputs with actual automated tests that reflect the expected product flow and let the agents do their thing, relentlessly and quickly.

However, compliance checks won’t go away. The compliance and regulatory framework will still be there, slow to evolve. In these cases, a human reviewer is still a must.

But there is a trick: move your review step to a pre-release stage instead of gating it at pre-merge. Give your agents their own default branch (i.e., “bot-main” instead of “main”) if needed. Before checking our deployment tag/branch, or before merging all of their changes to the real ‘main’ branch to trigger a deployment, cook up a UI to help the human reviewer go through all the changes quickly. The review workload will be big in this case, so give the human check boxes and group those check boxes in smaller categories for easier review. You can also make it an “LLM-assisted” review (i.e., have the agent explain the change to the human reviewer), but the human still needs to be responsible for clearing all the checks and hitting the deploy button.

If your business is not subjected to any regulatory compliance framework like this, well, good for you. But I know there is a lot of money on the table for this feature, and none of the code forges move fast enough to realize this.

Testing and CI

The biggest change in the post-agentic world will be testing. Agentic changes will need to be grounded and verified by tests. Having tests vastly improves the agent outputs, just like having real code references improves the agent's chain of thought.

But ALL the traditional CI systems are slow, bloated, and are a waste of compute. Historically, when an organization reaches a certain scale, it naturally hits some of these problems and has to converge toward one solution: hermetic build tools.

Google did it first with Blaze. Meta(Facebook back then) reached there soon after and started to create Buck. Twitter (now X) also reached that stage and started Pants Build.

These tools eventually evolved into Bazel, Buck2 today, powering the majority of the big tech names: Apple, Stripe, Nvidia, Tesla, SpaceX, Robinhood, … From software to hardware, from cloud computing to social networks, from financial institutions to self-driving and robotic. The engineers all agreed on the same thing:

1. With reproducible builds, you can cache + reuse results and save on compute.

2. To cache things accurately, you need to build the cache key from a Merkle tree of all factors that influence your task: inputs, env vars, tools, args, etc…

3. With reproducible builds, it should not matter if you run the build on your laptop, your workstation, or a cloud workstation.

4. If you divide your build into many smaller reproducible tasks, you can distribute these tasks to a build farm and use the aggregated result.

This is exactly what tools like Bazel and Buck2 do out of the box for you, with additional telemetry and profiling goodness on top.

But Son, what does this have to do with Coding Agents?

Well, the new thing here is that the Big Code problem is no longer exclusive to Big Techs, like it was in 2016, nor is it exclusive to multi-billion-dollar companies, like it was in 2020. The Big Code problem, powered by coding agents, is now accessible to everyone.

If you have yet to notice, many of the big AI labs started to hire a lot of experienced Dev Infra folks recently. Many of whom have years of experience in migrating monorepos onto Bazel, deploying Cloud IDEs, and setting up distributed build farms for Big Tech companies. The most notable hint would be that Codex started to adopt Bazel as a build tool.

And if you check out the commentary on these Bazel PRs, you can easily note the impact Bazel has on the future Code Farms’ performance.

Because of the remote caching benefits we get from BuildBuddy, these new CI jobs can be extremely fast! For example, consider these two jobs that ran all the tests on Linux x86_64:

• Bazel 1m37s …

• Cargo 9m20s …

From Codex’s PR #8875

… as OpenAI is generally using Bazel internally for many projects

From Codex’s PR #8504

Meanwhile, most code forges are stuck in the old world, with hundreds of CI jobs re-running unconditionally for each change landed on master. No granular build graph invalidation, no confidence in the test quality, and computationally expensive to scale up for monorepos with more than 100 active users.

Others

I have other quick thoughts on the death of existing code forges as well:

• Coding agents do not need file system snapshots. They need a lot of commits and automatic commit push to the cloud. If you have not yet watched Durham Goode videos (some on YouTube, some on Facebook videos) about how Meta designed and scaled Mecurial with push-rebase extension and Commit Cloud service, go watch them. It’s a great product roadmap to scale up forges in general.

• High velocity merge queue will need a shared conflict-resolve cache. In Git, this would be git-rerere cache, but distributed. In Jujutsu, I think the resolve is stored inside a commit’s header? But the ability to freely reposition commits within a queue, batching stacks of commits, can result in huge CI compute savings and speed up the agentic loops.

• I have yet to explicitly state this, but Code Farm, just like Build Farm, will be a thing. Instead of headful cloud workspaces exposed to the IDE, we will now have headless cloud workspaces exposed to the agents. Similar constraints, but bigger scale and easier to manage (because unlike a human engineer, agents will not mistaken the cloud workspace is a local shell and start to install Dota 2 on it, causing disk space issues). Although prompt injection attacks are definitely a harder category to defend against.

• As the CI workload increases, code forges and CI services will have to prepare ways to distribute the code changes without causing significant pressure on the git storage layer. We can see GitLab is struggling with this as it tries to revamp my 6-year-old feature request for sparse-checkout support, as well as introducing a new layer of pull-through caching proxy. Canva built this a while ago by forking google/goblet to add Gitaly’s pack-object cache on top. I suspect we will continue to see more of these in a post-agentic world: from a multi-tier git cache setup (local disk - local network - global) to a p2p sharing distribution system similar to Sapling’s Commit Cloud.

• Don’t even get me started on Git LFS.

Housekeeping Notes

I don’t have much time to draw up pretty diagrams, so I pulled a few of them from my previous blog series. As HashNode began to block all bots and automation using CloudFlare, the RSS feed there is no longer functional. I am planning to migrate that blog series over to Substack soon and bring everything under my own domain for easier migration in the future.

So if you are interested in these topics, subscribe and stick around.

Ever wished your Large Language Model (LLM) could truly get your Bazel-managed codebase? I've been working on a little tool called bzlctx that might just be the missing link. And yes, I'll be upfront: most of this post was drafted by an LLM, but I've carefully reviewed and tweaked it to make sure it's helpful and accurate!

The Problem: LLMs Need Context

When you ask an LLM to help with a specific code file (say, to generate documentation, suggest refactorings, or even write tests), it often struggles because it only sees that one file in isolation. It's like trying to understand a single puzzle piece without seeing the rest of the picture. Bazel, with its excellent dependency tracking, knows the bigger picture, but how do we get that information to the LLM?

Enter bzlctx

bzlctx (short for "Bazel Context") is a simple command-line tool that bridges this gap. Given a source file, it uses Bazel's query capabilities to find related source files – specifically, its dependencies – and then prints their contents. This provides a much richer context for your LLM.

How to Use It (with Examples!)

First, install it using Cargo:

cargo install bzlctx

# OR, directly from GitHub:
cargo install --git https://github.com/sluongng/bzlctx

Now, let's say you are working inside a Bazel workspace:

bzlctx cmd/cli/main.go |\
  llm ...

This pipes the contents of `cmd/cli/main.go` and its dependencies (up to a depth of 2, for now) to your LLM. The output looks like this:

==> cmd/cli/main.go <==
// ... contents of cmd/cli/main.go ...
==> cmd/cli/utils.go <==
// ... contents of cmd/cli/utils.go ...
==> pkg/config/config.go <==
// ...contents of pkg/config/config.go

The `==> filename <==` format makes it easy for the LLM to distinguish between different files.

Practical Example: LLM-Powered Rewriting

I've found this incredibly useful with tools like Simon Willison's LLM CLI. Here's a real-world example from the `bazelbuild/bazelisk` repository:

bzlctx core/repositories.go |\
  llm -m gemini-t 'rewrite the Repo interfaces in rust'

This command grabs the context around core/repositories.go, and then asks Google’s Gemini-thinking model to rewrite the Go interfaces in Rust. Because the LLM has the context of related files, it can do a much better job for a given task!

Limiting the Context Size

Sometimes, the dependency graph can be huge. `bzlctx` has a `--limit` (or `-l`) flag to control the maximum number of lines printed:

bzlctx --limit 1000 codesearch/cmd/cli/cli.go

This would show you the first few files, up to a total of 1000 lines.

It also sorts files based on their path distance to the target file, so the more relevant ones would be shown first.

Give it a Try!

If you're using Bazel and LLMs, I think bzlctx can significantly improve your workflow. I'd love to hear your feedback and suggestions! You can find the code and contribute on GitHub. Let me know how you're using it!

Subscribe now

It’s 2025, which means I did not write much in 2024.
Part of it was because we had our first baby girl in Feb 2024, but part was also because I never felt " satisfied” with my writing. There is always a certain level of incompleteness that emits from the pile of drafts that I have. Sometimes, I would have spent days and weeks on drafts and diagrams to illustrate my posts, just so that I ended up not publishing anything.

So to fix that in 2025, I figure that I should just “move faster” and stop caring about quality. If folks enjoy a better writing style, then they are free to pipe my posts through w/e LLM of choice and rewrite it the way they want. It’s the thought that matters.

And with that, here is the first short post in 2025. This time, I want to let you know more about new things that I have been trying out in my daily workflow. Some hits, some misses but never stop trying.

1. Fountain pen

This one is a “TikTok made me do it”. I got the idea from watching a short video there.

It’s surprising to me as well as I have really bad childhood traumas with fountain pens. The Vietnamese education system which I grew up in forced all kids to learn how to write with fountain pens since 1st grade. At that age, we had to carry our pens around and ink bottles in our backpacks to school. The very same backpacks that we used to chase and hit each other with as typical 7-8-year-old kids would. Our white uniforms are always decorated with ink drops throughout the school years as some kids would weaponize their pens and swing them around to scare away others.

Yet, I do like buying this “Lamy Safari” pen for just 20 EUR on Amazon. It’s cheap, light, and does not require a separate ink bottle to get you started. Instead, most fountain pens now come with disposable ink cartridges, which is a more ergonomic option. I will probably invest in a convertible kit + ink bottle in the long term, but this does the job. I picked the Extra Fine pen nib as I do enjoy the sharper ink lines. A smaller nib also means less friction between the pen and the paper which lets you write faster.

But how often do you write on paper in this day and age?

Clearly not enough!

My handwriting has gone to shit over the years of using keyboards. These days I would rather brainstorm using LLM instead of draft papers. However, the slowness of writing things down by hand gives you more time to contemplate things you want to focus on. Instead of thinking of a word once when I typed it down on my keyboard, I would have to think of that same word 5-7 times when I write it down on physical paper. An enjoyable pen makes that experience more tolerable for me. We will see how long it lasts.

2. Using LLMs more

I was skeptical of LLMs a year ago. “Too much bullshit” as some friends of mine still say today. However, that does not stop me from keeping on trying it out throughout 2024. Every 3-4 weeks, I gave an “LLM-wrapper” service a try: OpenAI, Replit, Gemini, Bing Search, Anthropic, etc… The problem I usually give it is

Create a CLI in Rust/Go that does foo bar using …

And it can often do a pretty decent job. However, I would have to hand-tune a lot of things that made it never worth it. At $DAYJOB, my employer was generous enough to give me a ChatGPT plus subscription to play with but the model quality was still not at the point at which I could use it to code reliably.

However, I discovered new use cases with LLM that I had not encountered before: replacing information discovery (i.e. Google Search). At first, I started to look up different baby symptoms with it. I can describe very rough observations I have about the state of the baby and get the first hints from the LLM so that we can research further. It helped us interact with our doctors more effectively as the “House doctors” in the Netherlands can be quite… shit.

After that, I started to use LLM to help digest longer information easier. For example, we throw in a long contract from the daycare that we are registering with to ask various questions. Worth noting here that the contract was in Dutch and we were asking questions in English and Vietnamese. Not all questions were answered correctly so we would still do our diligence, but it still has saved us a bunch of time across many different contracts and legal articles. Especially with ChatGPT Search, I was able to navigate through some recent and upcoming changes to tax laws in The Netherlands much quicker and without having to hire a consultant.

Finally, I discovered the LLM CLI. It seems like CLI is my favorite form factor after all. I can easily do something like `cat file.go | llm “fix this“` or `kubectl describe pods my-pod-abcd | llm` and get unstuck very quickly.
At work, I found myself doing this

llm -m gemini-2.0-flash-exp 'im using "git commit --verbose", write a git hook using "llm -m gemini-2.0-flash-exp <prompt>" to help me generate the commit message from the diff. Use the existing verbose commit message as part of the prompt. craft the prompt so that the output is exactly the commit message following the conventional format'

which got me a pretty decent prepare-commit-msg hook for our monorepo. After some small minor tweaks and a custom prompt inside the tweak, I now get a pretty decent commit message template to edit each time I create a patch.

PROMPT="You are a commit message generator. Please create a concise and well-formatted commit message, following conventional commits format (e.g., feat: Added a new feature, fix: Resolved a bug, etc.). The message should be no longer than 50 characters for the first line. Follow up lines should be wrapped at 72 characters and provide commentary to help reviewer/reader better understand the change.
Here's the existing verbose commit message:

Verbose commit message:
\`\`\`
$VERBOSE_MESSAGE
\`\`\`

Commit message:"

I don’t expect it ever to be perfect the way I want it to be. But this has already been a really good improvement given how little time I put into it. I am currently experimenting with applying the same tool inside Neovim, my daily code editor. That would save me from having to run `head -456 file.rs | tail -23 | llm` over and over again.

I have recently switched my family Google One account to a subscription with Gemini enabled. I expect the direct integration with GDrive, GDocs, and Gmail as well as GPhotos to be well worth the money.

3. More Apple products

In early 2024, with a new baby, I figured our family would have less time to spend on deep-diving into things on the Android ecosystem. I used to be that guy who rooted my phones to install low-level adblocker and mess around with different dev apis. Ain’t nobody has time for that when all you care about is whether your baby has drank enough water today. So I made a switch for my entire family to jump over to Apple.

The wife is now on an iPhone Pro 15 while I am on an iPhone Pro Max 16. And yes, the extra camera button is worth it when you want to capture those fleeting moments of the baby and share them with the grandparents who live 5 timezones away. Both me and the wife are on MacBook M-series CPU and we have a shared iPad Pro acting as an overpriced baby monitor.

Was there any problem switching to the iOS ecosystem? Yes, quite a few actually:

• Screen flickering in some views.

• iCloud + services nagging in setting.

• The migration from Android to iOS can get stuck and waste multiple hours.

• Switching from Chrome → Safari is clunky.

But overall, we appreciate the reliability and ease of use during this period of our life. It enables us to focus on what matters right now: our family and our work. The amount of ads we get was also reduced dramatically on iOS which is a huge plus. I’m sure we will be back to Android one day given recent developments, but I think this has been a good choice for us for the next 1-2 hardware cycles.

Subscribe now