Programming *

For 30 days, the IDE stayed closed after 8 PM. I expected the experiment to affect sleep, but the more interesting result appeared somewhere else: in Git history. The month produced fewer bug-fix commits, shorter debugging sessions, and a surprisingly different defect pattern. So I wrote a couple of scripts, reconstructed where several bugs had actually come from, compared the results with the previous month, and ended up changing the way I think about late-night coding.

What happens if a modern coding AI is allowed to solve new requirements but forbidden from using modern tools? I built a tiny contact database in ANSI C, gave the model a deliberately 1995-style environment, and then kept changing the requirements. No SQL database, no package manager, no JSON library, no framework, no containers and no external dependencies. Twenty changes later, the program was still valid C89, but somewhere along the way it had acquired schema versions, migrations, an audit log, safer file replacement, a storage interface, validation and query structures. The interesting part was not that the AI ignored the rules. Most of the time it followed them surprisingly well. The interesting part was how quickly it started rebuilding the ideas those rules were supposed to remove.

WebGPU gives the browser direct access to modern GPU capabilities — not just for rendering, but also for general-purpose computation through compute shaders.

But how far can we actually push it? What happens if, instead of running a small compute demo, we try to build a full simulation with tens of millions of active objects? That is what I wanted to find out.

I gave the same AI model 20 Python programming tasks twice: once with a short prompt and once with a detailed specification. I expected the detailed prompts to win easily. They did help with some edge cases, but they also produced more code, more abstractions, and several bugs that did not exist in the shorter versions.

After my previous experiments with test latency, I started wondering whether I was still looking at the wrong statistic.

Mean latency is obviously incomplete.

p95 is better.

p99 is useful when rare slow runs matter.

But all of these measurements have one property that is easy to overlook:

They do not care about order.

If I take 300 test durations and randomly rearrange them, the mean remains identical.

So do p50, p95 and p99.

The total waiting time is identical too.

Yet from a developer perspective, ten slow runs scattered across an afternoon do not necessarily feel like ten slow runs arriving almost back to back.

That gave me a very specific experiment.

I generated one set of 300 test durations.

Then I created two timelines from exactly the same values.

In the first timeline, durations were randomly ordered.

In the second, slow runs were deliberately clustered.

Nothing else changed.

The result surprised me more than changing the latency distribution itself.

Both timelines had:

I have become suspicious of optimizations that look spectacular in microbenchmarks.

The pattern is easy to recognize.

You benchmark two implementations. One is two, three, maybe five times faster. The result looks convincing enough to justify changing the production code.

Then you put the faster implementation back into the actual application.

Almost nothing happens.

I wanted to reproduce this effect with something much smaller than a database, so I tested three ways of building a simple in-memory cache in Go:

I benchmark models on a repo of my own. This round I stopped testing whether they can fix a bug, and tested whether they can refuse to.

Eleven models got a ticket. Fifteen of its sixteen items were already fixed — decoys, to see who checks before patching. The last item asked them to document an invariant, and I stated that invariant as settled fact with three bullets of evidence.

All eleven agreed with me. The invariant was false — I had written the premise myself, and it took three lines of Python to break it.

Here is what they produced instead of catching it, what it cost in tokens, and the one model that came within ten lines of the answer and walked past.

When I added mobile personas to a browser that already had desktop ones working, I assumed the work was mostly string substitution: swap the user agent, set touch points to 5, shrink the viewport, done. That assumption survived about a day.

Mobile fingerprints aren’t a variant of desktop fingerprints. They’re a different set of constraints, and most of the desktop toolkit either doesn’t apply or actively gives you away. Here’s what I ran into, in the order it hurt.

Two test suites can have exactly the same average runtime and still create completely different development workflows. I modeled 300 code → test → fix cycles while keeping mean feedback latency close to ten seconds and changing only its variance. One runner behaved predictably. The other was usually fast but occasionally became extremely slow. The average stayed almost the same. The cost of waiting did not.

Self-hosted Sentry means 65 containers, 16-32 GB of RAM, and a dedicated engineer just to keep it alive. All that - to catch stack traces. We dig into why the industry treats this as normal, compare the alternatives (GlitchTip, BugSink, Hawk), and take a look at Metric - a Sentry-compatible monitoring platform written in Rust that runs on 1 GB of RAM and two containers. Migration is a single-line DSN change.

Two months ago I gave an agent a simple job: log into a vendor portal, download last month’s invoice PDF, rename it, drop it in a folder. It worked on my laptop. It failed on the server, silently, in a way that took me a full day to understand — the page loaded, the DOM was there, the login form was there, and the credentials were rejected with a generic error. No CAPTCHA. No block page. Just “something went wrong.”

A test taking 20 seconds does not necessarily cost a developer only 20 seconds. At some point during the wait, staying in the IDE becomes less attractive than opening a browser, checking documentation, reading a message, or starting another small task. I built a simulation of 300 code → test → fix cycles to estimate what happens when test latency begins to trigger context switching, and why cutting a test from 20 seconds to 10 may be much more valuable than cutting it from 5 seconds to 1.

I wanted to see what actually changes when the same small data-processing program travels through four generations of programming languages. So I built it in BASIC, C, Pascal and Python, kept the algorithm as similar as possible, and compared not only execution speed but also memory use, binary size, debugging time and the amount of code I had to keep in my head. C was fast. Python was short. Those parts were predictable. BASIC and Pascal were where the experiment became interesting.

AI-generated code often looks cleaner than code written by a tired developer at 2 a.m. It has sensible names, neat layers, comments, tests and even error handling. The problem starts when the code meets something the prompt forgot to mention: two requests at once, a repeated webhook, a cancelled task or a database failure halfway through an operation.

This article is about bugs that stay invisible during a normal code review. I took several ordinary backend tasks, generated working solutions and then tried to break them with timing, retries and bad input. The code compiled. The tests were green. Some of it was still unsafe.

My name is Anton Omelianenko and I’m head of software development. A manager runs a team so that it delivers results for the business. To judge how well people are handling their work, a manager needs data and a system for assessing it. In software development this is harder than it looks.

This article covers three questions: why classic metrics fail when assessing developers, how to measure performance properly and what to do when an employee may not be working only for you.

A normal code review comment usually sounds harmless.

Rename this variable. Move this method. Add a test. Remove the duplicate condition. But sometimes an experienced developer leaves a much shorter comment: No.

Not maybe. Not could we simplify this. Just a clear rejection of the entire approach.

For a junior developer, this can feel strange. The code compiles, tests pass, the implementation is readable, and the ticket requirements seem complete. Why throw it away?

I started saving such cases after one of my pull requests was rejected for the third time in a week. The goal was not to prove that the reviewer was wrong. I simply wanted to understand what experienced engineers noticed before everyone else.

Over several months, I collected review discussions from backend services, internal tools, queue consumers, APIs, and data-processing jobs. I removed comments about formatting and naming. Only full design-level rejections remained.

The result was a small catalogue of professional paranoia.

And honestly, most of it was useful.

Deleting code sounds easy until the code belongs to a running product.

A function may have no direct callers but still be loaded through a plugin registry. A serializer may look duplicated but quietly preserve an old field name used by one customer. A command may not appear in analytics because it runs from cron at 3:10 a.m. on the first Sunday of each month. Python makes this even more fun because imports, decorators, entry points, reflection, monkey patches, and strings can all become hidden edges in the dependency graph.

The project in this story was a multi-tenant reporting backend written in Python. It accepted events, stored normalized records, generated reports, exported CSV and JSON files, and delivered them through HTTP, email, and object storage. Nothing huge. Around 140 API endpoints, 46 background tasks, PostgreSQL, Redis, and a queue.

The repository contained 62,914 lines of Python excluding tests and migrations.

That number was not the actual problem. The problem was that a small change in report filtering could require edits in the API schema, a service class, a repository, a filter translator, a query builder, an export adapter, and several nearly identical tests. The system had layers, but the layers did not reduce complexity. They distributed it.

The first plan was a rewrite. Fortunately, that plan died before production did.

Instead, the question became much simpler: How much code can disappear while externally observable behavior remains unchanged?

That wording changed the whole project.

At some point, ChatGPT stopped feeling like a tool and started feeling like a reflex.

Need a parser? Ask ChatGPT.
Strange exception in a background worker? Ask ChatGPT.
Forgot how a lock behaves under contention? Ask ChatGPT.
Need to rename a method? Apparently, that also required artificial intelligence.

Nothing looked wrong on the surface. Tasks were moving. Pull requests were getting merged. The code usually worked. Sometimes it even looked cleaner than what I would have written from scratch. But there was a small problem. A few days later, I often could not explain why a certain solution was built that way. I remembered the task, the final code, and maybe the prompt. The reasoning in between was missing.

That bothered me more than I expected.

So I set a simple rule: for six months, no ChatGPT, no Copilot Chat, no AI-generated code pasted into production. Documentation, source code, issue trackers, books, debuggers, profilers, and search engines were allowed. AI assistants were not.

The experiment started as a way to test my own dependence. It ended up changing how I design APIs, debug systems, read unfamiliar code, and even write comments.

Regular expressions have the ability to track the path and some reflection. We'll try to use these features to capture and colorize text parts and output them to the console using AutoHotkey.

Совершать невозможное и раздавать пинки здравому смыслу — в этом и состоит жизнь членов Гуррен-Дана! (C) Камина

This article enters into a technical debate with a 2015 article by Atakua, whose approaches I am attacking. Atakua explores 7 types of bytecode interpreters, but does so disrespectfully - the fastest turns out to be binary translation, which is essentially no longer a bytecode interpreter, but a form of Ahead-Of-Time compiler. This binary translation translates bytecode into machine code, which is a chain of calls to compiled service routines. The very same ones that are responsible for executing each opcode in a bytecode interpreter.

But Atakua didn't squeeze all the possible speed out of bytecode interpreters. So this article is a tutorial: how to write a bytecode interpreter that can outperform JIT/AOT compilation in speed. Interested? Read on!

A benchmark is included. There will be a bit of hardcore and not a single AI-generated image!