My lead engineer walked into my office with production completely down. "What happened?!" I asked. "Kevin ran LLM-generated code directly in production and wiped our primary database," he said, holding back tears. "Fire him immediately and revoke his access!" my CTO screamed. I couldn't believe what I was hearing. If we fire this man, he will lose his AI-first momentum and his career trajectory will be completely ruined. "No need to fire Kevin. He is just still adjusting to prompt-driven development. Generative AI is very disruptive," I said. "What the fuck? He deleted 10 terabytes of customer data!" "Yes, but perhaps our legacy codebase triggered the LLM with ambiguous prompt context?" My CTO looked at me with disgust and handed in his resignation. Yes, there is no excuse for a total database wipeout. But ruining a perfectly good Claude subscription over algorithmic hallucination is just not fair.

Today seems to be the day Cosmos went from AppChains to BankChains.

Eating is realizing every six months how hungry you were six months ago.

Certain types of execution and complexity might always require a trustless offchain execution component.

Please stop with automated AI slop. Use not automated manual AI slop instead.

This has never been more true. The opportunity cost of endless planning and contemplation just went way up. Agents allow you to just try vastly more stuff, so let them, and you'll learn way more, way faster.

Paul Graham wrote "Beating the Averages" in 2001. In the essay, Graham invents a hypothetical, middle-of-the-pack programming language called Blub to explain how programmers perceive the power and abstraction of programming languages relative to their own expertise. To understand the Blub paradox imagine a continuum of programming language power and abstraction, with low-level assembly language at the bottom, Blub in the middle, and high-level languages like Lisp or Haskell near the top: Looking Down the Continuum: A Blub programmer looks down at less abstract languages (like C or Assembly) and clearly sees that Blub is superior. They recognize that Blub allows them to write more expressive, powerful code faster, and they wonder why anyone would willingly choose a lower-level language. Looking Up the Continuum: When the Blub programmer looks up at more powerful, higher-abstraction languages (like Lisp), they cannot see the extra power. Because they think in terms of Blub, they view the features of higher-level languages as unnecessary, weird, or redundant. They conclude that Blub is already sufficient for everything and that higher-abstraction languages offer no real advantage. Because a programmer can only evaluate language features through the lens of what they already know, it is easy to spot the shortcomings of less abstract languages, but almost impossible to appreciate the superpowers of more abstract ones until you actually learn them. Every similarity to todays frontier AI development and considering LLMs the path to AGI is interestingly correlated.

In my 20+ years of being involved with building software I tried to implement Test Driven Development multiple times and always failed. I did not only fail, I failed in a predictable way. When deadlines or budgets tighten, developers drop tests first. Next, documentation goes out the window. The absolute last thing to fall is code quality: developers still try to write clean, readable code as much as they can because they know they have to debug and maintain it tomorrow. AI-assisted coding and Large Language Models have completely inverted this failure model. Because LLMs generate tests, docstrings, and markdown specifications effortlessly, tests and documentation are no longer the casualties of speed - they are the easiest assets to produce and keep. Today, code quality is the first thing to fall, while documentation and test suites remain maintained. In the classic model, a passing test suite meant someone took the time to define business rules and write assertions - which was hard. In the AI era, tests are often generated alongside or after implementation code by the same model. This leads to problems with having performant and maintainable code even with LLMs still, so I guess we do need another way to approach the problem. Before LLMs, technical debt was expensive to write. Adding 500 lines of boilerplate required manual labor, which naturally incentivized developers to seek clean abstractions and DRY (Don't Repeat Yourself) patterns. With LLMs, generating 500 lines of code takes three seconds. The AI defaults to verbose, defensive, and highly repetitive code structures because token generation favors explicit, predictable patterns over clever, lean abstractions. The role of the developer has shifted from author to auditor. However, reviewing AI-generated code supported by full tests and documentation creates new unique cognitive traps and problems. Code reviews must now focus on line-count reduction, abstraction quality, and removing redundant logic rather than simply verifying if tests pass. What kind of a quality assurance framework we are going to end up using I do not know, and as a business focused washed up engineer I am probably not going to be the one solving that problem. But I am intrigued.

There are three things I use AI for: - deep iterative research with a human in the loop - spec driven development (more for a demo myself but I support production uses) - automation of strictly deterministic input-process-output processes This is what led me to like Jev a lot and I wish to endorse it as it specializes in high-speed, structural tasks. Jev prioritizes the speed of execution over deep conversational understanding. It operates roughly 40 to 200 times faster than current LLMs, boasting an end-to-end response time of just 70 to 500 milliseconds. Traditional auto-regressive models are relatively slow because they generate text one token at a time. Jev bypasses this by being explicitly designed for parallel sampling and "typed probabilistic decisions". Because of its rapid execution and structured nature, Jev excels at workflow-specific tasks such as sorting emails, improving RAG (Retrieval-Augmented Generation), mass sorting data, playing games, model routing or transforming data and doing lead scoring. Overall, Jev to me represents a shift towards (or a return to) using specialized, narrow models for fast, automated workflows rather than relying on brute-forcing a general-purpose foundation model for every single task. Jev will not bring us AGI, but neither will LLMs. :)

If AI replaces us all I wander who will be the first unemployment influencer.

Knowing constrains and max size of your market is extremely important.

Toly on why startups keep picking Solana "As long as we're cheaper, faster, and offer better prices in finance, users are always going to want that. That's going to be why startups pick Solana, why the next fomo that figures out that viral loop of growth will pick Solana again, and we'll get more and more users."

Can entrepreneurship be taught? Inherent traits like extreme risk tolerance, grit, and instinctive decision-making under pressure are difficult to instill in a traditional classroom. While theory helps reduce mistakes - most would agree that true entrepreneurial capability is forged through actual execution and real-world experience. I would argue that there are 3 factors that create a successful entrepreneur. 1) Deep understanding of a specific large enough market, either by living through the problems of that market or by being able to apply first principles thinking to it. 2) Willingness to constantly optimize for user experience versus for your own comfort and understanding that the clients are the ones paying the bills. 3) Consistent bias toward taking an action and learning from results versus pure research of a problem. When you are trying to make a decision as an entrepreneur ask yourself where are you leaning on those three. It might not help you solve the problem, but it is a pretty good test if you are going in the right direction. So, entrepreneurship as a subject probably cannot be taught - but it can be audited. And risk and pain tolerance can be trained trough other aspects of life.

Only true after taking expenses into account.

Blockchain and tokenization gave open-source projects something they historically lacked: a way to coordinate incentives and value accrual without building a traditional company around them. That makes open-weight AI models a natural fit for tokenization. A model can remain openly accessible and community-developed while a token coordinates contributors, funds development, rewards usage and improvement, and captures value created by the ecosystem around it. In that sense, tokenization can provide open AI with an economic layer that matches its open technical architecture. I hope someone big enough will explore this in the near term.

I knew about spin marketing but whistleblower marketing is new to me.

I am a bit confused by the current state of AI because somehow we are currently using human language to talk to machines, and machine generated language to communicate with humans.

Dario and Sam seem to be very obsessed with AGI considering we already know the answer is 42.

You can’t eat your AI model and have it too.

Usual reason for companies to say they need to slow down is because it is too hard for them to speed up.