DEV Community: Ștefănescu Liviu

LoopTroop 0.5.x is complete: the CLI and installer release

Ștefănescu Liviu — Wed, 26 Aug 2026 09:05:14 +0000

LoopTroop 0.5.x is complete: the CLI and installer release

LoopTroop 0.5.x is now complete at v0.5.9.

This is the release series where LoopTroop became installable software. It gained a CLI, a background service, one-line installers, package channels, standalone executable builds, and a release process that checks the files it publishes.

The series started with v0.5.0 and ended with v0.5.9.

LoopTroop is still early alpha. This release is about making it easier to install, run, and verify, not about declaring it production-ready.

The CLI

The main change in v0.5.0 was the looptroop command.

It includes:

looptroop setup
looptroop start
looptroop stop
looptroop restart
looptroop status
looptroop open
looptroop logs
looptroop doctor
looptroop clean

start runs LoopTroop as a background service, so it keeps running after the shell closes. open starts the service when needed and opens the local dashboard with a signed-in link.

setup guides the first run. status reports the daemon state. doctor checks the runtime, configuration directory, database schemas, port, OpenCode, GitHub authentication, and installation channel. It also has a JSON mode for scripts.

clean finds abandoned worktrees, stale locks, and OpenCode processes that LoopTroop started. Listing is the default. Applying cleanup requires an explicit flag.

The goal was to make the normal path look like ordinary software:

install
start
open
work

Installers became part of the product

The 0.5.x work did not stop at adding a command. It also added several ways to install it.

The one-line installer works on macOS, Linux, WSL, and Windows PowerShell.

On macOS, Linux, or WSL:

curl -fsSL https://www.looptroop.ovh/install | sh
looptroop open

On Windows PowerShell:

irm https://www.looptroop.ovh/install.ps1 | iex
looptroop open

The installer resolves a release that contains the required files, checks the download against the published checksum, and refuses to install a file that does not match. It does not ask for sudo.

The installer uses npm, so the npm installation path remains available:

npm install -g looptroop
looptroop open

The 0.5.x series also added release support for Homebrew, Scoop, Chocolatey, WinGet, Docker, and standalone executable builds. The current availability of each channel is documented on the Installation page.

Standalone executables

v0.5.2 added standalone executable builds for macOS on Apple silicon, Linux on x64 and arm64, and Windows on x64.

The executable carries its own Node runtime. Once installed, it does not need Node in order to run LoopTroop.

The one-line installer can install the executable instead of the npm package. The upgrade path is transactional:

Verify the downloaded archive.
Stop the running daemon.
Replace the executable by rename.
Check that the new executable reports the requested version.
Restore the previous executable if the new one fails.
Start the daemon again if it was running before the upgrade.

The installer itself still needs Node because the installer is a Node program. The standalone file removes Node as a runtime requirement for LoopTroop after installation.

A smaller production package

The release also changed what the production package contains.

The server became an embeddable runtime that does not start work merely because another module imports it. The production build bundles the server and ships compiled output. The production server serves the interface itself, so there is no separate web server to configure.

The runtime also moved from the native better-sqlite3 package to Node's built-in node:sqlite. That removed the last compiled dependency from the runtime and removed one of the common causes of installation failures.

The result was a much smaller global installation, from roughly three hundred packages to sixteen.

The release process was rebuilt

Publishing a CLI is different from running a development server locally. A successful release has to prove that the package can be installed, started, upgraded, and removed on the platforms people use.

The 0.5.x release process now:

Builds the package and release artifacts.
Records checksums for published files.
Publishes the exact built files to the supported channels.
Adds signed build provenance to release assets.
Builds and checks standalone executables.
Builds container images for Linux x64 and arm64.
Installs published releases on clean machines.
Starts the daemon and checks its health.
Tests the interface and authenticated API paths.
Stops and uninstalls the release again.

The workflow is resumable. It reads the state of the tag, GitHub release, package registry, and container registries before continuing. A release is only considered finished after the published files have been compared with the files produced by the build.

The final release in the series, v0.5.9, also fixed packaging and install checks for npm 12 and repaired an edge case where a slow daemon could become impossible to stop.

What the installation looks like now

For a Unix-like system:

curl -fsSL https://www.looptroop.ovh/install | sh
looptroop open

For Windows PowerShell:

irm https://www.looptroop.ovh/install.ps1 | iex
looptroop open

For npm:

npm install -g looptroop
looptroop open

open starts LoopTroop in the background when it is not already running, then opens the dashboard. Use looptroop start if you want the service without opening a browser.

After that, configure a model provider through OpenCode, attach a local repository with a GitHub origin, and create a ticket.

LoopTroop does not install OpenCode. It needs OpenCode with at least one configured provider. Git and GitHub CLI are also required for the pull request step, although some installation channels provide them as dependencies.

A note about safety

LoopTroop runs OpenCode with broad local permissions because it is designed for long-running, unattended coding work. Git worktrees isolate changes to the attached repository, but they do not sandbox the agent process from the rest of the machine.

Use a disposable VM, cloud development machine, or another sandboxed environment when trying it.

The result

The 0.5.x series changed LoopTroop from something you mainly cloned and ran as a development stack into something you can install, start, inspect, upgrade, and remove.

v0.5.x is complete at v0.5.9.

Code: github.com/looptroop-ai/LoopTroop

Installation guide: looptroop.ovh/docs/installation

Show Dev: LoopTroop - Local-first AI coding orchestrator with LLM councils, Ralph loops, and a visual Kanban board

Ștefănescu Liviu — Wed, 19 Aug 2026 16:27:43 +0000

Hey everyone!

I wanted to share LoopTroop, an open-source, local-first GUI app I have been building to solve one of the biggest headaches with AI coding agents: context rot.

We recently crossed 120 stars on GitHub, and I am actively developing and improving it every day.

GitHub Repository: https://github.com/looptroop-ai/LoopTroop
Quick Video Walkthrough (2.5 min): https://www.youtube.com/watch?v=LYiYkooc_iY

The Problem: Context Rot in Long-Running Tickets

AI coding tools are great when you ask them to write a quick function, generate boilerplate, or fix a single bug. But once you throw a complex, multi-file feature ticket at an agent, things usually fall apart after 10 to 15 tool calls.

The context window fills up with terminal outputs, compiler errors, large file dumps, and half-baked diffs. As that noise piles up, the model starts forgetting early requirements, re-introducing previously fixed bugs, or hallucinating code.

LoopTroop takes a different route: context engineering over infinite chat history. Instead of letting one long conversation degrade over time, it breaks work into distinct stages, persists state to disk as durable files, and feeds the model clean, minimal micro-contexts for each step.

How LoopTroop Works

LoopTroop is built around a "slow and precise" philosophy. Rushing an agent to write code immediately usually costs more time in cleanup than doing structured planning upfront.

1. Interactive Interview (Resolving Ambiguity First)

Before writing any specs or code, LoopTroop runs an interactive interview. It scans your repository, detects ambiguities in your ticket, and asks you direct clarifying questions about architecture, trade-offs, and edge cases. This makes sure the plan actually reflects what you want before any code gets touched.

2. The LLM Council (Multi-Model Planning)

Instead of relying on a single model's biases to architect your feature, LoopTroop uses an LLM Council for planning the PRD and task breakdown:

Multiple configured models draft their own proposals independently.
The models review and vote anonymously on the drafts to score the best approaches.
The winning plan absorbs the strongest ideas from the other drafts and runs a coverage check to ensure no requirements were skipped.

3. Decomposition into Atomic "Beads"

Large tickets are decomposed into small, self-contained units of work called Beads. Each bead defines:

A specific, narrow objective
Exact target files
Concrete acceptance criteria
Automated test commands to verify completion

The agent implements one bead at a time with a clean prompt focused only on that task.

4. Ralph Loops (Smart Failure Recovery)

When an agent gets stuck in a loop or fails a verification check, traditional tools just append the failure traceback to the chat, polluting future attempts.

LoopTroop uses a recovery loop pattern:

Each bead execution is time-boxed.
If a bead fails or gets stuck, LoopTroop stops the attempt, writes a short diagnostic note explaining what failed, and discards the noisy session history.
The next iteration restarts with a clean context, carrying over only that compact failure note. Failures turn into targeted learning rather than context pollution.

5. Local-First Visual Kanban Board

LoopTroop is a desktop GUI, not a CLI command or a hosted cloud platform. It gives you a clean Kanban interface to manage multiple repositories and multiple active tickets simultaneously:

Track phase progression in real time.
Inspect council drafts, voting breakdowns, and PRDs.
Monitor live execution logs and terminal output.
Review bead statuses, test outputs, and final Git diffs from one window.

Human in the Loop

LoopTroop is designed to keep you in the driver's seat at key decision points:

You answer the initial interview questions.
You review and approve the generated PRD and bead breakdown.
You can step in, pause, or adjust during bead implementation.
You review the verified changes before anything is handed over to your main branch.

Under the Hood

Execution Engine: LoopTroop uses the OpenCode harness for file operations, terminal execution, and model communication.
Model Agnostic: You can configure any model or provider supported in your setup (Anthropic, OpenAI, Google, DeepSeek, local models via Ollama, etc.) for both the main implementer and the council members.
Local: Runs locally on your machine against your local Git repositories.

Links & Trying It Out

Source Code: https://github.com/looptroop-ai/LoopTroop
Video Demo: https://www.youtube.com/watch?v=LYiYkooc_iY

Any feedback, critique, or bug reports are more than welcome. If you decide to give the app a spin and it works nicely on your projects or breaks completely on your stack, drop a comment here or open an issue on GitHub. I would love to hear your thoughts!

LoopTroop v0.4 is out + just hit 100 GitHub stars! A local-first AI coding orchestrator that turns tickets into real PRs

Ștefănescu Liviu — Wed, 29 Jul 2026 08:50:55 +0000

Hey everyone! The first 100 stars are always the hardest, so I wanted to share a big milestone and launch update. I just released LoopTroop v0.4!

What is LoopTroop?
LoopTroop is a free, open-source, local-first GUI designed to eliminate "endless chat drift" in AI coding assistants. Instead of unstructured back-and-forth chat, it breaks complex software tasks into planned task beads, automated recovery loops, and explicit human approval gates.

How it works:

🧠 LLM Councils: Architect and plan complex features before writing code.

🔁 Ralph Loops: Iteratively run, test, and self-correct until the feature works.

🌲 OpenCode Worktrees: Safely isolate code changes and automatically ship clean PRs.

Building LoopTroop in public has been an awesome journey. If you’re into agentic coding tools, grab the repo, run npm run dev, and test it on your own codebase.

🔗 GitHub Repo: https://github.com/looptroop-ai/LoopTroop

🌐 Docs & Website: https://looptroop.ovh

A huge thank you to everyone who has starred or given feedback so far. Give it a spin and let me know what breaks! 💬

LoopTroop #opensource #AgenticAI #BuildInPublic #AI #DevTools #CodingAgents

What is a Ralph Loop?

Ștefănescu Liviu — Wed, 22 Jul 2026 12:55:20 +0000

What is a Ralph Loop?

You are watching an agent work on a feature. It edits a file, runs the tests, hits an error, patches the error, runs again, finds a second issue, tries a different approach, and then stalls. The transcript is now long. Half of it is abandoned attempts.

So you tell it to retry.

It retries in the same chat. It carries the old stack traces forward. It carries the abandoned approach forward. It carries the file contents that no longer match disk. The next attempt fails the same way, or a slightly worse way, because the model is no longer solving the clean task. It is solving the task plus the sediment of every previous attempt.

Retrying in the same chat compounds errors. Junk piles into the context.

That is the problem a Ralph Loop fixes.

The short definition

A Ralph Loop is what you do when an agent attempt stalls or fails:

Stop the attempt.
Write a compact note of what went wrong.
Scrap the degraded session.
Retry fresh, in a clean worktree, carrying only that note forward.

The attempt is time-boxed. Default is 20 minutes. If it does not finish cleanly in the box, the loop stops, writes the note, and the next iteration starts over with fresh context and that one note.

The key move is the reset. You do not continue in the polluted transcript. You throw it away and start clean, except for the failure note.

Why retrying in the same chat fails

Every step an agent takes leaves context behind. Some of it is useful. Some of it was useful five minutes ago and is now harmful.

When you retry in the same chat, the model keeps:

old plans that were abandoned
stack traces from errors you already fixed
file contents that no longer match the repo
tool output that was only relevant to one dead branch
your corrections mixed with the model's guesses

After a while the model is not solving the task. It is doing archaeology on its own failed attempts.

A larger context window does not solve this. It gives the model more room. It does not decide what belongs in the room. Bad context pulls the model toward the wrong action even when the answer is technically somewhere in the window.

This is context rot. The working set became polluted, and the retry inherited the pollution.

The move: scrap and retry fresh

The fix is a boundary. The failed attempt does not get to bleed into the next one.

The flow is:

The attempt runs in its own isolated git worktree, so it never touched your main checkout.
It stalls or fails inside its time box.
The loop writes one failure note: what was being done, what went wrong, what to try next.
The worktree is discarded. The transcript is discarded.
A fresh worktree is created. A fresh session starts. The only thing carried forward is the failure note.

The next attempt gets a clean workbench and one useful fact. It does not get the 2000-line log. It does not get the abandoned plan. It does not get the old file dump.

This is the same pattern a careful human uses. When you get stuck on a bug and start going in circles, you stop, write down the one thing you know is wrong, close the noisy terminal, and start over with just that note. You do not keep rereading the same dead-end output hoping this time is different.

What a bad retry looks like

Keep going in the same chat.
Paste the full error log back in.
Ask it to try again.
Ask it to try harder.
Paste the log again.

The model now has the original task, the failed attempt, the full log, your frustration, and the same wrong context that produced the failure. It will likely fail the same way. The retry did not get smarter. It just got longer.

What a good retry looks like

Previous attempt failed because the password-reset test
creates a user without an email address.

Fix the fixture or guard the email access before rerunning:

    npm test -- password-reset

Retry in a fresh worktree. Do not inherit the previous transcript.

The next attempt gets the clean task plus one specific cause. It does not get the noise. It can actually move forward.

The failure note is the whole trick

The reset is easy. The hard part is the note.

A good failure note preserves only what changes the next action. It answers: what was being attempted, what specifically went wrong, and what to do differently.

Good compression:

The bead failed because the empty-state container replaced the
upload button, which broke keyboard focus. Keep the upload button
outside the conditional empty-state block. Rerun:
    node _check_css.js

Bad compression:

Tests failed. Try again.

The bad version throws away the only useful fact. The next fresh attempt is now flying blind in a different way. It has a clean context but no idea what went wrong, so it guesses from scratch and may repeat the exact same mistake.

The failure note is what turns a reset from "start over dumb" into "start over smarter." Each iteration of the loop carries one more useful fact forward instead of one more pile of sediment.

Why it is called a loop

Because it repeats. A bead may take one iteration or five. Each iteration is a fresh attempt with a growing set of failure notes and nothing else from the past. The loop ends when an attempt finishes cleanly inside its time box and passes its validation.

Failures compound into learning. They do not compound into context rot. That is the whole point.

Sources

Anthropic, "Effective harnesses for long-running agents": https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic, "Effective context engineering for AI agents": https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
OpenAI Cookbook, "Context Engineering - Short-Term Memory Management with Sessions": https://developers.openai.com/cookbook/examples/agents_sdk/session_memory

How LoopTroop uses Ralph Loops

LoopTroop is a local, open-source GUI app for running coding tickets across local git repositories. It is built around the idea that long tasks fail when every step lives inside one endless chat, so it orchestrates around the agent instead of letting it run until it rots.

The pieces that matter here:

A ticket is split into small atomic units called Beads, each with acceptance criteria and a validation command.
Each Bead runs inside its own isolated git worktree, so concurrent work never stomps on itself.
Each Bead is time-boxed, default 20 minutes.
If a Bead does not finish cleanly inside its box, the Ralph Loop stops, writes a failure note, discards the worktree and the session, and starts a fresh attempt carrying only that note.
The loop repeats until the Bead passes, or until you intervene.

The effect: every retry gets a clean workbench and one useful fact. The model never has to dig its way out of its own polluted transcript. You can watch the whole thing from one pane, see every failure note, every fresh attempt, and the final diff before anything reaches your main branch.

LoopTroop is one implementation of this pattern. It is not the only way to run a Ralph Loop, but it is a worked, observable one.

Site: https://www.looptroop.ovh/
GitHub: https://github.com/looptroop-ai/LoopTroop
16-minute demo: https://youtu.be/LYiYkooc_iY

Designing a local ticket-to-PR workflow for AI software delivery

Ștefănescu Liviu — Tue, 14 Jul 2026 09:46:01 +0000

If you have tried using AI coding agents for large, multi-file tickets, you probably know the exact moment the run starts to derail.
It usually starts with a simple error. The agent tries to fix it, but introduces another bug. It tries to fix that one, and now the terminal logs are piling up. Within a few iterations, the conversation history is bloated. The model starts dropping files, ignoring imports, or repeating the same mistake.
I call this context rot. When an AI chat session gets too long, the model loses focus. This is a systems problem, not a prompting problem.
To get reliable code out of an AI on complex tasks, you need a structured workflow that manages context instead of accumulating it. I spent the last five months building a local GUI orchestrator called LoopTroop to solve this.
Here is how I structured the workflow to keep the AI focused.

Stop guessing: the interview phase
Before writing code or specs, the system generates targeted questions to clarify the requirements. It focuses on identifying edge cases, constraints, and dependencies.
You answer these questions in the interface. This step resolves ambiguities early, so the plan matches what you want.

Planning with a model council
Relying on a single model to plan a complex ticket is risky. Instead, LoopTroop uses a council of multiple models for the planning phases.
Several models generate independent drafts of the spec. They then score and vote on each other's work anonymously to remove brand bias. The winner refines their draft by incorporating the best ideas from the other drafts.
This is slower than a one-shot prompt, but a solid plan prevents hours of debugging loops later.
Small, atomic units
We split the approved plan into tiny, independent tasks. Each unit has a clear objective, target files, acceptance criteria, and verification commands.
Instead of asking the AI to build a whole feature in one go, we make it focus on one specific unit at a time. This keeps the working context minimal.

Recovering with fresh context: the Ralph loop
When a task fails or times out, the typical reaction is to keep prompting the same session. That just adds error logs to the context, making the model more confused.
Instead, LoopTroop uses a recovery cycle:
We capture the failure details in a short note.
We reset the workspace back to the start of the task.
We start a completely new session with the original task spec and the failure note.
This keeps the lesson but throws away the context pollution. We limit these retries to a set number of attempts.
Keeping the human in control
The workflow is not fully autonomous. It requires your approval at important boundaries, such as approving specs and reviewing final changes.
You can monitor the entire run, view logs in real time, and inspect the final diff from a single Kanban board.
This approach is deliberately slow. It is not meant for quick edits, but for complex work where correctness matters.

If you want to look at the code or see how the GUI works, you can check the project on GitHub: https://github.com/looptroop-ai/LoopTroop
Here is a short 2m 30s video showing the workflow in action: https://youtu.be/g1A2g-oOR3E
Any feedback is more than welcomed. If you tried the app and it worked or did not work, give me a sign. I am happy to talk about it.

What is context engineering?

Ștefănescu Liviu — Tue, 30 Jun 2026 08:29:42 +0000

What is context engineering?

Prompt engineering is about asking better.

Context engineering is about deciding what the model gets to know while it works.

That sounds like a small shift, but it changes how you build with AI. A prompt can help with a single reply. Context engineering is what you need when the model has to work across tools, files, memory, tests, retries, and several steps of a real task.

Most agent failures do not come from one bad sentence in the prompt. They come from the model seeing the wrong working set: too much history, missing files, stale decisions, huge logs, old failed attempts, or instructions that no longer match the current step.

The context window is not a filing cabinet. It is a workbench. If you pile everything onto it, the useful parts get buried.

The short definition

Context engineering is the practice of choosing, shaping, storing, retrieving, compressing, and isolating the information an AI system receives at each step.

That includes:

the user request
system instructions
relevant files
retrieved documentation
examples
tool definitions
tool results
memory
previous decisions
error notes
acceptance criteria
the current task state

The goal is not to maximize context. The goal is to give the model the right context for the next action.

Sometimes that means adding more information. Sometimes it means removing information. Sometimes it means writing information outside the chat so the next step can retrieve it cleanly.

Why this became a real problem

Early prompt engineering mostly dealt with single calls: write this email, summarize this document, generate this function, explain this error.

Agents are different.

An agent may plan, call tools, inspect files, make edits, run commands, read failures, retry, and prepare a final answer. That creates a long trail of context. Some of it is useful. Some of it is noise. Some of it was useful five minutes ago but is now harmful.

Coding agents make this easy to see.

Imagine an agent working on a medium-sized feature. It starts with a ticket, scans the repo, drafts a plan, edits a few files, runs tests, hits an error, patches the error, runs more tests, finds a second issue, and then tries again.

If every step keeps inheriting the whole transcript, the model starts carrying around:

old plans
abandoned approaches
stack traces from fixed errors
file contents that no longer match disk
tool output that was only relevant to one branch of the attempt
user corrections mixed with model guesses

After a while, the agent is no longer solving the clean task. It is solving the task plus the sediment of every previous attempt.

That is context rot.

Larger context windows do not solve it by themselves

A larger context window gives the model more room. It does not decide what belongs in the room.

This matters because agent context is not just "more text." It is a live bundle of instructions, evidence, state, and tool access. Bad context can pull the model toward the wrong action even when the answer is technically somewhere in the window.

You can see the same thing in human work. Give a developer the current ticket, the target files, and the latest failing test, and they can focus. Give them every Slack message, every old branch, every failed patch, and every log from the last week, and now they have to do archaeology before they can write code.

Models have the same problem, with less judgment.

Context engineering vs prompt engineering

Prompt engineering asks:

How should I phrase the request?
What role should the model play?
What examples should I include?
What output format do I want?

Context engineering asks:

What does this step need to know?
What should be stored outside the chat?
What should be retrieved now?
What should be summarized?
What should be hidden from this step?
Which tool results are worth keeping?
When should the agent start fresh?
Which artifact is the source of truth?

Both matter. Good prompting still helps. But once a system has memory, tools, files, and multiple steps, the prompt is only one part of the environment.

The four practical moves

A useful way to think about context engineering is: write, select, compress, isolate.

1. Write important state down

Do not rely on the conversation transcript as the only memory.

Write important state into durable artifacts:

requirements
decisions
plans
acceptance criteria
implementation notes
test results
failure summaries
review notes

This gives the system something cleaner than chat history. A later step can load the current PRD or the latest failure note without dragging along every false start that produced it.

For coding agents, this is especially useful because files, specs, and test reports are easier to review than a long model transcript.

2. Select only what matters now

Each step should receive the smallest useful working set.

If the agent is planning, it may need the ticket, repo structure, relevant files, and user constraints.

If the agent is editing one small task, it may need only:

the active task
the target files
acceptance criteria
a compact note from the last failure
the command it should run to verify the work

The model does not need every planning draft or every old tool call just because those things happened earlier.

Selection is where many agent systems fail. They retrieve too much, retrieve the wrong thing, or treat all previous context as equally important.

3. Compress noisy information

Some information should survive, but not in full.

A 2,000-line test log may contain one useful fact: one assertion failed because the mocked user had no email address. A retry does not need the whole log. It needs the failure note.

Good compression turns messy context into useful working memory:

Previous attempt failed because the password reset test creates a user without an email.
Update the fixture or guard the email access before rerunning:
npm test -- password-reset

Bad compression hides the important detail:

Tests failed. Try again.

The point is not to summarize everything. The point is to preserve what changes the next action.

4. Isolate phases

Planning, coding, retrying, testing, and reviewing should not all share the same context shape.

A planner benefits from broad context. A coder benefits from narrow context. A reviewer benefits from the final diff, the requirement, and verification results. A retry often benefits from a clean session plus one compact failure note.

This is the part many people miss. Context engineering is not only retrieval. It is also deciding which information should not cross a boundary.

What bad context looks like

Bad context usually feels convenient at first:

Give the model everything.
Keep the whole chat.
Paste the full logs.
Include every file.
Ask it to continue.

That works for a while. Then the agent starts making strange choices.

It edits the wrong file because an old file dump is still in the transcript. It repeats a failed idea because the failed attempt is still nearby. It forgets the acceptance criteria because a huge tool result pushed the actual task out of focus. It treats a plan draft as if it was approved.

The model did not become lazy. The working set became polluted.

What good context looks like

Good context is boring in the best way.

It is explicit:

Current phase: implementation
Active task: add empty-state copy to the media manager
Target files:
- app.js
- styles/managers-media.css

Acceptance criteria:
- Empty state appears only when no media exists.
- Upload button remains visible.
- Layout works on mobile.

Validation:
- node _check_css.js
- manual browser check later

It is narrow:

Do not modify campaign logic.
Do not change media upload behavior.
Do not run full end-to-end tests.

It carries forward only useful failure information:

Last attempt broke keyboard focus because the empty-state container replaced the upload button.
Keep the upload button outside the conditional empty-state block.

This kind of context gives the model less room to improvise in the wrong direction.

Context engineering is not just RAG

Retrieval augmented generation is one technique inside context engineering. It helps the system fetch relevant information from docs, files, memories, or a database.

But context engineering is wider.

It includes tool design, memory design, artifact design, phase boundaries, retry behavior, human approval gates, and the shape of tool results.

For example, an agent with fifty tools may perform worse if every tool definition is always loaded. The system has to decide which tools belong in the current step. The same is true for files, examples, memories, and prior messages.

RAG answers: what should we fetch?

Context engineering answers: what should this model call know, what should it be allowed to do, and what should survive afterward?

A checklist for agent builders

Before you build a serious agent workflow, ask:

What is the source of truth for the task?
Which artifacts should survive between steps?
Which old messages should be discarded?
What is the smallest useful context for this phase?
Which tools should the model see right now?
How should large tool results be stored?
What should happen after a failed attempt?
Can a human review the plan before execution?
Can a human review the final diff before merge?

If the answer to most of these is "the chat has it," the system is fragile.

How LoopTroop applies context engineering

LoopTroop is built around this problem in AI coding: long tasks get worse when every step lives inside one endless chat.

LoopTroop is a local, open-source GUI app for running coding tickets across local Git repositories. It is not trying to replace every coding agent. It is the orchestration layer around longer work: planning, splitting, execution, retries, logs, review artifacts, and human approval.

The relevant pieces are:

LLM Council for planning
PRDs as durable specs
Beads as small implementation units
OpenCode as the execution layer
Git worktrees for isolated repo work
Ralph Loop retries for failed or stuck beads
human gates before important transitions

The important context engineering move is that each stage gets a different working set.

The council can look broadly and compare plans. The PRD becomes the source of truth. Beads turn a large task into smaller units with acceptance criteria and validation commands. Execution gets one bead at a time instead of the whole project history. If a bead fails, the Ralph Loop saves a compact note, resets the attempt, and retries with fresh context rather than dragging the polluted session forward.

That is the practical version of context engineering: keep the useful state, discard the noise, and give the model a clean job at each phase.

For tiny edits, a direct chat or editor agent is usually enough. For larger tickets, especially the ones that touch several files or need multiple retries, context engineering is what keeps the agent reviewable.

The final output should not be "the AI wrote some code." It should be a plan, a set of small tasks, logs, test commands, diffs, and a result a human can inspect without reading a giant transcript.

That is the lane LoopTroop is trying to own.

Sources

Anthropic, "Effective context engineering for AI agents": https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
Anthropic, "Effective harnesses for long-running agents": https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
OpenAI Cookbook, "Context Engineering - Short-Term Memory Management with Sessions": https://developers.openai.com/cookbook/examples/agents_sdk/session_memory
OpenAI Cookbook, "Context Engineering for Personalization": https://developers.openai.com/cookbook/examples/agents_sdk/context_personalization
LangChain docs, "Context engineering in agents": https://docs.langchain.com/oss/python/langchain/context-engineering
LangChain, "Context Engineering": https://www.langchain.com/blog/context-engineering-for-agents
LoopTroop: https://www.looptroop.ovh/
LoopTroop GitHub: https://github.com/looptroop-ai/LoopTroop

How I Built LoopTroop: An AI Orchestrator That Builds Apps Using AI

Ștefănescu Liviu — Mon, 22 Jun 2026 17:22:22 +0000

I've been heads-down on this for months and only now feel ready to talk about it properly.

LoopTroop is a local, open-source GUI orchestrator I built. It uses OpenCode (right now, more backends in the future) to create new apps or add features, fix bugs, and improve existing codebases. It leans heavily on context engineering, Ralph loops, beads, LLM councils, and git worktrees.

Think Lovable or Replit, but with the opposite philosophy: it cares more about getting things right than shipping as fast as possible.

The Problem That Started Everything

Early this year I kept hitting the same wall. I'd try to add meaningful features to my own apps and the normal IDE route just became overwhelming on anything complex. Tools like Replit didn't deliver what I needed either — they were even worse.

Around the same time Ralph loops were getting popular. I thought: What if I combine Ralph loops with a proper LLM council and a full development lifecycle? Maybe I could finally solve the real problems I was facing instead of fighting the tools.

I told myself it would take a month. Maybe six weeks max.

Boy, was I wrong.

(I also have a day job, kids, a house — you know, normal life.)

So me and my partner just started working on it whenever we could.

120 Hours of Planning (The Most Important Part)

The first 120 hours were pure planning. No code at all.

We looked at every similar project we could find and asked: what did they do well? Where did they fall short? I basically threw the initial idea at almost every model available back then and kept asking "What's missing? What's dumb? What should we push to later?"

Some of the Chinese open models actually gave the best suggestions. I'd take their feedback, update the plan, switch to another model, ask again, and repeat.

Once the core plan felt solid, I started digging into the actual tech stack behind it, this time leaning more on frontier models, then bouncing the new version back to the others for another round of criticism.

That whole back-and-forth took the full 120 hours.

Actually Building It (And Why One-Shotting Was Impossible)

Then we started implementing the plan.

I used a bunch of different harnesses — hammering GitHub CLI (insanely useful at the time because one request could just keep running for hours), Claude Code, Codex, Droid, and a couple others. I'd keep the best output from each run, steal good UI ideas from the rest, and then go back to the strongest harness (mostly Claude Code with Opus back then) to fold everything together.

Another month+ passed before it actually worked. This thing is genuinely complex. There was never any chance of one-shotting it.

After the core started working, I spent the next couple of months adding features and refining until it finally felt like the thing I had originally pictured in my head. Only then did I feel comfortable starting to talk about it publicly.

The Tools & Models I Actually Used

Because LoopTroop itself runs an LLM council, I needed access to lots of different models at the same time for testing and building. Here's what I leaned on:

Multiple Codex Pro subscriptions + Codex-lb (the open-source load balancer so I wasn't constantly logging in and out)
VS Code + Copilot + Copilot CLI (mainly for Claude Opus/Sonnet)
OpenCode Go subscription for smaller tasks
Antigravity (with Google Pro) for UI work and occasional Opus. Now that Flash 3.5 is out I use it constantly; it's fast and good enough for most non-complex work
Kilo and OpenRouter to pull in free models for the council

For big architectural decisions I would spin up GPT-5.5 (or 5.4) Pro and cross-check the plan across a ton of other models: MS Copilot, Z.ai GLM, Qwen, Minimax, Grok, Gemini, Deepseek, Kimi, Xiaomi, and sometimes even Mistral or Ernie. Same technique I used in my planning phase (described before) — moving the plan between different model families to catch edge cases and collect good ideas. I ended up with an architecture.md file with 10000+ lines that got so changed when I made the app actually work.

When I just wanted to know "What's the current best way people are doing X right now?", I usually started with Grok or Gemini.

Out of the open models, I'd currently recommend Kimi and GLM (on top of the big three).

Anything that got too complicated went straight onto the roadmap (it lives on GitHub and in the docs). That's how I actually managed to launch.

What I'd Recommend Now (After Going Through It)

If you're building something genuinely complex with AI right now, here's what I'd tell you:

Spend way more time on initial planning than you think you need. Run your plan through as many different models as possible. Different model families catch completely different things. Push the big scary features onto a roadmap and get as close to a real MVP as you can. Tens of hours, hundreds even if you want something serious — not a to-do app.
After planning, use the strongest model you can afford for the first real iteration. I'd honestly just use LoopTroop for this now, with whatever the current top model is as the main implementer.
Then settle into the real forever coding loop: Complex work? Use LoopTroop. Seriously, it's built for exactly this. Small stuff or quick fixes? Use whatever fits your budget (full Claude/Codex/Cursor plan, OpenCode Go, or free models via OpenRouter). Just keep repeating this forever.
Market and build at the same time. Don't wait until it's perfect. Keep shipping updates and talking about it in parallel with the development work.

See It In Action

Here's a full walkthrough of LoopTroop doing its thing:

Watch the full demo (16 minutes, after 6:50 the demo) on YouTube:
https://www.youtube.com/watch?v=LYiYkooc_iY

That's the story so far. It took way longer than I expected, cost more in subscriptions than I want to admit out loud, and taught me a ridiculous amount about how different models actually think.

If you're building something complicated with AI agents or orchestrators right now, I'd genuinely love to hear how you're approaching it.

Repository: github.com/looptroop-ai/LoopTroop
Docs: looptroop.ovh/docs

DevOps and SRE: The Dynamic Duo Transforming the Software Development Landscape

Ștefănescu Liviu — Thu, 13 Apr 2023 08:33:40 +0000

An easy-to-understand introduction to DevOps and Site Reliability Engineering for the general audience

Introduction

In the ever-evolving world of software development, two concepts have emerged as vital components for delivering high-quality, reliable software: DevOps and Site Reliability Engineering (SRE). These approaches have revolutionized the way software is built, deployed, and maintained, and their adoption has led to increased efficiency and collaboration across organizations. In this article, we'll explore the main concepts of DevOps and SRE, and explain their significance in a way that's easy for a general audience to understand.

What is DevOps?

DevOps, a combination of the words "development" and "operations," is a set of practices and cultural philosophies that bridge the gap between software development and IT operations teams. The goal of DevOps is to create a seamless, collaborative environment where developers and operations teams can work together to deliver high-quality software rapidly and reliably.

Key Concepts of DevOps

Collaboration: DevOps encourages increased communication and cooperation between development and operations teams, fostering a shared understanding of goals and breaking down silos.
Continuous Integration (CI): This practice involves regularly merging code changes into a central repository, followed by automated building and testing. CI helps detect integration issues early and speeds up the development process.
Continuous Delivery (CD): CD is the process of automatically deploying code changes to production-like environments after they pass testing, making it easier to release new features and bug fixes quickly.
Infrastructure as Code (IaC): IaC is the management of infrastructure (such as networks, servers, and storage) through code, which allows for version control, easy rollbacks, and collaboration between team members.
Monitoring and Feedback: DevOps emphasizes the importance of monitoring applications and infrastructure to gather insights and feedback, enabling teams to continuously improve processes and address issues proactively.

What is Site Reliability Engineering (SRE)?

Site Reliability Engineering (SRE) is a discipline that combines aspects of software engineering and IT operations to ensure the reliability, availability, and performance of software systems. SREs are responsible for defining service level objectives (SLOs), monitoring system performance, and implementing automated solutions to improve the reliability and efficiency of software systems.

Key Concepts of SRE

Service Level Objectives (SLOs): SLOs are measurable goals that represent the desired level of system reliability, such as uptime, latency, and error rates. SREs work closely with development teams to establish and maintain these objectives.
Error Budgets: An error budget is a defined tolerance for system failures or performance issues. By allocating an error budget, SREs can balance the need for system reliability with the desire to innovate and release new features.
Automation: SREs focus on automating tasks that are repetitive, error-prone, or time-consuming, freeing up resources to work on more valuable tasks and improving overall system reliability.
Monitoring and Observability: SREs use monitoring and observability tools to gain insights into the performance and health of software systems, enabling them to identify potential issues and proactively address them.
Blameless Postmortems: When incidents occur, SREs conduct blameless postmortems to review the event, identify the root cause, and implement improvements to prevent future occurrences, fostering a culture of learning and continuous improvement.

The Benefits of DevOps and SRE

The adoption of DevOps and SRE practices offers numerous advantages, including:

Faster Time-to-Market: By streamlining the development and deployment processes, organizations can bring new features and products to market more quickly.
Improved Collaboration: DevOps and SRE foster better communication and collaboration between development and operations teams, breaking down silos and resulting in more efficient problem-solving and decision-making.
Enhanced Reliability: By focusing on system reliability and implementing automated solutions, SREs can ensure that software systems are more stable, secure, and resilient.
Higher Quality Software: DevOps practices such as CI/CD and automated testing help to catch issues early, leading to higher quality software and fewer defects in production.
Cost Efficiency: By automating tasks and optimizing resource usage, DevOps and SRE can help organizations save time and money, while also reducing the risk of human errors.
Continuous Improvement: Both DevOps and SRE promote a culture of learning, feedback, and continuous improvement, enabling teams to learn from mistakes and proactively address potential issues.

Conclusion

DevOps and Site Reliability Engineering have transformed the way software is developed, deployed, and maintained. By fostering collaboration, streamlining processes, and focusing on reliability, these practices have helped organizations deliver high-quality software more quickly and efficiently. With a better understanding of the main concepts of DevOps and SRE, anyone can appreciate the profound impact these approaches have on the software development landscape.

DevOps & SRE Roadmap explained by AI - part 3

Ștefănescu Liviu — Thu, 06 Apr 2023 16:37:06 +0000

This part is for what you need to know about Cloud Native tools and principles.
Cloud native is essential for DevOps and SRE roles ☁️🌎 It allows you to build and run scalable applications in modern, dynamic environments 🚀 Cloud native technologies are highly customizable and can be used across a wide range of systems 🌐

👷‍♂️👷‍♀️ Infrastructure as code (IaC) is a DevOps methodology that uses versioning with a descriptive model to define and deploy infrastructure such as networks, virtual machines, load balancers, and connection topologies.

👩‍💻👨‍💻 Virtual machines are software that emulate hardware and run operating systems. They are useful for DevOps and SRE roles because they allow testing, deploying and scaling applications in different environments.

🌩️🌐👩‍💻 Cloud Computing Private cloud: dedicated resources for one organization, more control and security, higher cost and maintenance. Public cloud: shared resources for multiple organizations, less control and security, lower cost and maintenance. Choose wisely!

🤖🔧👨‍💻 Automation: using software to perform tasks that are repetitive, error-prone, or time-consuming, such as testing, deployment, monitoring, etc. Configuration management: using tools to manage the state and behavior of systems and applications, such as Ansible, Puppet, Chef, etc. Work smarter, not harder!

🐳🚀👩‍💻 Container Runtime is the software layer that enables containers to run on a host machine. It provides an interface between the container engine and the operating system. It also manages the container lifecycle and resources.

🌐🔌👩‍💻 Modern API Technologies are the tools and methods that enable developers to create, test, document, and deploy APIs. They include frameworks, protocols, standards, and platforms that facilitate API development and integration.

🐙🛠👩‍💻 Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It orchestrates clusters of nodes and pods that run containers across different environments.

🕸🛡👩‍💻 Service Proxy and Service Mesh are technologies that enable communication and security between microservices. A service proxy is a software agent that intercepts and handles network requests. A service mesh is a network of service proxies that manage traffic and policies.

🔄🚀👩‍💻 CI/CD is a set of practices that enable faster and reliable delivery of software. CI stands for continuous integration , which means merging code changes frequently and testing them automatically. CD stands for continuous delivery or deployment , which means releasing software to production with minimal manual intervention.

📺📨👩‍💻 Streaming and Messaging are techniques that enable asynchronous and real-time data processing for app development. Streaming is the continuous ingestion and analysis of data from various sources. Messaging is the exchange of data between applications or services via a broker or a queue.

👀📊👩‍💻 Observability is the ability to monitor and understand the internal state and behavior of a system based on the external outputs. It involves collecting and analyzing metrics, logs, and traces from various components and sources. Observability helps to identify and troubleshoot issues, optimize performance, and improve reliability.

🚀🌩️🔥 Serverless is a cloud computing model that allows developers to run code without provisioning or managing servers. It is ideal for DevOps and SRE roles who want to focus on business logic, scalability and cost-efficiency.

That's all for this part - Cloud Native.
Next part is NON SRE/DEVOPS, a small one so it's below.

NON DevOps/SRE

There is no such a thing as NON-SRE/DevOps part in a SRE/DevOps guide, what I meant is some additional knowledge that you need or don't depending on your situation.
I'm a telecommunications engineer so I know that pretty well. You definitely need to learn some networking.
Extra things that I (and maybe you) know or want to understand better are cryptography, project management (mostly Agile), licencing and important Organisation (like CNCF, FSF, etc.). As I'm a huge Bitcoin only fan I know some things around blockchains too.

DevOps & SRE Roadmap explained by AI - part 2

Ștefănescu Liviu — Wed, 05 Apr 2023 16:33:28 +0000

This part is for what you need to know about Operating Systems.

You will need to understand some OS fundamentals . And if you're in a very rare case of a company that is Windows exclusive you will only need to live in a Linux terminal 99% of your time. So learn only Linux and learn it well.

Linux is a powerful open-source operating system that’s essential for DevOps and SRE roles 🐧🔧 It provides a stable, secure, and customizable platform for software development, deployment, and maintenance 💻 Linux is highly scalable and can be used across a wide range of systems 🚀

Linux commands are essential for DevOps and SRE roles 🔧💻 They allow you to manage hardware and software resources, automate tasks, and deploy software with confidence 🚀 Linux commands are highly customizable and can be used across a wide range of systems 🌎

Bash scripting is essential for DevOps and SRE roles 📜💻 It allows you to automate tasks, manage systems, and deploy software with ease 🚀 Bash scripts are highly customizable and can be used across a wide range of systems 🌎
(lol AI really likes to write can be used across a wide range of systems 🌎)

Essentially you need to know Linux very well!

This is all for Operating Systems.
Next part is the biggest one - Cloud Native.

DevOps & SRE Roadmap explained by AI - part 1

Ștefănescu Liviu — Wed, 05 Apr 2023 16:04:54 +0000

Introduction

(you can view the screenshots in a better resolution on the twitter thread here)

Hey there, budding tech enthusiasts! Welcome to the exciting world of DevOps! In this article, we'll walk you through a roadmap to kickstart your DevOps journey, and with a little help from our AI friend, we'll demystify key concepts and techniques that you'll need along the way. So, buckle up, and let's dive into the realm where development and operations join hands to deliver the best software experience possible!

No one knows everything from a full roadmap including the one made by me. I made it a couple of years ago to start my new #DevOps role and it's a WIP. You only need to understand most of the notions and to really know a few of them.
My roadmap has 4 parts. And every part and sub-part has something below it. The full circles are a must and dotted circles are more important.

Higher resolution here

I'll use:

ChatGPT from OpenAI
Claude from AnthropicAI
Bing Chat from bing
Bard from Google to explain some DevOps and SRE concepts in an easy way and in a more complex one too. And what tools to know for each. So let's start with the first part

DEVELOPMENT

While it's not a bad thing to know a language, it's not a must. You will need how to write some scripts, but now with #GPT4 and #Copilot you can make easy scripts in seconds.

VCS
Version control is a practice of tracking and managing changes to software code that helps high performing development and DevOps teams prosper 🚀👨‍💻👩‍💻. It allows developers to move faster and preserve efficiency as the team scales 📈👥

Deployments are a process of deploying applications into production environments in a consistent and reliable way 🚀👨‍💻👩‍💻. It enables faster development of new products and easier maintenance of existing deployments 📈👥

Architectural patterns are a set of best practices that help you design and build reliable, scalable, and secure applications in the cloud 🌥️🚀 They are essential in a DevOps or SRE role as they enable you to automate multistage DevOps pipelines and achieve continuous delivery 🔁

Python scripting is a powerful tool for DevOps teams 🔧🐍 It’s used for automating repetitive tasks, infrastructure provisioning, and API-driven deployments 🚀 Python’s flexibility and accessibility make it a great fit for this job, enabling teams to build web applications and data visualizations 🌐

That's all for the first part - Development.
Next part is Operating systems.

Kubernetes: The Revolution in Managing Digital Applications Made Simple

Ștefănescu Liviu — Wed, 05 Apr 2023 07:14:53 +0000

A beginner's guide to understanding Kubernetes and its impact on the digital world

Introduction

In the fast-paced world of technology, it's essential to understand the driving forces behind some of the most cutting-edge innovations. One such force, Kubernetes, has revolutionized the way digital applications are managed and deployed. But what exactly is Kubernetes, and how does it benefit both tech giants and small businesses alike? In this article, we'll break down the main concepts of Kubernetes in a way that's easy for a general audience to understand.

What is Kubernetes?

Kubernetes (often abbreviated as K8s) is an open-source platform that automates the deployment, scaling, and management of containerized applications. It was originally developed by Google and later donated to the Cloud Native Computing Foundation (CNCF). Containers, which are lightweight, self-contained software packages, enable developers to build, test, and deploy applications more efficiently and reliably.

Key Concepts of Kubernetes

Containers: As mentioned earlier, containers are the fundamental building blocks of Kubernetes. They package an application and its dependencies into a single unit, ensuring that the application runs consistently across different computing environments.

Nodes: In Kubernetes, a node is a physical or virtual machine that hosts one or more containers. Nodes can be easily added or removed, depending on the required computing resources, making it possible to scale applications quickly and efficiently.

Clusters: A cluster is a group of nodes working together to run containerized applications. Kubernetes uses clusters to distribute workloads evenly, ensuring that applications are highly available and can recover quickly from failures.

Pods: A pod is the smallest and most basic unit in the Kubernetes architecture. It represents a single instance of a running application and can contain one or more containers. Pods are designed to be ephemeral, which means they can be easily replaced if they fail or need to be updated.

Services: A service is a stable network endpoint that provides access to one or more pods running an application. It allows users to interact with the application without needing to know the specific details of the underlying pods or nodes.

Controllers: Controllers are responsible for maintaining the desired state of the Kubernetes system. They continuously monitor the system and make necessary adjustments to ensure that the actual state matches the desired state. Examples of controllers include the ReplicaSet controller, which ensures that a specified number of replicas of an application are running at all times, and the Deployment controller, which manages updates and rollbacks of applications.

The Benefits of Kubernetes

Kubernetes offers numerous advantages to businesses and developers, including:

Scalability: Kubernetes allows applications to scale up or down quickly and easily, depending on demand. This enables businesses to save resources and respond swiftly to changes in the market.

Portability: Because containers can run consistently across different environments, Kubernetes applications can be easily moved between on-premises, public cloud, or hybrid environments without requiring significant changes.

High availability: Kubernetes automatically distributes workloads and ensures that applications remain available even if individual components fail, improving overall reliability and uptime.

Streamlined deployment: Kubernetes simplifies the deployment process, allowing developers to focus on building and improving applications rather than managing complex infrastructure.

Cost efficiency: By optimizing resource usage and reducing manual intervention, Kubernetes can help organizations save both time and money.

Conclusion

Kubernetes has quickly become the industry standard for container orchestration and application management. Its ability to simplify deployment, ensure high availability, and enable seamless scaling has made it an invaluable tool for businesses and developers alike. By understanding the main concepts of Kubernetes, anyone can appreciate the remarkable impact this technology has on the digital world.