Teaching the AI to Watch My UI Tests

While there are more topics in the backlog, and more drafts, today I want to share something big for me personally.

I've reached a milestone along another dimension: instructing the AI agent how to fix or improve the UI based on the automatically recorded video of a UI test.

TL;DR: I've instrumented everything with a UI test. In fact, it's not just a UI test — it does some things outside the UI, and I have a special hidden-from-the-user UI page that's used to show some console CLI terminal commands that are run, and their results. Then I programmatically record the run as a 10+ minute video that shows everything.

There's even a visible moving mouse pointer in the UI test btw; simulated, of course. But it makes it far more pleasant to follow.

We watch this video then: I myself, my colleagues, other people whose input we ask for. Then we gather feedback, such as "at this minute mark, this and that are not as they should be".

And then I can literally ask the AI agent to analyze the video. Yes, I know it doesn't have to be video, but so far it's working fine as is, to my great surprise and satisfaction!

Now, to close the loop: collect feedback, paste it, then watch the agent make the fix. The agent then produces the next video recording that passes all the tests. Rinse and repeat.

Agents can also diff videos. So I have MacOS and Ubuntu generating them, and then have the agents compare notes. (The simulated mouse movement on the video is so sloppy on Ubuntu compared to MacOS, heh.)

I think this is quite big. Not only am I quite happy to have pioneered UI testing in the project where I've been touching the UI for a long time — though that too.

The more important thing is that this AI-assisted coding, UI engineering, or rather product UX engineering, becomes a much easier and much more pleasant problem to have. Now literally all you need to ship amazing products is a good understanding of your customer and good taste.

To geeks reading me: Yes, I'm in the process of having my harness generate a sequence of screenshots, such that every frame of the video contains the index of the screenshot once that scene is complete. Because analyzing the video burns tokens and is far too slow overall. But watching that "mouse" navigate around my UX is mesmerizing.

After some basic cleanup, the largest two files on my MacBook are ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb and ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle, in this order.

Each one almost 8GB.

This AI-assisted coding boom will teach many if not most engineers that being a tech lead is too damn hard.

On the other hand, engineering teams used to produce code much slower than modern-day swarms of agents.

I have a vague idea that the future is some pre-trained / pre-prompted "chat windows", or "ready-to-join conference rooms", where our freshly minted human tech leads can chat or talk to the AI about the vey code that needs to be understood and evolved further.

So that the human part of the review process will mostly be some "Do I understand it correctly that ...?" questions, with various agents working together to produce meaningful answers from different angles.

And we will need harness for this tooling too. What a time.

How to make AI remember correctly, beyond RAGs and context windows.

Live in San Francisco.
Tue, Jun 2, 11:30am.

At the Snowflake conference, Braindate Lounge — Basecamp, South Hall A.

Join: https://snowflakesummit26.braindate.com/braindates/295744

This OneSix robot is so so cool!

I said sure, make a video, but it's just for fun, not to share. But then I watched it and it's so, so cool!

(The recording is 2x-ed by me before posting.)

Software Was Always Going to Break First

I had a thought I can't shake.

AI took over coding fast, and everyone has the obvious reasons ready: you can check whether code works almost instantly, and there's real money in shipping faster.

But here's the part nobody says out loud. Of all the industries the world runs on, software is the one that already tolerated slop. It was human slop — slower to build, more expensive, harder to maintain — but slop all the same.

The moment outsourcing took off, the industry quietly admitted something: it didn't really care about engineering quality. A great staff engineer or principal architect is worth more than a solid senior one, sure. But not 100x more. Usually 1.5x, maybe 2–3x at the bleeding-edge shops. And the closer a company is to ordinary, the smaller that gap gets.

Climbing past "senior" was rarely about engineering anyway. It was about "understanding business priorities," "managing stakeholders," "driving cross-team collaboration." In other words: the exact bureaucratic slop AI is now great at producing.

So what happens when an industry that is fundamentally about engineering decides to reward everything except engineering? Slop. Tech debt growing faster than features ship. A slow-motion disaster.

This was always heading somewhere bad. AI just sped up the arrival.

Some fields are better protected. In Michael Church's essay Engineers as Clerks, he points to three career ladders where raw intelligence matters most: law, medicine, and software.

Law and medicine did something software never did — they unionized, in the economic sense. Over decades they organized into something hard to crack from the outside. They keep their below-average members employed, and collectively the whole profession's pie grew. The rules of both fields are basically built to keep clever outsiders out.

(You could say theoretical physics fits too. But it's not really a career path, and I like Eric Weinstein too much to wade in there.)

By the same logic, electricians and plumbers might be more exposed to robots than people think. If an automation-friendly fuse box is cheaper and works better, young, fast-growing economies — Dubai, Argentina, El Salvador — have every reason to skip straight to it and win big.

Heavy industry like aerospace is probably safer, mostly because it's drowning in regulation. After Boeing, that's not nothing. AI will arrive there too, just slower — and slower likely means safer.

But in software — the world of bits, as Thiel calls it — the steamroller keeps going. There's no external standard forcing quality up. Entry-level jobs will change fast, because big companies do understand they need to grow talent and keep the market stable. The real problem is the middle: managers who learned nothing but soft skills on their way toward VP. They're exactly the wrong people to be guarding the gate.

Remember all the stories about US universities failing at basic student safety? That's institutional capture at its ugliest, and it's doing real damage. I think software's version of that capture will hurt us far more.

Because software runs on high switching costs. Imagine if you could actually pick up your Facebook or Apple account and move it somewhere else. There's no regulation for that, and there won't be one soon.

So realistically, we wait out a generation. The younger one has its own tools and devices. They won't need Gmail and the rest, and I hope they grow up fluent in encryption and privacy.

No tidy conclusion here. I'll stay exactly who I am: cautiously optimistic about the long run, pretty pessimistic about the short one.

[Un]popular opinion: if a human asks the AI to research something, and this research implies accessing some website, the AI should absolutely ignore robots.txt and visit that website right away.

Even if the very site says "for humans only, no AI".

Because the intent comes from a human.

Sure, internet browsing and serving content costs money. So we may well end up in a sane world where "for humans only" just means "free for humans, but one millicent for the AI".

Better yet, "free for humans, one millicent for the AI, ten millicents to return as a structured JSON object without ads". The Web3 folks have designed literally zero-friction abstractions for such payments a couple years back already.

I, for one, would be delighted to live in the world where some ~120% of hosting prices are covered by agents browsing my website. The money will ultimately be coming from users who are authorizing this research.

A sane world that would be. A sane world indeed.

Ah, and ads can and should be gone for good by that point. That is, ads for humans. The emerging strong AI will render them useless anyway.

Ads are, after all, prompt injections in disguise, and we'll need far fewer AI generations to reach herd immunity compared to how many human generations it is taking now.

Expect a bumpy road though: websites that are deliberately making money by luring your agents in. On the other hand we sort of have and are having this with humans already, so we know how to fight this.

Our AI assistants will be entering there teenage year and internet puberty in the next half a year or so. That'd be fun to watch.

And here I am, achieving perfect balance on a fine Sunday evening.

𝗦𝗸𝗶𝗹𝗹𝘀 𝗔𝗿𝗲 𝗚𝗹𝗼𝗿𝗶𝗳𝗶𝗲𝗱 𝗣𝗿𝗼𝗺𝗽𝘁𝘀 (𝗔𝗻𝗱 𝗧𝗵𝗮𝘁'𝘀 𝗮 𝗦𝘂𝗽𝗲𝗿𝗽𝗼𝘄𝗲𝗿)

Over the past several weeks I've been experimenting with various harness solutions for AI coding. I've gone two routes: instrumenting AI-assisted IDEs directly (opencode run ..., claude -p), and leaning on the more "AI-native" machinery — Skills and subagents.

Here's my sincere take so far. It distills to two pieces of wisdom that sit in tension with each other.

① 𝗦𝗸𝗶𝗹𝗹𝘀 𝗮𝗿𝗲 𝗴𝗹𝗼𝗿𝗶𝗳𝗶𝗲𝗱 𝗽𝗿𝗼𝗺𝗽𝘁𝘀. You can absolutely do everything Skills do by keeping a list of prompts — your own personal "prompt factory" — and copy-pasting them into an open agent. There's no magic in the abstraction itself.

② 𝗔𝗻𝗱 𝘆𝗲𝘁 — 𝘁𝗵𝗲 𝗳𝗮𝗰𝘁 𝘁𝗵𝗮𝘁 𝗮 𝗦𝗸𝗶𝗹𝗹 𝗰𝗮𝗻 𝗶𝗻𝘀𝘁𝗿𝘂𝗰𝘁 𝘁𝗵𝗲 𝗜𝗗𝗘 𝗼𝗻 𝘄𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝗻𝗲𝘅𝘁, 𝗶𝗻 𝗽𝗹𝗮𝗶𝗻 𝗘𝗻𝗴𝗹𝗶𝘀𝗵, 𝗶𝘀 𝗮 𝗴𝗲𝗻𝘂𝗶𝗻𝗲 𝘀𝘂𝗽𝗲𝗿𝗽𝗼𝘄𝗲𝗿. That second-order capability is what changes things.

𝗪𝗵𝗮𝘁 𝗜'𝗺 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗰𝗵𝗮𝘀𝗶𝗻𝗴

The goal was, and remains, to make automation better: longer uninterrupted AI coding sessions, more done in one shot, more precise questions asked back to me, easier-to-review code, and less slop.

That's not a trivial ask. It requires some genuinely hairy logic — a real state machine. The infamous "should Slack send a push notification?" flowchart comes to mind. Decisions branching into decisions.

What I've converged on is that it's likely beneficial to write parts of this logic in English.

Don't get me wrong — there will still be code. My Skill .md descriptions literally say: "use these Python scripts from your scripts/ directory for any and all operations except writing documents or code." (And except tool-calling, like gh.) But realistically, I've almost fully converged on the idea that expressing the harness rules in English is the way to go.

𝗧𝗵𝗲 𝗹𝗶𝗺𝗶𝘁𝗮𝘁𝗶𝗼𝗻𝘀, 𝗵𝗼𝗻𝗲𝘀𝘁𝗹𝘆

A couple of caveats keep me honest here.

I haven't found a way to spin up a subagent running a different model. For tasks that need that, an external runner — or, in my case, a human — does the job fine.

And there's a delicate financial wrinkle: claude -p now bills against API usage, so there's no subscription discount to hide behind.

All things combined, though, I'm becoming an advocate for Skills.

𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝘀𝘁𝗿𝗶𝗰𝘁𝗻𝗲𝘀𝘀 𝗹𝗶𝘃𝗲𝘀

The genuinely strict logic can still live in a real programming language. I keep metadata.json and summary.yml files around constantly — amended and parsed by Python scripts (or, eventually, my own native-code CLI binaries, though I'm not there yet). These files follow a strict schema. A Skill's first move is often to run a script to fetch the "current state," and only then proceed with further instructions.

And it works. Spawning subagents in parallel works. Collecting their results works — I call them "receipt files," dropped into .gitignore-d directories and prefixed by the RunIds handed to Skills as they run.

I even have meta-skills: Skills that confirm the other Skills — their English implementation and their accompanying scripts — don't violate the architectural and design principles I outlined for myself up front.

𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗶𝘀 𝗺𝗶𝗴𝗵𝘁 𝗯𝗲 𝗴𝗼𝗶𝗻𝗴

I'm not sure, honestly. But the geek in me seriously wonders whether we'll end up reinventing some semi-structured, Turing-complete language for Skills — still mostly English, but with strong guarantees baked in. And then defining complex pipelines becomes an art form of "engineering legalese."

What I can say is this: I can now run 10+ hour jobs with agents, and I cross-check them across various AI-assisted IDEs and various models. So, all in all, I'm quite happy I got to experiment with these things.

More to follow. Especially if something durable emerges from under my fingertips.

So there was a joke on 𝚋𝚊𝚜𝚑.𝚘𝚛𝚐[.𝚛𝚞], I believe, that went along the following lines.

𝐵𝑎𝑐𝑘 𝑖𝑛 𝑡ℎ𝑒 𝑑𝑎𝑦, 𝑡𝑎𝑘𝑖𝑛𝑔 𝑝ℎ𝑜𝑡𝑜𝑔𝑟𝑎𝑝ℎ𝑠 𝑤𝑎𝑠 𝑎 𝑏𝑖𝑔 𝑑𝑒𝑎𝑙. 𝑌𝑜𝑢 ℎ𝑎𝑑 𝑡𝑜 𝑝𝑟𝑒𝑝𝑎𝑟𝑒 𝑡ℎ𝑒 𝑑𝑒𝑣𝑒𝑙𝑜𝑝𝑒𝑟 𝑎𝑛𝑑 𝑡ℎ𝑒 𝑓𝑖𝑥𝑒𝑟, 𝑎𝑛𝑑 𝑠𝑒𝑡 𝑡ℎ𝑒 𝑐𝑜𝑙𝑜𝑟 𝑏𝑎𝑙𝑎𝑛𝑐𝑒. 𝐼𝑡 𝑤𝑎𝑠 𝑎 𝑤ℎ𝑜𝑙𝑒 𝑎𝑑𝑣𝑒𝑛𝑡𝑢𝑟𝑒. 𝐴𝑛𝑑 𝑡ℎ𝑒𝑠𝑒 𝑑𝑎𝑦𝑠 𝑦𝑜𝑢 𝑝𝑟𝑒𝑠𝑠 𝑡ℎ𝑒 "𝑠ℎ𝑜𝑜𝑡" 𝑏𝑢𝑡𝑡𝑜𝑛 𝑎 𝑡ℎ𝑜𝑢𝑠𝑎𝑛𝑑 𝑡𝑖𝑚𝑒𝑠, 𝑡ℎ𝑒𝑛 "𝑑𝑒𝑙𝑒𝑡𝑒" 𝑖𝑡 999 𝑡𝑖𝑚𝑒𝑠, 𝑏𝑎𝑟𝑒𝑙𝑦 𝑙𝑜𝑜𝑘𝑖𝑛𝑔 𝑎𝑡 𝑤ℎ𝑎𝑡 𝑒𝑎𝑐ℎ 𝑠ℎ𝑜𝑡 𝑡𝑢𝑟𝑛𝑒𝑑 𝑜𝑢𝑡 𝑙𝑖𝑘𝑒 𝑜𝑛 𝑡ℎ𝑎𝑡 𝑠𝑚𝑎𝑙𝑙 𝑠𝑐𝑟𝑒𝑒𝑛 𝑒𝑚𝑏𝑒𝑑𝑑𝑒𝑑 𝑟𝑖𝑔ℎ𝑡 𝑖𝑛𝑡𝑜 𝑡ℎ𝑒 𝑐𝑎𝑚𝑒𝑟𝑎.

Configuring various dev setups with AI today feels exactly the same!

I've got a custom Linux user on a random port, running Postgres, ClickHouse, my Rust app and my Python app, plus a headless browser, all over SSH over a terminal multiplexer, orchestrated by a skill. Even listing this all in one sentence is a challenge. But this works.

A few years back, this is something I'd have spent a month perfecting. And I'd be immensely proud of this setup.

I'd go give talks left, right and center about how awesome this way of working is.

And now I look at how the AI spawns all the right things, say meh, and move on to another tab — grumbling all the while that the skill's output isn't clean enough. Because I had to glance at that terminal for an extra half a second looking for the relevant output, instead of getting a nice self-contained report in one place.

We gotta re-learn how to appreciate those small engineering wins. I'm telling ya.

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.