Continuing our series on the tools we build for ourselves at ReflexAI: Reflexings, the system that gives our engineers more than just a coding agent.
Coding agents can now navigate large repositories, write substantial amounts of code, run tests, investigate failures, and open pull requests. We use them extensively, and they allow us to move much faster.
But writing code is only one part of delivering a successful feature.
An effective engineer also understands the customer need behind the work, finds the right repositories and documentation, inspects logs and product usage, runs the application safely, and follows the company’s architecture, conventions, and security requirements. Even the most capable coding agent begins without most of that environment.
So we built Reflexings.
Reflexings is our internal agentic development platform. An engineer can mention it in Slack or GitHub, or start a session from its web workspace, describe what they need, and often receive a linted, type-checked, and tested pull request in under fifteen minutes.
Stripe’s Minions work was an important inspiration. But it raised a question: what could a focused, technically ambitious team build without the resources of an enormous platform organization?
We wanted the smallest durable system that could make agents genuinely useful inside the way ReflexAI already works.
Why build anything?
At first, the obvious approach was to give engineers access to the best available coding agents and let them work locally.
That worked for individual tasks, but it created three larger problems.
First, the agents lacked company context.
They could read a repository, but they did not automatically understand the Jira ticket, related Confluence documentation, Datadog logs, Amplitude activity, our design system, relevant Figma designs, or the patterns Scout had identified across customer and prospect conversations.
An engineer could assemble that information manually, but repeatedly doing so defeated much of the purpose.
Second, local tools were difficult to make broadly available.
We wanted product managers, designers, and customer-facing teams to explore ideas and contribute to product development. But we needed a way to make these tools broadly available while preserving the same principle-of-least-privilege controls we apply across ReflexAI. More powerful agents required stronger boundaries.
Third, code generation did not eliminate the rest of the development process.
The agent still needed somewhere to run the product, reproduce bugs, execute checks, inspect the result, and prepare something a human could evaluate.
The breakthrough would come from giving AI more of what an engineer already had: context, a complete development environment, secure tool access, learned organizational knowledge, and clear points for human judgment.
What using Reflexings looks like
Everything begins in the tools where our teams already work.
Someone might post, “@reflexings fix the timeout bug in AWSM-1234” in Slack, mention Reflexings in a GitHub comment, or open a session from the web workspace.
Reflexings reads the surrounding conversation, retrieves approved context, determines which repositories are involved, and asks clarifying questions when needed.
For larger tasks, it proposes a plan first. A human can correct assumptions and approve the approach before implementation begins.
Once approved, the system creates an isolated workspace, branches the repositories, implements the change, runs checks, reviews its diff, and opens a pull request. The link returns to the conversation where the request began.
Follow-up comments continue the same session. “Also update the tests” or “this needs to work in Prepare as well as Assure” goes back to the agent that performed the original work, with the preceding context intact.
The web workspace shows the plan, current activity, console output, running application, and evolving diff.
Reliability isn't a claim you make about an agent. It's something you can see: what it inspected, what it changed, which checks it ran, and where human judgment is still required.
Under the hood
Reflexings is not one coding bot. It is a set of interfaces, context sources, orchestration services, and secure development environments organized around a deterministic workflow:
Branch. Plan. Implement. Verify. Review. Prepare the pull request. Monitor.
The model operates inside that workflow, but it does not control the workflow itself.
Some sessions coordinate multiple agents inside that workflow. Review uses one lead reviewer and, for larger diffs, blind sub-reviewers focused on skepticism, architecture, and minimalism. Every critical or major finding then passes to a separate verifier instructed to refute it before it can become an inline comment. The model may vary by role, but the surrounding workflow determines what evidence is required and what the system is allowed to publish.
Each coding task runs inside an ephemeral, kernel-isolated sandbox. Reflexings claims a clean environment, clones the required repositories, loads approved skills and tools, creates a branch, and begins the session.
Inside the sandbox, the agent can install dependencies, run checks, start services, inspect its changes, and prepare a pull request. It runs without root privileges, cannot reach production or arbitrary external services, and receives only the access required for the task.
These are structural constraints, enforced by the environment the agent runs in.
Quality gates are practical. Reflexings retries failures with error context, but if a check remains red, it does not burn an hour chasing perfection. It opens a clearly flagged draft pull request, identifies what failed, and preserves the work for a human reviewer.
The repository’s own CI pipeline then runs the full suite of checks. Reflexings continues monitoring the pull request after it opens and can investigate and automatically fix issues that emerge in the pipeline, pushing updates back to the same branch until the pull request is ready for review and merge.
Reflexings can investigate, implement, test, open, and maintain a pull request through its lifecycle. It cannot merge one. Human review remains the final gate.
One system, many kinds of work
Reflexings supports work across the product-development lifecycle. Different sessions help teams explore an idea, investigate a problem, validate a change, or automate recurring work. Each runs inside the same secure system, but receives the context, tools, and output format appropriate to the job.
Explore and shape
“Studio” boots a working version of the ReflexAI product inside an isolated environment, with multi-threaded conversations, code and diff views, a live preview, logs, and a Design Mode for modifying the running interface. Sessions can sleep, wake, and continue over several days as a team iterates with the agent.
“Prototype” provides a faster, lower-cost path from an idea to a working concept. It uses ReflexAI’s design system without the complete production workflow, and Scout can supply customer and market context so the concept begins with an observed need rather than a generic prompt. Together, Studio and Prototype let product managers and designers react to something working, without first configuring a local development environment.
Investigate and understand
“Triage” investigates a specific bug using tickets, documentation, logs, traces, metrics, user activity, and repositories. It produces a structured assessment with evidence, suspected failure points, confidence, and a recommended next step. High-confidence investigations can continue directly into implementation; lower-confidence ones still give an engineer a much stronger starting point.
“Insights” is a read-only analyst for broader questions about the codebase, architecture, documentation, and tickets. Where Triage asks what caused a particular problem, Insights helps teams understand how the system works and make better-informed decisions before changing it.
Validate and improve
“Review” examines a pull request against its intent, linked Jira ticket, repository context, and ReflexAI’s engineering standards. It flags unmet acceptance criteria, helping ensure the change delivers what the ticket actually requires. Independent reviewers challenge the code from different perspectives, and serious findings must survive a separate verification pass before they are posted as inline GitHub comments. Engineers can reply to a finding to dispatch a session that fixes it directly.
“QA” evaluates both test coverage and the running product. One lane identifies gaps in end-to-end coverage, writes the missing regression tests, and opens a pull request. The other explores the application and captures screenshots, console output, network traffic, accessibility checks, and layout diagnostics. Suspected bugs are verified and checked against open Jira issues before they are filed with evidence and a suggested fix.
Automate recurring work
Scheduled sessions handle work that should happen repeatedly rather than begin with a new request each time: vulnerability reviews, stale pull-request reports, analyses of recurring failures, and other routine checks. The session type determines the tools and output; the schedule determines when the work runs.
Not every task should become code. Depending on the need, the right output may be a working environment, prototype, investigation, review, test plan, pull request, report, or recommendation.
Context is the product
A coding model can already write code.
The harder problem is delivering the right context at the right moment without overwhelming the model or violating data boundaries.
Different sessions receive different context. A bug investigation may need Datadog logs, traces, and Amplitude activity. An Insight report may need repositories, Jira, Confluence, and technical documentation. A Prototype or Studio session may need customer pain points from Scout, relevant Figma designs, and our design system.
Not every agent receives every integration. Reflexings selects the information and tools appropriate to the task, with external systems exposed through read-only interfaces.
The system does not work blind, and it does not receive unlimited access. Both principles are essential.
Learning with human approval
One of the most promising parts of Reflexings is its skill library.
After a successful run, an agent can propose turning what it learned into a reusable skill: a repository convention, build quirk, migration pattern, testing approach, or effective debugging sequence.
That proposal does not automatically become organizational knowledge. A human reviews and approves it first.
Approved skills are loaded into future sessions. We are measuring whether they reduce tokens, agent turns, completion time, and cost.
Over time, skills that become outdated, redundant, or no longer improve performance should be revised or retired. Institutional memory only compounds when it is curated.
Models will change
We did not architect Reflexings around a single provider, model, or version.
Models are improving quickly, and different tasks justify different tradeoffs. Classification does not need the same model or reasoning budget as an architectural change.
Reflexings allows the model to vary by session and phase. Models can be changed through configuration without rebuilding the surrounding platform.
The durable investment is the system around the model: context routing, security, execution, observability, approvals, skills, interfaces, and recovery from failure.
Models will continue to change. The environment around them should compound.
What we have learned
The model is only one component. A slightly less capable model with the right repositories, tools, logs, environment, and company-specific guidance may be more useful than a frontier model working from an isolated prompt.
We saw this directly during the rollout of Review. An engineer ran the same pull request through a leading frontier model prompted directly, a default off-the-shelf review bot, and Reflexings. Only Reflexings caught two important, real issues, even though its reviewers were using lower-cost models. The advantage was not the model alone. It was the harness around it: independent reviewers with distinct mandates, repository and ticket context, ReflexAI standards, memory of prior review rounds, and a separate verifier built to challenge each serious finding.
Early use has followed the same pattern. Findings are specific enough to name the relevant file, function, and method, which lets a fix session act without a human translating the problem. False positives have been rare, and the minimalist lens has caught overengineering that other reviewers ignored. One engineer described the experience as “absolutely ruthless,” and meant it as praise.
Security and the harness expand participation. Together, they allow product managers, designers, and customer-facing teams to take on meaningful development capabilities while preserving the role-based permissions and least-privilege boundaries that apply across ReflexAI. By embedding our engineering practices and standards directly into the workflow, the harness helps non-engineers contribute safely without requiring unrestricted engineering access.
Agents work best when the task is well scoped. A clear ticket still beats a vague wish, and some draft pull requests still require a human to carry them the final mile.
Most importantly, build the environment, not the demo.
A coding demonstration needs a model and a repository. A reliable development system requires isolation, identity, access controls, context routing, testing, durable state, cost attribution, observability, and recovery from failure.
Most of the work is around the agent. That is also where much of the lasting value lives.
The central hub for how we build
Reflexings began as a Slack agent that helped investigate bugs.
It is becoming the central hub for how teams at ReflexAI understand, explore, build, test, and improve our products.
Scout provides customer and market context. Jira and Confluence provide planning and organizational history. Figma and our design system provide the intended experience. Datadog and Amplitude provide evidence about what the product is doing. Repositories provide the implementation. Ephemeral environments provide a safe place to execute and verify changes. Skills allow validated knowledge to carry into the next session.
Reflexings connects those layers.
The breakthrough is not an AI that writes code.
It is giving AI what an effective engineer has: the context required to understand the problem, an environment that runs the product, hard security boundaries, learned organizational knowledge, and a seat in the places where people already work.
Then it is giving humans clear control over every decision that matters.