Pitfalls

I decided to give Cursor a try and tried to vibe code. For context, I had a production system running for 2 years. Most of the stuff was implemented in the backend and no frontend at all. I decided to rewrite the backend and write the frontend. Due to the models' context window, I introduced the backend functionality step by step. Initially, it all went well, but as the number of functions grew, I observed inconsistencies in code structure, style, etc and constantly provided the necessary context to make the code more consistent. Then I started prompting to build the frontend side using react stack. Unfortunately, things didn't go quite well. Given I'm not good at frontend stuff, I completely relied on generated code. At some point, I noticed deprecated packages, poorly organized code, and a bunch of unnecessary boilerplate. Moreover, I constantly go through the error cycle, which I didn't quite understand.

To conclude, I quickly ended up having a mess than expected. I'd instead read corresponding documentation (react stack) and accept the outcome of those models carefully.

We still need substantial improvements. That is to say, the error rate should be close to zero to achieve what we call autonomous AI agents.

💰 They donate to get richer

Giving away is a necessity for rich people to become even wealthier. When billionaires spend a ton of money to build hospitals, schools, donate millions to fight homelessness and similar problems, people may think - what a generous and kind person. In reality they are doing it to earn more. It sounds counterintuitive, I know, but let me explain.

For an economy to thrive 2 things need to happen. The first is obvious - people should be spending actively. You're working your butt off and stacking all the Benjamins under your pillow? What a horrible person you are! No, just kidding, but it hurts the economy as well as it hurts yourself. What rich people do is just giving away some of their money to poor, so that they can return it to them by spending and incentivising economy. And they don't simply give away money for regular people, because it may demotivate them from working hard.

The second is about working productively. If people are actively working and producing goods and services, they are pure gold for riches. They give them back twice, first working for them and then spending their earnings. And this is the reason why they donate to education and healthcare. Their goal is to cure sick people and educate uneducated to eventually get back their investments.

It's not evil to be rich, earn a ton of money. It's evil and irrational not to return a portion of it back to your community. Remember - money is just the means to exchange your work to something else. If spent wisely it may bring more good than you could imagine

#financeandbusiness

How to Learn While Having a Full-time Job?

Some developers struggle to find time to learn topics they are interested in while working full-time. If you are a junior or mid-level engineer, the chances that you are learning fun stuff at work are high. Some mid-level+ engineers often invest into learning outside of working hours and some stop investing time into what they are interested in or want to pursue. In general, it's your choice whether or not you invest your free time into learning. The truth is you quickly stop acquiring new knowledge at your work unless you are working in fast-changing fields like artificial intelligence. If you want to keep making good growth while working full-time, there are a few things you need to keep in mind.

A few years ago, I tried to develop a habit of consistent learning, as I didn't always find myself learning what I was interested in. However, after I burnt out, I did different experiments to figure out how to learn effectively while keeping a balance. My key takeaway was managing your energy correctly. I discovered morning learning works best for me, as my brain would be fresh and not have much information to process. While learning after working hours works for some individuals, I often find myself having less/no energy to do something after work. So, it's important to find out what kind of schedule works for you.

You learn everything but nothing. You should commit enough effort to see progress. Unless you are learning a small topic, it may take from a few weeks to several months to cover the topic. Because of this, It's important to stay motivated to make good learning progress while having a full-time job. Prioritize things you want to learn and only learn 1 or max 2 topics at the same time. Otherwise, you end up learning nothing because of choice paralysis. Instead of setting a large, overwhelming learning goal, break it down into smaller milestones, and remember to take regular breaks to make good progress in the long run.

In-person interviews are back

I believe online assessments and coding interviews have been effective so far. However, I expect many companies will start rethinking their interview processes. The main challenge is that it’s difficult to truly evaluate a candidate’s abilities in just an hour.

leetcode-style problems and system design interviews have helped raise the bar, but as tools and AI models become more advanced, it will get easier to perform well on these types of interview questions. Because of that, I think mid-sized companies will begin to focus more on “How…” questions—emphasizing a candidate’s real-world experience rather than just testing their ability to solve leetcode-style problems.

As coding becomes less of a bottleneck in software development, interviews should shift toward evaluating a candidate’s practical experience, decision-making, and approach to solving real problems.

There Is No Perfect Code

The idea of clean code and clean architecture is often widely promoted by people of varying levels of experience. I sometimes hear folks discussing or debating this concept, making arguments based on commonly cited "best practices"—that it should be this way or must follow that convention. But in reality, there is no such thing as perfect code in production systems.

Over the past several years, I've worked on a variety of projects with different teams, and each project had its own level of quality, its own quirks and constraints. Not once have I encountered a codebase that could genuinely be called "perfect" (maybe I will one day).

What seems like perfect code today can easily become tomorrow's technical debt. Code doesn't remain static unless it's part of a small, throwaway project. What we write today is shaped by our current understanding and context, but it will inevitably change. Shifting business goals, changing requirements, and new constraints like latency, scalability, or compliance force us to adapt. That adaptation affects the code.

What we think is clean and ideal today can turn into a mess later. Or the opposite, something that seemed messy at first might end up being a practical solution. Building systems is always about trade-offs. Every system has different needs and goals: performance vs. readability, flexibility vs. simplicity, speed of development vs. stability. Improving one thing often means giving up something else.

Even the cleanest codebase decays. Without continual refactoring and maintenance, even well-written code degrades over time. I've seen many codebases slowly rot due to accumulating tech debt and a lack of care. That's why I believe the notion of "perfect code" is inherently short-lived.

In some cases, a team's obsession with clean code can even lead to project failure. In my experience, striving for perfection has delayed projects delivery and sometimes caused more harm than good. That's why I recommend avoiding over-engineering. There's no point in having beautifully crafted code if no one ends up using your product.

TypeScript's Dark Sides

I have been working within the TypeScript (TS) ecosystem for the past 4.5 years. During this time, I have worked on various codebases written in TS, each employing different approaches and mental models. Before discussing the problems associated with TypeScript, it's important to first consider the benefits it offers. TypeScript promises better tooling, improved type safety, and several other advantages. One of the key assertions often made by TS developers is that the type safety provided by TS facilitates the early detection of pre-compilation errors and improves the maintainability of projects. I agree with these statements to some extent. However, these claims no longer hold true once your codebase starts growing.

I believe one of the biggest issues is that TS was invented to solve JS issues. Most of the design decisions were made with compatibility with untyped legacy code in mind. TS prioritizes developer ergonomics over rigorous correctness, which has led to many poor design decisions. It opens the door to bypassing type-level checks, which in turn contradicts its promises.

You don't get a true sense of type safety. Even if the code compiles successfully, the chances of runtime errors persisting are high. In large projects, one of the most important things is strong compile-time guarantees, which TS cannot provide. This is because it's so easy to use any, unknown, type coercion, or abuse type assertions. Moreover, another significant issue is that the ecosystem itself is not reliable. As your project grows, you'll need to integrate different software and libraries, which in turn affect your codebase. If an SDK, library, or any external tool is not well-maintained or well-designed, you'll end up breaking things on your end or rewriting everything that those things provide (which is less likely to happen).

Additionally, the testing ecosystem sucks. As your project becomes larger, testing becomes very important. In TS, most popular testing frameworks and tools do not provide good type safety. From my experience, most of the teams that use TS end up using various workarounds, which significantly lowers the quality of your tests. I've encountered tests that appear to work due to low type safety (even they are broken). When you have large objects involved in testing, things get really complicated as you make changes to parts of your codebase.

To recap, I would say TS is good for shipping small projects on time. However, as the complexity of a project increases, the more you'll suffer from the fundamental issues the language has.

Using the conversations plugin feels so much better after years of using a mix of session based routers and state based step functions.

🌙 Eid Mubarak

Good starting point for AI agents and agentic flows.

AI economy

I was surprised with the results of the poll I posted recently. Claude won on spot (I assume that's because many of you are developers who use Claude Code), although I expected ChatGPT to take the lead followed by Gemini. Probably Anthropic's never ending hype makes itself known. Well this is a great opportunity for me to break everything down for you.

Anthropic's CEO - Dario Amodei is on every interview or show lately telling you and me that AI is coming for our jobs. I wonder if he's transitioned to chief marketing officer or some sort. But I get it, they need investors' money, looots of money. The company predominantly trains AI models and give you limited access to it for subscription fee. And training them is expensive, I mean EXPENSIVE.

Let's do some math. Sources say that training a frontier model on a cloud provider cost a couple of billion dollars. That's because GPUs that cost hundreds of thousands run day and night nonstop so eventually they have a model capable enough to respond your question. This is just training, running them also costs a bunch but significantly less. In a reasonably competitive market it's gonna make the company very hard to do their job if they rely on cloud providers only.

The solution is building a high end data center. The one with 1 Gigawatt power tailored for AI compute that would costs around $50B to build. That's land, energy, facility, cooling and hardware and additional 3-4 billion dollars annually to maintain it - technicians salary cost, electricity, water for cooling, hardware fixes and replacement. Still unimaginable amount of money, a third of Uzbekistan's GDP per say.

Yet I didn't factor in sales, marketing, engineering and all other administrative costs. To make such a business model work they need to scale out. Scale to tens of millions of users at the very least. Otherwise they still risk running out of money and getting bankrupt. Dario is probably praying every day for hardware to get cheaper, U.S government to go easy on them, so they reach IPO with trillion dollars valuation and he can take his big bag of profit from selling his shares just in case if they get crushed.

The same goes to OpenAI. Dario was OpenAI employee before leaving and founding Anthropic, of course he learned some tips and tricks from OpenAI's CEO Sam Altman. By the way I noticed that they both have jewish roots. They probably know how to play the game, I'm not being a racist here, just saying, ya know...

#tech