DEV Community: Viktor Vítovec

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.