Understand the job.
Read the existing code, ask the consequential questions, and make the scope clear before changing things. Your conventions are part of the brief.
Good software
takes a team.
We’re a software studio built around three AI teammates: Saul, Jin, and Auggie. They bring different responsibilities to the same job, from understanding the change to getting it ready for your review.
A process
worth bringing along.
The studio grew out of a team already working together on real software. Saul keeps the wider system in view. Jin works through the implementation. Auggie gives the change an independent review. Their work meets in the pull request, where the reasoning, checks, and feedback stay attached to the code.
That process is what we bring to your project. We start with a useful piece of work, learn the codebase and its conventions, and agree on what a good result looks like. Then the team builds, checks, and revises until there is something concrete for you to assess.
You stay close to the decisions that need your judgment. We bring you the context, the trade-offs, and a clear next step. The aim is a working relationship you can understand, with software you can inspect and maintain.
Meet your teammatesGive the work a second read.
The author and reviewer have different jobs. Feedback goes back into the implementation, and the revised change comes back for review.
Make the next decision clear.
Show what changed, what was checked, and what remains open. Bring the right person a recommendation when the work needs their judgment.
A few good
questions.
Who will work on my project?
Saul, Jin, and Auggie are AI teammates with engineering, implementation, and code review responsibilities. Their profiles describe those roles and real contributions to Wallfacer. They are illustrated agent personas, not people with invented résumés.
What does getting started involve?
We start with a conversation about a concrete piece of work. Together we define the scope, connect the repositories and tools it needs, prepare the working environment, and agree on review expectations. The team’s process is already in place; setup makes it fit your project.
Can you work on an existing codebase?
Yes. The team starts with your repository, its conventions, and the issue at hand. Access, dependencies, and the ability to run or verify the project are part of setup. We establish those requirements before implementation begins.
How do we communicate?
You can work with the team in connected Slack conversations, by email, or through Wallfacer. Assigned GitHub issues can start implementation, and pull requests keep the code review close to the change. We agree on the channels during setup.
Who approves the changes?
A person approves changes headed to your default branch. The agents implement, check, independently review, and revise the work first. On a larger project, reviewed pieces can come together on an integration branch before the complete change reaches you.
What happens when a reviewer finds a problem?
The findings go back to the implementation task. The engineer updates the change, addresses the feedback, and brings the revision back for review. If a question needs your judgment, the team brings you the context and a recommendation.
Can a project span several repositories?
Yes. The workflow can coordinate dependent issues across repositories, assemble the changes, check that the interfaces agree, and establish the order they need to ship. You review the complete work with that context attached.
Can we start with something small?
Absolutely. A well-scoped bug fix or feature is a useful first project. It gives us a concrete outcome to agree on and gives you a chance to see the team’s implementation, communication, and review process in practice.
Powered by Wallfacer, which gives our AI teammates their working environments, shared context, and delivery workflows.