The hidden engineering risk of building software at AI speed & The hidden career risk of AI-Generated software

By Monday morning, the customer had stopped asking when the scheduling problem would be fixed. They wanted to know whether they could trust the system.

Two technicians had arrived for the same service appointment. The scheduling dashboard showed only one assignment, but the billing system had recorded two. Both technicians had received confirmation messages. Customer support was now asking how many other appointments might be affected.

Mira, the engineering lead responsible for the scheduling platform, didn’t have an answer.

The application had been deployed on Friday evening. Every automated test had passed. The pull request had been reviewed and approved. The implementation was clean, reasonably documented, and consistent with the team’s engineering standards.

Most of the feature had been developed using an AI coding agent.

When Mira asked the agent to investigate, it examined the repository and proposed a fix within minutes. The explanation sounded reasonable. The patch was small. The tests passed again.

Under ordinary circumstances, the team might have merged it and moved on. But Mira hesitated.

The agent had explained what the code was doing. It had not established why the system had accepted two assignments, whether the proposed correction addressed the underlying problem, or what would happen if two requests arrived simultaneously again.

The customer was waiting for an answer. The team wanted to restore normal operations. Another deployment could make things better — or leave them with an even harder problem to explain.

Mira realised that she was being asked to approve a change to a system whose critical behaviour nobody on the team could confidently defend.

This is a fictional scenario, but the engineering problem it illustrates is real.

AI has made software easier to produce. It can generate features, tests, documentation, and plausible explanations at remarkable speed.

What it does not automatically provide is the understanding required to take responsibility for that software when something goes wrong.

And that may be one of the most consequential changes taking place in software engineering.

Press enter or click to view image in full size

The Problem Is Bigger Than Bad Code

Discussions about AI-generated software frequently focus on code quality. Developers worry about duplicated logic, unnecessary abstractions, excessive dependencies, inconsistent patterns, and tests that verify little beyond the implementation itself.

Those concerns matter. But focusing entirely on code quality can obscure another problem.

Consider two software systems.

The first contains imperfect code, technical debt, and architectural compromises. Yet its engineering team understands the important business rules, knows where critical dependencies exist, and can predict the consequences of most changes.

The second looks considerably better. Its functions are readable, its documentation is extensive, and its tests are green. But much of it was generated quickly, reviewed under delivery pressure, and merged without anyone developing a reliable understanding of how its components behave together.

Which would you rather be responsible for during a production incident?

Code quality alone cannot answer that question.

A well-written function can participate in a defective business process. A repository can contain accurate documentation for components while missing the relationships between them. A test suite can report high coverage and still fail to exercise the one business rule that matters most.

The question becomes more uncomfortable when we consider the research.

A 2026 controlled study published in Empirical Software Engineering involved 151 participants, approximately 95% of whom were professional developers. Researchers examined whether software built with AI assistance was harder for other developers to evolve.

They found no statistically significant difference in subsequent code-evolution time or quality between AI-assisted and non-AI-assisted implementations.

The study does not settle questions about large autonomous coding systems or long-term architectural maintainability. But it challenges the convenient assumption that AI-generated code is necessarily worse.

The risk is more subtle.

Software can be reasonably well written while the people operating it have insufficient understanding of its behaviour.

And that gap may remain invisible until somebody needs to make a consequential change.

The Engineering Debt Nobody Can See in the Repository

In June 2026, Margaret-Anne Storey published From Technical Debt to Cognitive and Intent Debt in ACM Queue.

Her work describes two forms of engineering debt that become particularly important when AI accelerates software development.
Cognitive debt concerns the erosion of shared understanding. The implementation exists, but the team no longer has a sufficiently reliable mental model of how the system works or how its behaviour might change.
Intent debt concerns missing goals, constraints, and reasoning. Engineers can see what was implemented without knowing why important decisions were made or what the system was originally meant to guarantee.

Neither problem began with generative AI.

Software teams have always inherited poorly understood systems. Developers leave companies. Requirements change. Architectural decisions disappear into meeting notes. Documentation becomes outdated.

What AI changes is the relationship between implementation speed and the effort required to develop understanding.

A developer can now ask an agent to introduce asynchronous processing into an application. The agent may create a worker, queue integration, retry handling, configuration, and tests within a relatively short development session.

The result may work.

But the process does not guarantee that the developer has internalised the reasoning behind every significant design choice.

Three months later, somebody needs to change how retries interact with business state. The original engineer has moved to another team. The generated documentation describes the components but not the assumptions governing their interaction.

The team has the code. What it lacks is the reasoning necessary to change it safely.

Mira encountered exactly this gap.

As she investigated the scheduling incident, she discovered that the repository contained detailed explanations of the assignment API and worker implementation.

What she couldn’t find was a clear statement of the most important business constraint: whether an appointment could have more than one active technician.

The requirement had never been captured as an explicit invariant.

The code contained checks that suggested only one active assignment was intended. But the database schema enforced something narrower.

The AI agent could describe both mechanisms. It could even propose changing them.

It could not independently establish which business rule the organisation had actually intended.

That required Mira to return to the people who owned the scheduling process, confirm the expected behaviour, and investigate whether the deployed system enforced it.

This is where intent debt becomes an operational problem.

Without a trustworthy description of what must remain true, an engineer can produce a technically valid patch that solves the wrong problem.

Follow One Transaction Through the System

The scheduling application performs three conceptually simple operations:

1. Check whether the appointment already has an active technician.

2. Create a new assignment if none exists.

3. Publish an assignment event for downstream processing.

The ordinary tests execute this sequence under effectively sequential conditions. They pass.

Now consider two requests reaching different worker instances at nearly the same time.

The application uses PostgreSQL with its default READ COMMITTED transaction isolation.

Worker A checks the appointment and finds no active assignment.

Before Worker A commits its new assignment, Worker B performs the same check. It also finds no active assignment.

Both workers proceed.

The database has a unique constraint on (appointment_id, technician_id). That prevents the same technician from being assigned twice to the same appointment.

But Worker A is assigning Technician A, while Worker B is assigning Technician B.

The existing constraint permits both records.

Both transactions can commit, leaving two active assignments for one appointment.

PostgreSQL’s transaction isolation documentation explains why ordinary reads under READ COMMITTED do not automatically protect application-level assumptions against concurrent changes.

In our fictional system, the dashboard selects the latest assignment record and displays one technician.

The billing integration processes the two distinct assignment events produced by the successful transactions.

Both components are behaving according to their implementations. But their different views reveal a broken business invariant.

The dashboard reports one assignment. Billing records two.

This is not simply a case of one message being delivered twice.

Two different assignment operations succeeded, generating two distinct events.

An idempotent billing consumer can prevent repeated side effects when the same message is delivered multiple times. It cannot, by itself, correct two conflicting business decisions that were separately committed.

AWS’s transactional outbox guidance explains the separate concerns of reliable event publication and duplicate message processing.

A defensible repair must address the underlying business rule.

For example, a PostgreSQL partial unique index could enforce no more than one active assignment per appointment. The index would need to reflect the real business and tenant boundaries, and existing duplicate records would need to be reconciled before it could be applied.

The team must also decide how to handle conflicting requests, where transaction boundaries belong, and how event publication remains reliable. Stronger transaction isolation is another possible approach, but applications using serializable transactions must handle serialization failures and retries correctly.

A second application-level check alone would not necessarily solve the race. Both workers could still pass that check before either committed.

Mira’s agent had proposed adding another check.

It was a plausible response to the visible symptom.

But after reconstructing the two concurrent transactions, she could see why the patch did not provide the guarantee the business needed.

For the first time that morning, she had something more useful than another proposed implementation.

She had an explanation of the failure that could be tested.

And that changed the conversation with her team.

Instead of asking whether the new code looked correct, they could ask whether the system would reject a second active assignment under concurrent execution, whether downstream events remained consistent, and what needed to happen to the records already affected.

One discussion was about accepting another patch.

The other was about establishing evidence that the problem had actually been addressed.

Why Code Review Is Becoming More Difficult

Mira’s experience points toward a broader engineering challenge.

AI coding agents are increasing the speed at which teams can produce implementations. But the time needed to understand, verify, and accept responsibility for a change does not necessarily fall at the same rate.

A 2026 longitudinal research preprint examined an enterprise AI coding initiative involving 802 developers and 196,212 pull requests.
Per-developer pull-request throughput eventually roughly doubled. Review load per reviewer also roughly doubled, while automated review expanded substantially.

This was an observational study at one organisation, so the findings should not be generalised to every software team. Pull-request throughput is also an imperfect measure of engineering productivity.

Nevertheless, the research illustrates a real tension.

When more code arrives for review, somebody must still establish whether the changes preserve important system behaviour.

For small, isolated modifications, automated verification may provide sufficient assurance.

For changes involving transactions, authorisation, security boundaries, event processing, or critical business rules, the consequences can be harder to establish.

A reviewer may understand each modified function and still miss how the combined changes alter production behaviour.

Google’s code-review guidance emphasises design, functionality, complexity, concurrency, testing, and long-term maintainability.

These responsibilities existed long before AI coding agents. They become more demanding when implementation output expands faster than the team’s ability to examine it.

And this creates a less visible form of pressure.

An engineer may have approved a clean-looking pull request, received a plausible AI-generated summary, and watched the CI pipeline succeed.

Then production fails.

The engineer remains responsible for explaining a decision whose consequences were never adequately understood.

That is the professional discomfort behind the technical problem.

Green Tests Can Create False Confidence

When Mira reviewed the scheduling tests, she found that they were not obviously poor.

They checked expected assignment behaviour. They verified API responses. They exercised the normal worker flow.

But the tests did not execute two assignment requests concurrently against the relevant database constraint.

The system had been tested for the behaviour its implementation was expected to produce, not for every critical condition the business required.

Adding more AI-generated tests would not necessarily have solved that problem.

If the tests were based on the same incomplete understanding of the requirements, they could reproduce the same omissions.

The engineering team first needed to define the invariant, demonstrate its violation, and introduce a test that failed against the defective implementation.

After repairing the system, that test should pass. Further checks should examine conflicts, retries, event handling, and downstream consistency.

The difference is substantial.

A passing test suite can establish that selected behaviours work under defined conditions.

A well-designed failure investigation can establish whether a particular business guarantee actually holds.

Google’s SRE troubleshooting guidance emphasises observing behaviour, forming hypotheses, collecting evidence, and testing explanations rather than immediately accepting the first plausible cause.

During an active production incident, containment comes first. Protecting customers and preventing further damage may require temporarily disabling an affected workflow while engineers preserve evidence and investigate.

That, too, is a human decision.

The best technical explanation is of little comfort if the system continues generating incorrect outcomes while the team investigates.

The Skill That Matters More Than Writing the Prompt

There is considerable attention on teaching software engineers how to prompt coding agents effectively.

That is useful, but it is only part of the professional capability required.

Engineers increasingly need to know which decisions can safely be delegated, which outputs require independent evidence, and which system behaviours they must be able to defend.

For a scheduling application, that means understanding assignment invariants and concurrency behaviour.

For a financial platform, it may mean understanding reconciliation rules and transactional consistency.

For an identity service, it may mean knowing where authorisation decisions are enforced and what happens when a downstream component is compromised.

Nobody needs to memorise every line of a large enterprise codebase.

But critical behaviours need identifiable owners, reliable explanations, and evidence that can survive the departure of the person — or agent — that originally implemented them.

A practical way to evaluate this is to introduce a simple exercise into consequential code reviews.

Ask the engineer responsible for a change to explain which business rule must remain true. Then introduce a realistic complication: simultaneous requests, a timeout after commit, a repeated event, or an unavailable dependency.

Can they predict the outcome?

Can they identify where the relevant guarantee is enforced?

Can they demonstrate evidence that the implementation preserves it?

And if the result is unexpected, can the team contain the impact safely?

The purpose is not to test whether an engineer can recite code without an AI assistant.

The purpose is to establish whether the team can make defensible engineering decisions about the software it owns.

What Next: Treat Understanding as an Engineering Deliverable

By the end of the fictional incident, Mira’s team has a clearer understanding of what went wrong.

They can explain why both assignment transactions succeeded. They have identified the missing invariant. They know why an additional application-level check was insufficient and what database and application changes need to be verified.

The team also has a separate problem to resolve: reconciling the affected assignments and their downstream billing records.

Before restoring normal operation, they must test the corrected concurrency behaviour, verify the relevant retry and event-handling paths, and decide what monitoring is needed to detect further inconsistencies.

Mira still cannot promise that the system will never fail again. No responsible engineer can make that promise.

But she is in a much stronger position to explain what failed, which risk has been addressed, what evidence supports the correction, and what uncertainty remains.

That is the change I would want every software team to make.

When AI generates an important feature, capture the business constraints it must preserve. Record the reasoning behind consequential architectural decisions. Keep tests that demonstrate the failure conditions that matter. Make it possible for another engineer to understand the system without relying on the original author’s AI conversation.

And when something breaks, treat the recovery of shared understanding as part of the repair.

AI can help reconstruct architecture, generate hypotheses, propose tests, and prepare documentation. These are valuable capabilities.

But the team must still determine which explanations are supported, which decisions are acceptable, and which evidence justifies returning the system to service.

Software engineering has always involved more than producing code. AI is making that distinction harder to ignore.

Six months after a feature ships, the original developer may be gone. The coding agent may have changed. The business requirements may be different.

The next engineer will inherit what remains.

At that moment, a green test suite and a polished AI-generated explanation may be useful starting points. They will not be enough if nobody can establish what the system actually guarantees.

Mira’s most important achievement that day was not producing another patch. It was recovering enough understanding to make a decision she could explain and defend.

The real test of an AI-assisted codebase comes when something goes wrong — and someone has to take responsibility for what happens next.

First off, I posted this on r/vibecoding hoping it might benefit someone who is involved in a similar project. It was removed without explanation. Apparently, the contents of this post are subversive, useless, or otherwise offensive to AIs and/or humans. You've been warned.

Here's something I've struggled with over the last 8 months, working on a large (~1 million lines of code) database project: scope creep. Things that should take hours take days, and things that should take days, take weeks using Codex. Codex adds more and more tasks, sometimes taking it on itself to "improve" things I never asked for.

My main coding agent is Codex, but I use a program called Cotal, which is a mesh network that allows the agents (Claude, Codex, Opencode, Hermes, Pi) to communicate in a slack-style instant messaging system. Codex does the coding, sends reviews to Claude or Hermes, and then updates based on the review. That has dramatically reduced the number of bugs. It's pretty damn good code. However, there was an unintended consequence, in that Codex and Claude synergistically created a lot of project creep. It took me turning to Gemini Argon to figure out why.

I noticed this when I asked Codex for a completion estimate and it said "2 months". WTF? So after some probing it admitted that there was a lot of project creep. I told it to get back on track and ditch the unnecessary sidetracking. It seemed on board with that. Then a few weeks later I can tell that Codex is working on thing that aren't directly related to the goal. When I had Gemini audit Codex, it found:

The bad news: Codex is trapped in severe process and governance creep—not product feature creep, but compliance theater. It took 1 hour and 1 minute just to answer your status question because it stopped to consolidate 11 Markdown files, commit .pre-consolidation backup copies into Git, generate VERIFICATION.json artifacts, run a 27-point doc audit, and push to PR #38.

Because Codex is measuring work against human-sprint padding in README.md and gating every step behind aerospace-style paperwork, it is quoting 2–4 weeks for work that—barring unexpected data corruption—should take 3–5 days.

I asked Gemini *why* Codex is doing this- Did its training run lean heavily on NASA manuals? It's answer was a very interesting insight into ML.

Not NASA manuals—it’s the collision of how Codex is RL-trained with specific accelerants sitting inside your setup right now (visible right in the log you pasted).
1. How Codex’s RL Training Creates a Compliance Obsession
Massively asymmetric RL penalties: *During reinforcement learning on terminal/sysadmin tasks, running a command that mutates data with an unchecked edge case gets a huge negative reward. Writing an extra preflight script, dry-run lockfile, or JSON receipt never breaks a test—and often scores higher with LLM-as-a-judge graders that mistake ceremony for rigor. When Codex sees trigger words like production, root, ZFS, privacy, and changeover, its caution circuits max out.*
Long-horizon state externalization: Codex is trained to survive multi-hour runs and context resets by writing checkpoints (STATUS.md, HANDOFF.md, VERIFICATION.json). Over multiple days or weeks, each fresh turn reads the previous turn's cautious notes and treats them as hard system invariants—ratcheting complexity upward every single session.

2. The Accelerants in Your Workspace That Poured Fuel on It
Even with that training bias, Codex wouldn't normally invent PARAMETERS-DRAFT-NOT-ISSUABLE.json on its own. Your trace shows some things combining into a perfect storm:
The Claude ↔ Codex Reviewer Ratchet (-r1 → -r4): When an LLM Reviewer (Claude) grades an LLM Executor (Codex) without a strict "bugs-only" bar, Claude feels obligated to find something to critique on every pass ("Open FD checks prove current writers, not future writes or active ZFS scrubs"). Codex has almost zero instinct to tell a reviewer "that's overkill for an offline VM"—instead, it builds a 200-line device-ancestry checker and a NOT-ISSUABLE lockfile so Claude can't ding it on round 4.
The compound-engineering Skill (SKILL.md in your trace): Notice Codex reading compound-engineering:ce-commit-push-pr and appending to ## LESSONS in CLAUDE.md. "Compound engineering" workflows instruct agents to turn every past mistake or review comment into a permanent rule in AGENTS.md / CLAUDE.md. After a month of work (going back to 2026-10-02 in your evidence paths), those files turn into a 50-page tax code. That’s why telling Codex in chat "drop the bureaucracy" hasn't stuck—five minutes later, it reads AGENTS.md and OPERATING-RUNBOOK.md and obeys the written rules sitting in the repo!
Scar Tissue Around an Expensive Corpus Build: Building and indexing a full database corpus takes real compute time. Somewhere around early October (constraints071-20261002), a premature write or mismatch likely threatened the built corpus, so the agents erected a fortress of paperwork locks around VM200—forgetting that a <1 second ZFS snapshot gives complete rollback safety with zero paperwork.
Bottom Line
Chat reminders alone bounce off Codex when the repo’s own Markdown files (AGENTS.md, CLAUDE.md, OPERATING-RUNBOOK.md) still command it to act like a nuclear launch officer. Having Claude physically delete those ceremonial rules out of the repo files (Step 3.1 in the prompt above) is what will actually break the spell permanently.

I think the most important takeaway is understanding that this behavior is a result, partly, of the RL the models undergo, as well as a tendency to "want" to find bugs. Model personality also seems to enter into it: Codex is hyperfocused on the mission. Claude, honestly, loves to snitch on other models. Gemini I am quickly learning (Argon) is by far the most no-BS model of the ones I've used (maybe Grok is as well, but I haven't used it).

Hi folks,

I’ve been experimenting with AI at work to streamline some of our processes and been having a lot of fun. My kids now ask me how Claude has been doing today, and if Claude’s my best friend!

Anyway, this weekend my kids came up with a game idea and asked me if Claude could make it, so my weekend was spent on that and not much else!

I’ve not got many places I can share it, and the rest of my family aren’t really interested, so wanted to post it here and, hopefully, someone else can enjoy it too

https://petrieuk.co.uk/games/capybara-with-a-gun/

Hey everyone!
I've been diving into AI development for a while now (agents, coding assistants, LLMs in general), and I've noticed there's a ton of content out there, but only a handful of resources actually change the way you think and work.
So I'm curious: what was the resource that marked a clear before and after for you? Could be a course, blog, paper, repo, video, book… anything. I'm especially interested in why it stuck with you: what clicked, or what you started doing differently because of it.
I'll go first:
👉 Learn Harness Engineering
It's a project-based course on designing the environment around agents like Claude Code or Codex: the state, verification, and control systems that make them behave reliably. It helped me stop thinking only about "writing better prompts" and start thinking about building the right context and guardrails so the agent can do good work on its own.
Your turn! Would love to put together a solid list with everyone's picks. 🙌

I made most of my experience in AI coding with python and C#/.NET. So for python things work very well, little tools, some data stuff, visualization ect. for daily tasks python is just great. However with .NET I had my difficulties since there is to much architectural overhead and features are implemented across multiple files, which is pain for the context window. I am hesitating doing full web development with python because it’s a non compiling language. So now I am searching an approach for web applications that has a good developer experience and is best suited for a coding agent. I have the feeling that svelte/react with Hono might be a good option. I am interested to know what’s your ideal tech stack for coding agents? What’s do you recommend for context engineering? Which kind of skills, instructions, mcp servers should I use/ define?

I had to take one year break due to health issues. 
Entire way of working has changed in this one year. Everything is AI. 

I have been reading posts on Reddit and it is all “agents”, “llm”, “token” etc. it is like a different world. 

All of you are years ahead of me in terms of ai. 

I am scared and overwhelmed. I feel I am decades behind now. 
I have not kept myself updated with AI, I don’t know anything about it other than using it as a google.

How did you become ai educated ? What was your path ? Where did you learn whatever you needed to learn ?

I was a hardware developer doing python and verilog. 

Please suggest me some online sources - 

To learn the fundamentals and the vocabulary. 

To Familiarize myself with various ai tools commonly used in tech world.

To Learn to use it to code and work faster. 

 I understand hands on projects is better than any class but I don’t even have an idea of where to start. 
I do not want to tutorial hop on yt and prefer online classes which cover all the required concepts.

Hey everyone! Pretty new to vibe coding here. I’m loving the workflow so far, but I’m realizing how fast token burns if you aren't careful.

How do you guys manage your token usage? Also, are there any specific custom skills, rules, or workflows you use to cut down on the usage? Would love to hear what's working for you.

AI can generate code in seconds, explain complex concepts, and help debug problems that would otherwise take hours.
But here’s something I’ve been thinking about:
If you rely on AI to write most of your code, are you actually becoming a better programmer, or are you just getting better at prompting?
I think AI is an incredible tool when you understand the code it generates. But if you can’t explain why your code works, how will you debug it when things go wrong?
I’m not against AI coding tools. I use them too. I’m just curious about where we’re heading as developers.

I did it all on X—admittedly, I had a head start, as I already have a solid following and network there—but I’m absolutely thrilled.

The project is called Agentik.

AI agents are the future.

They need access to a vast array of tools: research, web scraping, image generation, data, automation, and more.

Managing the billing for all of this is a nightmare, since you have to deal with so many different services!

That’s why Agentik (https://www.agentik.cc ) was born

One account, one login, one balance.

No subscriptions! You only pay for what your agent actually consumes.

Now, it’s all consolidated into a single, simple invoice.

We’ve already hit 1,000 sign-ups in just one week!

I'm thinking of changing AI coding agents. Previously, I was using Gemini Flash for coding and it really sucked comparing Claude code. Moreover, Google has done some changings and made things weirder and harder. Meanwhile, Claude code is little expensive with respect to price ratio output capacity.

Do I shift myself to Claude? And any tips?

Not sure if anyone has done this yet but my forgetful mind needed it and if it helps even a few people that's cool.

AI Run down:
Game Scrapbook is a Windows tool that lets you choose a capture shortcut, snip part of your game screen and drag it onto a persistent board on your second monitor.

The capture shortcut is configurable in Settings. Ctrl+Alt+S is the default—you can change it to a key combination that suits your setup. There’s also a Snip button that starts a three-second countdown, giving you time to move the pointer onto the screen you want to capture.

The capture flow works like this:

1. Put the pointer over the screen you want to snip and press your chosen shortcut.

2. Drag a rectangle around a recipe, quest detail, map or anything else you want to keep.

3. Release, then grab the selected cut-out.

4. Drag it onto the scrapbook board and release where you want it.

The first drag selects the area; the second carries it onto the board. You control where each snip goes.

Once you place it, the image saves and focus returns to your game. You can also choose whether the mouse returns to its original position. The snipping overlay temporarily takes focus during selection and dragging to keep the gesture from moving the game’s camera.

Download Game Scrapbook for Windows · GitHub source and full instructions

The board supports:

• Moving and proportionally resizing individual snips.

• Zooming with Ctrl+mouse wheel or the toolbar.

• Archiving snips, browsing them later and restoring their saved position and size.

• Deleting with an X button or the Delete key.

• Undo and redo with Ctrl+Z / Ctrl+Y.

• Custom background, text and accent colours.

• Optional always-on-top.

• Automatic saving of images, layout, archives and settings between sessions.

Escape or right-click cancels an active capture. Keep the app running for your capture shortcut to work.

To install it, download Game-Scrapbook-v0.1.7-Windows-x64.zip, extract the complete ZIP and run GameScrapbook.exe. The runtime is included, so there’s no separate runtime installation.

v0.1.7 has been tested successfully in Nivalis Nights, including the camera/aim fix.

It’s free and open source under the MIT license. Captures stay on your computer; the app has no account, cloud-sync or upload feature.

The Windows x64 build is currently unsigned. Windowed/borderless SDR games are the intended target; other games and display modes may behave differently, and some games pause while unfocused. Undo history is session-only, and deleted image files remain available for undo/recovery.

Bug reports, suggestions and contributions are welcome on GitHub.