Pratham
I talk about web, AI, API, and social • Building experiences at @APILayer • Prev @Rapid_API @HyperspaceAI
Page 1 • Showing 20 tweets
Software engineering is undergoing a massive shift. From writing code manually to managing multiple agents. But they are hitting a wall. It’s not just about compute only. It’s about context, orchestration, and the friction of local environments. Oz by @warpdotdev solves this. Oz is the easiest way to run an infinite number of agents in the cloud. It takes 10 minutes to set up. It gives you 10,000 hours of leverage. Multiple ways to deploy Oz coding agents: 1. Event Triggers: Connect via Slack, GitHub Actions, or Linear. Turn a bug report or a ticket into a PR automatically. 2. The CLI: Trigger and manage cloud agents directly from the Warp Terminal. 3. Manual triggers online. Here is why this changes everything: – Most agents die when they hit a second repository. Oz lives in isolated Docker environments that can hold your entire stack. Update a database schema in the backend and Oz automatically ripples that change into the frontend and the docs. – The biggest waste in engineering is waiting for a human to trigger a task. Oz has a built-in scheduler. It prunes dead code, updates documentation, and performs competitive research while you sleep. – You can join an agent's thought process via a single link, nudge it in the right direction, and fork the final task locally to ship the PR. Warp + Oz is the first stack built for the Orchestration Era. Sign up for the Warp Build plan and get 1000 free Oz credits ➞ http://oz.dev/prathamx
After ClawdBot, the next big thing could be Qoder Quest. Most of the coding tools today need multiple iterations of testing, debugging, and prompts. An autonomous coding tool would be game changer. Qoder Quest is exactly this. It’s designed to take ownership of your projects. For sure, it is not a replacement for your mental model. Instead of line-by-line hand-holding, the workflow looks like this: – Describe a goal: tell it what you want to build – Approve the Spec: approve the technical spec first to align Quest with your mental model – Walk away: let the Quest run autonomously Attached is a video of me playing around with Quest for the first time. Get started with it: https://qoder.com/download New users could have a 2-week pro trial with some credits to execute 5 Quest tasks. Appreciate the Qoder team for collaborating with me on this deep dive.
I think people have misconceived the concept of “humans being replaced by AI in their job”. Think about it in this way. As a developer, in the past whenever you got stuck somewhere you would go to StackOverflow (manually curated human-generated questions and answers) or ask for help from your seniors (also humans). Now, You might go to popular and tuned models to get the answers or sometimes you just need to click on “auto fix”. I can barely remember the last time I searched for a code related problem on Google. I think AI replacing humans is the basic idea of reducing human interference in the work of other humans so that one can work with their full potential and independently. AI has already replaced many direct human efforts. A lot to come, think about it.
Learning to code was never about learning syntax. It was about: – how systems think – how state changes over time – how abstractions leak – how small decisions compound – how to understand errors and fix When you write code yourself, you are forced to be precise. AI is great at producing code. But it doesn’t automatically give you the mental model of why it works, where it breaks, or how it fits into a larger system. Without that model, you can’t reliably steer, debug, or extend what AI produces. In practice, learning to code matters even more now. You are no longer just writing instructions, you are supervising a probabilistic system that writes them for you. The future developer writes less code by hand, but understands more of it.
New way to write code: 1. Don’t start by typing code, start by mapping the data flow. Use AI chat to brainstorm the skeleton of your system before a single line is written. 2. Feed the AI your specific constraints, existing file structures, and style guides. The better the context, the fewer bugs you will have to fix. 3. Review every AI-generated function as if you are a Lead Engineer. If you can't spot the potential security flaw or inefficiency, you aren't ready to use it. 4. Use the AI to explain a complex block, then try to explain it back to the AI in your own words. If the AI corrects you, stay on that block until you truly own the logic. 5. Don't try to build the whole app in one prompt. Build one small, testable feature at a time.
If you hand a beginner an AI that writes perfect code, they still end up writing buggy software. The bug isn't in the syntax, it's in the mental model. Writing code is just the final leaf node of a massive tree of assumptions. If you don't understand the edge cases, the state transitions, or how the pieces actually compose, you are just prompting your way into a local minimum. Engineering is about the architectural taste of knowing why a system fails, even when the compiler says it's fine.
This is literally the easiest way to build AI agents like ClawdBot/OpenClaw. Thesys Agent Builder just went live, and it changes the game in two massive ways. 1. Super easy to build Add the data source and get the live link of your agent, which you can use on your site. 2. Generative UI Your agents respond with interactive UI like charts, forms, tables, and reports. Try it for free: https://thesys.dev/agent-builder#utm_sou… Thanks to the Thesys team for the partnership on this post.
Nothing is more dangerous than having a Product Manager who has never had to use the actual product. In consumer SaaS, you can fail fast. You ship a broken button, check the heatmaps, and fix it in the next sprint. No big deal. But in Developer Experience, failing fast is just a fast way to go out of business. Here is what happens when you have a non-tech PM (my personal experince): – they think shipping a rough sandbox is fine because "it's just an MVP." They don’t realize that to a developer, a buggy testing tool is a signal that your entire production infrastructure is a house of cards. – they think trust can be built later. Developers do not give you a second chance. If your tool fails them on day one, they will never come back. – they don't understand the developer-focused feedback. – they see every product like a social media app with a massive, general audience. They think if 1,000 people land on the page, the job is done. – they see feedback as a blocker. A PM who has never been an engineer sees a release date as the finish line. An engineer PM sees a release date as the initial start line of the race. That's why most developer-focused tools have "Built by developers for developers" in their footer. Think about it!