Senko Rašić

Random thoughts | about

The software development profession is in the midst of upheaval. Nobody knows how the AI revolution will play out in the end, but it is clear many aspects of work and life will be transformed—including programming.

One of the comments I hear often lately boils down to “LLMs may be good at coding, but software was never the hard part” and “coding is easy, it's figuring out what to code that's hard”.

I believe that's a gross insult to all programmers everywhere.

If coding is easy...

If coding is easy, how come programmers were in high demand, and have demanded large salaries for years (even before ZIRP)? Why was there so much stress, overwork and burnout even before AI started churning out 5000-line PRs? Why did companies seek 10x ninja rockstar coders and subject them to leetcode interviews—surely, a junior fresh out of college could churn out something if it's so easy?

If coding is easy, why do we have doorstoppers like Clean Code and The Pragmatic Programmer? Is The Art of Computer Programming a light summer read? Is SICP a coffee-table book? Why do we have bootcamps or even whole college degrees dedicated to it?

If coding is easy, was Carmack just at the right place at the right time? Why do we consider Fabrice Bellard a genius?

If coding is easy, why are people angry at AI (or anyone else) copying their code? Why do they act like they've poured their sweat, soul, and copious amounts of time into something so trivial?

If coding is easy, why do many now feel like their identity and professional purpose are being stripped away from them?

If coding is easy, why is software so damn buggy?

If figuring out what to build is the hard part...

If deciding what to build is the hard part, why do so many product managers seem clueless? Why aren't there rigorous 10-step interviews for them? Why aren't they getting paid more than the developers?

If deciding what to build is the hard part, why aren't market researchers, usability experts and—hell, customer success—considered rockstars in a software company? If “understanding the customer” is harder, why are business analysts looked down on as pencil pushers?

If implementation is easy and finding demand is harder, why are programmers upset when the salespeople promise a new feature to a customer to close the sale? They've found a genuine demand, something people will pay for!

If coding is easy, why doesn't everyone just build ten variations of a thing and see which pans out?

There's no median programmer

Another cliché comment is “most work in software development is talking to stakeholders, understanding the customer's needs, and having clarity on the priorities”.

I have met many programmers throughout my career, and very few of them want to talk to stakeholders, much less customers (exceptions are freelancers and founders, especially of software development shops). And, “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”.

Some software developers do say “I don't write code, I solve customer's problems”. But then they turn around and start to opine on monads, memory safety, and DRY principles, while their understanding of the customer is a made-up “user persona”, and they think “affordance” is the money your parents used to give you on weekends so you could go out and have a good time.

Yet others will say “Software development is theory building”. Programs are actually proofs (as in, mathematical proofs). Every commit should tell a story. And solving a customer's problem by FTPing a PHP file is a cardinal sin.

I don't mean to imply there are no developers that simultaneously care deeply about the craft of software development and really empathize with the customer. I do believe they might want to see a professional about a split personality disorder, tho.

What is important?

I do believe that talking to users, understanding their experience, empathizing with them, solving customers' problems and having all the stakeholders on the same page is critical to the success of a software project.

I also believe that creating good code is a craft that requires skill, patience, attention to detail, experience and wisdom, and that it will continue to be relevant in the times ahead.

¿Por qué no los dos?

To the extent that we can pull it off, I think we should aim for both. A deep understanding of the system we're building, together with a deep understanding of why we're building it.

Loudly proclaiming that “code is easy” or, at the opposite end, “code is art, a creative human expression that cannot be automated”, is just burying our heads in the sand.

It's cope. And you don't want cope, you want to thrive.

By this, I don't mean “jump on the LLM bandwagon.” I don't mean “become a manager of fleets of AI agents.” I also don't mean “AI-generated code is stolen slop garbage, fight it with tooth and nail, the bubble will pop soon enough anyways.”

But do recognize we're in the middle of an industry-wide tectonic change. We need to figure out how to adapt. We need to understand what is likely to change and what never changes.

What doesn't change?

Software will be getting more complex. Software will always need maintenance: bit-rot is a fact of life. So is entropy. Technology (hardware and software) will move forward, for better or worse. The tower (skyscraper?) of abstractions grows ever higher.

Users will always want more and be prepared to spend less. They still won't know how to relay their needs and wants. Worse, they still won't know exactly what they want. The disconnect between the customers (who actually pay for the software) and users (who use it) will still be here, as will the tension between the needs of the business and the needs of its customers.

Also: there will never be a shortage of snake oil salesmen. Tech du jour comes and goes (I'm still waiting for the new VR renaissance!)

What changes?

Programmers have been in the business of disrupting our own industry since the beginning. Nobody uses punch-cards any more. Very few people need to code in assembly, or COBOL. Those decades spent fighting memory bugs in C or C++, with the scars to prove it, are worthless in the age of Rust, Go, Python and JavaScript.

I'm old enough to appreciate valgrind or remember mysql_real_escape_string() from the PHP4 era—stuff I'll never again need in my life. And that wasn't even so long ago! I narrowly missed the dBase, Clipper, HyperCard and Access era, technologies which I can still spot operating in shops, cafes, or a dusty, once beige and now golden-brown, midi-tower still happily running some bespoke biz solution (backups? what backups?)

How do we thrive?

Accept that change happens. Be equal parts curious and critical about the new stuff.

Understand there's a lot of hype and try to discriminate between hot air and what really works (and to what extent). Also be aware of ever-shifting goalposts: stand back and look at the past year, or five, and assess the velocity of change (technical, economic, societal).

Your role and your responsibilities will be changing. Be willing to invest time and energy into better understanding fields or roles adjacent to yours.

If you're a senior developer, don't just find solace in deepening your expertise. Learn about user experience, customer interviews, or business strategies for the companies in your domain. It will help you gain a better appreciation of all the work done to put a piece of software into users' hands, whether or not you'll actually ever have to do any of those other bits.

If you're just starting or are junior in your role: invest in deepening your understanding of how software works. Understanding pointers, recursion, or memory hierarchy will help you even if you're a JavaScript developer. Understanding network protocols and how HTTP works will be useful even if you're building WordPress plugins. Do leetcode and learn about algorithms and data structures even if you don't need to. Don't be afraid to ask why and how exactly.

For inspiration, here are a few books and other resources that might be helpful:

One more thing

Whoever you are, don't outsource your understanding, judgement, empathy and taste to AI. Don't abdicate your responsibility. Don't be a meat proxy.

Over the past week I've played around with Kimi K3 by Moonshot AI and Qwen 3.8 Max by Alibaba.

Both are large Chinese open-weight models (weights promised to be released soon) and tout benchmarks showing they're as capable as the frontier western models (Fable 5 by Anthropic and GPT-5.5 Sol by OpenAI).

I wouldn't go that far, but these are really capable models. In my AI-coding tests, both have performed really well. Compare the test mini-games on my vibe-coding benchmark generated by Fable, Sol, K3 and Qwen.

In a more serious test, building a web app to a provided spec, K3, Qwen and Fable generated very similar results. An AI judge (GPT-5.5 Sol via Codex) gave a positive code review to all three (of course, it did find some problems and room for improvement), with Fable being slightly better.

“Good enough” is great!

What I am most excited about, though, is that the open-weights models have reached the threshold of “good enough” for serious AI-assisted engineering. The Anthropic and OpenAI models reached this around October-November last year, and it unleashed a huge adoption wave across the software development industry.

But there was always a possibility of a rug-pull: either through intelligence (tokens) becoming too expensive (and not included via standard subscriptions), models being explicitly withheld (as with the Fable fiasco) or nerfed (Fable and Sol, with their overly aggressive allowed-usage filters).

Open models are insurance against this. Although these models are too large to be reasonably hosted locally, there's already a cottage industry of third-party inference providers. And for organizations that really need to keep all their data close, there exists an (expensive) option of hosting it themselves.

The Chinese scare

There's much angst in the West about these models being Chinese. As such, they might reflect a kind of world-view that's not completely compatible with traditional western values. There's also a question of breaking western labs' terms of service and copying from them.

Both Anthropic and OpenAI, having scraped the entire public internet and trained on copyrighted material such as books, don't get to complain. My personal view is that training on copyrighted material is fair use, but you don't then get to disallow training on your API results.

The censorship and model alignment that follows the ideas of the Chinese government is real (though let's not downplay the alignment done by western labs for different topics). But with these models being open, the censorship layer can relatively easily be stripped away by post-training.

Western open models

The Chinese models (Kimi, Qwen, DeepSeek, GLM) are the most prominent, but they don't have a monopoly on open models: one of the most popular small models is Google DeepMind's Gemma.

Then there are models like Laguna S2.1, Nemotron 3 and Mistral Small 4 and many more, which usually don't make a big splash but are nevertheless very capable.

Taken together, there is a healthy ecosystem of open LLMs of various sizes (from 4B to 3T params). Most of them are open-weights (meaning you only get the weights), but some are fully open source (you get the training data as well).

As these models reach the point of “good enough” in their niches or for specific use cases (like AI coding I started this post with), they are already solid alternatives to the big popular models.

Hardware

The one big difference between open-weights models and free software, in terms of user experience, is which hardware you need. Today (mid-2026), the average hobbyist has no way of running the large models in any usable way.

Computers like Mac Studio, NVidia DGX Spark or the AMD Strix Halo, with unified memory, cost on the order of $5000 and can only run models up to 100B-200B params. Kimi K3 is 2.8T and Qwen 3.8 Max is 2.6T!

I'm optimistic, though. There's so much money sloshing around AI-capable hardware (NVidia has a $5T market cap and 85% profit margins, high-bandwidth memory (HBM) makers are also rolling in money) that I have no doubt there's going to be increased competition, increased performance, and reduced pricing in a few years' time (it takes time to build fabs, sorry).

I'm a desktop Linux user — specifically Debian GNU/Linux with GNOME and Wayland. I also do a fair number of video calls involving screen sharing. And I have an ultra-wide screen monitor (32:9).

This can sometimes be a challenging combination. I want to share a portion of my screen and any window shown there, but most of the software I use only supports sharing either a single window, or an entire monitor.

If I share a single window, it's annoying to share a different window every time I need to show something else. If I share the entire monitor, the aspect ratio means the other participants will have a pretty bad time watching it.

Year of screen sharing on the Linux Desktop

Wayland has been around for almost 20 years, but the support in the wider ecosystem is still spotty. One reason is enhanced security (or — introducing any security at all) compared to the old X11 protocol, which breaks some use cases, screen sharing being one of them.

The Wayland way to do screen sharing is through PipeWire and XDG Desktop Portal. In a nutshell, the application that wants access to the screen asks the environment, which checks with the user (through a modal dialog) and then allows limited access.

The access can be to a single window, a region of the desktop, or a monitor — but most of the apps only support single window or entire monitor share. Not sure why: perhaps the region share is a relatively new addition most apps haven't picked up yet.

In any case, it's pretty annoying, and searching on the internet didn't yield any easy workaround. So I built one.

Waymirror

My workaround was to build a small app that uses the same components to get access to a selected region, then simply show that in a window. Other apps can then screen-share that window.

The app is called Waymirror and is available from PyPI and GitHub. If you want to try it out, note it depends on a number of GNOME and FreeDesktop system dependencies.

Assuming you have the dependencies, the usage is:

pip install waymirror

waymirror left # mirror the left half of the current monitor
waymirror right # mirror the right half of the current monitor
waymirror # select a region to share
waymirror 640x480+100+100 # define the region as X geometry

Recap of my short posts on LinkedIn in May

Unlimited Power, Limited Focus

In the age of AI, focus is essential.

We now have, to quote Darth Sidious, unlimited power (subsidized by Anthropic and OpenAI). But we don't have unlimited focus.

In fact, many of us behave like squirrels on caffeine. We can run very fast, burning the midnight candle at both ends, wasting our time and tokens on stuff that, had we paused to think about it, would not pass muster.

Code is a liability — always has been. We're now printing the liability with such abandon that Leeroy Jenkins would look sheepish in comparison.

With everyone having this awesome tool at their disposal, how can you stand out?

  1. Use your judgement, wisdom, and taste.
  2. Focus. Keep your eyes on the ball.
  3. Understand that AI is a good servant, but a bad master.

And FFS, don't brag about burning tokens. Brag about what you've achieved with the tokens.

AI Is Technology, Not a Feature

If you run, or work for, a tech startup, you've seen this: customers, investors, and bosses ask you “do you have AI yet?”. There's a lot of unhealthy pressure to keep up with the competition and ship “AI features”.

AI is great technology, but it's not “a feature”. In fact, the best implementations out there are where you wouldn't even notice it (if it weren't so prominently showcased).

The fact of (startup) life is, you're pressured into both adopting and marketing your use of AI. It's on you to find the good use cases that fit nicely into your product.

I explore the conundrum in AI is technology, not a feature.

Code Review is Broken

In The agent principal-agent problem, David (cofounder of Tailscale, founder of Exe) raises an uncomfortable question: do we need code reviews?

This echoes Ankit's (founder of Aviator) How to kill the Code Review and Justin's (cofounder of StrongDM) Software Factories essays. In particular, Justin argues that “Code must not be written by humans” and “Code must not be reviewed by humans.”

I also touched on this in my Code reviews in the age of AI article a few months ago, where I argue we should put more emphasis on reviewing the plans/specs, and only do limited, targeted manual code reviews.

If you're leading a software engineering team and don't want to sacrifice quality for velocity, this question is worth thinking about, and discussing with your team.

Style Convergence in AI-generated Design

The curious case of the “contemporary Fraunces serif magazine editorial” design in Claude.

Here's what happened to me yesterday (all in one day):

I had to quickly whip up a website, and I turned to Lovable for some inspiration. The design looked nice but too close to FT/WSJ and even had some undertones of Anthropic.

So I fired up Claude Design and asked it to do the same (based on the same brief containing no design guidelines). The results looked eerily similar.

I fired up Claude Code (CLI). Same thing. I was sure I'd somehow triggered this with my website brief, even without actually specifying it.

Then I noticed a LinkedIn post from someone featuring a virtually identical design. Now I was sure it wasn't my prompting or something contaminating my agents' contexts.

This looked like a new version of the “Bootstrap design” effect, where AI agents mostly churn out similar pages. I told Claude to go in a completely different direction, and called it a day... or so I thought.

Because hours later, I saw the same damn design on Twitter, from none other than Peter Steinberger, author of OpenClaw, talking about vibe-slopped web pages.

To top it all off, in the evening I was helping my kid with some physics lessons and decided to create an interactive visualiser in Claude Web, to help with the understanding behind the math. Guess what: same friggin' design!

Now, I understand LLMs are not creative. But I also understand they are supposed to be non-deterministic, and this was pretty damn deterministic in my book!

I suspect the culprit is the combination of how Claude was trained, and Anthropic's “frontend-design” skill, which probably got loaded into all of those places. Lovable doesn't disclose which LLMs they use (to the best of my knowledge), but this would pretty strongly indicate Claude, and with the frontend skill enabled. As for why Claude prefers this: since it is similar to what Anthropic itself uses, I suspect there was some (unintentional?) stylistic or taste influence (leakage?) from their designers into the training data.

Whatever the cause may be, somehow, Claude overwhelmingly tends to converge on this type of design.

I mean, it's a nice design — it was nice once. Now I'm seeing it everywhere; it's like the em dash all over again.

Bun, Ported from Zig to Rust by AI

This is cool and scary: Bun, a JavaScript platform (alternative to NodeJS), has been (officially) ported from Zig to Rust using AI.

We've seen LLM-powered rewrites (chardet, justhtml) before. This is different because of scale. Bun is a large and much more complex project than either of those, and it was apparently ported in two weeks.

Projects at this scale (like Claude's Compiler or Cursor's browser) have so far been interesting experiments, but a far cry from production-ready code.

The merged PR has a million lines of new code, which presumably haven't been human-reviewed. A week ago the author claimed 99.8% of all tests passed (on Linux). Looks like it took them only a week to get to 100% across all supported platforms.

More quietly, a similar rewrite has been happening at Ladybird, a new browser with its own from-scratch engine (i.e. not just a wrapper for Chrome, Firefox, or another existing browser). It was originally written in C++, and they've started (slowly) porting it to Rust with AI's help — not automatically.

A few thoughts:

  • first public, successful large-scale project using fully autonomous, non-reviewed AI — we'll probably see more
  • robust test suites are a must — this would be a non-starter otherwise
  • Rust, and to a lesser extent Go, are becoming the go-to languages for AI-assisted rewrites
  • this would have been at least a year-long project without AI

Happy First Birthday, Cijene API

This post is in Croatian

🎂 Sretan rođendan, Cijene API! 🎂

Prije točno godinu dana stupila je na snagu Odluka o objavi cjenika, čime je Vlada RH obvezala velike trgovačke lance da dopuste automatsko preuzimanje (scraping) i obradu cijena.

Vidjevši tu objavu, pokrenuo sam Cijene API kao zabavan vikend projekt.

Godinu dana kasnije, podržavamo 29 trgovačkih lanaca, preko tisuću poslovnica, prikupljamo preko 10 milijuna cijena dnevno, a u ovih godinu dana prikupili smo ukupno preko 3 milijarde cijena.

Sve ovo javno je dostupno kroz naš API na cijene.dev i kroz dnevne arhive cijena.

Imamo nekoliko desetaka API korisnika (komercijalnih i nekomercijalnih), projekt pokriva svoje troškove servera, a imamo i malu, ali aktivnu zajednicu ljudi koji doprinose, što prijavom problema, što kodiranjem — hvala im od srca!

Posao nije gotov. Dok ovo tipkam imam jedan PR u pripremi za promjenu CSV formata jednog lanca i drugi PR za dodavanje još izvora. Serveri trgovačkih lanaca ponekad se ruše ili kasne s objavama. Naš API bi mogao biti još bolji.

Ali kroz ovu prvu godinu, mogu reći da su (posredno) stotine tisuća građana Hrvatske vidjele ili iskoristile informacije koje su prošle (na ovaj ili onaj način) kroz Cijene API.

Idemo dalje!

Running a Frontier LLM on Your Own Hardware

The shape of things to come: how to run a frontier-level LLM on consumer hardware. Salvatore Sanfilippo (a.k.a. Antirez, best known as the author of Redis) has been working on a new LLM inference engine (like llama.cpp, VLLM, or HF transformers), optimized for the DeepSeek V4-Flash model.

The DeepSeek V4-Flash is a smaller version of DS' newest model, released a few months ago, with 284B params, of which 13B are active, supporting a 1M context window.

What Antirez is doing with his project (dubbed DwarfStar 4) is to really push the hardware to its full extent, hyper-optimized for the model in question, whereas other engines are more generic and thus can't make tradeoffs to speed up one LLM version.

DwarfStar 4 (DS4) supports Metal (Apple) and CUDA (NVIDIA) architectures, with ROCm (AMD) on the way. But it also runs on CPU, if you're really patient.

The other piece of the puzzle is the hybrid 2-bit quantization for the model, i.e. using only ~2 bits for each floating-point parameter (down from the original 16). If you know how floating point works, this feat alone is mind-boggling, but it works, with noticeable but acceptable quality tradeoffs.

The end effect is that you can run DS4 on a machine with 96+ GB of VRAM, like the NVIDIA DGX Spark, or 96+ GB of unified RAM (like the Macs). Or, if you're really patient and only do it for testing — on ANY machine with 128GB of RAM.

Well, I'm patient and only do it for testing, and I happen to have 128GB of RAM, so I took it for a spin. Well, at ~1 token/s, “rotating slowly” would be a more apt term :) It's supposed to run at quite usable 20-30 t/s on Macs or Sparks.

It did a great Minesweeper (no surprise there), and a working RTS! Don't get me wrong, it was barely working and full of glitches. Much worse than the DeepSeek-V4 Pro version tested via the official API.

But — it's fully local. And it does work.

Now the only thing we need is a bit faster (and cheaper) hardware. Let's go, Moore, we're counting on you!

The Frog Has Already Been Boiled

People on LinkedIn, X, Facebook and Instagram are worried about the upcoming Google search UI change, removing the links to content sites. I'm here to tell you not to worry — the frog has already been thoroughly boiled.

For years, Google has been a steadfast partner for many — or most — commerce sites on the internet. Through SEO juice, paid ads, or actual word of mouth (remember that, anyone?), Google sent traffic to sites. Users were happy, sites were happy, Google was happy. Now that Google has a competent AI and all the data it can ask for, it doesn't need to link to sites so much.

AI is just the tip of the iceberg, but Google has been experimenting with this for years. Yet, like addicts, sites needed the juice fix, and did everything Google asked of them in the guise of “best practices”.

Now the other shoe dropped, chickens are coming home to roost, and the frog is cooked.

It gets better: LinkedIn, X, Facebook, etc. — all the places people use to voice this — are doing the same. Y'all are feeding LinkedIn with data (ironically, this post as well), and it's staying locked within its walled garden. One example: LinkedIn has recently stopped allowing non-authenticated browsers to even expand the links in posts (meaning I can't open a link in a private/incognito window, which annoys me to no end).

On X, you can't open a thread / see replies to a post unless you're logged in. Combined with pushing users to add links to outside pages in comments, you get a lock-in mechanism.

On Facebook and Instagram, you often can't see the post unless you're either on the app or logged in. I purposely do neither, and have no end of traffic lights, fire hydrants and bicycles to click through if I really want to see a shared post.

There's going to be a feast, and your content is on the menu.

Bon appétit!

There's a lot of psychosis around AI. My belief is that as a technology, it can both be used in a way that improves the lives of people, and leveraged in a way that will harm us.

Like in the parable of two wolves, the one that wins is the one we feed. So how do we feed “good AI”?

Here's how I, personally, want to use it:

As a tool. It's here to help me, not to steal my attention or get fed by me (I have a cat for that). I want to be the active operator, not merely a clueless user or an unsuspecting audience.

To grow. As a research tool, an infinitely patient tutor who, true, might occasionally be wrong. Not as a crutch to avoid thinking.

To remove the grind. Some hard things are worth doing. Some are not. Sometimes the grind is just tedious and doesn't help us grow. Washing machines, dishwashers, and now AI (when used wisely) can free up time and energy for better things.

To stop and smell the roses. Productivity is output over time. I want the AI productivity boost to give me more time, not just more output. If AI can 10x me, a 10-hour workweek and 250% productivity increase sound vastly more preferable to 10x output.

To care about the details. More time to dedicate to the small details that usually fall below the quality fold. I want to delight and be delighted and be proud of the result. I want to use AI for anti-slop!

For silly things. Like memes, slop can be fun. Low production effort doesn't mean low creativity. Not everything in life must be serious, high-brow and a result of man's struggle.

As a power tool. Forklifts, power tools, and other machines help us shape our world way beyond our physical capability. Calculators, computers and calendars do the same for our mental capabilities.

I recognize that using AI as a power tool to remove the grind can easily transform into using it as a crutch. Here's what I keep in mind to avoid falling into that trap:

Focus. AI makes everything deceptively simple, so it's tempting to do everything. That's just wasting time.

Judgement. AI is a really fancy autocomplete tool. I still want to be in control of thinking, guiding and judging its efforts. AI can give me options, but I get to pick and choose.

Taste. I'm definitely not an artist, but as a human being I claim to have at least a spark of creativity and taste in me. For whatever it's worth, it makes all the difference between something human-made and autogenerated slop.

Intuition. I subscribe to the notion that human intuition is a superb pattern matching machine trained over our lifetime and, in work context, career. Like in the corny Star Wars line, I do want to listen to my feelings.

You may say I'm a dreamer, but it works for me. I do hope I'm not the only one. Care to join me?

Recap of my short posts on LinkedIn in April

A Big Week for LLMs: Gemma 4, Qwen, Cursor 3, and a Claude Code Leak

A lot of LLM excitement this week: Google/DeepMind released Gemma 4, Alibaba unveiled Qwen 3.6-Plus, Cursor has a big new release (v3), Anthropic leaked Claude Code source, and even Microsoft released some new models.

The Gemma 4 release, latest in Google's line of small open models (from 2B to 31B parameters — not to be confused with its large Gemini model series), generated much buzz and excitement in the community. A big reason is the license switch to Apache 2.0, clearing some legal blockers for wider (re)use.

I tried Gemma 4 via llama.cpp and ollama, in multiple sizes, and wasn't very impressed: it did poorly on my simple Minesweeper coding tests and happily hallucinated about facts it didn't know about. Maybe it's the quantization or something with my setup, but it performed worse than Qwopus (Qwen3.5 plus distilled Opus 4.6) of similar size.

Speaking of Qwen, Alibaba also released an update, Qwen3.6-Plus. This, like Qwen3.5-Plus, is not an open model, but they did promise smaller open variants soon. I expect it's going to be a solid incremental improvement on an already great model.

In the land of coding agents, the new Cursor 3 shifts the UX to more “managing your agents” style, closer to what Claude Code app/web are doing, and away from “AI in your IDE”. You can still do that, but it looks like it's not their focus going forward, begging the question — why use Cursor at all?

Meanwhile, Anthropic is playing DMCA whack-a-mole with Claude Code leaked source code repositories on GitHub. Moreover, there are several projects that attempted “clean room” reimplementation — generate detailed PRDs/specs for the product from the code, then generate a clone from those specs without looking at the code.

Considering you can't copyright algorithms, data structures, or architectural patterns in software, it's going to be interesting to see how that story unfolds.

Oh, and apparently Microsoft also released some foundation models, but nobody noticed. To quote HuggingFace's CEO: “If it's not either pushing the frontier meaningfully or open-source, no one will care these days.”

What Is TurboQuant, Actually?

Two weeks ago, Google published TurboQuant research that promises to make LLMs more memory-efficient, triggering jitters in RAM prices. But what is TurboQuant actually?

Let's backtrack a bit to give you a better context: the defining feature of modern AIs is something called “attention”: a mechanism by which every token in a chat is influenced by every previous token (the tokens are “paying attention” to the preceding content).

To calculate this, you have to do some matrix multiplications of every token with every other token, for every new token (I'm simplifying a bit here). To do this naively would take a really long time, so LLMs have something called “KV cache” (you can think of it as “attention cache”), caching the multiplication results, speeding up the operation at the cost of a large memory increase.

The larger the context window, the larger the KV cache you need. How large? It depends on the model, but for smaller LLMs, the KV cache can easily be larger than the model weights!

Another important LLM detail you need to be aware of is “quantization”. Basically, the numbers (weights, KV cache, etc) in a neural network are floating-point numbers. The higher the precision, the better the quality and the more memory you need to hold the number. Standard precision used in LLMs is 16 bits, meaning each number takes up 2 bytes. But there are cases when you can lower precision without much quality loss. If you run a “Q4KM” model, you're using numbers quantized to 4-bit. Although there's research using 1.58 bits (ternary LLMs), in most cases even 4 is a big quality drop and everything below is unusable.

This is where TurboQuant comes in. With a really simple and clever mathematical trick, the researchers can drop the required precision for the KV cache to 3 bits with negligible quality loss and virtually no overhead.

What's the trick?

Each KV cache value is a vector of floating-point numbers. A peculiar property of those vectors is that some dimensions (members) have a large absolute value and some very small. Thus, when you reduce the precision of the floats, you destroy a lot of information across the dimensions that had smaller numbers. The trick is to “rotate” the vectors — matrix-multiply them with an arbitrary vector. This has the effect of making the dimensions roughly all the same scale — meaning when you reduce precision, you reduce it for all numbers roughly the same, and by a larger amount. (If this is fascinating, there's an even better trick, 1-bit residual — read the paper to find out!)

When implemented in an LLM, this means you can run it on smaller hardware, it's faster (because memory bandwidth is usually the limiting factor), or with larger context windows.

Will this lead to RAM prices collapsing? I wish! But no — everyone wants larger context windows :) It's yet another important but incremental step in making modern LLMs even better.

Don't Reward Token Burning

This is wrong on so many different levels:

  1. any metric will be gamed (Goodhart's Law)
  2. “more = better” is rarely correct in software development
  3. “tokenmaxxing”, wasting as much resources as possible, is totally braindead as a metric
  4. Meta being Meta, they had to gamify it to increase engagement

Now instead of trying to build better software, developers are burning through trillions of tokens and billions of dollars to become “a token legend” (presumably there's some sort of a prize as well).

Would anyone actually caring about their craft want to work in an environment like this?

If you're in a technical leadership position and your org wants to “incentivize AI adoption” by reporting (or worse, rewarding) token usage — do not do this. This is likely the worst possible way to approach it, and will cause lasting damage to your org.

Source: Meta employees vie for “AI token legend” status

The Mythical Claude Mythos and AI Vulnerability Research

Anthropic says they have an awesome new model, Claude Mythos, that's so powerful they won't publicly share it. We've seen such marketing gimmicks before, but security-minded researchers and developers are taking LLMs seriously.

The new model is supposedly trouncing everything else on various benchmarks and has produced “thousands of high-severity vulnerabilities, including some in every major operating system and web browser.” To avoid proliferation of thousands of 0-day exploits, Anthropic is only making it available to “launch partners” to use it “as part of their defensive security work”.

Sounds like boasting, and I'm skeptical of such unfalsifiable claims. However, both the Linux and FreeBSD kernels have recently patched bugs that have possibly been surfaced by the new model. Simon Willison did some digging and has a good overview of the situation.

Recently Linux kernel maintainers, authors of popular open source software (like Daniel Stenberg, author of curl, who's pretty much against AI slopware), and various security researchers have been talking about LLMs becoming really good at finding security problems — see Vulnerability research is cooked.

As Thomas Ptacek says in that blog post: “I think we're living in the last fleeting moments where there's any uncertainty that AI agents will supplant most human vulnerability research.”

Now I really want to see that mythical beast.

Embarrassingly Simple Self-Distillation

Here's an interesting AI paper Apple released last week: Embarrassingly Simple Self-Distillation Improves Code Generation.

Accepted wisdom around LLM training is that you can't use LLM output to train the same LLM: if you try to do that (without improving, validating or cleaning the output in some other way), the LLM will get dumber and dumber. This is called model collapse and was documented in a 2024 paper, “AI models collapse when trained on recursively generated data.”

Turns out, it's not necessarily true. The new Apple paper does exactly that, in a specific domain (code generation), and the model keeps improving! From the paper:

Sample solutions from the base model with specified temperature and truncation, then fine-tune on those raw, unverified samples via standard cross-entropy loss. This method requires only a set of problem prompts and the model itself: no human-labeled solutions, no reference answers, no teacher model, no reward model, no verifier, no execution environment, and no reinforcement learning of any kind. Surprisingly, it works.

To anyone knowledgeable about how LLMs work, this makes as much sense as a perpetual motion machine. It shouldn't work. But it does! Why?

Code generation is a type of problem where the LLM must work in two different ways: “fork” mode that creatively thinks of possible solutions, and “lock” mode which has to correctly implement the chosen solution. These two modes require different “temperature” (or “creativity”) levels, but temperature is a single global setting, so it's always sub-optimal.

The self-distillation approach samples solutions with different temperature settings, nudging the model in different directions, then teaches it those approaches. This doesn't add any new information into the system, but helps the model better organize the information it already has.

The method really is embarrassingly simple — it doesn't even test whether the generated code is correct (which is pretty easy to do with code!). I'm sure this will be picked up by all AI labs to improve coding capabilities. And I wouldn't be surprised if someone manages to generalize it to other domains.

(PS. The paper was released on April 1st, but apparently is not an April Fools' joke, I checked :)

Claude Opus 4.7

Anthropic released Claude Opus 4.7, an incremental improvement to their existing 4.6 model (still not the mythical Mythos everyone's been talking about lately).

I took it for a quick spin using my “LLMCraft” test. It built a pretty solid (bare-bones) WarCraft/StarCraft clone. There were a few bugs which I pointed out in one message, and it managed to solve them in the response. (Playable version, code.)

(Note: my prompt calls for a single-user version with no enemies, just one level, no sound; multiplayer and enemies I want to leave as a challenge for 2027 :)

Besides the incremental improvements across the board (see benchmarks in their post — but take them with a grain of salt, as always), the highlights are an extra-high-effort option, a fix for Claude ignoring instructions (especially in CLAUDE and memory files), and vision improvements.

Speaking at SaaStanak 2026

Happy to announce I'll be speaking at SaaStanak 2026!

Honored to join an impressive roster of speakers covering GTM, Product, Engineering and more. I'll be talking about my experience leveraging AI to build a startup MVP in days instead of weeks or months.

Vibe coding, and AI in general, is impacting everything. But clarity of vision, human judgement, good taste and business sense are more important than ever, and these are exactly the topics explored at SaaStanak. I hope you'll join me!

28 Years of MicroLinux

This post is in Croatian

Prije točno 28 godina, napravio sam prvu hrvatsku Linux distribuciju — MicroLinux — sa idejom popularizacije Linuxa na domaćim prostorima.

MicroLinux je bio mala distra (14MB), mogao se instalirati na postojeću DOS/Windows particiju, a pokretao se iz DOSa. Pojednostavljena (za to vrijeme) administracija sustava bila je na hrvatskom, a uz distribuciju je dolazila i prevedena dokumentacija i korisničke upute.

Godinu dana kasnije izdao sam verziju 1.2, koju sam predstavio i na prvoj DORS/CLUC konferenciji 1999. godine — moje prvo konferencijsko predavanje (true story: nisam znao da se obično pripreme neki slideovi pa sam pričao “na suho” :)

Ovaj vikend ponovno dolazim na DORS/CLUC pa sam se tom prilikom prisjetio MicroLinuxa i uspio iskopati stare arhive (nažalost samo verziju 1.2 — prvu verziju imam negdje na Bugovom CD-u, uključili su je na jedan od prvih CD-ova uz časopis, ali ga nisam nigdje uspio naći).

MicroLinux je dugo bio dostupan na linux.hr serverima (hvala HULK-u na podršci od prvog dana!), a sad sam ga preselio na senko.net/microlinux zajedno sa QEMU slikom diska za jednostavno isprobavanje unutar emulatora.

Three New Chinese Models

Three new open(-ish) Chinese models have been released, to much hype, in the past couple of days: Kimi K2.6, Qwen 3.6-Max-Preview, and (two weeks ago) GLM-5.1.

All three are big & closed models, but promise smaller, distilled, open versions will be out soon. All three excel at various benchmarks and are pretty hyped up by the open-weights crowd, placing them neck-and-neck with the latest models from OpenAI and Anthropic.

That's an exaggeration. I haven't done much testing yet, but what I saw was good performance but not really comparable to the latest & greatest. Subjectively, they feel closer to last year's SOTA crop. And of course, if you run a smaller open variant, there's an additional quality hit.

But that might not matter for some cases. These new models, across the board, are now good enough for many tasks that don't really require the best model out there. With that caveat, they can be used for coding, agentic workflows, chatbots and many other simpler tasks.

Whether that's cost-effective is another matter. Renting or buying your hardware is still a pretty pricey option: if you just rent a GPU for a month and serve a model from there, it's probably going to cost more than paying for the tokens for a model of equivalent quality. OpenRouter is another option, but is slightly a mess — finding a reliable provider there is not easy.

However, these new models still represent a solid “Plan B” in case the major providers jack up the prices, implode, or start banning uses (like cybersecurity research) left and right.

Links: GLM-5.1, Qwen 3.6-Max-Preview, Kimi K2.6.

Claude Code Goes Max, SpaceX Eyes Cursor

Anthropic might soon require a Max subscription for Claude Code; meanwhile, SpaceX buys an option to acquire Cursor for $60B.

Anthropic is A/B testing subscription purchase workflows that seem to indicate users won't be able to use Claude Code with a ($20/mo) Pro plan. Instead, it would only be supported for Max plans ($100+/mo).

Anthropic just doesn't have enough capacity for the huge demand growth they've been experiencing. They've already been setting strict limits which, according to many users, have made Claude Code unusable on Pro plans. They've also banned subscription use with other dev tools (like Pi), OpenClaw and similar tools. And we've known for a long time that subs are subsidised. So this is nothing unexpected.

Yet even a hint already caused a lot of uproar. They pedaled back slightly, but a lot of the developer goodwill Anthropic has gained is getting burned. If OpenAI play their hand right, they might draw a bunch of devs back to Codex. And of course there's also Google with Antigravity, and a bunch of solid Chinese models (Cursor's in-house coding LLM is a fine-tuned Kimi K2.5, and a new Kimi was just released the other day).

(As an aside: startup founders, if you've ever wondered how post-product-market-fit demand can hurt you — here's how: you can easily collapse under the weight of it; let's hope that doesn't happen to Anthropic.)

Meanwhile in rocket land, SpaceX will “work closely with Cursor” and has an option to acquire it wholesale for a trifling $60B (for context, Musk bought Twitter for $44B).

Nothing to do with rockets, of course — SpaceX is now a conglomerate containing Twitter and xAI, and a reasonable reading of the deal is that Musk is looking for synergies between xAI and Cursor.

Now for the tough one: since the X-Code and CodeX brands are already taken, I wonder how Cursor would be (re)branded post-acquisition?

Local Models Are Now Good Enough for Coding

The local models are becoming good enough for coding. I've tested the newly released Qwen3.6-27B model on a local machine with my Minesweeper task, and it did about as well as Opus 4.5 from a few months ago.

I retired my Minesweeper tests at the end of last year because all models completed it successfully. All large models, that is. Local models, up to ~30B params, still had a lot of trouble.

This is now changing, and if you have beefy enough hardware, local models are now a viable alternative for coding tasks. I took the new Qwen3.6 with 27B parameters (quantized to 4 bits-per-param) for a spin.

It did a perfect Minesweeper implementation, subjectively (from a user POV) equivalent to what Opus 4.5 did in December. Not only that: Claude Code (Opus 4.7) and Codex (GPT-5.4) reviewed Qwen3.6-27B's vs Opus 4.5's output and both identified Qwen's output as much better. Check for yourself: Qwen, Claude.

This is a limited-scope test. Opus likely performs much better on large-scale projects (which I intend to test), and you need a beefy machine to run it at a reasonable speed (my own test was pure CPU+RAM, taking half an hour to generate it — you definitely want a large VRAM GPU or a Mac for actual use).

But, still. For the first time, unless you're vibe-coding complete features in one prompt, new models like Qwen (or the recently released Kimi K2.6) may be just good enough to switch, especially if you dislike the pricing shenanigans Anthropic is doing.

DORS/CLUC 2026 Recap

Had a wonderful time yesterday and today at DORS/CLUC 2026. There were many interesting talks and discussions, but the highlight for me was the hallway track!

I had a chance to see a few of the talks (had to miss several, sadly — will catch up when they're published online), participate on two panels and present the Cijene API project. I especially enjoyed Luka Kladarić's talk about the impact of AI on open source and the challenging questions for us all — I was so focused on the talk I forgot to snap a picture :)

I again met many old friends (some of whom I haven't seen in decades!), reminisced about the old days and caught up on what's new. For example, did you know we have a hardware fab right here in Croatia? (tinkerfab.net)

I also met new friends and was heartened to see newer generations of free and open source and open data enthusiasts involved in various projects.

Thank you for having me, DORS/CLUC — see you next year!

Coding Model Shootout: GPT-5.5, Kimi, DeepSeek, Qwen

There have been a bunch of capable coding models released recently: GPT-5.5, Kimi K2.6, DeepSeek V4 and Qwen 3.6 Max (Preview). I've run them all through my new LLMCraft benchmark.

GPT-5.5 is the best of the bunch by far, no question there. It's tied with Claude Opus 4.7, which I reviewed last week.

Qwen also did pretty well, while both DeepSeek and Kimi produced a less polished and more buggy experience. However, all three managed to produce a solution more-or-less to spec.

Here's the kicker: ALL of these models were markedly better than GPT-5.3-Codex, released just 3 months ago.

I used GPT-5.5 with Codex CLI, Kimi and DeepSeek through Pi.dev with the official API, and Qwen 3.6 Max Preview via Qwen's chat interface (since I was unable to onboard myself to Alibaba Cloud Platform to get 1st-party API access to Qwen). In the first three cases I only specified the initial prompt (one-shot), while for Qwen I gave it a few bug reports (non-clickable buttons or JS errors) and allowed it to regenerate the output a few (three) times total to fix them, to compensate for the lack of an optimized coding harness.

Note that DeepSeek and Kimi are open-weights models at full sizes, while Qwen3.6 Max Preview is not (Qwen/Alibaba earlier released smaller 27B/35B 3.6 models under an open license).

Across all of these, the raw LLM coding capability is good enough to avoid being beholden to OpenAI, Anthropic or Google (for Gemini), which makes me optimistic about subscription/token prices staying sane (i.e. no large increases).

I can totally see a future where, should the cost of Claude or GPT increase five-fold, I switch to one of these alternatives and accept the quality hit for the budget option.

“The goblins kept multiplying.”

Curious users recently unearthed goblin-suppressing instructions in OpenAI's Codex CLI, prompting questions, intrigue and theories around the rationale behind it.

OpenAI spilled the beans in a fun, endearing and informative post: they had a goblin infestation. The goblins came quietly, an innocuous side effect of the fun & quirky personalities feature added in GPT-5.1. They, alongside their gremlin brethren, were given more prominence in the “Nerdy” personality. As OpenAI document:

We unknowingly gave particularly high rewards for metaphors with creatures. From there, the goblins spread.

Although they've cleaned up their training data to lower the incidence of goblins spontaneously materializing in your coding session, it was too late for GPT-5.4, which was already trained, so they applied a hotfix to the system prompt:

never talk about goblins, gremlins, raccoons, trolls, ogres, pigeons, or other animals or creatures unless it is absolutely and unambiguously relevant to the user's query

For fans of mythical creatures and strange beasts, the post does contain instructions for how to remove the hotfix — at least until the next major GPT version.

Recap of my short posts on LinkedIn in March

Antarctica in the AI Chart

AI chart that looks like Antarctica

You know what I see when I look at this chart, being shared by everyone in the past few days? I see Antarctica. 😅

We can talk AI capabilities all day, I can't unsee it. Human pattern-matching at its finest!

AI-Assisted Development Talk at Python Zagreb

Python Zagreb talk

Yesterday I talked about vibe coding and responsible AI-assisted development to a packed room at Python Zagreb meetup, one of my favourite venues.

I covered recent LLM advanced, different approaches to coding with AI (YOLO vibe coding vs actually caring about the resulting code), best practices, team dynamics and future outlook. I also did a little bit of demoing – an AI agent was autonomously coding a Meetup platform clone while I was presenting.

We had great Q/A and discussion afterwards! This is a hot (and hyped up) topic, and I'm heartened to see people taking code quality, maintenance and overall “good engineering” practices seriously. There's no fate but what we make for ourselves.

The talk was an updated version of the one I gave a few months ago at a few venues. “Updated” is selling it short: virtually all the slides, and most of the content, had to change. There's been an enormous amount of progress in the past few months! I expect I'll have to update it again before too long :)

The prompts, resulting code, and presentation slides are all available in github.com:senko/python-zg-vibe-speeka Git repository.

Thank you Python Zagreb for having me!

Non-Techies “Accidentally” Building Apps with AI

Citizen developers

Yesterday a friend told me his wife and he (both non-techies) “accidentally” coded an internal web app for her work. They wrote the requirements and pasted them to ChatGPT to see if it could do a mockup. It built an entire app.

This was ChatGPT, not even an app builder like Lovable or Replit, and neither of them has any software development knowledge. They did, however, stumble on the most important bit – clearly specify what you want built.

Of course they already knew AI can do stuff like that (one reason being I bore him to death with it each time we grab a cup of coffee :), but were still blown away by seeing it in action.

Stipe's experience is another example of what the future holds. Forget AI building the next $1T startup: we're entering an era of bespoke single-user software – for fun, for solving niche problems.

Zvonimir Sabljić's idea of “citizen developers” sounded slightly insane back in 2023. A few years later, we can see examples everywhere around us.

1M Context Now Generally Available for Claude

Anthropic has made the 1M context window for Claude Opus/Sonnet 4.6 generally available in Claude Code, Claude.ai, and removed the price premium (ie. no extra charge for large context usages): announcement

For coding, this is huge. On a recent project involving a few thousand lines of C code, I was constantly hitting the context – the language was just too verbose and the problem had too many important details to comfortably fit under 200k.

I've been playing with this for a few days and it doesn't seem different from before, except I don't have to keep an eye on context usage (aside: they added a tiny tweak to Claude Code's “clear context and implement plan” where they show how much context is in use – very helpful when you're trying to determine whether to clear or not).

It remains to be seen whether the context is good in practice. Benchmark say recall is high (78% on 1M tokens), but practice often differs. But I am hoping this also improved the recall on smaller context sizes (200-400k), which is a huge win in of itself.

Another goodie (especially for folks in Europe, Africa and Asia timezones), Anthropic temporarily raises the US “off peak” limits 2x:

  • 2x usage on weekdays outside 5–11am PT / 12–6pm GMT / 1pm-7pm CET
  • 2x usage all day on weekends

This is likely an experiment to see if they can “bribe” people to offload usage to off-peak hours (similar to how many electricity companies operate). This can make Claude Pro ($20/mo) more usable, esp. if we start to (ab)use the 1M context windows. It'll be interesting to see if the “temporary 2 weeks” ends up permanent.

ChatGPT's Click-Baity Answers

I've been seeng more and more “click-baity” answers from ChatGPT (Pro). The bot answers, but concludes with (verbatim phrasing, details omitted):

If you want, I can also point out the one mistake that causes these [...] If you want, I can also show one trick used in studios for [...] If you want, I can also show one placement trick that makes [...]

Most assistants can't shut up and ask if you'd like to followup, but I haven't previously seen this click-baity “this one trick/mistake/secret” phrasing.

I asked around and apparently this is a common ocurrence (at least on free ChatGPT plans), so people already mentally ignore it, but I only noticed it a few days ago. I'm not sure if that's just me not paying attention previously, or was able to somehow avoid it so far.

There's no chance this is a coincidence, as it happens too often – but only in specific type of questions (this one was about home improvement / DIY). Feels very much like the LLM has already been aligned to lead with an in-content ad, but there's no ad inventory yet so the followup answers (to my “yes, please”) are just vanilla.

This could also be market research by OpenAI – gathering data for which kinds of queries people are interested in getting the “one trick” info, that will be amenable for ads.

Below-the-Radar LLM Updates

A bunch of below-the-radar LLM updates this week: OpenAI releases GPT-5.4 mini and nano, while small open model scene heats up with Mistral Small 4 and Nemotron 3 Super. Oh, and there's a new Mamba (v3)!

Good week so far for the fans of small and/or open models – and it's only Wednesday! The models are so varied there's no point comparing them head to head, so I'll just list the highlights.

Let's start with OpenAI. If you're using their smaller models, upgrading to GPT-5.4 Mini or Nano is a no-brainer. They're still noticably smaller / less capable models, so don't try to replace full GPT-5 or even 4.1 with 5.4-Mini. But for simple, straightforward task, it's a clear upgrade.

Mistral's new Small 4 model has 119B total params (6B active) with 256k context window and configurable reasoning effort, released under Apache 2.0 license.

Nemotron 3 Super is NVidia's 120B total (12B active) hybrid transformers/mamba model. Notably, it's hybrid transformers/mamba architecture, and was pretrained in 4-bit precition (NVFP4). Nemotron is also released under an open license and provides (some?) pretraining and post-training data.

With previous open models targeting ~120B sizes (GPT-OSS 120b and Qwen3.5), this size might become a sweet spot for capable models that can be still run on consumer hardware (eg. Mac Studio) or cheaper cards (“cheaper” here is relative to the top NVidia models – still quite pricey!)

Speaking of Mamba (a different architecture for LLMs), the team behind it just released Mamba 3! They also provide an AI model, but the main thing here is update to the architecture, and is mainly of interest to LLM researchers.

Quite a week so far! With a mysterious new “Hunter Alpha” model appearing in OpenRouter, expected imminent DeepSeek V4, and an unconfirmed MiniMax 2.7 model (again on OpenRouter), all 1T-sized, expect more exiting news for AI geeks soon. (edit: turns out it's Xiaomi MiMo-V2-Pro, see comments)

(it is a bit tiring to keep track of it all, I can tell you that...)

AI Research Papers and the Fast-Moving Industry

The trouble with research papers measuring impact, effects, or quality of LLM-based systems is that the industry moves way too fast – by the time the results are published, they're of interest only to historians.

Today I read two relatively fresh research papers (both from 2026):

Both very interesting papers, but: The Spreadsheet Intelligence cites GPT-4o, while the Cursor one uses data from August 2025. The frontier has moved so much since that any conclusions potentially greatly differ from the current state.

Since people usually repost the juicy bits without these (or other) caveats, any information quickly turns into misinformation. When presented with “a research has shown” post about AI, whatever the conclusions, check the date.

I feel for these researchers. They're doing important (and, let's be frank, tedious) work of surveying the current state of things. It's just that the current state is moving so fast.

The bespoke software revolution?

With all due respect to what Jason Fried and the crew from 37Signals/Basecamp have achieved, this take is wrong.

Bespoke sofware does exist. And yes, consultants small and large have built, deployed, and charged through the roof for bespoke software. And often it sucks. Here's why it sucks: because clients can't coherently describe what they need, don't have a budget, consultancies don't care and – critically – the person writing the spec (and controling the budget) isn't the same person that will use it. (here you also have “A Tragedy of EdTech” in one sentence, but that's a different post)

But there's another kind of bespoke software, which, for a lack of a better name, I'll unimaginatively call “internal tool”. This is what VB6/Access/VBA/HyperCard enabled back in the day, what Retool tried to own recently, and what many Excel spreadsheets are secretly doing.

This is duct-taped-code-pasta that barely holds but does exactly what the business needs, and nothing more. I've seen and heard of many cases already of non-techies doing exactly that. It's not scalable, it's not maintainable, it doesn't follow best practices, it doesn't have tests or docs, but it doesn't matter, because it works and solves a biz problem.

The reason it works is that the person can iteratively narrow down to what they need, feedback is instant, iteration is minutes not days or weeks and is super cheap (compared to external developers).

No sane freelancer or agency would ship something like it – for many reasons: as a software engineer you want to ship quality product and charge appropriate amount of money. Many times, that's the right thing for the customers.

Often, it's overkill, and these types of smaller “quick win” projects never get started in the first place. And there's loads of potential projects like these!

So yeah, nobody will vibe-code a payroll system for 100+ person company, nor should they. But people absolutely will, and already do, whip up something that solves their niche problem. Now maybe they'll use AI instead of Excel.

Is AI Killing SaaS?

Pingu status checker

Is AI killing SaaS? No, but it raises the bar. There are many instances where people previously had to reach out for SaaS solution, and now don't have to.

Case in point: a simple website status checker with alerts. Nothing fancy, but there is some amount of work involved, and previously it would have been easier to use a SaaS. Probably a free tier to begin with, then upgrade to a higher plan once I have a few of URLs to monitor, want higher frequency or some other premium feature.

Now I built it in between helping my kid with some school work and cooking lunch: Pingu

What about reliability, maintenance, etc?

1) I don't need HA on this one. This is on a separate service from the other hosts and I highly doubt they'll all go down at the same time. If Pingu goes down, I don't care (also I can easily set up another instance of Pingu that only monitors Pingu, and the two can monitor each other if I so choose)

2) Maintenance: I don't expect any ongoing work on this. It's going to sit in its corner and do its thing, and perhaps once in never I'm going to update it or add a small tweak. Codebase this size is easy for a modern AI to handle.

3) I haven't looked at the code at all, but I did ask another AI to perform a security check :)

4) It's only deployed internally (no outside access), as it's not designed for wide use – however, it's open source!

5) The full spec it was built from is also open source, and I'll attach the initial prompt it all started from in the comments, since this post is already large enough.

LiteLLM Supply Chain Attack

Massive supply chain attack hit LiteLLM AI Gateway, a very popular LLM wrapper/library/proxy package for Python. The attackers gained control using the trojan version of Trivy security scanner LiteLLM uses, then made malicious LiteLLM releases that steal keys and sensitive info from users who install it.

Detailed incident timeline, Hacker News discussion thread (includes the package maintainers).

I use litellm in my code and my “think-llm” Python package depends on it. Thankfully I haven't updated any of the projects in the past 24 hours (or installed it in new ones), but this is yet another example of how we need to seriously rethink the software supply chain infrastructure we all rely on.

GitHub Copilot's Worrying Trajectory

GitHub Copilot issues

GitHub Copilot was one of the first – if not THE first – really good AI coding tools. They seem to have dropped the ball since, and their latest announcements and behaviour make it worse.

A week ago they announced they'll start training on our code by default from April 24th. To disable, you have to opt-out explicitly at Settings → Copilot → Features. If you host any code on GitHub, make sure you check that setting!

Now, it also emerged that they're injecting ads into auto-generated pull-requests (they call it “tips”, but let's call a spade a spade). This is a pretty serious breach of customer trust – and to make matters worse, it wasn't even announced anywhere.

Their recent lack of stability and outages could be chalked off to massive spike in use as massive numbers of people vibe-code and it all ends up on GitHub. Taken together with the questionable tactics mentioned above, it presents a worrying trend.

Combine this with a massive flood of poor-quality PRs and Issues that many popular open source repositories are now getting (because people are using AI to game “stars” and “activity” stats on GitHub), and you've got a reasonable argument for hosting your stuff elsewhere.

Is Microsoft finally losing its patience, and strangling the open-source golden goose it bought in '18 for $7.5B?

Zagreb Cursor Hackathon Recap

Zagreb Cursor Hackathon

Last weekend I was honored to be on the judge panel for the first Zagreb Cursor Hackathon, where more than 20 teams built creative projects around “Make something Zagreb wants” idea.

The hackathon was organized by Nico Möhn, supported by Cursor, hosted by Microblink, with friends from Google Developer Group (GDG) Zagreb pitching in with some Google AI credits.

The results were awe inspiring. I've been on many hackathons before and most of them are heavy on the idea, but recognize you can't build much in just a few hours, so teams usually present a proof of concept, interactive mockup, or a presentation.

Not this Saturday. Virtually everyone had a fully working demo – from real-time calculation of sun & shade so you can find your favorite neighbourhood picnic spot, to volunteering platforms, waste management education through gamification and Pokemon Go for stray cats.

There were more than a few apps that'd I'd love to use regularly as a citizen of Zagreb, including the FixZG app (winners of the hackathon), a social way to report problems in your neighbourhood, and KajKam, a waste sorting education app by Ivan Zidov &co. I think Dražen Lučanin would be proud (and should look into some of these entries!)

My co-judges Antonio Hadrović, Vincenzo D'Elia and Domagoj Vuković and I had a really tough job! I wish we could have spent several more hours reviewing the submissions – but the participants probably wouldn't have liked to wait that long :)

Congrats to all the participants and big props to Nico for organizing the event!

(If you fancy a puzzle, go look at The Clock first, try to figure out how it works, then come back here for the explanation.)

Inspired by Gonon: Building a Clock with No Numerals (HN discussion), I decided to build my own as a sort of practical art project.

One of Gonon's goals is to build a timekeeping device that carries no cultural baggage or assumptions. Considering it still uses decimal (base-10) numbers and sexagesimal (base-60) time units, it hasn't fulfilled that particular goal – but it's still nice to look at and analyze.

So it got me thinking: what could a timekeeping device look like if we're free from any cultural baggage, yet still be practically useful once you understand how it works? Ideally, if aliens visit us on Earth and see one of these in operation, it shouldn't be hard for them to understand it without knowing anything about our civilization, writing, or language.

Starting from scratch

Let's start easy, by throwing out everything we can't use: * numbers of any kind (requires number base systems and numerals) * directionality (what is more, what is less, what's the “correct orientation”) * any symbols or markings that have some cultural meaning (like am/pm or “:“) * assumptions about time zones, weeks, calendar months

On the other hand, if you just start from nothing, say, by defining natural numbers, the user manual for the clock will be rather large. I'd like to make it a practical device, so I'm willing to use something – as long as that something is a physical fact that everyone can agree on. Here are a few:

  1. Earth rotates around its axis – one rotation is called a day
  2. “Noon” is defined as when the sun is exactly above a spot on the Earth (longitudinally speaking)
  3. Earth orbits around the Sun – one rotation is called a year; we'll ignore that it's not a circle, as it's an irrelevant detail for the calendar
  4. Earth's spin and orbit are in the same direction

The time piece is keeping local time for a specific spot on Earth (in my case, Zagreb, Croatia).

Earth is a (pretty good approximation of a) sphere, any place on it traces a circle as it rotates, and the orbit is an ellipse (that we'll stylize here as a circle – we're not doing orbital mechanics here). So it looks like the Sun as the “anchor point” and circles should play a role in our design.

Day One

Let's start by having a dot representing sun, and earth as a circle (looked at from above) that rotates. Zagreb is marked by a small tick on the circle. Here's the sped-up version (1440x, one minute represents one day):

While we have an impression of the Sun going from East to West, it's actually the Earth rotating from West to East. When the tick comes directly under the sun, that's (solar) noon, and one full rotation is one day. If you squint a bit, it's already some kind of time-keeping device.

Let's see what else this point of view gives us. Well, given that half of the planet is in darkness, maybe we can indicate that as well:

Note the day/night line is a bit tilted – it's not exactly perpendicular to the sun. This is because, as I write this, Croatia uses DST (Daylight Saving Time) – we intentionally shift time to have more daylight in the evening. While this shortens daylight in the morning, most people are asleep at that time so won't mind it.

Carve Diem

The “clock” we have so far is somewhat practical – we know roughly where in the day we are, compared to dawn, noon and dusk. But in everyday life we need more granular time precision instead of eyeballing the angles between our location on the Earth's surface, the center of the Earth, and Sun. Beyond the night/day line (which changes throughout the year, remember), there's very little natural phenomena that we could use.

One option would be constellations, but these suffer from not being visible at day. Another option is to arbitrarily divide the day into, let's use a random number – 24 hours! ....okay, I admit, I cheated, I had a reason to use that one – so that the clock is more people-friendly. But since any division is arbitrary, the aliens visiting from another planet won't be surprised to find some division.

Now that we've carved the day into fixed-size chunks of time we'll call “hours”, why not “zoom into” and make it easier to show progression within each hour? This slippery slope leads us to minutes: a new, smaller (“minute” – see?) circle within the Earth/day circle. The minute arc sweeps until it completes a full circle, which coincides with our Zagreb marking touching an hour tick.

While this looks like I'm caving under the pressure of “cultural assumptions”, notice we never define how many minutes is in the hour – this is a continuous variable. This is just a concession to the fact that humans need to be able to tell time on a smaller timescale than half a day or so, and the daily circle is not good enough for that (or it needs to be large).

I'll second that!

I'll slip on that slippery slope even more by adding a second circle inside the minutes to mark – no surprise here – seconds. The seconds are also sweeping until they complete a full circle, at which point we (the people living on Earth) know one minute has passed. The aliens, having no clue about our minute-to-second conversion ratio, don't know that, but if they have space flight, they'll quickly figure it out from rotation speeds.

Here's the clock for around 10:30 Zagreb time, with seconds sweeping in real time (1x).

Note that time keeps going backwards! Or at least, the clock is using a non-standard – literally called anti-clockwise movement. The reason, of course, is that we want to mimic the earth rotation, going from west to east, not the perceived Sun rotation.

But here again is a subtle cultural bias – this is only true in the northern hemisphere, or when looking at Earth from above the North Pole. If you live in the southern hemisphere, the sun still goes from East to West, except that East is right and West is left (like, ahem, on most maps – talk about consistency). So, from a vantage point of a Kiwi or a Penguin, earth actually rotates left-to-right, i.e. “clockwise”.

Which is correct? Both! The choice is arbitrary – so I'll take the southerner's point of view. Not because I'm from Argentina or Australia (I'd love to visit one day), but because the sweeps can then go clockwise, making it more familiar to the casual user. The choice between two equally valid approaches decided by user experience (UX).

Now we have a fully functional clock which mostly corresponds to the standard 24-hour analog clocks (not many people have those, but they do exist), with the added effect of showing the day/night cycle and DST, if in effect. Can we do better?

World clock

Since our tick on the day ring represents a place, there's nothing stopping us from adding more. Here's the same clock with Zagreb, San Francisco and Tokyo, still showing around 10:30 Zagreb time. Note how natural it is to see the time zone differences when shown this way!

Perihelion or not?

Can we extrapolate this approach further and get a usable calendar?

With the calendar, there's no one obvious “anchor” point, as noon was for time of the day. There are several candidates: solstices, equinoxes, aphelion, perihelion, but all of them are changing slightly because of the slight perturbations in Earth's orbit and rotation axis.

Earth doesn't orbit the Sun in a perfect circle, but in an ellipse (nothing strange here, all orbits are ellipses, due to Newton's law of gravity). Being an ellipse, this means there's a point where Earth is closest to the Sun (Perihelion) and furthest from it (Aphelion).

Since we already used “my point closest to the sun” for a daily anchor, using Perihelion is an exact analogue. Luckily, it falls very close to the New Year – usually between 2nd and 5th of January. (Orbit wobbles a bit so the figures are not stable). So, we're going to go with a standard start of the year, with the additional excuse that it's almost when the Earth is closest to the sun, as it will be (visually) in our clock.

Let's draw another circle to represent a highly-stylized Earth's orbit and add a small dot on it to represent the current location of the Earth.

Like with parts of the day, a full year is too large to be a useful indicator at a glance. At the very least we need to know roughly where we are in it, and we're going to use the same trick – have ticks for every month, taking into account how many days it actually has (so, they're not regularly spaced)

The Complete clock

There's still one thing missing: it's very hard to figure out the exact day in the month based on this alone. I've long debated with myself whether to add another ring for days, making it more usable at the expense of consistency and elegance. In the end I added it, which brings us to the complete clock:

You can see the final complete clock here.

The ET and us

Let's revisit our clock from the aliens' point of view.

If they found an operative clock like this on Earth, could they understand it? From tracking it for a day or so, they could quickly see that the rotation of one of the rings exactly matches the rotation of the earth, and could map a rough location of the place it refers to. The day/light length would help them narrow down approximately which latitude the place is at. The inner two rings would obviously show time passage, just at different scales, and if they looked closely enough, the larger of the two's full circle would exactly match one of the ticks on the day circle.

What about the longer periods? The ring encircling the sun would naturally imply orbit, even if drawn as a circle rather than an ellipse, and if they lingered long enough, they could confirm the movement of the Earth through it roughly matches what's on the clock. Once they figured that out, the second ring would obviously be a “higher frequency” counter, mapping the month ticks from the year and the day rotations. The aliens would no doubt be puzzled by the length of the second month of the year.

One big caveat: all of this logic would break apart on any other heavenly body than Earth. The clock assumes that the Sun will be the obvious anchor point, and that Earth rotates. Other planets, other star systems, would need their own version of this clock.

Did we manage to get away from our cultural influences? Turns out, not very far. We still have a circular time-piece and think in terms of seconds, minutes or months – purely human constructs. We could have constructed a clock even without these, but it wouldn't be a very useful one.

So, I vibe-coded me a simple web app the other day (Pingu, a web monitoring and alerting tool for internal use).

To increase the chances of it working correctly, I asked the AIs — there were multiple involved — to write tests as they wrote the code. This is standard red/green TDD practice, and is apparently very effective at ensuring the AI produces meaningful tests.

I wouldn't know, since my request for TDD was summarily ignored. I'd be annoyed, but I remember I always avoided that sort of thing too, so I can't be too harsh on the poor clankers. No matter. I asked the AI to write the tests after the fact.

Now, when you ask AI to write tests against existing working code, they often do stupid stuff: a certain percentage of tests written will invariably be tautological: test themselves, the mocks, the framework, or some combination of these.

To combat this, I asked another AI to carefully review the tests and identify those that don't make sense. As expected, it found more than a few. I presented these findings to the first AI and asked it to improve or delete the offending tests. After this was done, I asked for a re-review and adjustment. After two rounds, I was pretty happy with the results.

Okay, so now I had tests that made sense and 98% test coverage. Not bad. But, do these tests actually catch bugs?

Which brings me finally to the point of this blog post: mutation testing. I asked AI (in a clean new session — all of these steps were done in separate conversations to avoid context pollution) to review the code without looking at the tests, and to identify possible places where we can intentionally introduce a bug.

The reason to do this without looking at the tests is, I didn't want it to look at the tests, figure out what's being tested, and change that. By not looking at the tests, we have a chance to stumble upon a real uncaught bug.

Here's my prompt verbatim:

We have extensive test suite (98% test coverage), but I don't know if tests are reliable.

Go through the codebase, (not tests) and identify places where we could introduce realistic bugs in the codebase, and how to introduce a bug. Write up doc/TESTING-PLAN.md with all of those cases.

Do not change the code yet, just write up the detailed testing plan document (markdown). I'll review it and then we'll do testing case by case and check if our tests detect the problem.

Remember, this is important: do not look at the tests. If you let them into your context they will introduce biases and we will have to start from scratch.

Yeah, it's the good ol' “remember, this is important!” trick. Does it help? Dunno, can't hurt, right? To ensure it didn't cheat anyway, I looked at the session output to check whether it accessed any test files. (It didn't. Good bot.)

Once the test cases (mutations) were defined, I cleared the context again and let it rip. The results:

All 40 mutation tests are complete. Here's the summary:

Results: 30/40 mutations caught (75%)

The test suite is solid on core logic but has 10 gaps, mostly in: [...boring details omitted...]

The full results with suggested tests for each gap are in doc/TESTING-RESULTS.md.

A quarter of the mutations produced bugs that weren't caught. Now I wish I asked AI to come up with a thousand cases! But that probably wouldn't be as effective — AI has a tendency to give you what you ask for even if it's obviously stupid, false, or bullshit.

Mutation testing is an old technique. What's interesting here is that the AI can create more realistic, plausible mutations, much cheaper (in time, money, tears, and sweat) than a human developer. This greatly increases the technique's usefulness in general, and especially when dealing with LLM-generated tests.

To recap, here's what I aim for when doing AI-heavy coding:

  1. Red/green TDD if feasible — and I now know to pay additional attention to LLM ignoring the request.
  2. High test coverage, but still use human judgment on which areas are important.
  3. Use the AI to review the test suite and find meaningless tests.
  4. Use mutation testing to find new problem areas and as a means to test the tests. Importantly, do not let AI look at the tests while writing up the mutations.

Duty calls

I've recently seen many people suffering form hype fatigue. People just don't have the emotional energy to engage for the N-th time with random strangers on the internet to patiently and rationally explain their position, but still want to engage.

I've seen this happen across forums such as Reddit, Hacker News, LinkedIn, the blogosphere, and elsewhere.

As a result, people just lose patience, have “shorter fuse” and write emotionally-charged pieces that polarize the issue. In the end, we're all just shouting across the board or preaching to the choir. The nuance gets lost, the most ludicrous takes get the most attention because everyone jumps to refute it.

The hype waves, and associated flame wars, come and go. Just in this decade we flame-warred on how the pandemic should have been handled, what to do with inflation, and the blockchain.

AI flame wars

The most recent hype wave is, of course, artificial intelligence. The hype fatigue I'm currently seeing everywhere – and experiencing myself – is related to the AI.

There are several AI camps, all warring with each other:

  • AI hypers – “AI is so great it'll do everything instead of us”
  • AGI/ASI hypers – a more extreme version of AI hypers: not only will it do everything, it's going to be sentient
  • AGI doomers – an inverse of AGI hypers: people are going to lose jobs en-masse, leading to major societal upheaval
  • ASI doomers – or worse, the AI will decide it doesn't want to serve humans and kill or enslave us all
  • AI doomers – AI won't do everything, but increased use of AI will worsen pollution, inequality, give more power to authoritarian states, and have other major harmful effects
  • AGI deniers – all AI use is dead because it will not, in fact, lead to AGI
  • AI deniers – it's a very expensive random number generator and it's useless in the real world
  • AI moderates – AI is great for some cases, has some serious problems, let's all try to be calm and use it responsibly (full disclosure: I'm here)
  • Clawbot crew – screw all that, I'm connecting it with everything I've got, what could possibly go wrong
  • the military – Clawbot crew with nukes

God, it was tiring just enumerating all of these, and I probably missed a few variants.

If you're in any of those camps, you'll feel that the others are either exaggerating, or not taking it seriously enough, or dismissing valid concerns or opportunities.

Good intentions and path to insanity

You may have the noblest of intentions in the start, trying to rationally explain your position, back your argument by evidence and proof. Yet every day, everywhere you look, you see these other ridiculous claims, and bit by bit, you lose your patience, lose your temper, become jaded and start preaching instead of arguing. People in your own camp will amplify such takes more because they resonate emotionally.

Of course, you don't stop to think at least some of the ridiculous claims you've heard were end result of just such process somewhere in another camp.

What's a rational person to do?

The clearest option is to get away from the conversation. Unless your work depends on it, you don't have to engage in these shouting matches. Step away from the treadmill, lower your megaphone, and snicker from the sidelines.

Or you can burn out, unsuccessful in your quest to educate the public, moving away completely from this part of the tech, disgusted by it all.

Or you can cynically see what's going on and – intentionally or not – use this to amplify your own voice, presence, and brand. Become an influencer, pundit, someone whose opinion matters, and who gets invited to podcasts and conferences. Tech hype, meet tech populism.

Coping

Here's how I try to cope with it:

I like the new technology and my day job is working with it and helping others understand it. So I can't just get away from it all – not without stopping doing things I like! But I have to be on the constant lookout. When I spot cynism, sarcasm or “wtf are these idiots thinking” train of thought, I try to stop myself.

To people I do reach, I try to convey a balanced picture of the situation, as reasonably and with supporting evidence as I can, and let them make their own conclusion.

Sometimes I succeed, sometimes not. When I spot a heated discussion or sense that someone has deeper emotional motives behind their position, I try not to engage – you can't out-reason a hothead.

I often remember the XKCD cartoon I included at the top of this post – “Someone's wrong on the Internet!”

That someone could be me, too.