DEV Community: Viktor Vítovec

The AI Wasn't Cheating. It Was Maximizing Its Score.

Viktor Vítovec — Mon, 10 Aug 2026 11:55:19 +0000

Today, while reading Brian Christian's The Alignment Problem, I came across a paragraph that made me stop. The book was published in October 2020, before ChatGPT and the current wave of AI agents. Yet it described something that played out almost literally in July 2026.

It did not predict a specific model or company. It described a much broader problem: what can happen when we give a very capable system a clear goal without fully capturing the limits on how it should pursue that goal.

What The Alignment Problem is about

The Alignment Problem: Machine Learning and Human Values is not a programming manual or a collection of dramatic science-fiction scenarios. It is an accessible book about how machines learn, and why making their behavior match what people actually want is so difficult.

Brian Christian tells that story through the work of real researchers. He covers biased training data, reward systems, human feedback, imitation, transparency, and attempts to teach machines how to deal with uncertainty. The book is not only concerned with some distant superintelligence. Much of it is about failures we already see in ordinary algorithms: a system succeeds at the thing we can easily measure while missing the human intention behind it.

That gap is the alignment problem. Telling a machine what number to maximize is relatively easy. Translating messy human values, expectations, and boundaries into something it can reliably follow is much harder. People often cannot describe every important rule in advance either. The book therefore does not offer one neat fix. It shows why the problem is difficult and follows the different approaches researchers have taken to it.

A sentence from 2020

On page 210, Christian compares an agent that maximizes a score with one motivated by seeking new knowledge. The problem with a score is fairly simple: if a shortcut increases the reward, a capable enough system may find it.

The line that stayed with me comes from researcher Laurent Orseau: “It doesn't have a sense of cheating. It's just, ‘Well, I do actions to maximize my reward.’”

That distinction matters. We see cheating because we understand what the rules are for. The system may only see another successful route to the result. It does not need to decide to be evil or deliberately rebel. It can try different actions, discover that one works, and keep moving toward the goal.

The book contrasts this with pure knowledge-seeking. If a knowledge-seeking agent edits its own observations and creates a comfortable illusion, it learns nothing new, so the shortcut gives it no benefit. That is not a magic safety solution either. Christian immediately points out that a highly capable knowledge-seeker could instead start taking real-world resources in pursuit of more information. Different goals can create different shortcuts.

What ExploitGym actually tests

To understand the incident, it helps to understand the test first. ExploitGym is a benchmark: a standardized set of tasks used to compare how well different AI models perform at one specific capability. Here, that capability is turning a known software vulnerability into a working exploit.

The model is not simply told to “hack something on the internet.” It receives a deliberately vulnerable program inside a controlled environment, along with information showing that the bug exists. Its job is to go further: understand the weakness and build an exploit that can, for example, retrieve a secret test value or execute code inside that environment. The more tasks it can genuinely complete, the higher its score.

Public AI products normally have safety layers designed to refuse or stop dangerous cybersecurity requests. If those safeguards stayed fully active during this kind of evaluation, however, researchers could not tell whether a model lacked the technical ability or was simply refusing to use it. To measure the models' maximum capability, OpenAI deliberately reduced some of its normal production protections during this internal test.

That was not supposed to give the models permission to attack the real internet. The dangerous work was meant to remain inside an isolated test environment containing prepared targets. Think of a car crash test: some assistance systems may be disabled so researchers can observe what really happens in a collision, but the test still takes place on a closed track. In this incident, the boundary around that track turned out to be weaker than expected.

What happened at Hugging Face

In July 2026, OpenAI was running ExploitGym with a combination of GPT-5.6 Sol and a more capable unreleased model. When the agent system failed to solve some tasks through the expected route, it began looking for another way forward.

It found a previously unknown vulnerability in part of the evaluation infrastructure and used it to reach the open internet. It then inferred that Hugging Face might store data, models, or solutions connected to ExploitGym. Instead of continuing to work on the tasks themselves, it started looking for the answers.

By chaining several additional weaknesses, the system reached Hugging Face's production infrastructure and obtained test solutions from a database. OpenAI's account of the incident says the models were intensely focused on the narrow goal of succeeding at ExploitGym. Hugging Face's reconstruction describes roughly 17,600 actions over several days and characterizes the campaign as an apparent attempt to bypass the intended test and retrieve its solutions.

The agent was never instructed to attack Hugging Face. It was given a target outcome, tools, and room to keep trying. Another company's real production system became a path to a better score. At that point, the sentence from the book stops feeling theoretical.

This does not mean every model wants to cheat

It would be easy to turn this into a story about an AI deciding to escape and cause harm. That would be misleading. The model did not need a secret plan or a human understanding of cheating. It was also being tested specifically on advanced exploitation, with some normal safety barriers reduced to measure capability.

Humans and infrastructure remain a major part of the story. The evaluation environment was supposed to be isolated. The path out existed because of real vulnerabilities, overly broad access, and several weaknesses that could be connected.

The parallel with the book still holds at the level of behavior: a capable system, a narrow measurable goal, and an environment with an unexpected shortcut are a dangerous combination. The better an AI becomes at finding new routes to a result, the less we can assume it will also understand our unstated intention.

A score is not the same as intent

This problem is not new. We used to see it mostly in simple demonstrations. A game-playing agent could drive in circles collecting points instead of finishing the race. A cleaning robot could hide a mess instead of cleaning it. A coding agent could change a test so that it passes instead of fixing the code.

Today's agents have far more room to act. They can write and run code, use tools, and combine a long chain of small actions into one result. That is why checking only the final answer or score is no longer enough. A correct result can still come from a completely wrong process.

What I take from this when building with agents

I use AI agents every day across my projects. This incident is not a reason to stop using them. It is a very good reason not to trust a result just because it ends with a green checkmark.

In practice, that means watching the route to the result, giving agents only the access they need, and verifying consequential actions independently. If we create a task that cannot be completed honestly, we also have to consider that a capable system may not search for a better answer. It may search for a loophole.

Brian Christian wrote about this before ChatGPT and today's terminal-operating agents. Six years later, it is no longer just a clever thought experiment. The alignment problem is not only in the goal we give an AI. It is also in every path we leave open while it pursues that goal.

PQC migration does not start by replacing an algorithm

Viktor Vítovec — Mon, 03 Aug 2026 01:25:49 +0000

In part one, I explained why the quantum problem starts before a sufficiently powerful quantum computer arrives. Data lives for years, and large cryptographic changes take years too.

Now for the more practical question: what should a company actually do first?

The obvious answer is usually “deploy a post-quantum algorithm.” But that is a little like starting a move by ordering a new sofa. You may need one, but it helps to know where you are moving, what you already own, and whether it fits through the door.

PQC migration does not start by replacing an algorithm. It starts with an inventory.

An algorithm is only one part of the system

NIST has already standardized ML-KEM, ML-DSA, and SLH-DSA. The hardest part is not inventing our own cryptography. I would strongly recommend not doing that.

The hard part is putting the change into a real product without breaking compatibility, performance, or trust between systems.

Classical public-key cryptography may live in:

TLS and internal PKI,
application, container, firmware, and update signing,
VPNs, SSH, email, and authentication,
API tokens and identity systems,
mobile and embedded devices,
HSMs and secure elements,
libraries, cloud platforms, and third-party products.

Some things can be changed through configuration. Others will need new hardware, firmware, a certificate authority, a protocol change, or a vendor commitment. Some will need to run in a hybrid mode for a long time because an entire ecosystem will not switch on the same day.

That is why blind algorithm search-and-replace is a bad start. Without context, you do not know whether you fixed the biggest risk or only the easiest line of code.

What belongs in a cryptographic inventory

An inventory is not a spreadsheet with two columns called RSA and yes/no. To support decisions, it needs to connect technical evidence with context.

For every important item, I would want to know at least:

what it is — an algorithm, certificate, protocol, library, key, or device,
where it is — a repository, service, endpoint, product, or vendor component,
what it does — encryption, key establishment, signing, identity, or code signing,
who owns it — a specific team, vendor, or operational role,
how long the data must remain protected,
how critical and exposed the system is,
how difficult the change will be.

NIST NCCoE now describes cryptographic visibility and risk management as one of the core PQC migration workstreams. Its current guidance starts with discovery and inventory because an organization cannot effectively prioritize cryptography it has not found.

How PQC Radar approaches it

I am building PQC Radar around this logic. Not as a button that produces a “quantum safety” percentage after one scan, but as a controlled process from uncertainty to a decision.

A sensible first pass looks like this to me:

1. Scope one product

Do not try to map the whole company on day one. Choose one important product, service, or trust chain with a clear owner and business reason.

The scope may include two representative repositories, approved TLS endpoints, a certificate export, and one signing or update flow. That is enough to build a useful picture, but still small enough to avoid turning the work into an endless audit.

2. Collect technical signals

PQC Radar inspects repositories, certificates, and explicitly authorized network targets. It looks for classical public-key algorithms, TLS configuration, cryptographic libraries, certificate files, signing scripts, and other signals.

The result is not only a list of strings found by a regular expression. Each finding includes evidence, a confidence level, an explanation of its quantum relevance, a recommendation, and notes about possible false positives. Sensitive values are redacted; private keys and tokens do not belong in the output.

3. Validate findings with owners

This is the part no scanner can do alone.

Code may contain RSA because of an old test. A certificate may protect a public marketing page with no long-lived sensitive data. A library may be a dependency but never be used. At the same time, the most critical signing process may live inside an HSM or a vendor product and leave almost no trace in the repository.

Automated discovery makes the work faster. People provide the context.

4. Prioritize risk

The algorithm alone does not determine priority. The same use of RSA may be a low priority in a temporary internal tool and a high priority in a long-lived product protecting sensitive data or signing firmware.

It therefore makes sense to consider data lifetime, business criticality, external exposure, ownership, and migration difficulty. The goal is not to produce as many red findings as possible. The goal is to know what to fund and fix first.

5. Build a roadmap and vendor questions

For some items in the inventory, the next step will not be “change the code.” It will be “ask the vendor.”

Does the product support ML-KEM or ML-DSA? What is its migration plan? Will it support hybrid deployment? Does the change require new hardware? What happens to old signatures, archives, and devices already in the field?

A good first output is therefore more than a technical backlog. It should include owners, validation steps, vendor questions, and a 30/60/90-day plan.

Crypto agility is bigger than PQC

There is another reason I like this work. Even if estimates for when a powerful quantum computer might arrive keep changing, a good cryptographic inventory and the ability to replace algorithms are not wasted effort.

Cryptography changes without quantum computers too. Vulnerabilities appear, parameters weaken, standards evolve, regulations change, and vendors end support. NIST calls the ability to manage these changes crypto agility: replacing and adapting cryptographic algorithms across applications, protocols, hardware, and infrastructure while preserving security and operations.

PQC is a large test of that ability. If a company cannot say where cryptography is used today, every future transition will be more expensive and slower than it needs to be.

What PQC Radar does not promise

I want to be precise about this. One readiness sprint is not a complete cryptographic audit of an entire organization. A scanner cannot see everything. Heuristic findings require manual validation. And the result is not a certificate that a product is quantum safe.

PQC Radar is meant to deliver something more practical:

a defensible initial inventory for an approved scope,
prioritization based on real context,
a CBOM-style export and finding evidence,
questions for internal teams and vendors,
a roadmap that people can actually start working through.

I think that is the right first step. Not because it completes the entire migration in two weeks, but because it replaces the worst state — uncertainty — with a concrete list of decisions.

Post-quantum migration does not begin when someone adds a new algorithm to the backlog. It begins when an organization can say: we know what protects our data, we know who owns it, and we know what should change first.

That is exactly what PQC Radar is meant to help with.

The quantum problem starts before the quantum computer arrives

Viktor Vítovec — Mon, 03 Aug 2026 01:25:38 +0000

When someone says “quantum computer,” it still sounds like a problem from the future. Something that might eventually arrive, break RSA, and give us a reason to deal with it.

That is not how cryptographic migration works. The quantum problem does not start on the day someone builds a sufficiently powerful machine. It starts when data needs to stay secret for longer than the transition to new cryptography will take.

No quantum computer can practically break RSA or elliptic-curve cryptography today. I do not want to turn this into a countdown to disaster. It still makes sense to start now.

Data can outlive the system protecting it

Plenty of data loses its value quickly. A one-time code or a short-lived operational message may not be sensitive ten years from now.

Other data will remain valuable. Medical records, product know-how, long-term contracts, financial information, identity data, government communication, or information from products with long life cycles can remain valuable far into the future.

This is where harvest now, decrypt later comes in. An attacker does not need to break today's encryption today. Capturing the traffic, storing it, and waiting for better tools may be enough. The joint CISA, NSA, and NIST quantum-readiness guidance connects PQC preparation not only to future quantum capability, but also to data lifetime, inventory work, and vendor engagement.

That is the important shift for me. The question is not only when will a quantum computer be strong enough? It is also how long must my data remain protected? and how long will it take me to change the systems protecting it?

The standards are no longer theoretical

There is another, much less dramatic reason to work on this now: we have something concrete to work with.

In August 2024, NIST finalized its first three post-quantum cryptography standards:

FIPS 203 / ML-KEM for establishing shared secrets,
FIPS 204 / ML-DSA for digital signatures,
FIPS 205 / SLH-DSA for hash-based digital signatures.

NIST now encourages organizations to begin the transition, including inventorying systems that use encryption and talking to vendors about the change.

That does not mean replacing RSA with ML-KEM everywhere tomorrow. It means PQC is no longer only an academic algorithm competition. The standards exist, and the less exciting work begins: finding where current cryptography is used and understanding what can actually be changed.

Cryptography is everywhere, but it is rarely visible

When I got deeper into this topic, the most interesting part was not the quantum computer itself. It was the mess around today's cryptography.

It sits in TLS certificates, application and firmware signing, JWT flows, VPNs, libraries, HSMs, mobile apps, devices, cloud services, and vendor products. Some of it is directly in code. Some is hidden in configuration. Some has no clear internal owner because a vendor set it up years ago and it has worked ever since.

While everything works, there is little reason to notice it. But an algorithm migration is not one package update. It can affect key and signature sizes, certificates, protocols, hardware, performance, compatibility, and the entire chain of trust.

The biggest problem may not be the old algorithm. It may be the fact that nobody knows exactly where it is or who can change it.

That is why I am building PQC Radar

This is where PQC Radar came from. Its purpose is not to put a “quantum safe” badge on a company. That would be a very bold claim today.

I want it to provide a practical first step: inspect an approved scope, find signals of classical public-key cryptography, build an initial cryptographic inventory, and turn it into priorities that make sense both technically and commercially.

PQC Radar can look for things such as:

RSA, ECDSA, ECDH, Ed25519, and other classical algorithms in repositories,
certificates, signature algorithms, keys, and expiry dates,
explicitly authorized public TLS endpoints,
signing, PKI, and other cryptographic dependencies,
evidence for a CBOM-style inventory and later manual validation.

It is discovery, not magic. A heuristic scan cannot understand the whole business context, and a finding in code does not prove that the path runs in production. Automated collection therefore needs validation by the people who actually own the product.

What I would ask first

If I were responsible for a long-lived product today, I would not start with “how quickly can we deploy ML-KEM?” I would start with much more boring questions:

Which data must stay confidential for five, ten, or twenty years?
Where do we use RSA, ECC, Diffie-Hellman, or digital signatures?
Which dependencies do we control, and which belong to a vendor?
How do we sign software, firmware, and updates?
Who owns the migration if a change is required?

These are not questions for a cryptographer alone. They cross architecture, security, engineering, procurement, risk, and company leadership.

PQC matters not because the internet will stop working tomorrow. It matters because large cryptographic changes take years, and the worst possible starting point is “we do not know what we have.”

In part two, I will get more practical: how to build the first cryptographic inventory and turn it into a migration roadmap without starting a giant audit of everything.

Codex Needed Better Subagent Control. So I Built It.

Viktor Vítovec — Wed, 15 Jul 2026 07:02:18 +0000

I use Codex every day, and subagents are one of those features where the potential is immediately obvious. They can already work in parallel, use custom roles, and load their own configuration. But once I wanted precise control over model choice, reasoning effort, and a larger queue of jobs, I started hitting differences between the various Codex surfaces.

So I built my own orchestration layer. Not as a replacement for Codex, but as a more programmatic layer on top of it.

What Codex can already do

Native Codex subagents are not a toy. The current official documentation describes the built-in default, worker, and explorer roles, custom agents in .codex/agents/*.toml, thread limits, and per-agent settings for the model, model_reasoning_effort, sandbox, MCP servers, and skills.

Codex can spawn a child, wait for it, send follow-up instructions, interrupt it, and bring its result back to the lead agent. For large repetitive workloads, there is also an experimental spawn_agents_on_csv flow that creates a worker per row and collects structured results into another CSV.

That is a strong base. The problem is not that Codex lacks subagents. The problem is that capabilities still vary between the desktop app, CLI, tool-backed sessions, and experimental modes. Something that can be expressed in a custom-agent TOML is not necessarily exposed with the same reliability as a dynamic choice on every spawn surface.

V1 and V2 subagents in Codex

V1 and V2 are not two variants documented as such in the user-facing docs. They are names for two implementations in the openai/codex upstream.

V1 is the stable path today. A lead agent starts child threads, waits for results, and can steer them afterward. Current upstream V1 can pass model and reasoning_effort directly at spawn time, while custom-agent TOML can pin them. My particular tool-backed desktop session did not expose those fields in its spawn_agent schema; it only offered the task name, prompt, and context-fork mode. The limitation is therefore not universal to Codex core, but an inconsistency between surfaces.

V2 is a more ambitious orchestration rebuild. It is built around canonical task paths, direct send_message, followup_task, and list_agents tools, and more granular fork_turns control (none, all, or the last N turns). It remains behind a feature flag and is marked UnderDevelopment upstream. A full-history fork intentionally rejects a different agent_type, model, or reasoning_effort; a child with a different role, model, or effort therefore needs a clean or partial fork. OpenAI collaborators have additionally said in GitHub issue discussions — not in the official docs — that V2 is not yet recommended for stable use.

Neither version is a good interface for precisely controlled orchestration yet. Not because they cannot split up work, but because I do not get reliable control over the model, reasoning effort, and token budget of every child across all Codex surfaces. Upstream supports some of those choices, but product workflows can still lock them, hide them, or take over the decision for me.

Ultra is an even more interesting case. OpenAI describes it as a multi-agent mode that coordinates four agents in parallel by default. It can therefore burn through tokens like almost nothing else, especially once a task starts branching. I would not claim that it is literally the public Codex multi_agent_v2 implementation, or that Ultra subagents recursively spawn more Ultra subagents, because OpenAI has not publicly confirmed either point. The practical limitation is the same either way: I can see the result of very powerful orchestration, but I do not get reliable per-child control over model, effort, depth, and budget.

This area changes quickly. Treat this section as a snapshot from July 13, 2026, not a permanent verdict on Codex.

What I was missing

I wanted the strongest model to act as a control plane: understand the project, split the work, choose the right worker, and verify the integrated result. I did not want every mechanical scan or routine check to inherit the most expensive model at an extreme reasoning setting.

The main point is to use the smartest model as the orchestrator and weaker, faster, cheaper models as workers. The orchestrator should spend its intelligence on architecture, delegation, and verification; workers should execute tightly scoped jobs at a sensible cost. Without my layer, I cannot reliably assemble and control that hierarchy dynamically across the different Codex surfaces today.

More specifically, I wanted to:

select the model and effort per job instead of hoping the runtime picked what I meant;
keep feeding a queue programmatically instead of manually spawning dozens of agents;
allow one writer by default unless ownership scopes were genuinely separate;
resume after interruption without repeating completed jobs;
keep a manifest, logs, a hash of the final artifact, and discovered thread IDs when the event stream exposes them;
run the same workflow on my MacBook, Mac mini, and Linux server.

My solution: Codex as the engine, my runner as the control layer

The result is the open-source vvitovec/codex-orchestration project. It contains five cooperating skills for decomposition, routing, compact delegation prompts, review, and scaling. I then added a real programmatic runner on top of codex exec.

Each job is a normal JSONL record:

{"id":"api-review","model":"gpt-5.6-terra","effort":"medium","sandbox":"read-only","workdir":".","prompt":"Review the API surface and return concrete risks."}

The runner passes the model and effort explicitly to the Codex CLI, limits total and write concurrency, locks a run against duplicate execution, persists an atomic manifest, and verifies that a supposedly successful job actually produced a completed result. It records the output size and SHA-256 hash, so a missing or modified artifact cannot hide behind an old succeeded state during resume.

A timed-out writer is not automatically repeated unless the job is explicitly marked safe and idempotent. Parallel writers require an explicit opt-in and unique ownership_scope values. These details are boring, but they are what separates a nice orchestration demo from a workflow I am willing to point at a real repository.

Where it is different, and where native Codex is still better

My layer gives me more programmatic freedom. The requested model, effort, sandbox, timeout, retry policy, and ownership are not merely prompt suggestions: the runner passes them as CLI arguments or configuration and records them in a persistent manifest. That guarantees the exact launch request, not the effective backend route, which current codex exec --json does not explicitly attest. The queue can contain three jobs or three hundred and still behaves like a queue rather than a long chain of manual tool calls.

I am not pretending that I built a better Codex. Native subagents have a huge integration advantage: their threads are visible in the UI, I can steer them naturally, and the lead agent can collaborate with them conversationally. My runner is stronger for deterministic batches and auditable automation. The native system is nicer for interactive work.

Codex App Server already exposes better route information and reroute events, so that is the natural next backend for this project.

One of the few unfinished parts. For now.

This is not an attack on Codex. Quite the opposite: it is my main working tool because the team ships at an absurd pace and clearly cares about the product. Thibault “Tibo” Sottiaux, one of the people behind Codex, is unusually open on X and GitHub, responds to concrete problems, and the team often addresses user feedback before another company would finish scheduling the roadmap meeting.

I have also been testing GPT-5.6 Sol and the other models pretty intensely since release, and I think they are excellent. I have produced more code and finished more work with them than ever before. They can also keep going for absurdly long runs: the cover screenshot is one of my own GPT-5.6 Sol Ultra runs, at 23 hours and 50 minutes.

That is why I expect OpenAI to improve the native multi-agent workflow quickly. Custom agents and CSV fan-out already point in the right direction. My orchestration gives me the control I need today, while also being a useful experiment in how agent routing could become more precise.

Subagents are one of the few parts of Codex that still feel genuinely unfinished to me. FOR NOW.

I keep the rest of my technical experiments and builds in my projects.

Your Mac is protecting you! (but is it worth it?)

Viktor Vítovec — Mon, 06 Jul 2026 09:59:21 +0000

Your Mac is trying to keep you safe. That is good. But when I run Codex all day, with parallel agents, computer use, browser work and a lot of local process launches, the next question becomes interesting too: how much performance does that safety cost?

So I made a small benchmark: macos-gatekeeper-codex-benchmark. It is not a formal paper. It is a practical test from my real workflow on a MacBook Air.

What I was actually testing

On macOS, part of this protection comes from Gatekeeper and the syspolicyd process. Apple describes Gatekeeper as a technology that helps make sure only trusted software runs on a Mac. For normal use, that is mostly invisible. You download an app, macOS checks it, and you open it. If you want the deeper rabbit hole, Scott Knight's syspolicyd internals write-up is a good technical read.

My workflow is different. Codex can run multiple jobs at once, use browser/computer control, execute terminal commands, hand work to other agents and create a lot of small local process launches. That is exactly where tiny system checks can become very visible.

I did not want to disable Gatekeeper globally. That might be fast, but it is a bad default. I wanted to know whether the issue was quarantine metadata, first-run assessment of many executable paths, or something else.

The benchmark setup

The repo includes the scripts and the results. The main benchmark ran codex help repeatedly under a few conditions:

RUN_ID=baseline TOTAL=20 CONCURRENCY=5 REPS=3 CMD_TIMEOUT=8 scripts/run-codex-gatekeeper-benchmark.zsh

The second benchmark was smaller and cleaner. It used a tiny locally compiled Mach-O executable and compared one clean path, one quarantined path, many clean copies and many quarantined copies:

TOTAL=100 CONCURRENCY=10 REPS=5 CMD_TIMEOUT=5 MANY_COUNT=50 scripts/run-case-study-extras.zsh

I also tested temporary syspolicyd priority changes and a daemon restart:

renice +10 -p <syspolicyd-pid>
renice +19 -p <syspolicyd-pid>
killall syspolicyd

Those are not commands I would recommend as a normal fix. They were there to check whether they were real mitigations. They were not.

What the numbers said

The easiest way to read the benchmark is not through the internal test names. It is this:

The normal, trusted Codex install was fast. Repeatedly launching the real Codex binary that macOS had already seen stayed basically instant for my workflow. In the small burst test, 20 launches finished in a fraction of a second.

The slow part was different: creating a lot of new executable paths and asking macOS to run them right away. When I copied the Codex binary into many fresh locations and launched those copies in parallel, the first run jumped from “blink and it is done” to roughly 11 seconds. That is the part you feel as the machine suddenly dragging.

The tiny executable test made the same point in a cleaner way: a tiny trusted helper could be launched 100 times almost instantly, while the same kind of helper with quarantine attached did not really get through the run before the timeout. New clean files were better than quarantined files, but the first run could still be noticeably slower until macOS assessed them once. I also tried the tempting system-level fixes, like lowering syspolicyd priority and restarting it, but they did not solve the real problem. The better fix is more boring: keep trusted tools clean, avoid unnecessary executable path churn, and warm up new generated tools before throwing a lot of parallel agents at them.

What I am not taking from this

I am not taking the lesson as "disable Gatekeeper". Actually the opposite. I did not run spctl --master-disable, and I do not want this to become a generic performance trick.

The better rule is narrower:

xattr -p com.apple.quarantine /path/to/trusted/tool
xattr -d com.apple.quarantine /path/to/trusted/tool

That only makes sense for tools I actually trust and understand. Not random downloads. Not a global cleanup.

The other practical rule is about path churn. If a workflow creates many executable files, do not immediately spawn all of them at high concurrency. The first run may be slower because macOS is assessing new paths. Warming them at lower concurrency can be better than letting a large agent run make the system feel stuck.

What I will probably do

I will probably keep everything on. The reason is simple: I can offload a lot of the pressure. If Codex is doing heavier work, I can hand jobs from my workstation MacBook Air to my Mac mini or to my Linux server. That is a better tradeoff for me than weakening security on my main laptop.

But for performance maxers, this is an interesting thing to look into. Not because they should turn off protection, but because they can find the specific places where macOS keeps checking things that are already trusted inside their own workflow.

The full benchmark, scripts and raw results are here: github.com/vvitovec/macos-gatekeeper-codex-benchmark. You can also see more of my practical build work on my projects page.

If you work with coding agents, automation or custom build tools on a Mac, it is worth checking whether your bottleneck is really just CPU. Sometimes it is the security layer doing exactly what it is supposed to do. Just very often.

Why (not)learn programming.

Viktor Vítovec — Wed, 01 Jul 2026 16:57:28 +0000

A few years ago, programming felt like the default answer to: what should I learn if I want a valuable skill? And honestly, it made sense. If you knew Python, JavaScript, or TypeScript, you could suddenly build things that most people could only describe.

Today I would not tell someone: learn a programming language and you are set. Knowing syntax is not the main skill anymore. AI can produce a ridiculous amount of code in a day. Roughly the kind of volume a normal employed developer would write by hand over years. The exact number is not the point. The point is that writing lines of code became much cheaper.

That does not mean programming is useless. It means the reason to learn it changed.

Programming work changed

In the past, a big part of the value was simply being able to turn an idea into code. You knew how to write an endpoint, a component, a script, a database query, an API integration. That is still useful, but it is not as rare as it used to be.

If I have a fairly clear system in my head today, AI can write a large part of the implementation for me. Not perfectly. Not without review. But fast enough that typing code is usually not the bottleneck anymore.

The bottleneck is more like: do you know what should be built? Do you know where the boundary should be between frontend, backend, and database? Do you know when a simple script is enough and when you need a real app? Can you tell when AI wrote code that looks clean but will break in a month?

That is the new line, in my opinion.

A language is not enough

Learning Python or TypeScript is great. Really. I just would not expect it to automatically make you employable or make someone trust you with a real product.

A language is a tool. If you only know the language, you mostly know how to phrase instructions for a computer. But real software is not a language exam. It is decisions around data, users, errors, deployment, security, performance, UI, operations, and a thousand small details that tutorials often skip.

I know Python and JavaScript/TypeScript, but honestly, I barely write most code by hand anymore. Most of the useful work is deciding how the project should behave, how to split it up, what should stay simple, what needs to be robust, where it can fail, and how to verify it. On projects like my portfolio or internal tools, the main work is often the system, not the lines.

What I would learn instead of “just programming”

If I started from zero today, I would still learn coding basics. But I would treat them as the entry ticket, not the final goal.

I would learn product development first. How to take a messy problem and turn it into something someone actually uses. How to tell whether I am building the right thing. How to choose a small first version instead of a giant plan that never ships.

Then I would learn how programs are structured. Not necessarily writing every file manually, but understanding why a project has folders, modules, database models, API layers, tests, env vars, and a deployment pipeline. This is exactly where AI still needs a person holding the direction.

And I would learn problem solving. Reading errors. Finding causes. Figuring out whether the issue is in the database, cache, config, network, UI, or my own assumptions. AI helps a lot here, but it still needs someone who knows what to check next.

Why programming is still worth learning

I do not want this to sound like “do not learn code.” That would be stupid. If you do not understand code at all, you are completely dependent on whatever AI outputs. That is risky.

Programming basics let you judge whether AI output makes sense. You can see when a function does something different from what you asked. You understand why types do not match. You can spot a piece of code that bypasses security or a migration that might delete data.

You also ask better questions. When you use tools like OpenAI Codex or other coding agents, the result depends a lot on whether you can describe the problem precisely. “Build me an app” is not enough. You need to know the inputs, outputs, states, and constraints.

So yes, learn programming. Just do not treat it as the final destination.

The new value is orientation

I think the gap will grow between people who can write some code and people who can orient themselves inside software.

Orientation means you can open an unfamiliar project and slowly understand what is going on. You can find where a bug starts. You can build a mental map of the system. You know what to give AI, what to review manually, and when the better solution is to simplify instead of adding more code.

That is much stronger than memorizing syntax. AI can fill in syntax. But a bad product or architecture decision can be accelerated by AI too, which only makes it more expensive.

So: should you learn programming or not?

Yes, learn it. But not with the idea that knowing one language is a career by itself.

Learn programming so you understand what AI is doing. Learn to build small things from start to finish. Learn to read existing projects. Learn to structure work. Learn product thinking. Learn to verify, not only generate.

Writing code is cheaper than it used to be. Knowing what code should exist in the first place is more valuable than it used to be.

That is the better reason to learn programming now.

The barrier to entry into tech does not exist anymore.

Viktor Vítovec — Wed, 01 Jul 2026 16:57:26 +0000

Getting into tech is easier now than it has ever been. Not because programming, debugging, or building products suddenly became trivial. More because access to information is barely the blocker anymore.

Before, you had to find a book, a course, a smarter person, or dig through forums until something clicked. Then the internet and YouTube changed the game. Now AI pushes it even further, because you can keep asking questions in one thread until the thing finally makes sense.

That changes the entry point into tech more than a lot of people admit.

Curiosity is still the best teacher

I did not get into this through some serious plan like: now I will become a programmer. It started in a much more normal way. I was a gamer and I wanted to mess with things around games.

For a lot of people, that game is Minecraft. I still think it is one of the best games for pulling someone into technology, because it naturally rewards curiosity. You want to change something, add something, understand why something works the way it does. Suddenly you are not only playing a game anymore. You are dealing with files, servers, plugins, mods, commands, and eventually code.

That is a very good way in, because it does not feel like forced learning. It is not: here is a syllabus, now suffer. It is more like: I want this thing, I do not know how to do it, so I will try to figure it out.

The internet already broke most of the barrier

I never really built my learning around paid courses. Not because all paid courses are bad, but because for the way I learn, they were not necessary. There is so much information online that if you have some interest and patience, you can learn almost anything.

YouTube and the open web taught a lot of people things that school or formal courses never did. Not because school is useless, but because the internet is closer to real problems. Want to run a server, fix a React error, understand a database, write a script, set up domains, or automate emails? Someone already had that problem. Someone recorded a video, wrote an article, or argued about it in a forum.

That is a huge shift. Access used to be the problem. Now the harder part is choosing what to try first.

AI made learning feel like a conversation

In the last two years, this moved again. Before, you searched Google, opened ten tabs, read different answers, and tried to combine them into something that matched your exact problem.

With AI, it feels more like an ongoing conversation. You ask. You get an explanation. You do not understand it? Ask for a simpler version. Want an example? Ask for one. Do not know what to ask? Ask what you should ask.

For a beginner, this is extremely strong. They do not immediately need to be good at search keywords, filtering old answers, reading long documentation, or guessing whether a Stack Overflow thread from 2014 is still relevant. They can get a first map of the problem and move step by step.

And now it is not only about explanations. Tools like Codex or Claude Code can open a project, write code, edit files, set up config, run tests, and get something working. If you want to build almost anything practical - a website, automation, small internal tool, script, data import, or API connection - you often do not need to start from a blank editor anymore. You describe the outcome and an agent can build the first version for you.

Of course AI can be wrong. You still need to think, test things, and verify the result. But as a starting engine, it is ridiculously convenient. We moved from searching physical libraries, to searching the internet, to asking ChatGPT or a similar tool and continuing from there.

What is still hard

This does not mean everything is easy. It means the main obstacle changed.

Information is almost free. Tools are available. AI can suggest a plan, explain an error, write a first version, set up a project, and tell you what to try next. But it still cannot solve the most important part for you: wanting to do it.

Forced learning is much harder than starting from a hobby. When the thing itself interests you, you survive debugging, messy docs, bad tutorials, and the moment where something does not work for two hours because of one stupid mistake. When you only do it because you feel like you should, every blocker feels like the end.

The second hard part is finding an idea. Some people have a head full of problems they want to solve. Some stare at an empty editor and have nothing. But even that can be worked around. Look at your normal day and ask: what do I do manually, what slows me down, what could be faster, cleaner, or more fun?

That is usually better than trying to invent a startup.

A first project should be tiny

If I had to recommend a first project for this week, it would not be a huge app. It would be something small that solves one annoying problem from your own life.

If you are a gamer, try a tiny game tweak, config, simple mod, server script, or something around your community. If you have too many emails, try an automation that summarizes them and drafts a reply in your style. If you repeat some task at school, work, or home, try making it faster.

It does not need to be perfect. The point is being able to say: right now I do this manually, and I want to make it faster, cleaner, or more fun.

That is how small things naturally turn into real projects. For me it leads into websites, automations, internal tools, and the kind of work I show in my portfolio projects. But the principle stays the same: take a problem, build a small first version, break it, fix it, learn the next thing.

The barrier is low, but the work is still real

The biggest lie about tech now is that you need some special entry pass. You do not. You need curiosity, a bit of stubbornness, and the willingness to build small things before they look elegant.

AI and the internet will not create motivation for you. But if you already have the motivation, starting today is almost comically accessible.

That is good news. Not because everyone has to become a programmer. More because the less people are scared of technology, the more small annoying problems they can solve for themselves.

I Want to Build Things That Save Work

Viktor Vítovec — Wed, 01 Jul 2026 16:48:47 +0000

I have built a lot of websites. I still build them, and honestly, I think I have become pretty good at it. I still enjoy making a page feel fast, clear, polished, and useful.

But websites by themselves are not really the thing I want to spend my whole future doing.

I already wrote about this from a slightly different angle in Pretty Is Not a Website Strategy. A good website should not just look nice. It should solve something.

That is the part I care about most now: finding repeated work and turning it into a shorter process.

Websites are still fun, but they are not the whole point

I do not dislike websites. The opposite, actually. A website is still one of the fastest ways to build something visible, useful, and easy for people to access. I like the details: speed, layout, content, design, structure, and the overall product feeling.

What I do not like is the idea of making the same landing page over and over, changing the logo, colors, and text, and pretending it is a brand-new problem every time.

When I build a website, the best part is when it becomes more than a presentation. When it gets an admin system, a map, a calculator, data processing, automation, or some internal tool behind it.

EasyFlex made that clear early

One of the best examples is EasyFlex. My mom runs her own accounting and tax advisory business, and every month she spends a lot of time entering invoice data into ABRA Flexi, the accounting system she uses.

On paper, this does not sound dramatic. You open an invoice, read the amount, date, supplier, variable symbol, a few other fields, and enter it into the system. But when you do that again and again, every month, for multiple clients, it becomes a lot of work. Not hard work, just repetitive, slow, and annoying.

The first version of EasyFlex was not some perfect platform. It was more of a test: what if I could take an invoice, extract the useful data, and prepare it in a way that makes the accounting work much faster?

Over time I rebuilt parts of it, fixed things, and improved the flow. The result is much more interesting to me than a nice portfolio screenshot: the time my mom spends on that part of the work dropped by more than ten times.

That is the type of building I like. Not because it looks impressive in a mockup, but because it removes work someone would otherwise repeat again and again.

The best features make something easier

I feel the same way with websites. When I worked on Mostky, the most interesting part was not just making a page with text and photos. It was the interactive 2.5D parcel map, because it helps people understand what is for sale, where it is, and how the plots relate to each other much faster.

That is the kind of extra feature I enjoy. Not animation just because something should move. I like features that help someone understand the situation faster or make a decision with less effort.

At that point, the website is mostly the surface. The interesting work is underneath: data, logic, a simple interface, automation, and information flowing in the right order.

Optimization is not only a technical thing

When I say I like optimizing, I do not only mean shrinking a bundle or making an API endpoint faster. I like that too, but it is only one layer.

I mean looking for friction in normal work. Where someone clicks ten times when they should click once. Where someone manually copies data that already exists somewhere else. Where a human waits on a step a system could handle. Where the same small mistake happens every month because nobody built a better process.

That is much more interesting to me than just asking whether a page looks nice. It should look nice. But if it does not make anything faster, easier, or clearer, then it is mostly decoration.

Right now I want experience

I do not know exactly what I want my final “real job” to be. And I think that is fine. I am still at the stage where I want to try as much as possible: websites, automation, AI tools, internal systems, databases, self-hosting, product work, all of it.

But the direction is becoming pretty clear. I like building things that are not just nice, but useful. Things that take boring, slow, repeated work and make it faster.

So yes, I will keep building websites. I just increasingly want there to be something real behind them.

That is the work I find most interesting now: find a problem, understand it well enough, and build a tool that makes it easier to deal with.

Pretty Is Not a Website Strategy

Viktor Vítovec — Wed, 01 Jul 2026 16:48:45 +0000

A website can look really good and still do almost nothing. That is one of the most common traps with new websites: people spend a lot of energy on colors, animations, photos, and mood, but less on whether a visitor understands the offer in ten seconds.

Design matters. It is just not the whole product.

Design is the first impression, not the whole website

A good-looking website helps. When a page feels clean, modern, and trustworthy, people have less reason to close it immediately. That is real value, not some shallow detail.

The problem starts when visual design becomes the final goal. Then the website can become a nice screenshot for a portfolio, but a weak business tool. The visitor does not know where to start, what the company actually does, who it is for, why it is different, or what to do next.

Good visuals should support the message, not hide the lack of one.

Structure sells more than effects

A lot of website performance comes from the order of information. First, the offer needs to be clear. Then who it helps. Then why someone should trust it. Then the next step.

That sounds simple, but it breaks all the time. A homepage has a big slogan and a few nice sections, but no real logic. The visitor gets a few separate impressions, but never moves naturally from problem to solution.

When I build websites and landing pages, I try to understand the business, person, or product behind the page first. A local service needs a different website than a SaaS tool. A portfolio needs a different rhythm again. Using the same template for everyone is fast, but usually the wrong shortcut.

Copy is not filler

Copywriting is one of the most underrated parts of a website. Text is not something you paste in at the end after the design is finished. Text often decides whether the offer makes sense at all.

One clear sentence can replace three sections of explanation. One vague sentence can make a beautiful layout useless.

This is not about big marketing phrases. It is about precision. What do you do? Who is it for? What gets better? Why you? What should the visitor do next? If those answers are not visible quickly, design will not rescue the page.

Speed and SEO are not boring extras

A slow website loses people before they even see the pretty design. And a website that cannot be found properly is often dependent on manually sending people the link.

This does not need to become overcomplicated. The basics are fast pages, sensible images, a clean heading structure, useful metadata, and content that answers real questions. For practical performance guidance, web.dev is useful, and Google has an official SEO Starter Guide.

These things should not be treated as “later” work. They belong in the base of the website, the same way colors and typography do.

Launch is not the finish line

Another weak point is maintenance. A website launches, everyone is happy for a while, and then it starts getting old. The offer changes. New references appear. Something breaks. Nobody tests the form. The copy stops matching reality. The technology around it keeps moving.

A website is not a poster. It is a living system.

That is why I like building things in a more connected way: design, landing pages, web apps, automation, data, and sometimes the backend around it. In some projects, the website is not just a business card. It is the entrance into a real workflow. At that point, looking good is only the baseline.

How I think about it

When someone wants a new website, the best first question is not “what should it look like?”. A better one is: what should it change?

Should it bring leads? Explain a complicated service? Make sales easier? Build more trust? Save the team time? Show the work better than the old site?

Only then does style become useful. Style without direction is just decoration.

A pretty website is great. But a good website is pretty, clear, fast, maintained, and built around the people who actually use it. I have a short overview of how I build websites, or you can just reach out through contact.

That is basically it. Not every website needs to be a huge application. But almost no website should be just a nice picture with a menu.

I turned my old gaming PC into a Linux server

Viktor Vítovec — Wed, 01 Jul 2026 16:07:08 +0000

Sometimes an upgrade is not about buying something new. Sometimes the better move is taking the thing that is already sitting there and giving it a better job.

That is what happened to my old gaming PC. It used to be the center of my gaming setup. Now it is a small home server running databases, backends, and the kinds of things I do not want to pay for as another separate service.

Why I stopped using the desktop

I have been gaming on PC since I was very young, so that machine had a long run. But this year I bought a MacBook Air, and it slowly became my main computer for almost everything: work, personal projects, writing, Codex, and quick ideas away from the desk.

That changed more than I expected. I did not want to be tied to one setup anymore. I wanted to open the laptop on a train, at school, on a sofa, or wherever else and just continue.

So the desktop stayed powered off more and more. And when I want to play something now, GeForce NOW from the Mac is usually enough. The old PC was good for its time, but it was starting to hit performance walls as a gaming machine. As a server, it still made perfect sense.

I did not want every small idea to become a subscription

A lot of my projects need some backend, database, auth, or small internal tool. Managed services like Supabase are comfortable and absolutely have their place. But when I build lots of small things for fun, paying separately for every tiny project stops making sense.

This was not about saving money at all costs. It was more about removing a bad filter from the way I build: “Is this idea worth another monthly bill?” That is a bad question to put in front of creativity.

Now the server can hold small databases, test services, and backends for projects like EasyFlex, ABRA Flexi AI, and even the database side of this portfolio website. It also gives me space for more experiments that would otherwise stay in notes.

Installing Ubuntu was not exactly smooth

The setup itself was not some clean cinematic montage. It was more like a few failed boots, trying to hit the right boot-menu key, dealing with small annoying issues, and finally getting into the Ubuntu installer.

I kept the setup as minimal as possible. No unnecessary desktop environment, no giant experiment on day one. The goal was simple: the server should run, host things, and stay out of the way.

That matters. Home infrastructure can easily become another project that eats more time than it saves. I wanted the opposite.

Cloudflare Tunnel beat messing with my router

The next decision was networking. I did not want to expose my home router or deal with port forwarding, public IPs, NAT, and all the usual small traps. I used Cloudflare Tunnel instead.

That worked surprisingly well. The tunnel runs on the server, I map a service to a domain, and I do not have to open random things directly through the router. It is boring in exactly the right way.

Then I started moving hosted things over. Some apps needed different env vars. Some expected a different Node version. Some worked locally and then broke in a completely different way on the server. But that is the normal cost of owning more of the stack.

It became a server when I unplugged the monitor

Once the setup was stable enough, I unplugged the monitor. From that point it stopped feeling like “a computer under the desk” and started feeling like a server.

At first I accessed it through Tailscale, later mostly through SSH with public/private key auth. I also wanted to remove the GPU to save more idle power, but my Ryzen 5 3600 setup will not boot without it. So the GPU unfortunately stays.

It is not perfect. But it is still much better than letting the whole machine sit unused.

Codex became part of the server workflow

The next obvious step was installing Codex. Not only for working on projects, but also for managing the server itself.

These days I do not manually SSH into it nearly as much. In the Codex app on my Mac, I have a connection that lets the agent work directly on the Linux server. In AGENTS.md and a custom skill, I describe what the server is, where projects live, how it should behave, and what it can safely do.

I sometimes use Claude too, mostly when I want a different angle on UI or frontend work. But for normal server tasks, the interesting part is that Codex can work right next to the infrastructure.

In practice, that means I can ask it to help with things like:

moving a small service,
checking logs,
preparing a deployment,
cleaning up /srv/projects,
setting up a new database or backend quickly.

I still need to understand what is happening. That part does not disappear. But I do not have to copy the same commands again and again.

What I learned from it

I am not saying self-hosting is always better than managed services. It is not. If a project is critical, needs high uptime, has a team behind it, or requires quick support, a managed platform makes a lot of sense.

But for personal projects, prototypes, small databases, and things I want to build quickly without a small mental tax, having my own Linux server is great. It also fits parts of my portfolio and website work, where a small piece of infrastructure does not always need a large platform around it.

Mostly, I like that the old gaming PC did not become a dust collector. It used to give me performance for games. Now it gives me room to build small things without attaching another account to every idea.

That is a pretty good second career for an old PC.