Another massively underrated way to talk to the AI is to tell it:

• Ask me questions one by one.

So that it feels like a conversation, not an essay.

If it's an important topic, I'd ask it to summarize our notes after we're done regardless. And probably ask other AIs and my co-workers to sign off on this.

With a bit of luck I could perhaps make it tweak its tone and length, so voice-assisted coding will be just what it should be.

In fact, no instrumentation is even needed. It can be a vanilla Claude Code or Cursor all the way. Just equipped with a skill to write its text responses in one text file, and await instructions that would come from another one. And then external tooling does the text-to-speech and the like.

Just yesterday I was talking to a friend that as I get older and wiser I understand the value of regulation better and better.

To the degree that not only I think those who are universally against regulation are silly, but that I can even see myself supporting some reguations.

With this being said, I have absolutely no clue how to even postulate the problem statement when it comes to regulating AI models.

Mythos/Fable are now officially declared "too powerful". Do I agree with this, or is is just a yet another circle of this Anthropic <=> Uncle Sam "cold war" and mutual PR love-hate relationship?

Well, I sincerely do not know.

What I do know is that Anthropic reserved the right to look at all the prompts and the inputs/outputs to Fable for 30 days. So if there is anything dangerous, Anthropic would have definitely seen it by now.

But given the possibility that it's all the pre-IPO play is real, we can only speculate now.

There is one belef I hold quite deeply though: in a few months time, we will all agree Fable was nothing revolutionary compared to Opus 4.8 or GPT 5.5. Harness and guardrails will catch up very soon.

The more scary possibility is that we will begin seeing more and more models taken out of the market, even retroactively.

My dream was and remains that we will have an open-weights model comparable to at least Opus 4.7 in the next ~six months. Yesterday I was 95+% this will happen. Now, sadly, I'm back to some 80%.

Although, of all the people, I should not be the one complaining. Coding is my passion after all. And even if I mastered the art of AI-assisted coding, the "sad" turn of events that in fact makes me code more by hand would only make me more valuable on the grand scheme of things.

Here’s a trivial idea that I’m confused no big lab has suggested yet. Confused because it would help sell TONS of tokens.

AI agents resolving disagreements with other AI agents in an AI court with AI judge and human jurors.

Such a natural and such a powerful idea. Humans provide the Constitution, Amendments, and, at times, Court Rulings.

Presumably, every decision made by AI agents follows from the above. So they keep working.

When the above is not exhaustive enough, or if a corner case or a contradiction is identified, AI agents engage in a competitive debate.
With an AI attorney general, AI prosecutor, AI plaintiff, etc.

Eventually there is an “Agent X vs. Agent Y” Case, where the arguments are presented cleanly and concisely, drilldowns happen in the directions the human community asks to go deeper into, and ultimately a human verdict is journaled.

Then we’re back to business of AI agents “working as usual”.

But this preparation of arguments by itself will be an activity that a) requires tons of tokens, which b) humans will be happy to pay for.

Heck, I’d love to see some agent trying to argue that one of my team’s decisions was unconstitutional — if anything, this is the most Socratic way to quality documentation.

“When agents can’t agree, they summon humans.”

Isn’t this the future?

So I was chatting with a friend yesterday — hi @@danielkornev! — and he said something deep: that it's easier for a non-engineer to build a good harness toolkit compared to an engineer.

I took it as a challenge to steelman the argument, since I quite liked it.

My phrasing went along the following lines. What engineers take as durability is a bit too rigid when it comes to a harness, while a product owner's brain is naturally used to working with a more fluid set of requirements that evolve over time.

So when it comes to designing and implementing a good harness toolkit — a big task these days — I do believe a product owner / product manager has an edge over an engineer. Because the failure modes that an engineer would see are different from what the problem naturally calls for.

One could argue that a product person would see a different set of problems entirely, and I would not disagree. But they are less likely to be way off.

An engineer can spend months optimizing some instability or race condition. A product owner won't fall into this, or similar traps.

So, all in all, a harness designed (and vibe-coded!) by a non-engineer may well be much better at solving the real-life problem compared to what an engineer could ship by themselves.

Especially if the product person in question has worked with data engineering / data science / metrics / evals / etc. before.

So it happened — I Claude-coded an app for my personal use.

I got tired of copy-pasting URLs between browsers to keep login sessions and whatnot separate. Switching the default browser all the time is cumbersome too. And the app I quickly found stops being free after 14 days.

But Fable is here. So I thought about the problem statement and the best way to shape the "product" — and built it in a few prompts. Now I can open any link in any browser right away, with Enter and keyboard shortcuts for the digits working just fine.

Mind you, I'm an ML/data/AI and backend/harness engineer. I've never coded for macOS in my entire life.

Moving forward, the life of a software technologist is likely to become more and more exciting.

https://github.com/dkorolev/selby

It's still beyond me how top labs make it difficult to copy or "print to PDF" the history of some chat.

While these very models are notoriously good at structuring unstructured content.

While these very models can literally control our desktop.

Never attribute to malice ...

I think I can finally formulate something that makes me more of an engineer than ... a non-engineer.

It is no longer that I want my processes to be deterministic. That has been gone for a couple of months now.

AI agents are far too powerful to disregard, and there is evidently not much to be won by forcing their workflows to be 100% reproducible. It is possible, yes; it is just pointless.

The correct approach, I believe, is to focus on good harnesses: build systems where one misstep does not derail the whole thing, but is quietly taken care of down the road.

Call this one of my engineering-minded maxims if you wish; for me, it is just common sense. Either I can prove something is 100% correct, like arithmetic, or I know for a fact that a mistake in a particular non-deterministic step has a) a very small blast radius, and b) is self-healing in the grand scheme of things.

Kind of how I have worked with people my entire life. There are very few folks you can trust 100%. With virtually everyone else, you act in good faith, but the bigger the decision becomes, the more checks and balances you should both be interested in introducing.

So what makes me more of an engineer is not determinism.

It is checkpointing.

I want my processes to always support some form of “Undo”. To the point that I can meaningfully reason about it.

For instance, with my AI-assisted coding, I simply have two GitHub accounts. I create private repos in one of them, configure branch protection, and invite the other one. And this other one is the account that agents have have full access to it.

But it is me, the human being me, who needs to log into a different browser and confirm with the passkey — my fingerprint! — that I endorse a certain pull request to be merged. Or to kick off a production deployment.

For me, this way of designing processes is second nature. Because this is the only way that makes sense at scale.

AI agents did not create new attack surfaces. They just helped us understand how much of what we chose to ignore is actually full of holes.

People as paranoid as me — we did see most, if not all, of these holes for years. We were just not listened to. And rightly so, I must say. Since listening to us would have broken the “move fast and break things” paradigm, which was quite effective for a long time. But not any more.

So, all in all, I personally am quite happy with what is going on in the industry. Because it is both moving much faster and returning to sanity. The sanity people like me have been preaching for a long, long time. And we are finally being heard.

So, it is not really about guarding against vendor lock-in or potential data loss. It is about defining the fine line between “this is a sustainable way to do business” and “this is almost guaranteed to blow up.”

Ten or even five years ago, it was a relatively safe call for most businesses to ignore those crying wolf. But AI is setting the record straight as we speak.

In the meantime, if you will excuse me, I will continue making sure my code is backed up on three devices in two locations. Because if, for instance, GitHub or Amazon is wiped off the face of the Earth tomorrow, I do not want to lose more than a couple of minutes of productivity.

Not exactly a standard risk profile, I will grant you that.

But that is my personal path to staying informed, safe, and sane. And I plan to stick to it, because so far, it has not let me down.

Discovery of the day: AI is really good at cleaning up space.

Sometimes repo clones, build artifacts, Docker containers, Apple containers, and Python cache pile up and eat too much of my disk, and I have to spend time wiping them out.

Eventually I just asked the AI: "Could you please help me understand what takes the most space and what is safe to clean?"

Whenever I tried myself I could usually only free up single-digit GBs, even getting creative with my scripts and grubs and whatnot. AI cleaned up 50+ right away.

Now I don't even really have a /skill for it — I just have a prompt I can copy-paste, and I don't think I'll need it often anyway.

And the terrifying thought: this cuts both ways. AI is unnervingly good at looking at a machine and reconstructing what its user was up to — better than most analysts these days. That's great when it's your own disk. Less great when it's aimed at you.

But for a geek just using the computer to solve their problems, AI continues to prove to be amazingly helpful in surprising ways — including something as mundane as disk cleanup.

𝗜'𝗺 𝗰𝗼𝗻𝘃𝗲𝗿𝗴𝗶𝗻𝗴 𝗼𝗻 𝗮 𝗿𝗮𝘁𝗵𝗲𝗿 𝗰𝗼𝗻𝘁𝗿𝗼𝘃𝗲𝗿𝘀𝗶𝗮𝗹 𝘆𝗲𝘁 𝘁𝗿𝗶𝘃𝗶𝗮𝗹 𝗿𝗲𝗮𝗹𝗶𝘇𝗮𝘁𝗶𝗼𝗻.

Even with all the exponential growth of AI-assisted coding, we're still on the same bell curve: all-encompassing deep-knowledge engineers are getting more and more productive, while the average hardly moves.

In other words, it is more and more beneficial if you truly are a talented engineer who 𝘸𝘢𝘯𝘵𝘴 to keep doing software engineering, 𝘢𝘯𝘥 wants to be good at it, 𝘢𝘯𝘥 enjoys it as a form of arts and crafts.

Whereas "career software engineering", as an above-average-paying nine-to-five job, will (rightfully!) die out.

Yours truly, just now, is going through a transformative experience 𝘢𝘳𝘰𝘶𝘯𝘥 software engineering: realizing that a lot of things I used to not want to do are actually quite easy with modern-day AI assistants. Liberating, to say the least.

I'm not an indie coder about to found a one-person company (yet?), and I have neither the product/artistic taste to build simple things 𝘸𝘦𝘭𝘭 𝘦𝘯𝘰𝘶𝘨𝘩, nor the entrepreneurial drive to envision truly new things that will be commonplace with average-{Joe,Jane} audiences in single-digit years.

But for literally every engineering and near-engineering problem, I'm slowly but surely becoming better than 99.99% of the respective domain experts of a few years ago — not because I'm better at it, but simply because AI lends a helping hand, so that my human intelligence is no longer shy to dig deeper. Examples abound, from Web UI intricacies to legal paperwork redlining.

𝘈𝘐 𝘪𝘴 𝘫𝘶𝘴𝘵 𝘴𝘶𝘤𝘩 𝘢 𝘮𝘶𝘭𝘵𝘪𝘱𝘭𝘪𝘦𝘳 — 𝘪𝘧 𝘰𝘯𝘦 𝘩𝘢𝘴 𝘴𝘰𝘮𝘦𝘵𝘩𝘪𝘯𝘨 𝘵𝘰 𝘮𝘶𝘭𝘵𝘪𝘱𝘭𝘺.

Guess I have to be happy about this, since I was always pro-individual and pro-progress, and this wave empowers just the right people — me and those like me.

Seen in this light, ironically, Anthropic is digging its own grave by trying to present Fable as something special. Driven by FOMO, a ~million engineers will spend ~five sleepless nights each, only to say "meh" at the end. Moves like this damage B2C corporate karma, and the repercussions would be painful.

Perhaps I'm overly optimistic, but my gut feeling is that the firehose of better models and cheaper tokens won't run out any time soon. And most good engineers are already leaps and bounds — literally ~50x, not ~10x! — ahead of the crowd. Sure, the above-average part of the crowd is also ~3x .. ~10x more productive, but this doesn't change the calculus.

And about jobs — well, I'm a huge believer in Parkinson's law. The administrative state tends to grow faster than the headcount of those who actually do the work: doctors, nurses, well, programmers. So I'd start worrying when large institutions — academia, government, military, Wall St. — begin getting sane about "only" keeping the doers.

Until that trend emerges — and I see not the slightest hint that it will any time soon — let's just continue BAU.

Weirdest personal observation of the month: Long fights do not feel long enough with several coging agents to herd.

(Yes, I'm working towards herding them less, like many if not most engineers these days. But those agents still require attention, ata least so far.)

So, on the one hand, it's not that much toil. I can handle two or three parallel tracks despite not sleeping for quite a few hours. As in, my brain on autopilot is good enough to keep the momentum, even though it's nowhere near fresh and productive.

On the other hand though, 8+ hours feels not like "good, it's time to land". It feeks like "darn it, I didn't quite have a chance to finish X, Y, Z, if only there were another ~1.5 hours".

Some awkward combination of anxiety and fatigue that is. Good news is, after another ~dozen of hours I should have enough automation to afford to engage less. Famous last words though.

TIL: “Require linear history” is not enough on GitHub

Two GitHub settings solve different problems:

• Require linear history keeps main free of merge commits.

• Require branches to be up to date before merging ensures CI actually ran against the current main.

One could have two PRs based on version 1.0, each bumping it to 1.1, and both passing CI.

The first merged and shipped 1.1. The second stayed green since its checks ran on the old base. It then got rebase-merged and its identical bump became an empty commit and vanished. Oops.

Linear history + green CI, but no actual release. Oops again.

The fix is to enable Require branches to be up to date before merging. The second PR would then have gone stale, forcing a rebase and fresh CI.

TL;DR: If your checks validate anything against the base — versions, migrations, generated files, etc. — turn on both settings.