EntryThingy automated its own development pipeline with an AI coding agent that writes specs, implements features, and fixes testing failures, all before a human touches the PR. The team now ships three and a half times the work, with nobody new hired.
We run EntryThingy, an art call management system that is over twenty years old. When we purchased it, we knew we had a project on our hands if we wanted to get the business to get back to growth. After rebuilding the entire tech stack of the company from scratch, we wanted to maintain the same programming velocity without having to hire more engineers.
When one of our users would encounter a bug, they would email our customer support team. This team would then reproduce the bug, report it to our team by writing out a Linear issue, and then ask us to fix it. They would have to wait until our team had the bandwidth to turn to the problem, investigate, reproduce, and troubleshoot. From there, we had to actually put in a fix, which is often harder than it sounds. Once complete, we would come back and tell them it was fixed.
This back-and-forth could take days. At every moment, one of our team members was waiting for somebody else to unblock them, give more information, or create the fix. This led to users being blocked on potentially urgent bugs that they couldn’t do anything about, leading to loss of confidence or goodwill in our business, all the while, generating more customer support burden.
When it came to complex features or bugs, we saw a similar inefficient flow. Requiring a human to draft a specification file before implementation began was a bottleneck we couldn’t get past. Having a human read logs, diagnose, fix, and then push was often taking hours. Context-switching cost us too. We run several businesses, so attention is the scarce thing.
To solve this, we built a Linear-status automation system. When a customer support agent encountered a problem, they could write a quick note and then immediately send the support request to Linear. From there, a research agent would go investigate the issue. It would traverse customer context, their description of the problem, any screenshots and information, and then figure out what the issue would be.
Once the agent commented on the Linear issue with the requisite information, a separate agent would be called. This agent would take what the previous one found, and then suggest a fix. This would lead to a third agent who comes in and actually creates that fix, and then notifies the support agent. By the time an engineer saw there was an error, we already had a code change pending or being worked on. Their job now became reviewing the code change and perhaps testing to make sure it was a good fix, instead of diagnosing the problem themselves. From the time a support agent escalated the issue to the time it was fixed, between five and fifteen minutes had passed and they already had a solution.
One important caveat: we do not allow agents to deploy their own changes. This process is always gated by a human, who would review. Then, the human could deploy to production. Additionally, the agent would also not ‘guess’ at an issue. If it wasn’t sure, it would come back and comment on Linear saying as much, showing what dead ends it went down and why they didn’t work. Finally, the agent would check the existing pending code changes before creating duplicates, that way there was no wasted time on issues that were already being addressed.
This freed up our support and engineering teams. Instead of waiting on each other for days, they are down to hours and sometimes even minutes.