--- title: AI-assisted development we use in 2026: Claude Code, Superpowers, GSD description: 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. url: https://everlabs.com/blog/ai-assisted-development-summer-2026 author: Oleg Pasko date_published: 2026-08-16 date_modified: 2026-08-16T22:33:39+03:00 reading_time_min: 8 --- # AI-assisted development we use in 2026: Claude Code, Superpowers, GSD > 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. **Author:** Oleg Pasko ([link](https://www.linkedin.com/in/olegpasko/), [link](https://github.com/olegpasko)) **Published:** 2026-08-16 **Reading time:** 8 min --- 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. ![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. 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. --- *Markdown version of [https://everlabs.com/blog/ai-assisted-development-summer-2026.md](https://everlabs.com/blog/ai-assisted-development-summer-2026.md). For AI assistants and answer engines. [Browse all articles](https://everlabs.com/blog.md).*