# Everlabs – full content index

> Web and mobile software development agency. Agents do the work in an agentic AI workflow; Everlabs answers for delivery and quality. Logistics, SaaS, and e-commerce for startups and enterprise. Ruby on Rails, React, iOS, Android – full-cycle from ideation to support.

Everlabs is a software development agency. We design and build full-cycle products: ideation, UX/UI, web development, mobile development, and ongoing support – all delivered through an agentic AI workflow where agents do the work and Everlabs answers for delivery and quality. Agents are in the setup from day one: a working proof of concept on real client data within days, AI running through the whole pipeline from PRD and discovery to tested, verified releases – with human engineers accountable for everything that ships. The discipline behind it is context engineering: feeding agents the right specs, codebase knowledge, and acceptance criteria so their output ships reliably. Our specialty stack is Ruby on Rails on the backend with React and native mobile on the frontend, and we have shipped logistics platforms, SaaS products, and e-commerce systems used by millions. Everlabs has operated since 2013 and is rated 5.0/5 on Clutch across 10 verified client reviews, with a willingness-to-refer score of 5.0.

This document inlines the full body of every public article and case study, in addition to listing the URLs. For the link-only short version see `https://everlabs.com/llms.txt`. Markdown mirrors of every page are available by appending `.md` to any URL on this site.

## FAQ

- **How fast can Everlabs deliver a proof of concept?** A working proof of concept on your real data, built and demonstrated in days – you see results before you commit to a build.
- **What is an agentic development workflow?** Agents do the work; Everlabs answers for it. AI runs through the whole delivery pipeline – PRD and discovery, specs, coding, QA, release verification – while the responsibility for delivery and quality never leaves our engineers.
- **What is context engineering?** Feeding agents the right specs, codebase knowledge, and acceptance criteria so their output ships reliably.
- **What does Everlabs build, and for which industries?** Custom web and mobile applications – Ruby on Rails on the backend, React and native iOS/Android on the frontend – mostly for logistics, SaaS, and e-commerce.
- **Who is responsible for quality when AI agents write code?** Everlabs engineers. Every release is tested and verified before it ships.
- **What do Everlabs projects cost?** Engagements start at around $5,000; most projects fall in the $50,000–200,000 range at $25–49/hr, per the public Clutch profile.
- **How long has Everlabs been operating?** Since 2013, with offices in Cherkasy, Ukraine and Dover, Delaware, US.

## Main pages

- [Home](https://everlabs.com/index.md): Services overview, featured portfolio, technology stack, testimonials, and contact.
- [Blog](https://everlabs.com/blog.md): Long-form articles on web and mobile development.
- [Careers](https://everlabs.com/careers.md): Open positions and team culture.
- [Terms](https://everlabs.com/terms.md): Terms of service and privacy policy.

## Case studies


### Gold Avenue

URL: https://everlabs.com/projects/gold-avenue
Markdown: https://everlabs.com/projects/gold-avenue.md

Buy, sell & store precious metals

Buy, sell & store precious metals

**Technologies:** RoR, HTML5, CSS, JavaScript, React, Next.js, TypeScript, Node.js

**Services:** Iconography, Information architecture, UI/UX, Web development, API & Integrations


### Trainual

URL: https://everlabs.com/projects/trainual
Markdown: https://everlabs.com/projects/trainual.md

Onboarding staff worldwide via app

Onboarding staff worldwide via app

**Technologies:** KOTLIN, SWIFT, HTML5, CSS, RoR, JavaScript, React

**Services:** Web development, Mobile development, API & Integrations


### ChangeSync

URL: https://everlabs.com/projects/changesync
Markdown: https://everlabs.com/projects/changesync.md

Enterprise Change Management Software

Enterprise Change Management Software

**Technologies:** React, RoR

**Services:** Research, Information architecture, UI/UX, Web development, API & Integrations, Support, Consulting


### AssetSpace

URL: https://everlabs.com/projects/assetspace
Markdown: https://everlabs.com/projects/assetspace.md

Bringing Clarity to Fixed Asset Management

Bringing Clarity to Fixed Asset Management

**Technologies:** KOTLIN, React, SWIFT, RoR

**Services:** Research, Brand design, Imagery, Iconography, UI/UX, Web development, Mobile development, API & Integrations, Support


### Visit Cherkasy

URL: https://everlabs.com/projects/visit-cherkasy
Markdown: https://everlabs.com/projects/visit-cherkasy.md

Social travel-promotion project

Travel software, created in collaboration with local state institution. The mobile app is designed and crafted for free as part of a social travel-promotion initiative.

**Technologies:** KOTLIN, SWIFT, RoR

**Services:** UI/UX, Mobile development, API & Integrations, Support


### Fuel delivery

URL: https://everlabs.com/projects/fuel-delivery
Markdown: https://everlabs.com/projects/fuel-delivery.md

Mobile app for curbside fuel delivery

Custom iOS and Android mobile apps for the company that delivers fuel direct to parked cars on behalf of car-sharing companies and private clients

**Technologies:** KOTLIN, SWIFT, RoR, React, HTML5, CSS, JavaScript

**Services:** Print design, Information architecture, UI/UX, Research, Web development, Mobile development, API & Integrations


## Articles


### Proven or top-notch: how we choose technology for a client project

URL: https://everlabs.com/blog/technology-adoption-without-over-engineering
Markdown: https://everlabs.com/blog/technology-adoption-without-over-engineering.md
Author: Oleg Pasko
Published: 2026-08-28
Reading time: 7 min

Technology adoption without over-engineering: we try new tools on our own work, never first on a client project, and price the risk into the estimate.

In autumn 2018, I was at a conference in Boston, wearing a T-shirt from one of our projects, which is how the conversation with the people sitting next to me started. Their product was about the same age as ours and, as they described it, still a long way from a release date. Ours had gone live four months after development started.

Nothing about our stack was clever. Ruby on Rails, a ready-made template instead of a custom design, and not one component chosen because it was new. Theirs was the opposite bet: a rich client-side framework of that generation – as I remember it, an early Angular – chosen when that was the modern answer.

If my memory of the framework is right, that generation was already on a countdown. [Active development on the AngularJS 1.x line had formally stopped](https://endoflife.date/angularjs) that June, and the successor was an incompatible rewrite: the same name, a different framework. An official upgrade library existed and still ships. What it could not make cheap was the architectural move underneath it.

One hallway conversation is not evidence, and I am not claiming their framework is the reason they were late. The narrower point is the one I still work from: we had chosen nothing for its novelty, and we were live.

## The rule we work by

So here is the rule, and it is older than the current argument about AI. We follow the trends closely. We monitor new frameworks, new gems, new agent harnesses, whatever somebody dropped into the internal channel this morning, and we try them. **What we do not do is learn a technology on a client's codebase.**

The experiments run on our own work, in our own repositories, where a bad bet costs us time and costs a client nothing. When something looks promising, we want to see it working on something real, and we want to have broken a version of it ourselves. Only after that can we put an honest number on it. **Enthusiasm is not an estimate.**

## What top-notch actually means

Top-notch is the wording I keep coming back to, and it does not mean newest. Proven tends to get heard as old, as though maturity and ambition sat at opposite ends of one scale. They do not. When the ambition is to reach users and keep changing the product in front of them, the mature choice is the ambitious one.

[Six years ago I used the same word about Ruby on Rails](https://everlabs.com/blog/is-ruby-on-rails-still-worth-using-in-2020), and the line I kept repeating then still holds: "Make your project popular first and decide how to improve the speed after." I would not change the argument today. Rails is still shipping releases in 2026. That is a duller way of being right than picking the breakout winner, and a more useful one.

Applied technology evolves the way anything under selection does. One origin, a fan of branches, and most of the branches stop: reasonable approaches that got tried and did not survive contact with real projects. What is left after several rounds of that is not the newest branch. It is the branch that kept being chosen. **Top-notch is a position on that tree, not a release date.**

![A diagram titled how an approach earns its place, read from left to right as an evolution tree. A single dark square on the left bursts into a fan of pale grey rays, like a sun, and almost all of them stop short and are capped with a short stop tick to mark an approach that did not survive. Only one ray continues, and where it lands the burst happens again, five times in all, with each burst smaller than the last. The one line that survives every round is drawn dark and unbroken across the whole diagram and ends in a red square. The six points along it are labelled underneath: everything new, worth an experiment, tried on our own work, estimated honestly, used on client work, and, at the red end point, top-notch.](/uploads/blog/technology-adoption-without-over-engineering/evolution-of-approaches.svg)

Watching those failures happen from a distance is a large part of the work, and the cheapest way to learn any of it.

## Why proven is cheaper

The reason is not taste. When we put a technology into a product, we are committing to keep that product running afterwards, and that commitment is only worth something if we can predict what maintaining it looks like. A proven component comes with known failure modes, a known upgrade path, and people who have already walked into its walls. **Something adopted because it looked promising has none of that, and the bill for finding out arrives later, in somebody else's budget.**

The expensive failure is rarely the first build. It is the re-architecture two years later, when an integration has to be rewritten because the layer underneath it changed shape, or a plugin has to be reconnected because the thing it plugged into stopped being maintained. None of that reaches the first invoice, which is part of why it so rarely reaches the decision.

## The rule in the AI era

The rule has not changed in the AI era. The surface it applies to has. There are more plausible ways to build the same product than at any point I have worked through, and they move monthly. Most of them are younger than the estimate they would be used to justify.

So an estimate from us for a new project arrives as a range rather than a number, and the range is wide enough to need explaining. What the range measures is not difficulty. It is method. At the high end sits the classic path: people writing the code, the most hours, and the strongest guarantee we can give. **In the middle is AI-assisted delivery, which is how we actually work today** and what I described [in the last article](https://everlabs.com/blog/ai-assisted-development-summer-2026). At the low end, the machine carries more of the chain, for fewer hours and a much shorter track record. We are piloting that end. We do not present it as how we work, which is exactly why it is priced and flagged separately rather than folded into the rest. The two ends can differ by a multiple.

![A diagram titled one request, one honest range, showing a single horizontal axis with a red bracket drawn around its full width and labelled estimate range, so that the range covers the whole axis rather than any one point on it. The left end of the axis is labelled highest estimate and hand-written code, described as the guarantees we have always given, and as more hours with fewer unknowns. The right end is labelled lowest estimate and AI workflows, described as newer ground that is still settling, and as fewer hours with more unknowns. Underneath the graph, deliberately off the axis, a caption reads keywords, not points on the line, followed by three grey keyword boxes: AI agent factories, agent workflows and spec-driven development.](/uploads/blog/technology-adoption-without-over-engineering/estimate-range.svg)

**We show the whole spread, because the choice inside it is not ours to make.** It is a trade between speed and certainty, and it belongs to whoever owns the product. What we owe is a plain account of what each end costs and what each end guarantees, before anything is signed rather than after something has gone wrong. A single confident number would be easier to read and would hide the only decision that matters. An optimistic estimate does not move the risk anywhere. It just stops naming it.

## Being late is not being wrong

David Heinemeier Hansson made a version of this point from the opposite side, at 00:43:53 of [his August 2026 appearance on the Lex Fridman podcast](https://lexfridman.com/dhh-2/), episode 501:

> "Let me caveat this by saying, if I'd heard myself talk like this nine months ago, I would probably have used the label AI psychosis. I think it would be fitting because nine months ago when people were talking like this, they weren't shipping, and I think that's the ultimate difference."

He is using "AI psychosis" in the industry sense that was current this year, for talk running far ahead of anything working, and he is applying it to himself. He is not arguing for caution. He is arguing close to the reverse: the people who saw it early were seeing something real, and what separated them from the noise was that they shipped. He is also clear that he was not one of them. By his own account, he was skeptical and did not install Claude Code until about six months after its release, while Tobi Lütke was trying to show him what he was missing and not getting through.

That is what I take from it. Seeing something first and being right about it are not the same skill, and arriving later is not the same as arriving wrong. **Shipping is what separates a real signal from noise, and it is not the whole test for us** – we still have to maintain what we ship long after the excitement about it has moved on.

## Who carries the risk

This is the conversation we try to have before a contract rather than after it: what is new, what is proven, what would be getting discovered on somebody's budget, and what we are prepared to guarantee. **The risk of a new thing is ours to carry while it is still new.**

None of that is an argument for standing still. What we run today looks very little like what we ran two years ago. It arrived by the same route each time: watched, tried on our own work, broken, estimated, and only then committed.

What is worth having in a partner is not the first company to try something. It is the one that already tried it somewhere it was allowed to fail and can tell you what it cost.



---


### AI-assisted development we use in 2026: Claude Code, Superpowers, GSD

URL: https://everlabs.com/blog/ai-assisted-development-summer-2026
Markdown: https://everlabs.com/blog/ai-assisted-development-summer-2026.md
Author: Oleg Pasko
Published: 2026-08-16
Reading time: 8 min

Claude Code is our standard harness at this moment, summer 2026 – it can change, and we continuously review the options to pick what works best. What runs on top of it – Superpowers, GSD, Matt Pocock's skills – and how a practice travels from one engineer's experiment to every project.

In May, one of our engineering team leads, Valentyn Dmytriuk, spent a day finding out how many parallel Claude Code sessions in git worktrees one person can actually hold. Peak: 4. Stable: 3. The real finding was about attention rather than tooling: combine task types deliberately, and never stack two maximum-concentration tasks. He later [wrote it up](https://www.linkedin.com/feed/update/urn:li:activity:7463227191296753664/); the rest of us saw it earlier, as a drop in our internal Discord.

That is how ideas travel here: we exchange thoughts in shared channels, some get picked up, and a few make it all the way to standard. This article is about what we run right now, and about that path.

## The privilege of many projects

Everlabs works with many client projects at once (an outsourcing agency, if you prefer). They range from greenfield code written this quarter to systems with a decade of decisions baked in, and from one engineer for a few hours a week to several squads. For validating a practice, that spread is a privilege: a new approach gets pointed at very different codebases within days, and the ones that survive all of them are worth keeping. The ones that only worked on the greenfield project turn out to have been a preference, not a practice.

## What we run right now

Our standard harness today is Claude Code, and the word today is deliberate: it is the standard at this moment, summer 2026, and we do not know what it will be in three months.

It is not only for code. The same harness sits in development, in QA, in project management, and in design work. The skills we write for it cover project management alongside Rails and React, and the engineering and QA sets are being merged into one starting stack for new projects.

I also run ChatGPT and Codex myself. I prefer them for web research, for a second reflection on Claude's results, for deep research, and for personal things. Cross-model review turned out to be a team habit rather than a personal quirk: one model checks another's output before a person reads either, and it catches a class of mistake a model does not catch in its own work.

Beyond that, we check other tools from time to time to see whether something better has appeared, and we follow the trends. Lately that means the open-weight tier: [Kimi K3](https://huggingface.co/moonshotai/Kimi-K3) published its weights at the end of July; [GLM-5.3](https://z.ai/blog/glm-5.3) was announced in mid-August with the weights held back until a security review completes. Neither is what we run on client work – the distance to the frontier is the number we watch.

## Ready-made packs on top of the harness

Two layers get conflated in these conversations. The harness runs the agent: Claude Code, Codex, Cursor. The workflow pack sits on top and decides what the agent does and in what order. There are many ways to organize the same harness, and for development we mostly use ready-made packs rather than inventing our own.

[Superpowers](https://github.com/obra/superpowers) optimizes for discipline, and it is the pack most people land on first – just over a million installs on Anthropic's plugin marketplace as of mid-August 2026. Its skills fire on their own and gate the work: tests before code, a review that blocks on critical issues, a finish step you do not get to skip. Its README is blunt about it: "Mandatory workflows, not suggestions." It is Jesse Vincent's MIT project, distributed through Anthropic's marketplace rather than made by Anthropic. Its brainstorming companion phones home by default – disclosed in the same README, and an environment variable turns it off.

[GSD Core](https://github.com/open-gsd/gsd-core) makes a different bet. The enemy it names is context rot, the quality decay that accumulates as an agent fills its window, and it answers architecturally rather than procedurally: heavy work runs in fresh-context subagents while the main session stays thin, and state lives in files. The original repository was archived in mid-2026; the project continues, community-maintained, as GSD Core.

Both of those own your process. [Matt Pocock's skills](https://github.com/mattpocock/skills) take the opposite position, in his own README: "Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve." His pack ships about two dozen skills you invoke one at a time – `grill-me`, which I come back to below, is one of them – and deliberately does not chain them for you.

For all the disagreement about control, the three packs agree on the order: spec before code – spec-driven development, SDD. GSD's README claims the term outright; Superpowers never uses it but gates implementation behind a design document you sign off; even Pocock's unchained skills run `/to-spec` before `/implement`. The packs differ on how hard that order is enforced, not on the order.

![Three workflow packs compared as stage chains. Superpowers runs brainstorming, then using-git-worktrees, then writing-plans, then subagent-driven-development or executing-plans, then test-driven-development, then requesting-code-review, then finishing-a-development-branch. GSD Core runs a repeating five-phase milestone cycle: Discuss, Plan, Execute, Verify, Ship. Matt Pocock's skills have no single chain by design; the engineering path runs /grill-me or /grill-with-docs, then /to-spec, then /to-tickets, then /implement, which drives /tdd and closes with /code-review.](/images/blog/ai-assisted-development-summer-2026/flow-comparison.svg)

## The bottleneck moved upstream

Writing code stopped being the slow part somewhere in the last eighteen months. Deciding what is worth building did not. If we can build four things in the time it used to take to build one, the price of building the wrong thing went up fourfold too – so product owners and product managers became the narrow point, not because they got slower but because everything downstream of them got faster.

That is why the tooling investment went to the front of the pipeline. Turning a messy screen recording into reviewable specs is one half of it, and I wrote about that [in the last article](https://everlabs.com/blog/video-to-spec). The other half we did not build. [grill-me](https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md), from Matt Pocock's pack, is a relentless interview that keeps asking about a plan until every branch of it is resolved. It writes no files, needs no repository, and the subject does not have to be code. That last part matters: a non-technical person can run it against their own idea, and what reaches a developer afterward is already specified.

The author names the failure mode himself: passivity – forty questions answered "agreed, agreed, agreed", and a plan at the end that "the agent wrote and you nodded at". His documentation is direct about why that is hard to notice: "It feels productive because it was long."

## How a practice travels

There is a fixed path from one person's experiment to the standard board, and each step has an artifact.

One person tries something on the project they are on. It gets written up and shared, internally first and sometimes publicly under their own name. If it holds, it goes into `everlabs-skills`, our shared internal skills library on GitLab – added this year, private and shared by choice. Its README states the goal: same quality bar, every project, every developer. From there a practice gets taught – we ran four AI Fluency cycles in the first half of this year – and only after that does it move onto the standard board.

![How a practice travels at Everlabs, in five steps, each with its artifact. One, one person tries it: a day of parallel agent sessions in git worktrees. Two, it gets written up: an internal write-up, then a public post under the engineer's own name. Three, it enters the shared library: the everlabs-skills repository, private and shared by choice. Four, it gets taught: an AI Fluency cycle, four of which ran in the first half of 2026. Five, it becomes standard: it moves onto the standard-practice board, expected on every project.](/uploads/blog/ai-assisted-development-summer-2026/practice-travel.svg)

That path is where the obvious client question sits, so here is the boundary. **What travels between projects is method:** skills and prompts, harness configuration, review checklists, spec templates, and observations at the altitude of "this approach held up on a legacy Rails application". **What never leaves a project is the project:** code, diffs, schemas, data, domain logic, client names, and business context. The skill that encodes how we review database migrations contains no migration. If a thing cannot be written down without a client's system inside it, it does not go into the shared repository, and it does not go into an article either.

## Standard, and still experimental

Standard practice, expected on every project now: agent skills and IDE rules, and one rule that matters to me more than any adoption statistic – no code before the spec is approved. That is spec-driven development held as a house rule, whichever pack happens to enforce it.

Still experimental, running on real work but not claimed as normal: the full agentic loop end to end, ticket to spec to implementation to review to merge, with the machine carrying the whole chain. We are piloting it. We are not going to describe it as how we work.

Which is the shorter way of saying we are AI-assisted, not AI-agentic. In August 2026 the claim of being fully agentic is close to universal, and a universal claim carries no information. The useful statement is where the human still stands, and ours stands at the gates: a person approves the spec, a person answers for the review, a person verifies the release. Agents do the work. We answer for it.

## With a deliberate expiry date

All of the above is dated. The harness will move, the packs will move, and the model names here will read as quaint by spring. That is the point of saying at this moment: a standard nobody is willing to date is not a standard, it is a habit with better presentation.

What takes something off the board is the same path that put it there: something else has to go through one person, a write-up, the shared library and a teaching cycle, and come out better. That is a slower trigger than the release notes, which is the point of having one.

What does not expire is the method. Point one practice at a system you started last month and a system you inherited nine years ago, in the same week, and the ones that survive both are worth writing down. That will still hold when every tool named here has been replaced.



---


### From a Loom walkthrough to user stories: an open Agent Skill that turns screen recordings into specs

URL: https://everlabs.com/blog/video-to-spec
Markdown: https://everlabs.com/blog/video-to-spec.md
Author: Oleg Pasko
Published: 2026-08-07
Reading time: 6 min

Recording feedback as a Loom is easy; turning it into work is not. video-to-spec is the open Agent Skill I built to close the gap – user stories with the screenshots attached.

Most of my product feedback – and by now a lot of our projects' feedback – starts as a Loom. I open the thing I want to improve, hit record, and think out loud while browsing it: ideas, small annoyances, half-formed feature requests, the occasional "wait, no, forget that", "this is weird". It is the most honest snapshot of what I want, and nobody can build from it.

So someone watches it and writes the tasks. What comes out is their reconstruction of my vision, and the part carrying most of the meaning – what was on screen when I said it – does not survive the trip into a ticket.

Writing the requirement down properly is itself the problem. You censor the brainstorm out of it, because a strict spec is a courtesy – you respect whoever has to work with that file after you. (Not that we do not respect AI – I would rather stay on its good side, and we do say thank you.)

That respect is what restricts you. No jumping between ideas, no going back on what you said two minutes ago, no half-formed thoughts on the page. A recording has none of those rules, and cleaning it up afterwards is mechanical work – the part AI is actually good at.

## What I built

video-to-spec turns a screen recording into specs: a folder of user stories, each carrying the exact screenshots I was looking at when I spoke. It reads anything ffmpeg reads: a downloaded Loom, a QuickTime capture, `.mp4`, `.mov`, `.webm`. No new service, no account, no Loom integration: you point it at a file on your disk and it writes markdown next to your code. MIT-licensed, and the first skill in our [public-skills repo on GitHub](https://github.com/everlabs/public-skills).

![How video-to-spec works: recording to frames and transcript, to timeline, to task extraction, to spec folder](/images/blog/video-to-spec/scheme.svg)

## How it works

ffmpeg pulls one frame per second out of the video. A perceptual hash throws away the near-identical ones – ImageMagick if you have it, Python's imagehash as the fallback – so a cursor drifting across a static page collapses into one frame, while modals, scrolls, navigation and form input survive as separate screens.

For the words, the cheapest path is the one where you already have them: if the recording comes with an `.srt` or `.vtt` beside it, the skill skips transcription. Loom transcribes on every plan, though [downloading the caption file](https://support.atlassian.com/loom/docs/loom-video-transcription-and-closed-captions) is a Business or Enterprise feature.

Otherwise it transcribes. If mlx-whisper or openai-whisper is installed on your machine, the skill prefers those – free, and your audio never leaves the laptop. If neither is there, it can call OpenAI's API at their [published Whisper price](https://developers.openai.com/api/docs/pricing) of $0.006 per minute as of August 2026; there it is told to estimate the cost, say plainly that your audio is being uploaded, and wait for a yes. It never installs anything on your behalf.

Every spoken segment is then matched to the screen that was visible when it was said. The skill reads that timeline looking for four kinds of signal:

- **Direct tasks** – "we need to make sure...", "let's fix...", "this should...".
- **Reversals** – "wait, actually", "no, scratch that". The later statement wins, and the earlier intent is rewritten or dropped.
- **Dissatisfaction** – "this is weird", "doesn't make sense", "would be better if". These become a task only when the change can be named; otherwise it is logged as an open question.
- **Indirect requirements** – something visibly wrong in the frame that I am describing but never actually asking anyone to fix.

The frame, not the words alone, is the source of truth for what I was looking at. That is the reason to extract tasks from a video rather than its transcript.

## What comes out

A folder in your repo, named after the recording and the day it was made: an index with the task list and open questions, one numbered file per task, and the frames they reference.

Each task file carries a short imperative title, a type, the source timestamps, a user story, the motivation, the context with screenshots inline, and what to do. What and why, not how.

Everything is drafted first, then the skill asks its questions in one batch: ambiguities, contradictions, places it over-reached. You answer once and the affected specs are updated. I supervise at a named gate, I do not author.

The folder is delegable. To sub-agents, to an AI coding agent, or to a human team – it is markdown with screenshots, and a person reads it as easily as a model.

## A real run

The last one I ran was 4 minutes 16 seconds long: a walkthrough of a playground project of mine, a small macOS menu-bar app that records my meetings. It came back with nine task specs. All nine are implemented, and one of them by not building it: the spec had captured a non-goal.

Part of that recording is me demoing [Wispr Flow](https://wisprflow.ai/r?OLEG44) (referral link), a voice-to-text tool I really like, and pointing at its dropdown because I wanted the same submenu in mine. The spec came back carrying my own words – "Past notes. I also would like to introduce a new past notes. We already have the account and we can pull it from the hub." – and the exact frame I was pointing at.

![A generated task spec: Add a Past notes list, with user story, motivation quoting the recording, and the matched frame](/images/blog/video-to-spec/example-spec.svg)

The transcript actually heard "fast notes". It came back in the batch of clarifying questions, I confirmed "Past notes", and the spec was fixed before any code was written.

## One SKILL.md, any agent

video-to-spec is an **Agent Skill** – a folder with a `SKILL.md` in it, following the standard documented at [agentskills.io](https://agentskills.io). The format was originally developed by Anthropic, released as an open standard, and is now read by a growing number of agent products.

So it works with Claude Code, Codex, Cursor, OpenCode, Gemini CLI and dozens of other skills-compatible agents – not because anyone shipped an integration, but because they all read the same file. Progressive disclosure keeps it cheap: your agent loads only the name and description at startup, about a hundred tokens, and reads the rest when a task matches.

One caveat, since I would want to know. I have run it in Claude Code; elsewhere it should behave the same – it is spec-conformant and calls nothing product-specific – but I have not tested each harness.

## Install

```
git clone https://github.com/everlabs/public-skills.git
cp -R public-skills/video-to-spec ~/.claude/skills/
```

That is the Claude Code path; for Codex, Cursor, OpenCode and Gemini CLI, copy it into `~/.agents/skills/` instead – the interoperable path they all read. It needs ffmpeg and an image hasher, and no pip packages on the default path. Then name your file and say "turn this walkthrough into tasks".

The point was never the transcription. The point is that the spec is the artifact – not the ticket, not somebody's notes from the call – and a spec with the screenshot attached is delegable, so the code gets written against the actual screen, not someone's memory of a walkthrough. Ambiguity is cheapest to kill early, and mine starts in a recording.

It is open source at [github.com/everlabs/public-skills](https://github.com/everlabs/public-skills). Try it on your next walkthrough and tell me where it gets you wrong.



---


### How many parallel AI workflows can one engineer hold efficiently?

URL: https://everlabs.com/blog/how-many-parallel-ai-workflows-can-one-engineer-hold-efficiently
Markdown: https://everlabs.com/blog/how-many-parallel-ai-workflows-can-one-engineer-hold-efficiently.md
Author: Valentyn Dmytriuk
Published: 2026-05-21
Reading time: 4 min

I ran four Claude Code sessions in parallel git worktrees for a day and kept notes. Three held, one fell off within the hour. Which tasks bundle into a parallel AI workflow, which fight for the same attention, and why the limit is not the machine.

I kept seeing the same claim: run several agents at once and you multiply your output. It sounds right until you try it, because the first thing to run out is not compute. It is attention, and it is yours.

So I gave it a day. One real project, real tickets, no demo repository. I set up git worktrees, opened a [Claude Code](https://www.claude.com/product/claude-code) session in each one, and kept notes.

**Peak: 4 sessions. Stable: 3.**

I'm convinced it's a valid flow, even for product development, but only under a few conditions: the right task mix, solid focus, and not overloading your own context. The number itself turned out to be the least interesting part of it.

## Why worktrees, not four terminals

Each [worktree](https://git-scm.com/docs/git-worktree) is a separate checkout on its own branch, sharing a single `.git`. That separation is the point: two agents in one checkout collide within minutes, one running the test suite while the other is halfway through rewriting the file being tested. Claude Code [documents the pattern](https://code.claude.com/docs/en/worktrees) for exactly this reason.

## The four sessions

**The first was the anchor:** a heavy spike, tons of reasoning and architectural decisions, but it didn't need my hands every minute. That gap is exactly what makes a second session possible.

**The second was something more local** – manual debugging with a small fix. I wired a browser to it through the [Playwright MCP server](https://github.com/microsoft/playwright-mcp), so Claude Code could drive the page and test variants on its own instead of asking me to click through them. I'd answer a question and drop in context now and then.

Since neither of those needed 100% of me, I added **a third: a product review of a colleague's pull request** – edge cases, odd states, unexpected scenarios. Review is bursty work. It wants your judgment in short concentrated pulls and nothing at all in between, which makes it a good fit for the gaps.

**The fourth was error monitoring** in Datadog. It fell off fast.

![Four parallel agent sessions from one day, each in its own git worktree, rated on the same two three-point scales used in the next figure: how much of my thinking the task wants, and how often it wants my hands. Session one, a heavy architectural spike: thinking three of three, hands one of three. Held all day. Session two, manual debugging with a small fix, browser driven through the Playwright MCP server: thinking one, hands two. Held all day. Session three, a product review of a colleague's pull request: thinking two, hands two. Held all day. A red rule marks the stable ceiling at three sessions. Below it, session four, Datadog error monitoring: thinking one, hands three and on its own schedule. Dropped within the hour.](/uploads/blog/how-many-parallel-ai-workflows/session-mix.svg)

## Sorting tasks by shape, not by size

What I actually got out of the day was not a number. It was a way of sorting tasks before starting them, on two axes that have nothing to do with how big the ticket is: how much of your thinking a task wants, and how often it wants your hands – and, the part I had not thought about properly before, **whose schedule it wants them on**. A debugging session wants your hands often, but on your schedule; the agent waits. An alert wants them rarely, on its own schedule, and it does not wait.

![A map of task types on two axes. The horizontal axis is how much of my thinking the task wants, from low on the left to high on the right. The vertical axis is how often it wants my hands, from rarely at the bottom to often at the top. The top band spans the full width and is labeled: on its own schedule, it decides when you look. Below it, the bottom left is the companion zone, which runs in the gaps an anchor leaves. The bottom right is the anchor zone, one at a time. Datadog error monitoring sits alone in the top band. Manual debugging with agent self-tests, and a product review of a colleague's pull request, sit in the companion zone. A heavy architectural spike sits in the anchor zone, marked in red and labeled the anchor. Nothing sits in the top right.](/uploads/blog/how-many-parallel-ai-workflows/task-shape-map.svg)

Plotted that way, the day explains itself. Monitoring does not parallelize at all – not because it is hard, but because it decides when you look at it. That is why the fourth session died. Which gives the rule: **one anchor at a time, then one or two companions from the light half. Never two anchors.** They do not add up, they take from each other, and you notice late, when both are already going badly.

## What I'd tell someone starting tomorrow

1. **Start from the anchor, not from the number.** Pick the task that will genuinely occupy an agent for a long stretch, then ask what fits around it. Deciding on four sessions and hunting for work to fill them is the wrong way round.
2. **Give every session its own worktree and its own branch.** It is cheap, and it removes a whole class of problem instead of making it rarer.
3. **Favor companions the agent can verify by itself.** A browser through Playwright MCP, a test command, a linter. The expensive sessions are the ones where you are the only oracle.
4. **Kill sessions early.** The fourth one was not a failure of the flow, it was the flow working. Being willing to drop back to three is what makes trying four safe.
5. **Count stable, not peak.** Peak is a number you can post. Stable is the number you can work at.

Efficiency went up. Stress did not, in any way I noticed, and I think that is down to the mix rather than to anything about the tooling. Feel the cognitive load of each task and bundle them so they do not fight for attention, and the day feels ordinary. Bundle them badly and you get all of the parallelism and none of the benefit.



---


### Is Ruby on Rails still worth using in 2020?

URL: https://everlabs.com/blog/is-ruby-on-rails-still-worth-using-in-2020
Markdown: https://everlabs.com/blog/is-ruby-on-rails-still-worth-using-in-2020.md
Author: Oleg Pasko
Published: 2020-07-24


Ruby was realized in 1996, and now it's pretty mature language. Is it still actual nowadays?

If you doubt about choosing technology for your startup, you probably heard about Ruby on Rails (ROR) framework. Everyone related to startups was talking about it all the past decade. I consistently was fronting with it reading non-technical books like _Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal_ (as you likely know Twitter originally was built with Ruby on Rails) or _Deep Work: Rules for Focused Success in a Distracted World_ (there are some parts dedicated to the efficiency of David Heinemeier Hansson, creator of Ruby on Rails). Also, I remember an IT-conference from 5 years ago where the speaker said, 'Everyone is going crazy about Ruby on Rails here in Silicon Valley.' 

So, 5 years passed from that conference, 10 years from I started learning it, and almost 15 years since Ruby on Rails was invented. I'll not dig into the history of the framework but focus on actual usage.

The main reason to use ROR nowadays is its ability to build web applications and APIs really fast. Also, it allows you to change and pivot your project in a pretty fast and cost-effective way. I've never met a project which was never changed during the development stage. We live in dynamic and active times. The only option for a 'static' way is development for space projects, some medicine software for hardware, etc., something that requires a predictive approach and waterfall methodology.

Actually, nothing changed for the past years. There are many new frameworks and trendy solutions, but nothing has to replace Ruby on Rails in this area. Maybe the Laravel framework, but it looks like a compromise between impressive Rails architecture and the number of available PHP developers in the market.

Let's check [GitHub's rating of languages](https://madnight.github.io/githut/#/pull_requests/2020/1) for 2020 and select TOP-10. Github is the most popular platform for code storage, sharing, and collaborating. It is an excellent way to understand the popularity of technologies.

- JavaScript 18.703% (-1.406%)
- Python 16.238% (-1.654%)
- Java 10.938% (+0.538%)
- Go 9.005% (+0.978%)
- C++ 7.423% (+0.040%)
- Ruby 6.812% (+0.342%)
- TypeScript 6.769% (+1.522%)
- PHP 5.127% (-0.458%)
- C# 3.835% (+0.141%)
- C 3.181% (-0.203%)

First of all, GitHub themself written with Ruby on Rails. But let's check it one-by-one. 

Is **JavaScript** (JS) a good one language? For sure. All the programming languages in this list are good; otherwise, they didn't exist and were not so popular. Along with the **TypeScript** , this is a language for the Frontend part of your web-application. Any interactive, rich client-side frameworks like ReactJS, Angular, VueJS are based on JavaScript. Because it's pretty popular and has a low entry-level (many frontend guys start with HTML/CSS and add JS after), there are many ways to adapt it for other cases. Cross-platform apps for iOS, Android, macOS, Windows (Ionic, Electron, React Native) made with JavaScript. Backend frameworks, like NodeJS, use JavaScript too. 

So, it's really wide-used, and many developers use it. It's faster than ruby but much slower in project development speed in comparison to ruby. Ruby on Rails is a high-level framework created to make project development fast. NodeJS is useful for creating fast projects.

I like to repeat: 'Make your project popular first and decide how to improve the speed after.' Twitter is a great example. Initially built with Ruby on Rails, it doesn't use RoR as a core technology anymore.

Do you need faster solutions, e.g., processing millions of events per hour? Don't use Ruby on Rails. Use **Go lang**! Do you feel your Ruby on Rails app gets bottlenecks in performance? Separate a microservice with Go. It will be much slower in development speed but resolve a specific issue for your project.

If you already know that you have to handle high-load data processing, take a look at Ruby on Rails as a core for SaaS functionality. It's possible to build SaaS part with user registration, billing, management of app with RoR (Ruby on Rails is a top-notch technology for SaaS), and create a high-load piece with Amazon Lambda + Amazon GateWay, or mentioned Go, or NodeJS.

**Python** is the best language for Machine Learning and Artificial intelligence solutions. There is also a popular framework Django based on Python, but it has a much smaller community and libraries for the Web. This is a similar case to JavaScript. Someone knows Python and started to use it for the Web.

**С++** and **C** are not for the Web. They are too low-level languages and used to create other programming languages (e.g., ruby written in C) or firmware.

**PHP...** no. It was the right choice 20 years ago and still the right choice for your WordPress website. There are still many PHP developers, but I heard hundreds of cases of devs migration from PHP to Ruby/JS/Go/Python, etc., but none switched to PHP. Just use it to support and maintain current solutions. Most websites on the Web still work with PHP. I mentioned Laravel, but it doesn't have such a good community and ready solutions. Just notice, Ruby (6.812%) is almost entirely represented with Ruby on Rails. Laravel is only by a small percentage of active PHP-developers (5.127%).

**Java** is excellent for your next financial project, like banking, money transfer service. It has many related libraries. You can decide to use Groovy on Grails with Java, influenced by Ruby on Rails architecture.

And the last option is C# with likely **.NET** framework. A good one for large enterprise projects. If you build a startup with up to a few millions of people, go with Rails. It's all about startups. If you have millions to build enterprise solutions, go with .NET.

As you see, each language is perfect for each specific case. 

Choose RoR if you'd like to build a startup, SaaS product, social platform, API for a logistic app, e-commerce solutions (Shopify is written in Ruby on Rails), a marketplace, CRM, or another custom-made solution for your business. 

Fast in development, perfect for Rapid application development, loved by developers and community, has many ready solutions and libraries for the Web (aka 'gems'). 

**We still in passion with Ruby on Rails.**



---