Mahmoud Abdelwahab built one internal Railway tool for website content, email, social posts, media, creator relationships, task tracking, and launch planning.
2
A structured codebase with reusable abstractions helps coding agents extend an app by following existing patterns instead of inventing new ones.
3
Agents need explicit instructions for product details such as autosave, optimistic updates, undo, archiving, URL state, reference pages, agent skills, and end-to-end verification.
Summary
Mahmoud Abdelwahab describes replacing several internal marketing SaaS tools at Railway with one application built using coding agents. The app manages website content, email, social publishing, media, creator relationships, tasks, launches, comments, and real-time editing. His main argument is that getting a feature to build is only the beginning. A well-structured codebase gives agents existing abstractions to follow, which produces more consistent features. Abdelwahab then lists behaviors agents often omit unless asked for them directly, including non-blocking autosave, protection against losing unsaved work, optimistic updates with rollback, undoable actions, archiving, URL-persisted filters, and infinite scrolling. He recommends showing an existing page as a reference and packaging recurring design and deployment preferences into agent skills. His final step is to have the agent run the application and test the feature end to end. Passing builds and tests alone can still leave a broken user experience.
A structured codebase gives agents patterns to reuse
Abdelwahab says the programming language or framework matters less than giving an agent a properly structured codebase with solid abstractions. When a new feature follows existing patterns, the agent does not need to reinvent the same solution or introduce another way to do the same thing. He uses libraries from the TanStack ecosystem for web work and recommends Payload for content-related applications. He says he compared content management systems rather than building one from scratch, even though building one was possible. The practical result is consistency across features that share the same concepts.
Daily-use software needs details that agents often omit
A basic server-rendered form can send an email or publish content, but Abdelwahab says software used every day needs more care in its flows. He found that agents generally do not add several of these behaviors unless the request names them explicitly. Autosave is his first example. A document editor should save progress in the background without blocking typing. The browser can also warn users before closing when unsafe changes remain. He added real-time collaboration for concurrent edits, and says the agent could build it once he asked for and reviewed the feature.
Optimistic updates should recover when the operation fails
Instead of showing a loading spinner after every action, an application can show the expected success state immediately and synchronize the change in the background. If the operation fails, the interface should roll the change back and tell the user. Abdelwahab says this makes suitable interactions feel faster, although he does not recommend using optimistic updates blindly. He suggests asking the agent to identify where they make sense. For deletion, he prefers removing the item from the interface immediately and offering a short period to undo the action before completing the deletion.
Archiving gives users a reversible alternative to deletion
Abdelwahab connects undo with archiving. Users sometimes want to hide a record from the interface or search results without destroying it. An archive and unarchive flow avoids forcing deletion when the real intention is simply to remove something from view. He presents this as a product behavior worth requesting directly from an agent. It gives people room to change their minds and preserves a way to bring the record back.
URL state and infinite scrolling remove repeated navigation
Filters and sorting on a record list should be persisted in the URL when that makes sense. A teammate can then open the same link and see the same conditions. Abdelwahab also asks for infinite scrolling instead of repeatedly clicking a load-more control or a next-page button. The user keeps scrolling until reaching the end. He calls this a small detail, but says it matters when people use the application every day.
Existing pages define what a new feature should look like
Abdelwahab gets better results when he tells the agent to use an existing page as a reference for the interface, data fetching, behavior, and overall structure. That page defines what good looks like once, then gives later features a concrete pattern to reuse. The agent does not always follow the instruction, but he says his success rate is higher when he includes it. Two parts of an application that both list records and support creating, updating, and deleting them should feel substantially alike.
Agent skills package recurring design and deployment preferences
When Abdelwahab formed opinions about how the application should work, he packaged them as agent skills so the agent would follow them while building. He mentions skills for interface quality, typography, layouts, error messages, and animation. He also used Railway skills for deployment. The internal application runs its buckets, databases, app, and real-time server on Railway. Giving the agent those skills allowed it to work with Railway and deploy the application.
End-to-end verification catches failures that builds miss
Abdelwahab calls verification the final and most important step. An agent may report that it implemented a feature and that the build and tests passed, while the actual experience remains broken. His verification loop has the agent open and use the running application, test the feature from start to finish, notice failures, fix them, and repeat. He says computer use became much more effective for this workflow. His instruction is to verify that every new feature works end to end by running the real infrastructure rather than relying only on build and test output.
"When you give the agent a proper codebase with solid abstractions, what ends up happening is whenever you're working on a new feature, you end up with a much more consistent result that is similar to what you've already built before."02:41
Who should watch
You are building internal tools with coding agents and the generated features work technically but feel inconsistent in daily use.
Your application has forms, lists, publishing actions, or collaborative editing and you want concrete behaviors to request from an agent.
You rely on passing builds and tests but do not yet have an agent workflow that uses the running application from start to finish.
