Yes, that's interesting and very true. In fact we see it happening too. This is where we have had to explore follow up action in the agents. Completely agree these AI is a looped sequence and without a hybrid approach where we devs are monitoring the actions and even the reviews it can devolve quickly. The point here is really that both code gen and reviews can be automated with control that you can accelerate, and yes, the cruft that comes along with it. Eg, the tooling has to flow both ways. AND most of the time it is triage. I do not disagree with that - you are spot on. The golden age is in harnessing the supervision to increase dev effectiveness. I am living that right now and spending half my time in the review cycle with maybe 20-30 percent in the actual coding. But I can say that I am accelerating beyond my wildest expectations on my projects here. Are there gaps? Sure! Am I delivering 100x? Yes I am. But that comes with a certain amount of oversight and due diligence I hadn't anticipated too. There are trade offs. Happy to share examples here.
Travis Muhlestein PRO
TravisMuhlestein
AI & ML interests
Product & AI CTO at GoDaddy focused on AI infrastructure, orchestration, agent systems, observability, and enterprise-scale AI deployment
Recent Activity
repliedto their post 12 days ago
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end. posted an update 12 days ago
What happens when you treat an AI support assistant like a product instead of a chatbot?
The Katana platform team had 5 engineers supporting 500+ production applications, with adoption doubling every year.
They built an AI assistant grounded in:
Slack history
Internal documentation
Custom instructions
Live platform API data, including logs and configuration
Today, it resolves 80%+ of support requests autonomously.
The interesting part is what happens around the model.
The team continuously improves the assistant based on real usage, monitors escalations and sentiment, keeps it updated as the platform changes, and maintains a human fallback when needed.
They also ran a two-week experiment with direct Slack support disabled before making the approach permanent.
The model is only one piece of the system. Context, feedback loops, observability, escalation paths, and human handoff are what make it work in production.
🔗 https://www.godaddy.com/resources/news/how-we-scaled-platform-support-10x-without-scaling-the-team posted an update 19 days ago
One of the most underrated parts of AI-assisted engineering may have nothing to do with the model.
It's the infrastructure around the engineer.
Shriyash Balshetwar and Shubham Jangle, engineers at GoDaddy, were spending roughly 16 mechanical pull requests per week managing localization branches. None of the work was particularly difficult—it was repetitive, easy to forget, and occasionally capable of blocking releases.
They built a GitHub App to remove the entire workflow.
What I find interesting is what happened underneath the simple idea of "automate the PRs."
The production system needed idempotent webhook handling, installation-scoped authentication, retry logic around GitHub's asynchronous mergeability state, per-repository configuration, and safe pattern matching.
The app itself is under 900 lines of JavaScript.
The interesting lesson is that the hard part of automation isn't always the automation.
It's building the reliability around it.
As AI agents take on more software engineering tasks, I expect this distinction to become even more important. The systems surrounding an agent—events, permissions, state, retries, validation, and feedback—may matter as much as the model making the decision.
🔗 https://www.godaddy.com/resources/news/how-a-github-app-saved-us-hours-of-manual-effort
Curious what other engineering workflows people have found worth automating end-to-end.