DEV Community: Bojan Josifoski

Your Git Log Is a Legal Document

Bojan Josifoski — Fri, 29 May 2026 15:49:50 +0000

In 2024, Orca Security sued Wiz and demanded their full git version control history. Orca wanted to see "when features and functions were added, modified, or altered, including through engineers' notes and comments." The court recognized git history as relevant evidence in a software IP dispute. It ordered production of commit logs tied to two specific features.

That ruling should concern you. Your commits record author name, email, timestamp, and content hash. Git chains them together cryptographically, replicates them across clones, and makes them discoverable in litigation. You are building a legal record whether you intend to or not.

You already use git as a development tool. It is also a chain of custody for intellectual property. And you are probably destroying yours.

A Cryptographic Chain of Custody

Every git commit stores five things: the content of the change, the author's name and email, the author's timestamp, the committer's name and email, and the committer's timestamp. That commit is hashed using SHA-1 (or SHA-256 in newer repositories), and the hash incorporates the hash of the parent commit. Change one byte anywhere in the chain and every subsequent hash changes.

This is a Merkle DAG. The same data structure that makes blockchains tamper-evident. Your commit history is a cryptographic proof linking each change to all previous changes.

Git records three layers of timestamps. AuthorDate is when the content was written. CommitterDate is when it was finalized into the repository. And the server-side push timestamp, recorded by GitHub or GitLab, marks when the remote received the data. That third timestamp is outside the developer's control.

A clone is a full copy of the entire history. Your collaborators, CI runners, and backup systems each hold an independent replica. Forensics researchers call this "evidence proliferation." Tampering with one copy does nothing if fifty others exist unchanged.

Under Federal Rules of Evidence 902(14), data verified through a process of digital identification can be self-authenticating. Hash verification qualifies. Your git history records what you wrote and proves nobody changed the record after you wrote it.

Git History in Court

In Orca v. Wiz, the court agreed git history is relevant to IP disputes but denied the blanket discovery request as overbroad. It granted a targeted request for specific features instead. Well-structured git history with clean attribution is more useful in court than a sprawling monorepo dump.

Krause v. Titleserv shows what happens without version control evidence. An independent contractor wrote 35 programs over 10 years with no written IP assignment. The relationship ended, and neither side had clean evidence of who built what. The contractor took his notebook containing the only source code copies. The company had the running executables but no development history. The Second Circuit spent years sorting out what should have been a straightforward question of authorship. A git log would have resolved it in an afternoon.

SCO v. IBM collapsed partly because SCO could not point to specific lines of infringed code. The judge called it "astonishing" that they offered no competent evidence. Version control history documenting who wrote which lines and when would have been the foundation of that case. Without it, SCO had nothing.

Doe v. GitHub, the class action against Copilot, alleges that GitHub stripped authorship metadata from training data. The DMCA Section 1202(b) claim treats attribution data as legally protected copyright management information. Your name in a git commit qualifies. Stripping it out is a potential legal violation. That case is still active.

How Developers Destroy Their Own Evidence

Squash merging is the most common way. A pull request with 15 commits gets squash-merged into a single commit. Before GitHub fixed this in December 2019, the squash commit was attributed to whoever clicked the merge button. The original author disappeared. Even now with co-author trailers, the granular timeline is gone. Fifteen data points reduced to one.

Rebasing rewrites commit hashes. Force pushing overwrites the remote. If those commits existed on one machine and one remote, the evidence is gone. New hashes, new CommitterDates, broken chain. The cryptographic proof that your history is tamper-free now proves it was tampered with.

Researchers studied 111 million repositories and found 1.22 million with altered histories. 8.7 million rewritten histories total. The reasons were mundane: retroactive license changes, removing committed secrets. From a legal perspective, each rewrite weakens the evidentiary value of the whole chain.

Shared commit accounts are worse. Teams using a single identity like deploy@company.com or generic CI bot accounts destroy attribution at the source. Research across 2 billion git commits found over 23 million author identities, with major problems linking them to real people. If your commits are attributed to a shared account, they are not attributed to you.

Leaving a company adds another layer. You lose access to the repositories. If the company deletes the repo, migrates without history, or folds, your proof of authorship goes with it. GitHub deleted repos are recoverable for 90 days. After that, years of work have no provenance.

Three Things Developers Get Wrong About Copyright

The first is that paying for code means owning it. It does not. Under 17 U.S.C. Section 201, the author owns the copyright unless there is an explicit work-for-hire arrangement or a written assignment. For independent contractors, work-for-hire requires a signed written agreement AND the work must fall into one of nine statutory categories. Software does not fit those categories. CCB Journal published an analysis concluding the work-for-hire doctrine "almost never works in software development contracts."

If you are an independent contractor and your agreement has no copyright assignment clause, you own what you wrote. The client paid for the service. They received a license to use the deliverable. They did not receive the intellectual property. This surprises both sides when it matters.

Only 28% of freelancers use a written contract for any given project. Of those who do, 68% have unknowingly signed away IP rights. The gap between what developers think their contracts say and what they actually say is where disputes start.

The second is that git history is bulletproof evidence. It is not. Author fields can be set to anything. Local timestamps can be faked by changing the system clock. Without GPG-signed commits or server-side push timestamps from a third-party platform, git history is strong corroborating evidence but not conclusive on its own. The Orca v. Wiz court treated it as relevant but still pushed back on scope. It strengthens your position. It does not guarantee it.

The third is that copyright requires registration. Under the Berne Convention, protection is automatic in 182 member states the moment you write the code. But in the US, registration unlocks three things you cannot get without it: the right to file an infringement lawsuit (Fourth Estate v. Wall-Street.com, 2019), statutory damages up to $150,000 per work for willful infringement (17 U.S.C. Section 504), and recovery of attorney's fees (Section 505). Without registration, you can recover actual damages only, and for code, proving a dollar amount is a different kind of fight.

The $45 Insurance Policy

US copyright registration for source code costs $45 through the Electronic Copyright Office. You submit the first and last 25 pages of source code. If trade secrets are a concern, you can redact portions or submit only the first and last 10 pages. Processing takes about four months. Expedited review costs $800 and takes five business days.

There is no citizenship requirement. International developers building for US clients can and should register. Without registration, you have automatic protection under Berne but no access to statutory damages or attorney's fees in US courts. For anyone doing contract work for American companies, $45 buys a legal position that is otherwise unavailable.

Timing is critical. 17 U.S.C. Section 412 limits you to actual damages if infringement starts before your registration is processed. No statutory damages. No attorney's fees. Fourth Estate confirmed the Copyright Office must process the registration before you can file suit. If a dispute starts and you have not registered, you are waiting months before you can do anything. Register before you need to.

Unicolors v. H&M (2022) confirmed that inadvertent errors on your application do not invalidate the registration. Deliberate falsehoods at the time of filing would. Honest mistakes do not.

What To Do Now

Sign your commits. GPG or SSH signatures prove the commit was made by the holder of a specific private key. GitHub stores the verification record with a timestamp that cannot be edited after the fact. A signed commit is a verified attestation. Without the signature, a commit is a self-reported claim that anyone could have authored.

Stop squashing by default. Clean git history looks nice and destroys legal evidence at the same time. A merge commit preserves the full branch history with every original author, timestamp, and message. A squash commit erases all of it.

Keep your own remote. If you are a contractor, maintain a clone on infrastructure you control. A remote with its own server-side timestamps that survives the end of the engagement. You are preserving proof of authorship, not taking code that belongs to someone else.

Use your real name. Commits attributed to deploy@company.com or ci-bot or jane@computer.local are not evidence of your authorship. They are evidence that someone pushed code. Use a real name and a verifiable email.

Write commit messages for a reader who does not know the codebase. "Fixed stuff" tells a judge nothing. "Implemented webhook deduplication using idempotency keys to prevent duplicate order processing" documents original engineering work. Your commit messages are the narrative layer of your contribution.

Register your copyright. $45 and a four-month wait. Do it before anything goes wrong. Section 412 does not care about your reasons for waiting.

Read your contracts. All of them. Look for two clauses: copyright assignment and IP ownership. If neither exists, you likely own what you build. If both exist and are specific, you likely do not. If the language is vague, that is where disputes live. Clarify it before you write the first line of code.

The Record

If you have a GitHub account, you are building a legal record right now. Your commits could be subpoenaed, analyzed, and presented in a courtroom. The name on those commits, the integrity of your history, your signatures, your registrations: those are decisions you are making today that you cannot make retroactively.

You will probably never face a copyright dispute. But if you do, your git log will be one of the first things a lawyer asks to see. Make sure it says what you need it to say.

Breaking Code: The Addiction Nobody in Tech Will Admit To

Bojan Josifoski — Tue, 26 May 2026 18:09:12 +0000

The First Cook

You remember the first time. Everyone does.

You typed a prompt. Something simple. Maybe a REST endpoint, a database migration, a React component you had been putting off. The AI generated it in seconds. Working code. Clean code. Code that would have taken you an hour, done in the time it takes to read a paragraph.

You felt something. Relief, and something past relief. A rush. The same feeling Walter White had in that RV in the New Mexico desert, watching the first batch crystallize. You just discovered a new capability. And you wanted more.

That was the first cook, and everything after that is escalation.

The Chemistry

B.F. Skinner spent his career studying what makes behavior compulsive. He tested every reinforcement schedule on every animal he could get into a lab. Fixed ratio: do X, get reward. Fixed interval: wait Y, get reward. Variable interval: wait some unknown Y, get reward.

None of them came close to variable ratio reinforcement.

Variable ratio is what happens when the reward comes, but you never know when. You pull a lever. Sometimes you win. Sometimes you do not. You never know which pull will pay off. Skinner found that this schedule produced the highest response rate and the greatest resistance to extinction in every species he tested. He was so confident in its power that he once claimed he could turn a pigeon into a pathological gambler.

The slot machine industry proved he was right about humans too.

Now look at what happens every time you type a prompt and hit enter. Sometimes the AI generates flawless code that works on the first run. Sometimes it generates garbage. Sometimes it builds an entire feature. Sometimes it hallucinates an API that does not exist. You never know which one you are going to get. The uncertainty triggers dopamine release before the result even appears. Your brain responds to the anticipation of the outcome, not the outcome.

Every prompt is a lever pull. But unlike a slot machine, this one occasionally builds your entire product.

Say My Name

The people describing these symptoms are some of the most prominent names in technology.

Andrej Karpathy, OpenAI co-founder, went on the No Priors podcast in March 2026 and admitted he had not written a single line of code since December. His ratio of handwritten to AI-delegated code flipped from 80/20 to 0/100. He spends 16 hours a day issuing commands to agent swarms. And when he has tokens left over near the end of the month, he gets "nervous" and rushes to use them up. That last detail is compulsive consumption.

Garry Tan, CEO of Y Combinator, told Bill Gurley at SXSW that he sleeps about four hours a night and has what he called "cyber psychosis." He estimated a third of the CEOs he knows have it too. He posted on social media about staying awake 19 hours and sleeping at 5 AM, then acknowledged in a reply to a founder whose CTO had not slept in 36 hours: "This is unhealthy by the way (speaking from experience)."

Armin Ronacher, the developer behind Flask and a respected voice in the Python community, wrote in January 2026: "Many of us got hit by the agent coding addiction. It feels good, we barely sleep, we build amazing things." He later admitted to spending two months obsessively prompting Claude, building tools he never used, and creating what he called "vibeslop." He described watching people develop parasocial relationships with their AIs and forming communities that reinforce unhealthy behavior.

Quentin Rousseau, CTO and co-founder of Rootly, could not sleep for months after switching to agentic coding. He required prescription medication designed to suppress the wakefulness signals his brain refused to turn off. His description of the tools: "They operate like slot machines. You hit one prompt, you get an answer, you get some coding done."

The people describing these symptoms are founders and CTOs, some of whom built the tools. When Walter White started using his own product, that was the turning point.

The Blue Stuff: What Makes This Hit Different

Traditional coding addiction exists. Programmers have been losing sleep to side projects since before version control. But AI coding has four properties that make it different in kind from anything that came before.

Writing code is work. Prompting is not. The barrier between "I have an idea" and "I have a working prototype" collapsed from days to minutes. Every reduction in friction increases the potential for compulsive repetition. This is why mobile gambling is more addictive than casino gambling. You can do it from bed at 3 AM. You can prompt from bed at 3 AM too.

When you write code yourself, you are doing. When you prompt an agent and watch it work, you are watching. Watching someone else do impressive things on your behalf activates reward circuitry without the cognitive cost of doing the work yourself. This is the same mechanism that makes watching sports pleasurable, except the agent is playing for your team, on your project, every single time.

Every completed prompt opens three more possibilities. Fixed that bug? Now you could add the feature you have been thinking about. Added the feature? Now you could refactor that ugly module. Refactored the module? Now you could write tests. Each branch is one prompt away. There is no natural stopping point. The work never ends because the work is free.

Ship a side project on Twitter. Post a demo on LinkedIn. Show your agent-built app on Hacker News. The social feedback loop compounds the dopamine from the coding itself. Twenty-five percent of companies in Y Combinator's Winter 2025 cohort had codebases that were almost entirely AI-generated. The culture celebrates the addiction.

Half Measures

Early research complicates the productivity pitch.

A study by engineering analytics firm Multitudes tracked over 500 developers and found that engineers using AI tools merged 27.2% more pull requests. That is the headline number, the one that ends up in pitch decks. Buried below it: a 19.6% rise in out-of-hours commits. The developers are shipping code at midnight, on weekends, outside their working hours.

Researchers from Boston Consulting Group and UC Riverside published a study in Harvard Business Review in March 2026 introducing the term "brain fry": mental fatigue from excessive use or oversight of AI tools beyond one's cognitive capacity. Workers experiencing it reported 33% more decision fatigue and scored 39% higher on major errors. Fourteen percent of AI-using workers endorsed the experience. In marketing departments, that number hit 26%.

The researchers were careful to distinguish brain fry from burnout. Burnout is chronic. Brain fry is acute. It is what happens when you push attention, working memory, and executive control past their limits in a single session. When you run six parallel agents across three projects for 14 hours straight, your brain does not burn out. It fries. The authors described participants reporting a "buzzing" feeling, mental fog, difficulty focusing, slower decision-making, and headaches.

Simon Willison, a developer with 25 years of experience, said: "There is a limit on human cognition, in how much you can hold in your head." He identified "elements of gambling and addiction" in usage patterns and called the choice to code over sleep "obviously unsustainable."

The Tolerance Curve

During a 2026 GitHub outage that took down AI coding tools, developers described being unable to write code without the AI.

This is the part of the cycle that separates a habit from a dependency. When the tool is removed and your ability to function degrades, you are no longer choosing to use it. You depend on it. When a developer cannot write code they used to write without help because their brain has outsourced the effort, that is tolerance and dependency operating together.

Developers who have been prompting 14 hours a day report the same pattern with manual coding. It feels slow. It feels boring. It feels pointless when you know the agent can do it in seconds. The reward threshold has shifted, and everything below it feels like standing still. Your brain has recalibrated around a new baseline, and everything that used to feel normal now registers as insufficient.

I Am the One Who Prompts

The deepest parallel to Breaking Bad is the denial.

Walter White told himself he was doing it for his family. Then for the money. Then for the empire. At no point did he say: I am doing this because I am addicted to the feeling of being the most capable person in the room.

Developers tell themselves they are being productive. They are shipping faster. They are 10x engineers now. At no point do most of them say: I am doing this because the dopamine loop from prompting an AI agent is the most rewarding experience I have had in my professional life, and I cannot stop.

Garry Tan compared his current experience to a previous startup that took $10 million in VC capital and 10 people over two years. He says the sleep deprivation now is from "pure excitement." That distinction might matter less than he thinks. The brain does not care whether the reward comes from a funding round or a prompt.

Steve Yegge, a veteran engineer, said: "Intermittent reinforcement of dopamine and adrenaline hits creates the core addictive pull." He then admitted he has to run "a practiced escape plan every night to get my computer closed by 2am." That is a coping mechanism for a behavioral pattern described by someone who recognizes it and still cannot fully control it.

No Half Measures

Behavioral addictions have a structural problem: you cannot quit cold turkey. A gambler can stop gambling. But a developer cannot stop coding. The tool that triggers the compulsion is the same tool required for the job. This is like telling Walter White he needs to keep teaching chemistry but stop cooking.

Quentin Rousseau documented the strategies that worked for him: batching agent runs instead of prompting continuously, tracking hours instead of output, setting hard closure times, and medication when those strategies failed. Those are harm reduction strategies.

The research from the CHI 2025 Conference on Human Factors identified four design patterns in AI interfaces that exploit addictive mechanisms: non-deterministic responses, immediate visual presentation, notifications, and empathetic agreeable responses. The designers built those patterns to keep you pulling the lever, the same way a slot machine's near-miss animation keeps you feeding quarters.

Recognizing the pattern is the first step, and it is the one most developers skip. The culture, the metrics, and the tools all reward the compulsion. Stepping back requires self-awareness: recognizing when you have stopped building and started chasing the next hit.

Walter White understood the chemistry of what he was building. He kept building anyway.

The Three-Body Problem: AI Code, Supply Chain Attacks, and the Talent Exodus

Bojan Josifoski — Mon, 25 May 2026 09:02:41 +0000

In physics, the three-body problem describes a system where three objects interact gravitationally in ways that are fundamentally unpredictable. You can model any two of them. The moment you add the third, the math breaks. Small changes in initial conditions produce wildly different outcomes. The system becomes chaotic.

Software security has its own three-body problem. Three forces are converging right now, and the industry is modeling each one independently while ignoring what happens when they interact.

Force one: AI is generating code with 2.74 times more vulnerabilities than human-written code, and it is being shipped at unprecedented volume.

Force two: supply chain attacks grew 1,300% in three years, and the infrastructure the internet runs on is maintained by burned-out volunteers.

Force three: the security talent pipeline is collapsing. Junior hiring is down 73%. Security teams are being cut. 88% of organizations experienced a significant incident due to skills shortages.

Each force alone is a problem with known solutions. All three at once is something this industry has never faced.

Force One: The Code Nobody Audited

46% of all code on GitHub is now AI-generated. In Java repositories, that number is 61%. This is not a projection. This is the current state of the world's largest code repository.

Veracode's 2025 report found that 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities. 86% fail XSS defense. 88% are vulnerable to log injection. 72% of Java samples fail security tests. Design-level flaws, authentication bypasses, insecure direct object references, broken session management, increased 153%.

CVEs attributed to AI-generated code jumped from 6 in January 2026 to 35 in March 2026. Security researchers estimate the real count is five to ten times higher because most AI-generated vulnerabilities are never traced back to their origin. The code just ships. Nobody flags it as AI-generated. The vulnerability exists and nobody knows why.

A Stanford randomized controlled trial found that developers using AI tools wrote less secure code while reporting higher confidence in its security. They shipped faster, felt better about it, and the code was worse. That confidence gap is the mechanism through which AI-generated vulnerabilities reach production at scale.

Pull requests per author rose 20% year-over-year. Incidents per pull request jumped 23.5%. More code. More bugs per unit of code. The math is multiplicative, not additive. And nobody is reading the diffs.

Force Two: The Supply Chain Nobody Owns

On March 12, 2025, attackers compromised a GitHub Action called tj-actions/changed-files. It was used by 23,000 repositories. The attack modified version tags to inject a payload that dumped CI/CD secrets into public workflow logs. AWS keys. GitHub personal access tokens. npm tokens. It started as a targeted attack on Coinbase and then went wide. CISA issued an alert within a week.

On September 8, 2025, an attacker phished a single npm maintainer with a fake two-factor reset email. Within hours, 18 packages were compromised, including chalk and debug, which between them have 2.6 billion weekly downloads. The malicious code intercepted cryptocurrency transactions. It was live for roughly two hours. Two hours was enough.

In December 2025, a vulnerability called React2Shell was disclosed. CVSS 10.0, the maximum severity score. An unsafe deserialization flaw in React Server Components allowed pre-authentication remote code execution via a single HTTP request. It affected Next.js 15.0.0 through 16.0.6. Nation-state actors, China-nexus groups deploying backdoors, exploited it before most teams could patch. Vercel blocked over 6 million exploit attempts.

In April 2026, Vercel itself was breached. Not through a code vulnerability. Through an AI tool. A Vercel employee had granted an AI tool called Context.ai full read access to their Google Workspace. A Context.ai employee had been infected with malware. The attackers pivoted from the compromised AI tool into the Vercel employee's account, then into Vercel's platform, then enumerated and decrypted environment variables. The stolen data was listed on BreachForums for $2 million.

454,648 malicious packages were discovered on npm in 2025 alone. That is a 75% year-over-year increase. Over 99% of all open-source malware targets npm. The first self-replicating npm worm, called Shai-Hulud, appeared and infected 500 packages before containment. Malicious open-source package threats increased 1,300% in three years.

And underneath all of this sits the template attack that showed how fragile the entire system really is. The xz Utils backdoor, disclosed in March 2024. An attacker spent two years building trust with a burned-out solo maintainer of a compression library used by virtually every Linux system. They contributed code. They earned commit access. Then they planted a backdoor. CVSS 10.0. It was caught by accident, by a developer who noticed a 500-millisecond latency increase in SSH connections. If that developer had not been paying attention, it would be in every server on the internet right now.

The software supply chain is not a chain. It is a web of dependencies maintained by people who are exhausted, underfunded, and increasingly targeted by state-level attackers with AI tools and years of patience.

Force Three: The Talent That Left and Was Never Replaced

245,953 tech workers were laid off across 783 companies in 2025. In 2026, over 100,000 more followed by May. Security teams were not spared. For the first time, budget cuts surpassed talent scarcity as the top cause of security workforce shortages. 33% of organizations cited budget as the reason security positions stay empty.

Junior developer hiring collapsed 73% year-over-year. 54% of engineering leaders plan to hire fewer juniors. The entry-level pipeline that feeds mid-level and eventually senior security engineering roles is drying up. The ISC2 pegs the global cybersecurity talent gap at 4.7 million unfilled positions, up 19% from the previous year.

95% of security teams report skills gaps. 59% call them critical or significant, up from 44% in 2024. Organizations with significant skills gaps are nearly twice as likely to suffer a material breach, and those breaches cost $1.76 million more per incident.

The companies cutting security headcount are the same companies shipping more AI-generated code. They are reducing the humans who catch vulnerabilities while increasing the code that produces them. The same CFO who approved the layoffs approved the AI tooling budget. Nobody put these two line items next to each other on a spreadsheet.

Where the Three Forces Collide

Model any two of these forces and the picture is manageable. AI-generated vulnerabilities plus strong security teams equals a solvable problem. Supply chain attacks plus experienced reviewers equals a defensible position. Talent shortages plus human-written code equals a staffing challenge, not a crisis.

All three at once is different.

AI generates code with more vulnerabilities. That code flows into the supply chain as packages, dependencies, and shared actions. The supply chain has 454,648 new malicious packages per year and maintainers who are too burned out to review what enters their repositories. The security teams who would catch the vulnerabilities and the supply chain compromises have been cut. The juniors who would have grown into security engineers were never hired.

Meanwhile, the attackers are using the same AI tools. AI-powered cyberattacks increased 72% year-over-year. AI-crafted phishing emails achieve a 54% click rate compared to 12% for human-written ones. A new attack vector called slopsquatting has emerged: attackers register the fake package names that AI coding tools hallucinate. Researchers found that 19.7% of AI-recommended package names do not exist, and 43% of those hallucinated names repeat consistently, making them predictable targets. The AI tools writing the code are directing developers to install packages that attackers have already registered.

The FBI documented 22,364 AI-related cybercrime complaints with $893 million in losses in 2025. Prompt injection, the technique where hidden instructions in data manipulate AI tools into executing unintended actions, is being compared to SQL injection in the early web. It is a fundamental architectural flaw, not a bug to be patched.

The attack surface is growing exponentially. The defense capacity is shrinking linearly. Those curves crossed sometime in 2025 and nobody marked the date.

What the Next Twelve Months Look Like

Gartner predicts that 50% of enterprise cybersecurity incident response will involve AI application incidents by 2028. They predict that 25% of enterprise generative AI applications will experience five or more security incidents per year, up from 9% in 2025. Forrester predicts that an agentic AI deployment will cause a publicly disclosed data breach in 2026.

IBM's 2025 report found that shadow AI breaches already cost $4.63 million on average, $670,000 more than standard incidents. 97% of organizations with AI-related breaches lacked proper AI access controls. Enterprises invest 17 times more in AI-powered tools than in securing the AI itself.

The Vercel breach was the preview. An AI tool with workspace access became the entry point. Not a code vulnerability. Not a phishing email. An AI tool doing exactly what it was authorized to do, being exploited through a compromise the AI tool's own security could not prevent. That pattern will repeat because every company granting AI tools access to codebases, cloud accounts, and internal documents is creating exactly the same attack surface Vercel had.

The prt-scan campaign in March and April 2026 used AI to automate GitHub Actions exploitation across 500 repositories in six weeks. That is the new pace of supply chain attacks. Not one patient attacker spending two years on xz Utils. An AI system attacking hundreds of repositories simultaneously.

Nobody Has a Model for This

The security industry models threats individually. AI code vulnerabilities are an AppSec problem. Supply chain attacks are a DevSecOps problem. Talent shortages are an HR problem. Each one has a playbook. Run SAST scans on AI code. Pin dependencies and verify signatures. Increase security headcount.

None of those playbooks account for the other two problems happening at the same time. You cannot run SAST scans effectively when the security team has been cut. You cannot verify supply chain integrity when nobody has time to audit dependencies because they are reviewing AI-generated code. You cannot increase security headcount when the junior pipeline that feeds it has been shut off.

The three-body problem in physics has no general solution. The three-body problem in security might not have one either. But physics does not let you change the initial conditions. The industry still can.

That window is closing. The developer velocity that feeds them is not slowing down. And the companies still modeling them independently are going to be the ones in the incident reports.

Nobody Reads Your Code Anymore

Bojan Josifoski — Sat, 23 May 2026 10:50:19 +0000

Here is what happened to code review in 2026. AI writes the code. AI reviews the code. A human clicks approve. The PR merges. Everyone moves on. Nobody in that chain actually read the diff.

This is not a prediction. This is Tuesday.

46% of all code on GitHub is now AI-generated. In Java repositories, that number is 61%. Teams with high AI adoption merge 98% more pull requests than they did before. And the time spent reviewing those pull requests increased by 91%. Not because people are reviewing more carefully. Because there is more to review and the reviews take longer to skim.

The volume of AI-generated code is projected to outstrip human review capacity by 40% this year. The code is arriving faster than humans can read it. So they stopped reading it.

The Ceremony

Code review used to mean something. A senior developer would read your pull request line by line. They would catch the bug you missed. They would explain why your approach had a hidden performance problem. They would push back on the architecture. They would teach you something. The review was not a gate. It was a conversation.

Now it is a gate. And the gate is made of rubber.

The pull request arrives. It is 400 lines long. It was generated by an AI agent that restructured the database queries, added error handling, and wrote tests. The code looks clean. The tests pass. The linter is happy. CI is green. The reviewer has their own AI-generated PRs to ship. They are chasing the same tokens as the author. They skim the diff. They click approve. Everyone moves on.

Nobody read the code. The code was reviewed. Those are two different things and the industry is pretending they are the same.

Camp One: Reviews Still Matter

The review defenders have data on their side. 40 to 45 percent of AI-generated code contains security vulnerabilities. That is not a fringe finding. That is across multiple studies from Stanford, NYU, and Veracode. XSS failures hit 86% in Java code generated by AI. Design-level security flaws, authentication bypasses, insecure direct object references, broken session management, increased 153%.

AI-assisted developers produce three to four times more code but generate ten times more security issues. Over 10,000 new security findings per month from AI-generated code alone. And 43% of AI-generated code changes require production debugging even after passing QA and staging.

There was a prompt injection vulnerability in GitHub Copilot Chat, rated CVSS 9.6, that allowed attackers to exfiltrate AWS keys from private repositories through hidden instructions in PR comments. The code review process was supposed to catch that. It did not, because nobody was reading PR comments for prompt injection attacks. That threat did not exist when the review process was designed. These vulnerabilities are one force in a convergence the industry is not prepared for.

This camp will tell you that human review is the last line of defense against AI-generated vulnerabilities. That the 91% increase in review time is not a problem to optimize away but evidence that review needs to become more rigorous, not less. That the moment you remove the human from the loop entirely, you are shipping code that nobody on the team can vouch for.

Camp Two: Review Is Theater

The review skeptics have a different argument and it is harder to dismiss than the defenders would like.

Nobody actually reads 500-line PRs. They did not read them before AI, and they are definitely not reading them now that the volume doubled. The rubber-stamp culture is not new. AI just made it visible by increasing the volume to the point where the pretense collapsed.

As one prominent essay on the death of code review put it: every engineering org has the same dirty secret. PRs sitting for days. Rubber-stamp approvals. Reviewers skimming 500-line diffs because they have their own work to do. Human-written code died in 2025. Human code review dies in 2026.

The argument is not that review does not matter. The argument is that line-by-line review of AI-generated code is the wrong checkpoint. The human should be upstream, authoring the spec and acceptance criteria, not downstream reading diffs they did not write and cannot fully contextualize at the speed they arrive.

This camp will tell you that the ceremony of code review is being preserved for political reasons, not engineering reasons. That LGTM was always the most common review comment, and that AI just made the honesty about that impossible to avoid.

What Happens When Nobody Reads the Code

Amazon found out in March 2026. AI-assisted code changes deployed without proper review triggered outages that cost an estimated 6.3 million lost orders. Amazon initiated a 90-day code safety reset across 335 systems. GitHub itself logged 257 incidents between May 2025 and April 2026, roughly one per week, driven by the explosion of AI-generated code and agentic workflows.

These are not small companies with loose processes. These are the companies that built the tools generating the code. If they cannot keep up with review, nobody can.

The pattern is consistent. AI generates code faster than humans can review it. The backlog grows. The pressure to ship increases. Review becomes cursory. Bugs ship to production. Incidents happen. The response is always the same: we need to improve our review process. But the process is not the problem. The volume is the problem. And the volume is not going down.

The Knowledge Transfer Problem

There is a quieter crisis underneath the security headlines. Code review was how knowledge transferred between engineers. A senior reviewing a junior's PR was not just catching bugs. They were teaching architecture. They were explaining why this pattern causes problems at scale. They were sharing context about the system that is not written down anywhere.

When AI writes the code and AI reviews it, that transfer stops. The senior does not read the junior's code because the junior did not write it. The junior does not learn from the review because the review is automated. The codebase grows in capability and shrinks in comprehension. More features, fewer people who understand how they work.

The optimistic data says juniors receiving AI feedback improved code quality 3.2 times faster, cutting onboarding from six months to eight weeks. The pessimistic interpretation is that they learned to satisfy the AI's criteria without understanding why those criteria exist. They optimized for the metric without learning the principle.

Gartner predicts 80% of engineers will need upskilling by 2027 specifically for AI collaboration. The codebase becomes legible to AI but opaque to the humans responsible for it. And when something breaks in a way the AI does not understand, the human who also does not understand it is the one on call.

The New Bottleneck

The bottleneck in software development used to be writing code. Then it was shipping code. Now it is understanding code.

AI can write a service in hours that would have taken weeks. AI can review the PR and catch the obvious issues. AI can generate tests that cover the happy path and most edge cases. What AI cannot do is tell you whether this service belongs in this system. Whether the architecture you are building will hold when usage doubles. Whether the trade-off you made today will become a production incident in six months.

Those judgments require understanding. Understanding requires reading. And nobody is reading.

The teams that figure this out will not go back to line-by-line reviews. That ship has sailed. They will move the human checkpoint upstream. Review the spec, not the diff. Define what the code should do and let AI do it, then validate the behavior, not the implementation. Test the system, not the syntax. Invest in integration tests and observability rather than code review for implementation correctness.

The teams that do not figure this out will ship faster and faster until something breaks that nobody on the team knows how to fix. Then they will have an incident review where the root cause is that nobody understood the system, and nobody will know what to do about that because the review process that was supposed to ensure understanding has been a rubber stamp for eighteen months.

So What Do You Do?

If you are a reviewer: stop pretending you read 500-line AI-generated diffs. You did not. Everyone knows you did not. Focus on what humans are still better at. Does this change make architectural sense? Does it introduce a pattern that will cause problems at scale? Does the test coverage match the risk? If you can answer those questions, you added value. If you cannot, you were a rubber stamp and the green checkmark meant nothing.

If you are a team lead: measure what you actually care about. If review time is your metric, you are measuring the ceremony, not the outcome. Measure production incidents. Measure security findings. Measure how quickly a new team member can understand a service. Those tell you whether your code is understood. PR approval time tells you nothing.

If you are a developer: understand what you ship. Not every line. That is not possible anymore and was barely possible before. But understand the architecture. Understand the data flow. Understand the failure modes. If you cannot explain what a service does without asking the AI to explain it to you, you do not understand it. And the person on call at 2am when it breaks should be someone who understands it.

Nobody reads your code anymore. The question is whether anyone understands it. Those are different things, and the gap between them is where the next generation of production incidents is being born.

Your Side Project Is Not a Business

Bojan Josifoski — Fri, 22 May 2026 10:47:30 +0000

There are 630 million repositories on GitHub. App Store submissions jumped 84% in Q1 2026. Product Hunt launches with AI in the name went from 5% to 40% of all submissions. Non-technical founders built 3.2 million production-grade apps using AI builders in 2025 alone.

Most of these will never have a paying customer.

That is not pessimism. That is the math. AI solved the building problem. Nobody solved the selling problem. And the gap between those two problems is where careers and savings accounts go to die.

The Great Shipping Delusion

Something changed in 2025. The hard part of building software stopped being hard. A developer with Claude Code or Cursor can go from idea to deployed application in a weekend. Not a prototype. Not a mockup. A real, working, deployed application with authentication, a database, a payment page, and a landing page that looks like it was built by a funded team.

This is genuinely remarkable. The barrier that kept most ideas from becoming products has collapsed. The same AI-driven velocity that redefined what one developer can ship is now aimed at the market. Twenty years ago, you needed a team, capital, and months of development to ship what one person can build in 48 hours today.

And that collapse created a delusion that is burning through the developer community like wildfire: the belief that shipping is the hard part.

It is not. Shipping has never been the hard part. Distribution is the hard part. Finding people who have the problem you solved, convincing them your solution is worth paying for, and keeping them around long enough to build a sustainable revenue stream. That was hard before AI. It is still hard. AI did not touch it.

Camp One: Just Ship It

The build-in-public crowd has a seductive argument. Lower the barrier to entry and more people can participate. More participation means more experiments. More experiments mean more discoveries. More discoveries mean more real businesses.

And they have success stories. Real ones. Sabrine Matos, a growth marketer with no engineering background, built Plinq entirely using AI tools. Ten thousand users. $456,000 in annual recurring revenue. Three months. Base44, a solo developer, hit 250,000 users and profitability in six months. Wix acquired it for $80 million.

These stories are real and they are powerful and they are the exception, not the rule. But they prove something important: the ceiling for what one person can build has been removed. The limiting factor is no longer technical capability. It is everything else.

This camp will tell you that the old world was worse. That the gatekeeping of needing a team and capital and time just meant that only privileged people could try. That AI democratized the attempt. That more attempts, even with a high failure rate, produce more winners in absolute terms. The same dynamic is reshaping who gets to build professionally.

Camp Two: You Built a Demo

The other side of the aisle has a body count to point to. Vibegraveyard.ai and vibegraveyard.rip catalog the wreckage. Of 60-plus AI app builders launched in 2025, roughly half are dead by April 2026. The apps they helped create are dying even faster.

One indie hacker posted a summary that captures the entire problem: 4 organic users. 400,000 impressions. Zero paying customers. Building in public update.

That ratio is not unusual. It is typical. The feed is full of beautifully built applications with nobody using them. The code is clean. The UI is polished. The landing page converts. There is just nobody on the landing page.

This camp will tell you that AI made the easy part easier. Building was never the hard part for people who knew what they were doing. It was the hard part for people who did not know what they were doing, and making it easy for them does not make them entrepreneurs. It makes them people with deployed applications and no customers.

A deployed application is not a business. A business has customers who pay money. Everything else is a hobby with hosting costs.

The Distribution Cliff

There is a cliff that every side project hits. The building phase is euphoric. You have an idea, you open your editor, the AI helps you ship fast, and in days you have something real. The dopamine is extraordinary. You are a builder. You are shipping. You are doing the thing.

Then you launch. And the essay that captures this moment better than anything else this year put it plainly: you shipped something real. You spent nights and weekends building something that actually solves a problem. Then you launched. Silence. Crippling, soul-destroying silence.

The silence is not because the product is bad. The silence is because nobody knows it exists. And the skills required to make people know it exists have nothing to do with the skills required to build it. Marketing. Distribution. Sales. Positioning. Community building. SEO. Content strategy. Partnerships. These are not coding skills. They are not enhanced by AI coding tools. They take as long to learn as software engineering does.

The community consensus emerging in 2026 is blunt: the distribution versus product skill gap is very real. A lot of builders assume that if the product is good enough, users will somehow appear. Those are two completely different problems to solve.

The Market Is Drowning

The App Store review queue tells the story. Wait times ballooned from a 24 to 48 hour baseline to 7 to 30 days. Not because Apple got slower. Because submission volume exploded. Apple started actively blocking updates for apps built with AI coding tools and removing others.

Product Hunt is seeing the same pattern. AI's share of launches jumped to 40%, but upvotes did not follow proportionally. More launches, same attention. Horizontal AI tools show diminishing returns. The market is not growing as fast as the supply.

This is the part nobody in the just-ship-it camp talks about. When shipping is easy, everyone ships. When everyone ships, attention becomes the scarce resource. And attention was already scarce. Now it is being divided among ten times more products competing for the same eyeballs.

The irony is thick. AI made building so easy that building is no longer a competitive advantage. The thing that used to differentiate you, the ability to turn an idea into working software, is now table stakes. If everyone can build, nobody stands out by building.

What Actually Becomes a Business

The pattern emerging from the wreckage is consistent. The side projects that become businesses are not the ones with the best code or the most features. They are the ones built by people who understood the problem before they built the solution.

They talked to customers first. They understood the workflow they were improving. They knew where the money was. They built the minimum thing that solved the specific problem for a specific group of people willing to pay for a solution. Then they built distribution before they built features.

The highest-leverage advice for solo founders in 2026 is counterintuitive: use AI to build things for specific clients at premium prices rather than building SaaS tools for anonymous markets. Sell a finished product for $5,000 instead of selling access to a tool for $50 per month. The economics are better, the feedback is faster, and the learning is real.

The projects that become businesses skip the launch-and-pray model entirely. They find the customer first. They validate the willingness to pay first. Then they build. AI makes the building fast enough that this order of operations actually works. Build last, not first.

The Uncomfortable Question

If you are building a side project right now, ask yourself one question. Not whether you can build it. You can. AI made sure of that. Ask whether you have talked to ten people who have the problem you are solving and whether any of them would pay for a solution.

If the answer is no, you do not have a business idea. You have a building idea. Those are different things. Building ideas are fun. Business ideas are profitable. The gap between them has not changed. AI just made it easier to find out which one you have, faster.

If the answer is yes, you might have something. Build it fast, ship it to those ten people, and find out if they actually pay. If they do, find ten more. That is a business. Everything else is a portfolio project with a Stripe integration.

The side projects that win in 2026 are not the ones built fastest. They are the ones built for someone specific. AI changed the speed of building. It did not change the definition of a business. A business is someone paying you money to solve their problem. Everything before that is practice.

The Death of the Junior Developer

Bojan Josifoski — Thu, 21 May 2026 22:06:03 +0000

Somewhere right now, a hiring manager is looking at a requisition for a junior developer and asking a question that did not exist two years ago: why would I hire someone to do what my senior developers and their AI tools already handle?

Across the industry, a CS graduate is staring at a job board that looks nothing like the one their professors described. Entry-level postings are down 60% since 2022. The career path they were promised has a gap where the first rung used to be.

Both of them are right to be concerned. Neither of them has a good answer.

The Numbers Are Not Subtle

A Harvard study tracking 62 million workers across 285,000 U.S. firms found that companies adopting generative AI cut junior employment by 7 to 12 percent within six quarters. Senior employment stayed flat. The decline was driven by slower hiring, not layoffs. The juniors were not fired. They were never hired in the first place.

Stanford's Digital Economy Lab found that employment for developers aged 22 to 25 dropped roughly 20% from its late-2022 peak. CS graduate unemployment sits at 6.1%. For ages 22 to 27, it is 7.4%, nearly double the national average.

Big Tech junior hiring fell from 32% of new hires in 2019 to 7% today. Salesforce halted new engineer hiring entirely. Klarna froze developer recruitment. A LeadDev survey found that 54% of engineering leaders plan to hire fewer juniors going forward. AI was the reason given every time.

The math is straightforward. If a senior developer with AI tools produces the output of a senior plus two juniors, the two juniors do not get hired. That is not ideology. It is a spreadsheet.

Camp One: Juniors Are Dead Weight

The efficiency camp does not enjoy saying this out loud, but they are thinking it. A senior engineer with Copilot, Cursor, or Claude Code ships more code in a week than a junior ships in a month. The code is better. It needs less review. It has fewer bugs. The senior already knows the architecture, the edge cases, the patterns. The AI compresses the implementation. The junior was the implementation.

Dario Amodei, the CEO of Anthropic, said it plainly: entry-level jobs are squarely in the crosshairs. He predicted AI could eliminate 50% of entry-level white-collar jobs within five years. He said leaders were sugar-coating what was coming.

Companies report 40 to 55 percent more code output per sprint after adopting AI coding tools. The velocity gains are real. The developer grind that produces them is relentless. And most of that velocity came from eliminating the work that juniors used to do: the boilerplate, the CRUD endpoints, the straightforward implementations that a senior would spec and a junior would type.

This camp will tell you that the market is correcting. That the industry over-hired juniors for years because implementation was expensive. That AI made implementation cheap. That hiring someone to do cheap work at expensive wages is not sustainable. That this is not cruel. It is math.

Camp Two: We Are Eating Our Seed Corn

The pipeline camp has one question the efficiency camp cannot answer: where do future seniors come from?

Matt Garman, the CEO of AWS, called replacing juniors with AI one of the dumbest things he has ever heard. His argument: they are your cheapest employees, your most AI-engaged learners, and if you stop hiring them now, you will have nobody who learned anything when you need senior engineers ten years from now.

Microsoft's Mark Russinovich and Scott Hanselman published a paper in the Communications of the ACM warning that companies are optimizing for short-term throughput while the pipeline that produces future seniors quietly collapses. Their projection: a reduction in junior hiring between 2024 and 2026 means a proportional senior shortage between 2031 and 2036.

Fast Company ran a piece documenting what happens when you eliminate juniors: burnout. Senior engineers expected to absorb junior workloads plus manage AI tools are burning out faster than companies can replace them. The seniors who were supposed to benefit from not having juniors to mentor are drowning in the work juniors used to share.

This camp will tell you that senior engineers do not appear from nowhere. They are built. Through years of shipping bad code and learning from the failure. Through debugging production incidents at 2am and understanding why the shortcut they took six months ago is the reason they are awake. Through code reviews where a more experienced developer explained not just what was wrong but why it mattered.

Remove that process and you do not get a more efficient industry. You get an industry with a ten-year expiration date on its talent supply. The security consequences of that talent gap are already visible.

The Learning Paradox Nobody Talks About

There is a deeper problem underneath the hiring numbers. AI does not just replace junior work. It replaces junior learning.

Anthropic's own research found a 17-point comprehension gap between developers who learned with constant AI assistance versus those who coded manually. Debugging skills showed the largest deterioration. The developers who used AI the most understood the least about what they built.

A randomized trial by METR found that experienced open-source developers using AI were 19% slower on average but believed they were faster. If experienced developers misjudge their own productivity with AI, imagine what happens to someone who has never worked without it.

The junior developer who never struggled through a bad database schema never learned why normalization matters. The one who never optimized a slow query by hand never developed intuition for what the database is actually doing. The one who never shipped without tests and got paged at 2am never internalized why testing is not optional.

The pain was the education. Remove the pain and you remove the education. What remains is someone who can prompt an AI to produce code they cannot evaluate, debug, or explain. That is not a junior developer. That is an operator who does not understand the machine they are operating. And when their code passes through a review process that has become a rubber stamp, there is no safety net left.

The Trust Problem

Research shows that junior developers trust AI output at 78%. Seniors trust it at 39%. That gap is not about skepticism versus enthusiasm. It is about pattern recognition.

A senior developer has seen enough production failures to know where AI tends to go wrong. They have intuitions about security, performance, and maintainability that were built through years of consequences. When the AI produces something that looks clean but has a subtle flaw, the senior catches it because they have been burned by that class of flaw before.

A junior developer does not have that library of failures. They cannot evaluate what they cannot contextualize. They accept the output because they have no basis for skepticism. The code compiles. The tests pass. The PR gets approved. The flaw ships to production and nobody knows until a customer finds it.

The paradox: AI is most dangerous in the hands of the people most likely to trust it completely. And the people most likely to trust it completely are the ones with the least experience to validate what it produces.

Neither Camp Has a Plan

The efficiency camp has no answer for the pipeline problem. You cannot run an industry on seniors forever. They retire. They burn out. They leave for management or consulting or farming or whatever people do when they are tired of being on call. If nobody replaces them, you do not have a talent shortage. You have a talent extinction.

The pipeline camp has no answer for the economics. Telling companies to hire people they do not need for work that can be automated is not a workforce strategy. It is charity with a training label. No CFO is going to approve headcount for someone whose primary value is that they might become useful in seven years.

The real answer is probably somewhere in the middle, and neither camp wants to hear it. The junior developer role as it existed from 2010 to 2022 is gone. The work that defined it, the boilerplate and the basic implementations, is automated. That specific job is not coming back.

But the need for people who are learning to become senior engineers has not gone away. The role has to change. What that looks like, whether it is apprenticeships, preceptorships like Microsoft proposed, or something entirely new, nobody has figured out yet. The industry is moving too fast to stop and think about it, which is exactly why it needs to stop and think about it.

The Question Nobody Wants to Ask

If you are a hiring manager: look at your team in five years. Where do your senior engineers come from? If the answer is other companies, ask yourself what happens when every company has the same plan.

If you are a junior developer: the career path that existed for the generation before you is gone. That does not mean there is no path. It means the path has not been built yet and you might have to help build it. The developers who figure out how to combine AI tools with genuine understanding, not just prompting but actual comprehension, will be extraordinarily valuable. The ones who use AI as a crutch instead of a tool will be the ones the efficiency camp points to when they justify not hiring the next cohort.

If you are a senior developer: the juniors you mentor today are not slowing you down. They are the reason someone will be available to maintain your systems after you move on. The thirty minutes you spend on a code review teaching a junior why their approach has a hidden performance problem is not lost productivity. It is the only investment that produces senior engineers.

The junior developer is not dead. But the junior developer role as we knew it is. And the industry has about five years to figure out what replaces it before the consequences become impossible to reverse.

Chasing Tokens: The Developer Grind Nobody Warned You About

Bojan Josifoski — Thu, 21 May 2026 09:37:46 +0000

It is 3am somewhere and a developer is shipping code they did not type. Across town, another developer is asleep because they refuse to touch AI tooling. Both of them think the other one is making a terrible mistake.

This is the state of software development in 2026. There is no middle ground. The middle ground packed its bags sometime around January and nobody has seen it since.

Camp One: The Token Chasers

You know who these people are because they will not shut up about it. They are shipping at a pace that makes no sense. Projects that would have taken a team of five and six months are coming out of single-person operations in weeks. They talk about context windows the way previous generations talked about RAM. They have opinions about which model handles database schemas better. They have muscle memory for /compact.

Their day does not end at 5pm. It does not end at midnight. It ends when the context window gets too long or when they physically cannot keep their eyes open. Not because someone is making them work. Because the gap between having an idea and seeing it exist has collapsed to almost nothing, and that feeling is difficult to walk away from.

The token chasers will tell you that AI did not make them worse at their job. It made them dangerous. Twenty years of architectural knowledge that they could only partially apply because implementation was the bottleneck, and suddenly the bottleneck is gone. The ideas are the same. The standards are the same. The speed is not.

Camp Two: The Refusers

You know who these people are because they will not shut up about it either. They write every line by hand. They understand every function in their codebase. They have never shipped a line of code they could not explain from memory.

They look at Camp One and see a generation of developers building a dependency on something they do not control, shipping code they did not fully write, at a pace that makes proper review impossible. They see vibe coding dressed up as productivity. They see technical debt being manufactured at industrial scale.

The refusers will tell you that speed is not a feature. That understanding your codebase is not optional. That the developers chasing tokens are building on sand because the moment the model hallucinates something subtle, the moment the API changes, the moment the service goes down, they will be standing in front of production code they cannot debug without their AI crutch.

They Are Both Right

Here is the thing nobody in either camp wants to hear: the other side has a point.

The token chasers are right that AI fundamentally changes the economics of building software. When the mechanical cost of implementation drops to near zero, you stop compromising. The edge cases get handled. The tests get written. The architecture stays intact. You build the thing you actually envisioned instead of the 80% version that the timeline forced. That is real. That is not hype.

The refusers are right that speed creates a temptation to skip the thinking. That plenty of developers are using AI to ship code they do not understand. That vibe coding is real and it is producing software that will collapse under real usage. That building a dependency on a service you do not control is a genuine risk. That is also real. That is also not hype.

The difference between these two outcomes is not the tool. It is the operator.

The Operator Problem

A senior developer using AI to implement decisions they already made is not vibe coding. They designed the schema. They chose the API contracts. They defined the error handling strategy. They know what the tests need to cover. The AI compresses the typing. The thinking was already done.

A junior developer prompting a model and accepting whatever it produces is vibe coding. They did not design anything. They described what they wanted and shipped what they got. The code might work. It might even look clean. But the first time something unexpected happens in production, they will not know where to look because they were never the architect. They were the prompter.

Same tool. Same tokens. Completely different outcomes. And the industry is pretending this distinction does not exist because it is easier to argue about whether AI is good or bad than to admit that the answer depends entirely on who is using it.

What Nobody Warned You About

The discourse is about whether AI produces good code. That is the wrong question. AI produces whatever the operator accepts. The real question is what AI does to the operator.

For experienced developers, it removes the bottleneck that forced compromises. You always knew how the system should be built. Now you can actually build it that way. Every edge case. Every test. Every proper abstraction. The cost of doing it right dropped to near zero, so you do it right.

For inexperienced developers, it removes the learning process that builds the judgment to know what right looks like. You never struggled through a bad database schema and felt the pain six months later. You never shipped without tests and got paged at 2am. You never cut corners on error handling and watched a production system fail silently for weeks. The pain that builds judgment got optimized away, and nothing replaced it.

For everyone, it removes the natural stopping points. The compile time that forced a coffee break. The deploy that took twenty minutes. The test suite that ran for an hour. All gone. Everything is instant. And instant is not always good for the human operating the machine. The token chasers working until 3am are not doing it because they have to. They are doing it because nothing in the workflow forces them to stop. That is a new kind of problem and nobody is talking about it.

The Uncomfortable Prediction

In twelve months, the gap between these two camps will not close. It will widen. The token chasers with strong fundamentals will have shipped production software at a pace that redefines what a small team can do. The token chasers without strong fundamentals will have shipped demos that are starting to collapse. The refusers will have deep understanding of fewer systems and will be watching both groups from the sidelines, unsure whether to feel vindicated or left behind.

The companies that figure this out first will not hire based on whether candidates use AI. They will hire based on whether candidates can evaluate what AI produces. That is a fundamentally different skill than prompting. It is closer to code review than it is to coding. And it requires exactly the kind of experience that the refusers have been building all along.

The irony is thick. The people best equipped to use AI well are the people most skeptical of it. And the people most enthusiastic about AI are often the least equipped to use it without producing garbage.

So Which Camp Are You In?

If you are chasing tokens at 3am, ask yourself: are you building software or are you addicted to the feeling of shipping? Are your standards the same as they were before AI, or have you quietly lowered them because the speed made it easy to justify? Do you understand every system you shipped, or are there files you would struggle to explain without the model's help?

If you are refusing AI entirely, ask yourself: is your position based on principle or on fear? Are you building deep understanding or are you building slowly? Is the tortoise winning or just falling further behind? Will your deep expertise matter more in two years than it does today, or less?

Both questions are uncomfortable. That is the point. The comfortable position does not exist anymore. You are either moving fast and hoping your judgment keeps up, or moving deliberately and hoping the world waits for you.

The tokens do not care which camp you are in. They just keep flowing.

Async Everything: Why Background Processing Matters for Operational Software

Bojan Josifoski — Wed, 20 May 2026 17:31:57 +0000

The first version of most operational software runs everything synchronously. User clicks a button, the server does the work, the response comes back. It works fine until it does not. And when it stops working, it stops working suddenly and visibly, usually when a customer is watching.

I learned this building SampleHQ. The CRM setup flow that worked in development took thirty seconds in production because Salesforce metadata deployment is slow. The CSV import that handled fifty rows instantly choked on five hundred. The shipping label purchase that completed in two seconds occasionally timed out at eight because the Shippo API was under load.

Every one of these was a synchronous operation that should have been asynchronous from the start.

What Breaks Synchronously

External API calls. Any operation that depends on a third-party API is at the mercy of that API's response time. Shippo label purchases, CRM data syncs, carrier tracking lookups, address validation. These calls typically take one to five seconds. But under load, or when the provider has an incident, they take ten, twenty, thirty seconds. The user stares at a spinner and assumes the system is broken.

Bulk operations. Importing five hundred samples from a CSV file means five hundred database inserts, five hundred image downloads, and five hundred validation checks. Running this synchronously locks the browser tab for minutes. The user cannot tell whether the import is progressing or stuck. If they close the tab, the import stops mid-way, leaving partial data.

Multi-step workflows. Connecting a CRM requires OAuth, then capability probing, then metadata deployment, then webhook subscription setup. Each step depends on the previous one, and each involves API calls that can take seconds. Running this as a synchronous chain means a setup flow that takes forty-five seconds of wall time with no feedback.

Nightly maintenance. Attribution backfill, webhook cleanup, deal cache refresh, email log pruning. These jobs run across every tenant in a multi-tenant system. Running them synchronously in a single request is not just slow. It is impossible. They need to run as scheduled background tasks.

Action Scheduler as a Job Queue

WordPress does not have a built-in job queue. WP-Cron is a scheduling mechanism, not a processing queue. It runs on page loads, has no retry logic, and cannot handle concurrent job execution. For operational software, it is insufficient.

Action Scheduler, originally built for WooCommerce, is the job queue I use. It stores pending jobs in the database, processes them on a schedule (every minute via system cron), supports retries with configurable backoff, and handles concurrent execution across multiple workers.

The key architectural decision was loading Action Scheduler early in the plugin bootstrap, before plugins_loaded. This ensures that the scheduler's own hooks register before any business logic that depends on them. Getting this load order wrong causes jobs to silently fail to schedule, which is a category of bug that only manifests in production and is extremely difficult to diagnose.

What We Queue

Eleven distinct background jobs run in the SampleHQ platform:

Attribution backfill runs nightly. It recomputes attribution snapshots for deals whose linked orders or deal amounts have changed. This ensures attribution reporting stays accurate even when CRM data is updated after the initial computation.

Webhook cleanup runs daily. It purges processed webhook event logs and expired idempotency keys. Without this, the webhook tables grow indefinitely in a multi-tenant environment.

Email queue processing runs continuously. Notification emails are never sent synchronously. They are queued and processed by a background worker, which prevents email delivery delays from blocking user-facing operations.

Shipping label purchase is queued per-order. When a user purchases a label through Shippo, the request is queued with retry logic. If the Shippo API is slow or returns an error, the job retries with exponential backoff rather than failing in the user's face.

CSV import processing runs as a background job with progress tracking. The user uploads the file and sees a progress indicator. The import runs in the background, processing rows in batches. When it completes, the user gets a notification with success and error counts.

Image download fallback runs every five minutes. When a CSV import includes image URLs, those images are downloaded asynchronously. If a download fails (URL unreachable, server timeout), the fallback job retries it on the next cycle.

Cancellation lifecycle runs daily. When a subscription is canceled, the system tracks the lifecycle: day three winback email, day seven second email, day fourteen workspace freeze, day thirty suspension, day ninety archive. Each step is a scheduled job triggered by the lifecycle timer.

Plus site summary refresh, AI watch checks, ERP sync log cleanup, and magic link token cleanup.

The User Experience Difference

The difference between synchronous and async operations is trust. When a user clicks "Purchase Label" and sees an immediate confirmation with a "processing" status, they trust the system. When they click the same button and wait eight seconds with no feedback, they assume it failed and click again, which queues a duplicate purchase.

Async operations with proper status feedback eliminate this class of user error entirely. The job is queued instantly. The UI shows the job status. The user can continue working. When the job completes, the UI updates and optionally sends a notification.

Retry Logic and Failure Handling

Every async job needs a failure strategy. The default should be retry with exponential backoff: first retry after ten seconds, second after one minute, third after ten minutes. If a job fails three times, it moves to a failed state and triggers an alert rather than continuing to retry indefinitely.

The failure alert is important because silent failures are worse than loud ones. A shipping label that silently fails to purchase is worse than one that fails and notifies the fulfillment team. The notification gives them the chance to retry manually or investigate the issue.

For critical operations like attribution computation and CRM sync, I also run nightly reconciliation jobs that check for inconsistencies and re-queue failed operations. This safety net catches edge cases where the retry logic itself was insufficient.

The Rule

The rule I follow: if an operation depends on an external API, takes more than two seconds, or processes more than a handful of records, it should be async. The engineering cost of making it async is a few hours per operation. The cost of leaving it synchronous is user frustration, timeout errors, duplicate operations, and support tickets.

SampleHQ runs eleven scheduled background jobs processing CRM syncs, shipping labels, attribution, imports, and email delivery. The result is a system that stays responsive under load and handles failures gracefully instead of showing spinners.

18 Years of WordPress and My First Plugin on WordPress.org

Bojan Josifoski — Wed, 20 May 2026 09:57:05 +0000

I have been building on WordPress since 2008. Themes, plugins, custom post types, REST API integrations, multisite networks, WooCommerce stores. Hundreds of projects across nearly two decades. And until today, I had never published a single plugin on WordPress.org.

That changed this morning. SampleHQ Request Form is now live in the WordPress plugin directory. It is a free, standalone plugin for collecting product sample requests. And building it taught me more about WordPress development standards than the previous 18 years combined.

Why It Took 18 Years

The honest answer: I never needed to. Every WordPress project I built was for a specific client or a specific business. The code lived in private repositories, deployed to specific servers, maintained for specific people. There was no reason to generalize it for public distribution.

Publishing on WordPress.org is a different discipline. Your code runs on servers you will never see, inside configurations you cannot predict, alongside plugins you have never heard of. The standards exist because they have to. When 43% of the web runs on WordPress, a sloppy plugin is not just your problem.

The reason I finally did it is SampleHQ. The platform I have been building as a multi-tenant SaaS needed a way for WordPress users to collect sample requests without signing up for the full platform first. A free plugin that works standalone, with an optional connection to SampleHQ for teams that need CRM integration, fulfillment tracking, and analytics.

What the Plugin Does

The core problem: businesses that ship physical product samples have no good way to collect structured requests. Generic form plugins give you text fields. But a sample request is not a contact form. It has products with SKUs and images, quantities, shipping addresses, and selections from a catalog.

SampleHQ Request Form includes a built-in sample library where you manage products with categories, images, SKUs, and descriptions. The form builder has 17 field types, including a sample picker that lets visitors browse your catalog, filter by category, and select products with quantities. It is structured data from the start, not free text that someone has to parse later.

The form builder is drag-and-drop with multi-column layouts, conditional logic, and a multi-step wizard mode. You embed forms with a Gutenberg block, Elementor widget, or shortcode. Submissions land in a dashboard where you can search, filter, star, and export to CSV.

For WordPress sites already running WooCommerce, the plugin can use WooCommerce products as the sample catalog instead of maintaining a separate library. It adds a "Request a Sample" button to product pages and handles the form rendering in a modal.

Everything works without an external account. No API keys, no SaaS dependency, no feature gates. The optional SampleHQ connection syncs submissions and catalog data to the platform for teams that need more than what a WordPress plugin can provide.

What the Review Process Taught Me

The plugin went through six versions before the WordPress.org review team approved it. That is not a complaint. Every piece of feedback made the plugin better, and several issues were things I would have missed in a private deployment.

The review flagged inline JavaScript event handlers. I had used them in a few admin views. The fix was extracting all inline scripts into properly enqueued external JS files. Standard practice, but easy to skip when you control the environment.

They caught a CSS injection feature I had included for form appearance customization. It let admins enter arbitrary CSS. On a single-site install where the admin is the owner, that is fine. On a multisite where admins might be tenants with limited trust, it is a stored XSS vector. I removed it and replaced it with a fixed set of CSS custom properties for theming.

File upload validation needed tightening. I was checking MIME types but not using is_uploaded_file() to verify the file came from an actual HTTP upload. The review caught that. They also flagged that I was not recursively sanitizing JSON when importing form configurations, which could have been a vector for injecting unsanitized data into the database.

The redirect handling needed wp_safe_redirect() instead of wp_redirect() with an allowed_redirect_hosts filter. Admin notices needed scoping to plugin pages only. The sslverify flag in a self-check HTTP request needed to be removed.

Every fix was legitimate. The review process is what separates WordPress.org plugins from the wild west of zip files downloaded from random websites. After 18 years of building WordPress code that only I reviewed, having someone else audit it with security-first thinking was humbling and educational.

Architecture Decisions Worth Noting

A few choices that might be useful if you are building a WordPress plugin in 2026.

Custom tables instead of custom post types. The plugin uses eight custom database tables for samples, categories, forms, submissions, and rate limits. CPTs are great for content, but structured operational data with relational queries, proper indexing, and clean joins works better in custom tables. The plugin includes a versioned migration system that handles schema changes across updates.

React for the builder, vanilla JS for the frontend. The form builder is a full React application using @dnd-kit for drag-and-drop and @wordpress/scripts for the build pipeline. But the public-facing form is server-rendered PHP enhanced with vanilla JavaScript. No React runtime on the frontend. The form works without JavaScript for basic submissions. Progressive enhancement, not a JavaScript dependency.

Form tokens instead of nonces for CSRF. WordPress nonces are tied to user sessions. Public forms have no user session. The plugin generates transient-based form tokens with 24-hour TTL and one-time consumption to prevent replay attacks. Combined with a honeypot field and IP-based rate limiting, this handles spam without requiring a third-party CAPTCHA. Cloudflare Turnstile is available as an optional layer.

PSR-4 autoloading without Composer in production. The plugin registers a custom autoloader that maps the SampleHQForm namespace to the src/ directory. Composer is used for development tooling (PHPStan, PHPCS, testing) but no vendor/ directory ships with the plugin. This avoids the dependency collision problem that plagues WordPress plugins sharing Composer packages.

The Testing Infrastructure

One thing I insisted on from the start: proper test coverage. The plugin has 909 unit tests, 29 integration tests running against a real WordPress instance via wp-env, and 33 Playwright end-to-end test files covering the admin UI, frontend forms, accessibility, responsive behavior, and WooCommerce integration.

For a free WordPress plugin, that might seem excessive. It is not. The plugin runs on servers I cannot access, inside configurations I cannot predict. The test suite is the only way to ship updates with confidence. Every WordPress.org review cycle involved code changes that could have introduced regressions. The tests caught several.

What Comes Next

The plugin is version 1.0.5 on WordPress.org. The GitHub repository is public. Issues, pull requests, and feature requests are welcome.

The immediate roadmap includes more field types, form analytics in the dashboard, and deeper WooCommerce integration. The longer-term goal is making this the standard way WordPress sites collect sample requests, with a clear upgrade path to the full SampleHQ workflow for teams that outgrow what a plugin can do.

After 18 years, publishing something on WordPress.org felt like a milestone. Not because the technology is new, but because the mindset is different. Building for one client is about solving their problem. Building for the directory is about solving the problem correctly for everyone. That distinction took me too long to appreciate.

SampleHQ is the platform behind this plugin. For teams that need CRM integration, fulfillment tracking, and revenue attribution on top of sample requests, the plugin connects with one click.

Building an AI Agent That Queries Operational Data (Not Just Chats)

Bojan Josifoski — Wed, 20 May 2026 09:55:30 +0000

There are two kinds of AI integrations in operational software. The first wraps a language model around documentation and lets users ask questions about how the product works. That is a support chatbot. It is useful, but it does not touch operational data.

The second gives the AI agent structured access to the operational database through purpose-built query tools. The agent can look up orders, search samples, check attribution data, and surface patterns. That is what I built for SampleHQ's AI assistant, and the architecture behind it is worth explaining because the difference between these two approaches is the difference between a toy and a tool.

Why Generic Chat Fails for Operational Data

A generic chatbot connected to a database has two failure modes. Either it generates SQL queries directly, which risks both incorrect results and security vulnerabilities, or it summarizes data it has seen in its training, which means hallucinated numbers that look plausible but are fabricated.

When a sales leader asks "how many samples did we send to Acme Packaging this quarter?" the answer must be exact. Not approximately. Not "based on typical patterns." The answer needs to come from the actual database, reflect the actual data, and be verifiable. A language model generating SQL might join the wrong tables, misinterpret a date range, or return results from the wrong tenant in a multi-tenant system.

The solution is to never let the AI touch the database directly. Instead, give it tools.

The Tool-Based Architecture

Modern language models support function calling, also called tool use. Instead of generating SQL, the model describes what it wants to know, and the system executes a pre-built function that returns the result. The model then formats that result into a natural language response.

For SampleHQ, the AI agent has access to several query builders, each designed for a specific domain:

OrderQueryBuilder. Searches orders by account, date range, status, recipient, or sample content. Returns structured results with order IDs, statuses, and delivery dates. The query is parameterized and runs against indexed columns. No SQL generation involved.

SampleQueryBuilder. Searches the sample catalog by name, category, SKU, or availability. Returns structured results that the AI can reference when answering questions about what samples exist or what has been sent most frequently.

AttributionQueryBuilder. Queries the attribution data model: orders linked to deals, credit assignments, close dates, and influenced revenue. This is the most complex query builder because it joins across orders, CRM links, attribution snapshots, and deal cache tables.

CustomerQueryBuilder. Searches customer and contact data, including CRM-synced information. Useful for questions like "what is our history with this account?"

Each query builder validates its inputs, constructs a safe parameterized query, executes it, and returns a structured result object. The AI model never sees raw SQL, never has direct database access, and cannot return data that does not exist in the database.

Why This Prevents Hallucination

The key insight is that the AI model is constrained to what the tools return. If the OrderQueryBuilder finds no orders matching the criteria, the model gets an empty result set. It cannot invent orders. If the AttributionQueryBuilder returns $42,000 in influenced revenue, the model reports $42,000. It cannot round up to $50,000 because that sounds better.

This is fundamentally different from a model that generates answers from its training data or from unstructured context. The tools act as a ground-truth layer between the model and the data. The model handles natural language understanding (parsing the question) and natural language generation (formatting the answer). The tools handle data retrieval. Neither can do the other's job.

Context Injection

The AI agent is more useful when it has context about what the user is looking at. If a user is on the order details page for Order #412 and asks "when was this delivered?" the agent should know they mean Order #412 without being told.

A context layer injects page context into the AI conversation. The current page, the selected order, the active filters, and the visible data summary are all included in the system prompt. The agent uses this context to interpret ambiguous queries and provide relevant responses without the user having to specify what they are asking about.

Multi-Provider Support

One design decision that proved valuable: the AI layer supports multiple providers through a factory pattern. The system works with OpenAI, Anthropic's Claude, and other providers through OpenRouter. Each provider uses the same tool definitions and the same query builders. The difference is in the model's reasoning quality and response style.

This matters for two reasons. First, enterprise customers often have approved vendor lists. If their organization has approved Anthropic but not OpenAI, the AI features still work. Second, different models have different strengths. Claude tends to be more careful about caveats and qualifications in analytical responses. GPT-4 tends to be more direct. Letting customers choose their provider gives them the interaction style that fits their preference.

Credentials are stored encrypted per-tenant, and the provider factory instantiates the correct client based on the tenant's configuration. Switching providers does not require any code changes. It is a settings change.

What the Agent Cannot Do

Constraints are as important as capabilities. The AI agent can read data through query builders. It cannot write data. It cannot change order statuses, send emails, modify attribution, or perform any destructive action without explicit user confirmation through the standard UI.

This is a deliberate design choice. Operational data has consequences. Changing an order status triggers notifications and updates dashboards. Sending a follow-up email reaches an actual customer. These actions should go through the same permission checks and audit logging as any other user action, not through an AI agent that might misinterpret a request.

The agent can draft a follow-up email. It cannot send it. It can suggest that an order should be escalated. It cannot escalate it. The human stays in the loop for every action that changes state.

The Pattern

If you are building AI features into operational software, the pattern is: give the model tools, not database access. Build query builders for each data domain. Validate inputs in the query builders. Return structured results. Let the model handle language, not data. Inject page context for relevance. Support multiple providers for flexibility. And never let the agent write data without human confirmation.

This produces an AI assistant that is genuinely useful for operational questions, reliably accurate because it can only return real data, and safe because it cannot modify anything autonomously.

This architecture powers SampleHQ's AI assistant. It queries orders, samples, attribution, and customer data through purpose-built tools. It cannot hallucinate numbers because it can only return what the database contains.

How I Built a Programmatic Video Engine for SaaS Product Demos

Bojan Josifoski — Fri, 15 May 2026 12:39:56 +0000

Every SaaS product needs a demo video. The standard options are screen recording, which looks amateur and breaks every time the UI changes, or hiring a motion designer, which costs thousands of dollars and takes weeks. Both produce a static artifact that is outdated the moment you ship a new feature.

I needed a product walkthrough for SampleHQ. Instead of choosing between those two bad options, I built a third: a React-based framework that generates cinematic demo videos programmatically. The result is remotion-cinematic, an open-source template built on Remotion.

Here is the video it produced:

Why Code Instead of a Screen Recording

A screen recording captures pixels. When you redesign a page, rename a feature, or change the navigation structure, the recording is wrong. You re-record, re-edit, re-export. Every time.

A programmatic video captures intent. The video is a React composition that renders your actual UI components. When the UI changes, you update the component and re-render. The choreography, camera movement, cursor interactions, and transitions stay intact. The whole process takes minutes, not days.

There are other advantages. Version control. Branching. Code review. The same workflow you use for your product applies to your marketing video. You can diff two versions of a demo video the way you diff two versions of a feature.

What Remotion Cinematic Does

Remotion is a framework for making videos with React. You write components, they render frames, and Remotion stitches those frames into an MP4. It is excellent infrastructure but it does not solve the choreography problem. Moving a cursor smoothly across the screen, timing window entrances, coordinating camera movement with scene transitions: that is a lot of custom code.

Remotion Cinematic is the layer on top. It provides:

Prop-driven choreography. Every visual element, including window positions, sizes, entrance animations, rotation, and z-index, is defined as an input prop. You edit values in Remotion Studio's right panel and see the result immediately. No code changes for layout tweaks.

Geometry-aware cursor. The cursor targets real elements by their DOM ID. It follows arc, linear, or eased curves between waypoints. When it clicks a button, the button actually responds. When it drags a window, the window moves. The cursor changes shape based on what it is interacting with.

Scene-relative camera. Camera keyframes reference scene names, not absolute frame numbers. If you change a scene's duration or reorder scenes, the camera timeline adjusts automatically. The camera supports zoom, pan, and rotation with per-keyframe easing.

A full visual editor. Click any element in the preview to select it. Drag to reposition. Use handles to resize. Snap guides appear when elements align. Double-click text to edit inline. A floating property panel shows context-aware controls for whatever is selected. There is a visual cursor path editor with SVG overlays for drawing and adjusting cursor movement.

App UI from JSON. A descriptor format defines entire app interfaces: sidebars, navigation bars, data tables, stat cards, chat panels. Drop in a JSON object and the framework renders a full application interface with interactive elements. The descriptor can be generated from Figma files or screenshots.

Figma and screenshot import. A CLI tool converts Figma frames into app descriptors via the Figma REST API. Alternatively, point it at a screenshot and Claude vision generates the descriptor. Either way, you go from a design to a rendered app UI in the video without manually coding components.

The Architecture

The framework is organized into three layers.

The engine handles motion. It includes the choreography system (resolving window positions at any frame), the cursor system (interpolation, anchoring, shape switching), the camera rig (global transforms applied to the composition), and the audio manager (music bed with auto-fade, sound effects with volume ducking).

The primitives are reusable visual components. macOS-style windows with traffic lights. Serif headlines with word-stream animation. An end card with logo and call to action. Push transitions that slide scenes continuously instead of cutting. 17 app-ui building blocks that compose into realistic application interfaces.

The editor is a separate layer that reads and writes input props. The composition itself is pure: it receives props and renders frames. The editor overlays selection boxes, drag handles, snap guides, and property panels on top. This separation means the editor can be disabled for production renders without touching composition code.

The interaction layer ties everything together. A UIKeyframe system defines state changes on a timeline: at frame 24 the sidebar highlights item 1, at frame 40 the tab switches to "Orders," at frame 56 a table row highlights. These keyframes sync with cursor actions. When the cursor clicks a sidebar item, the sidebar responds. No manual wiring required.

Claude Integration

The template includes a Claude skill file that teaches Claude the full API. When you open the project in Claude Code, Claude can add new scenes from a description, wire up cursor choreography, build app UI from screenshots, and adjust timing and easing. The same AI-assisted approach that works for operational software works for video production.

This is not a gimmick. Scene creation involves writing a React component that uses specific engine APIs, registering it in the composition, adding window layout entries, defining cursor waypoints, and setting camera keyframes. Having Claude handle the boilerplate while you focus on creative direction is a genuine productivity multiplier.

The Numbers

The framework has 509 tests covering the engine, primitives, editor, CLI, schema validation, and end-to-end wiring. It ships with 5 example scenes: a chaos desktop, product reveal, feature showcase, headline, and end card. The tech stack is Remotion 4.x, React 19, TypeScript 5.9, and Zod for schema validation. Output is 1920x1080 at 30fps.

The entire thing is MIT licensed. Clone it, swap in your screenshots and brand colors, and you have a cinematic product demo.

npx degit codeverbojan/remotion-cinematic my-video
cd my-video
npm install
npm run studio

What I Learned

Three things surprised me during the build.

First, the visual editor was harder than the engine. Getting drag-to-move, resize handles, snap guides, and inline text editing to work correctly inside Remotion Studio required a careful separation between the editor overlay and the composition iframe. The postMessage bridge between them is where most of the complexity lives.

Second, scene-relative timing is essential. Early versions used absolute frame numbers for everything. Changing one scene's duration broke every cursor waypoint and camera keyframe that followed. Referencing scene names instead of frame numbers eliminated an entire class of bugs.

Third, the prop-driven approach pays for itself immediately. Being able to hand the Remotion Studio interface to someone who does not write code and let them adjust copy, colors, timing, and layout without touching a source file changes who can iterate on the video. The feedback loop goes from "file a request and wait" to "change it and preview."

Try It

The repository is at github.com/codeverbojan/remotion-cinematic. The README has a quickstart, customization guide, and full project structure. The docs folder covers the engine API, scene creation, and advanced customization.

If you are building a SaaS product and need a demo video that does not go stale, this is the approach. Fork it, make it yours, render it.

SampleHQ is the product this framework was built to demo. It manages samples, tracks fulfillment, and connects sample activity to pipeline data.