Por favor… chega de substituições de SaaS improvisadas em uma única tentativa — Mahmoud Abdelwahab, Railway

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Please… Enough with the Sloppy, One-Shot SaaS Replacements — Mahmoud Abdelwahab, Railway · Canal: AI Engineer · 13:01 · Assistir no YouTube

Tópicos: Agentes de IA, Aplicações empresariais de IA, Automação de tarefas e workflows, Engenharia de software com IA, Ferramentas de desenvolvimento com IA

Resumo

Mahmoud Abdelwahab conta como criou, com agents, uma ferramenta interna completa para substituir vários serviços de SaaS usados pela equipe da Railway. Ele destaca que há uma grande diferença entre software que funciona após ser gerado de uma vez e um produto realmente polido, consistente e agradável de usar. Para fechar essa lacuna, recomenda aproveitar uma base de código bem estruturada e pedir explicitamente padrões de experiência como salvamento automático, atualizações otimistas, desfazer ações e estado na URL. Também defende registrar preferências em agent skills e validar as funcionalidades de ponta a ponta.

Pontos-chave

Software gerado em uma única tentativa pode funcionar, mas ainda ficar aquém de uma ferramenta polida e agradável de usar.
Uma base de código bem estruturada e com abstrações sólidas ajuda agents a seguir padrões existentes e produzir funcionalidades consistentes.
Recursos como salvamento automático, colaboração em tempo real, atualizações otimistas, desfazer ações e arquivamento precisam ser solicitados explicitamente.
Manter filtros e ordenações na URL facilita compartilhar uma visualização específica com outras pessoas.
Usar páginas existentes como referência melhora a consistência de interface, busca de dados e estrutura entre funcionalidades semelhantes.
Preferências recorrentes de design e implementação podem ser organizadas em agent skills para orientar o trabalho dos agents.
A verificação de ponta a ponta revela problemas que a confirmação de build e testes, por si só, pode não detectar.
A ferramenta interna da Railway reúne gestão de conteúdo, publicação em redes sociais, CRM, tarefas, planejamento de lançamentos, calendário e edição colaborativa.

Capítulos

Início	Capítulo	Resumo
00:00	A diferença entre funcionar e ser agradável de usar	O palestrante apresenta a lacuna entre software gerado de uma vez e ferramentas internas realmente polidas, e descreve o sistema que criou para a Railway.
02:05	Uma base de código consistente	Ele explica por que estrutura e abstrações sólidas ajudam agents a reaproveitar padrões, além de citar suas escolhas para projetos web e de conteúdo.
04:09	Padrões de experiência que precisam ser solicitados	O palestrante percorre recursos como salvamento automático, colaboração em tempo real, atualizações otimistas, desfazer, arquivamento e estado na URL.
08:20	Reutilizar referências e registrar preferências	Ele recomenda usar páginas existentes como referência para manter a consistência e transformar opiniões recorrentes em agent skills.
10:24	Agent skills e verificação de ponta a ponta	O palestrante descreve skills de design e da Railway, destaca a importância de testar funcionalidades em execução e conclui incentivando a criação de ferramentas internas.

Citações

Há uma grande lacuna entre um software que funciona depois de ser gerado de uma vez e um software que eu realmente usaria. — 00:00

O salvamento automático é um recurso básico para um editor de documentos. — 04:40

Defina uma vez o que é bom e depois reutilize isso em mais funcionalidades. — 09:22

Na minha opinião, a etapa final — e a mais importante — é a verificação. — 11:27

Conceitos e entidades

Mahmoud Abdelwahab (pessoa): Apresentador que relata a criação de ferramentas internas com agents.
Railway (empresa): Empresa para a qual foi criada a ferramenta interna descrita na palestra.
GPT-6 (modelo): Modelo que o palestrante aponta como um momento decisivo para seu trabalho de construção de ferramentas.
TanStack (ferramenta): Conjunto de bibliotecas que o palestrante recomenda para projetos web.
Payload (ferramenta): Solução recomendada pelo palestrante para projetos relacionados a conteúdo.
Agent Skills (conceito): Instruções reutilizáveis que registram preferências e orientam agents na implementação.
atualizações otimistas (conceito): Padrão que mostra o resultado esperado de uma ação antes de concluir a sincronização em segundo plano.
verificação de ponta a ponta (conceito): Processo em que o agent executa e testa uma funcionalidade no fluxo completo para identificar e corrigir falhas.

Tradução completa (pt-BR)

00:00 As pessoas dizem há algum tempo que o SaaS está morto. A essa altura, isso nem é mais uma opinião polêmica. Por que pagar alguém para criar e manter as ferramentas que você usa, se você mesmo pode fazer isso? É só pedir para seu agent fazer. E, para mim, falta uma peça que raramente é mencionada: o fato de haver uma lacuna, uma grande lacuna, entre um software funcional feito de uma só vez e um software que eu realmente usaria. Um software que dá prazer de usar, que é refinado, que é agradável. E, na verdade, embarquei numa jornada para substituir vários provedores de SaaS que usamos internamente na

00:31 Railway, para fins de marketing. E simplesmente criei uma ferramenta completa que usamos. Ela nos permite gerenciar o conteúdo do site da Railway, o changelog e o blog. Podemos usá-la para enviar emails, publicar em todas as nossas redes sociais ao mesmo tempo e gerenciar a mídia do site. Tem até um mini CRM para que, quando trabalhamos com criadores externos, possamos acompanhar tudo. Há acompanhamento de tarefas e planejamento de lançamentos, porque você sabe que é preciso coordenar várias coisas e quando elas serão publicadas. Há um calendário e, ao mesmo tempo, comentários e edição em tempo real

01:02 e tudo foi criado usando agents. Eu diria que senti que houve um salto quando GPT6 foi lançado, e tudo isso está rodando na Railway. Tudo é publicado automaticamente. E agora vou explicar os princípios que uso para garantir que, quando quero adicionar um recurso, ele fique realmente refinado e combine com o restante do app, além dos princípios que você pode aproveitar e aplicar ao criar suas próprias ferramentas. Então, em vez

01:33 de fazer minha palestra no meu escritório sem graça, decidi mudar um pouco e fazê-la ao ar livre. Está absolutamente lindo. Agora estou em Edimburgo, na Escócia, e é surreal. Estou sentado num banco lá fora e esta é a vista. Com certeza, um banco nota 10. Para mim, esse tipo de palestra é um pouco diferente do que estou acostumado, porque vou contar a jornada de como criei nossas ferramentas internas e as opiniões que desenvolvi. Mas também entendo que

02:05 o cenário muda muito, muito rapidamente. Então, qualquer coisa que eu disser pode mudar completamente em questão de meses. Quem sabe? Então, não sei. Considere isto minha ressalva. Mas, na época da gravação, estamos no outono de 2026. É outubro. Enfim, dito isso, vamos falar do primeiro ponto: textos não importam. Muita gente diz que não importa qual linguagem de programação você

02:36 usa, nem qual framework. Você pode simplesmente pedir ao seu agent para criar qualquer coisa, e ele consegue fazer isso. E, embora eu concorde até certo ponto, descobri que, quando você está criando uma ferramenta que realmente vai usar e dá ao agent uma base de código adequada, com abstrações sólidas, o que acontece é que, ao trabalhar, por exemplo, em um novo recurso, você obtém um resultado muito mais consistente, parecido com o que já criou antes. E o motivo é muito simples: o agent não precisa

03:08 reinventar a roda toda vez que tenta adicionar um novo recurso, nem introduzir novos padrões. Ele simplesmente segue os padrões existentes. E, quanto ao que escolher, acho que não importa muito, desde que você tenha uma base de código bem estruturada. Mas, hoje, minha opção preferida são as bibliotecas do TanStack para qualquer coisa que eu crie para a web. E, se você estiver criando algo relacionado a conteúdo, eu diria para escolher

03:38 Payload. Ótima experiência, ótimas abstrações. Em certo momento, acabei entrando num grande buraco de coelho, comparando CMSs, porque não acho que eu deva criá-lo do zero, embora possa. Mas, de novo, quem sabe? Talvez o futuro mude. Enfim, esse foi o primeiro ponto principal com que me deparei. Quando você usa muitos produtos SaaS por aí de que realmente gosta e que usa todos os dias,

04:09 como usuário, há muitas coisas que você não percebe. Mas, quando tenta reproduzir uma experiência, logo descobre o quanto de cuidado e reflexão há nos diferentes fluxos. Algo tão simples quanto querer enviar um email ou publicar alguma coisa pode ser feito facilmente com um bom e velho app renderizado no servidor, com formulários que você envia. Mas, se tentar criar algo que será usado todos

04:40 os dias, algo que você vai usar bastante, vai pensar: “Não deveria ser assim”. E há vários padrões que descobri que os agents normalmente não implementam, a menos que você peça explicitamente. Esta é a minha lista. Vamos passar por eles um a um. O primeiro é o salvamento automático. Descobri que, se estou criando, por exemplo, algum tipo de editor de documentos, o salvamento automático é um recurso básico. Então, em vez de clicar manualmente em Salvar para salvar

05:13 as coisas, basta pedir para salvar o progresso automaticamente em segundo plano e garantir que isso não bloqueie a interação, para que você possa, por exemplo, continuar digitando enquanto tudo é salvo automaticamente. E outra etapa que você pode acrescentar é impedir que a aba do navegador feche se houver alterações não salvas. Essas duas camadas garantem que aquilo em que

05:44 você está trabalhando não se perca. Você também pode ir além e adicionar colaboração em tempo real, para permitir edições simultâneas. E, de novo, meu agent não teve dificuldade nenhuma para adicionar esse recurso. Foi só, sei lá, perguntar sobre ele, analisar como funcionaria e, depois de tudo pronto, >> apenas 700 milhões de tokens depois, eu tinha edição em tempo real. Então, em geral, eu diria que essa é a primeira coisa que os agents não fazem bem do ponto de vista da experiência

06:16 do produto. Outro padrão que descobri que os agents esquecem completamente de implementar são as atualizações otimistas. Em vez de mostrar um monte de indicadores de carregamento aos usuários sempre que eles realizam alguma ação, você mostra imediatamente o estado de sucesso, de forma otimista, e sincroniza em segundo plano a alteração que fizeram. Se a sincronização ou a operação falhar por algum motivo, basta desfazer a alteração e avisar que a operação não funcionou. É claro que não se deve usar atualizações otimistas às cegas para

06:46 tudo. Há situações em que você quer mostrar um indicador de carregamento ao usuário e esperar para verificar se tudo funcionou corretamente. Mas, em geral, as atualizações otimistas fazem a experiência geral parecer significativamente mais rápida, muito mais ágil e imediata. Tenho quase certeza de que você pode simplesmente pedir ao seu agent: “Quero implementar atualizações otimistas onde fizer sentido. Vamos elaborar um plano.” Ele vai indicar todas as áreas em que isso faz sentido. De novo, não é difícil para o agent implementar. Você só precisa

07:19 pedir e saber exatamente o que pedir. Agora, na minha opinião, uma extensão das atualizações otimistas é dar aos usuários a possibilidade de desfazer certas ações. Por exemplo, se você pedir ao seu agent para implementar a capacidade de excluir registros, o que ele normalmente fará é adicionar um botão de exclusão. Você clica nele, talvez apareça uma caixa de diálogo de confirmação, você confirma e então a exclusão é realizada. Mas uma experiência muito melhor é permitir que o usuário desfaça essa ação. Então, ele clica em Excluir,

07:49 você remove imediatamente da interface o item que ele quer excluir, mas avisa: “Ei, você tem alguns segundos para mudar de ideia”. Se não fizer nada, significa que realmente quer excluir o item. Aí, você realiza a operação. Caso contrário, se clicar em Desfazer, você restaura a alteração. Então, a operação também acontece em segundo plano. É basicamente uma ação adiada, o que se conecta ao próximo ponto: arquivamento. Você

08:20 Você deve dizer ao seu agent que quer a possibilidade de arquivar registros e desarquivá-los, porque às vezes você quer ocultar algo completamente da interface ou, digamos, dos resultados da busca, e arquivar será a maneira de fazer isso. Você não deveria obrigar o usuário a pensar: “Bem, se você não quer ver isso, precisa excluir”. Uma experiência muito melhor é simplesmente poder arquivar registros. Então, acho que esse é um padrão que definitivamente deveria existir. Outro ponto importante para mim é o estado da URL. Você deve pedir ao seu agent que persista as informações na URL sempre que fizer sentido, é claro.

08:51 E isso é muito útil porque, quando você tem, digamos, uma lista de registros e quer poder filtrá-los ou ordená-los, com um monte de condições, manter essas informações na URL facilita muito compartilhá-las com outra pessoa. Aí, digamos, outro membro da equipe pode ver exatamente o que você quer que ele veja. Outro detalhe pequeno que os agents não implementam de fábrica é a rolagem infinita. Não quero ficar clicando em “Carregar mais” repetidamente, nem em um botão de próxima página enquanto eu

09:22 rolo a página. Eu deveria simplesmente receber os dados, sem precisar clicar em “Próxima página”, e, no fim, só ver que cheguei ao final. É algo muito pequeno, mas, quando você usa uma coisa todos os dias, acho que faz uma diferença enorme. Outro padrão que descobri que melhorou bastante o resultado foi dizer explicitamente ao agent para usar páginas existentes como referência para a interface, a busca de dados, o funcionamento e a estrutura geral da página. Isso me permitiu essencialmente definir

09:53 uma vez o que é um bom resultado e depois reutilizar isso para mais funcionalidades. Para ser completamente sincero, às vezes, mesmo quando você diz ao agent: “Ei, use a página X como referência”, ele simplesmente não segue a instrução. Não sei se os modelos ficam mais burros às vezes, mas isso acontece. No geral, porém, eu diria que tenho mais sucesso quando digo ao agent para usar uma página existente como referência, porque assim você também acaba com uma experiência mais consistente. Então, conforme você usa seu

10:24 app, pensa: “Ah, isso combina com a outra parte do app”, se ambas compartilham o mesmo conceito. Por exemplo, se duas partes do app são essencialmente listas de registros que você pode criar, atualizar, excluir e listar, essas duas partes devem ser praticamente idênticas. Essa lista me leva ao próximo ponto: sempre que você tiver opiniões sobre algo, elas devem ser organizadas como skills de agent. Assim, quando o agent estiver criando alguma coisa, ele seguirá essas skills de perto. E

10:56 enquanto eu criava todas as nossas ferramentas internas, acabei recorrendo a três skills de agent. Duas delas estão relacionadas à engenharia de design. Uma facilitava a criação de interfaces melhores, com tipografia e layouts melhores, além de mensagens de erro melhores em geral. A segunda era um conjunto de skills de engenharia de design que facilitava criar animações melhores e outras coisas do tipo. E, por último, mas não menos importante, estão as skills de agent da Railway, é claro. Então, tudo o que criei internamente para nós na Railway roda na

11:27 Railway, é claro, tudo. Ou seja, buckets, bancos de dados, o próprio app, o servidor em tempo real, tudo. Para o agent trabalhar de forma eficaz com a Railway e conseguir fazer o deploy de tudo, bastava fornecer as skills de agent, e ele conseguia fazer isso. E, sim, depois que você tem todas as suas skills de agent e tudo mais, na minha opinião, a etapa final — e acho que a mais importante — é a verificação. Normalmente, quando você pede aos agents para criar algo, eles dizem: “Beleza, implementei a funcionalidade, a compilação passou, os testes passaram, está tudo certo, né?” Mas o que descobri é que, quando você realmente testa o que acontece, às vezes acaba com uma experiência totalmente quebrada. Então, quando você tem um ciclo de verificação em vigor, a diferença é enorme, porque dá para ver o agent literalmente dizer: “Beleza, criei isso. Testei. Não funcionou. Vou corrigir.” E ele continua fazendo isso. No fim, diz: “Beleza, testei tudo completamente.” E senti que houve um avanço na utilização do computador quando ela ficou realmente, realmente

11:59 O build passou, o teste passou, tudo certo, né? Mas o que descobri é que, quando você realmente experimenta o que foi feito, às vezes acaba tendo uma experiência muito quebrada. Então, quando você tem um loop de verificação em funcionamento, a diferença é da noite para o dia, porque dá para ver o agent literalmente dizendo: “Certo, construí isto. Experimentei. Deu errado. Vou corrigir.” E ele continua. E, no fim, é como se dissesse: “Certo, testei tudo por completo.” E senti que houve um avanço no uso do computador quando ele ficou realmente, realmente

12:30 boa. Agora, sempre que quero adicionar uma nova funcionalidade, digo no final: “Você deve verificar se a funcionalidade funciona de ponta a ponta e testá-la executando a infraestrutura; use-a para testar tudo de ponta a ponta.” E os agents são muito capazes de fazer isso. Você só precisa dizer a eles. Com todas essas peças, eu diria que você acabará com ferramentas internas sólidas, que pode criar rapidamente, que funcionam direito e de maneira consistente. E é isso. Esta foi

13:01 a minha lista de princípios que uso sempre que estou criando qualquer ferramenta interna. Espero que tenham sido úteis, mas, mais importante, que você se sinta inspirado a criar suas próprias ferramentas internas, que sejam agradáveis de usar, bem-acabadas e despertem alegria. E espero que você também possa se tornar a camada de SaaS da sua empresa. E, com isso, muito obrigado por assistir. Vejo você no próximo

Transcrição original

[00:00] People have been saying that SAS is dead for a while now. It’s not even a hot take at this point. Why pay someone to build and maintain the tools you use when you could just do it yourself? Just ask your agent to do it. And for me, there’s one missing piece that rarely gets mentioned. And it’s the fact that there’s a gap, a big gap between working software that got oneshotted and software I would actually use. Software that sparks joy, that is polished, that feels good. and actually went on a journey to replace a bunch of SAS providers we’re using internally at

[00:31] Railway for marketing purposes. And I just built an all-in-one tool that we use. The tool allows us to manage content for the Railway website, change log, blog. We can use it to send emails, post on all of our social platforms at the same time, manage the website’s media. There’s even a mini CRM so that when we’re working with like external creators, we can keep track of that. There is task tracking, launch planning because you know you want to coordinate multiple things and when they’ll go out. There’s a calendar and at the same time there’s like comments, realtime editing

[01:02] and it’s all built using agents. I would say I felt the breakthrough when GPT6 came out and all of this is running on railway. Everything just auto deploys. And let me essentially now walk you through the principles I use to actually make sure that when I want to add a feature, it’s, you know, actually polished and matches the rest of the app and at the same time the principles that you can pull from and apply when building tools of your own. So instead

[01:33] of doing my talk from my boring office, I decided to switch things up and do it outside. It is absolutely beautiful. Right now I’m in Edinburgh, Scotland, and it’s just unreal. Like I’m on a bench outside and this is my view. Definitely a 10 out of 10 bench. Now this type of talk for me feels a little bit different than what I’m used to because I essentially will walk you through the journey of me building our own internal tools and the opinions I’ve developed. But I also understand that

[02:05] the landscape changes very very quickly. So like anything I say might change completely in like the span of months. Who knows? So I don’t know. Consider this my disclaimer. Like but the time of recording is fall 2026. It’s October. And yeah. So anyway, with that out of the way, uh let’s talk about the first point which is texts don’t matter. Now, a lot of people say that it doesn’t matter what programming language you

[02:36] use, what framework you use. You can just ask your agent to build you anything and build it is able to do it. And while I agree to some extent, what I found is when you’re building a tool that you will actually use, when you give the agent a proper codebase with solid abstractions, what ends up happening is whenever you’re working, let’s say, on a new feature, you end up with a much more consistent result that is similar to what you’ve already built before. And the reason is like it’s very simple. the agent doesn’t need to

[03:08] reinvent the same like wheel every time it tries to add a new feature or it doesn’t need to introduce new patterns. It will just essentially follow existing patterns. And when it comes to like what you choose, I feel like it kind of doesn’t really matter as long as you have a code base that is properly structured. But like my go-to choice today is one tan stack libraries for anything when building on the web. And if you’re building anything content related, I would say definitely go with

[03:38] payload. Solid experience, great abstraction. I went down like a big rabbit hole of like comparing CMSS at some point because I don’t believe that I should uh build it from scratch even though I can. But again, who knows? Maybe the future will change. But yeah, and that’s kind of like the main first item that I kind of ran into. When you use like a lot of SAS products out there that you actually love that you use every day,

[04:09] when you’re a user, there’s like a lot of things you don’t notice, but when you actually try to like replicate an experience, you quickly find out how much care and thought goes into different flows. So like something as simple as oh I want to be able to send an email or to publish something. You can easily do it by having like a good old you know just like server side rendered app with like forms that you submit. But if you try to build something that is going to be used every

[04:40] day that you will reach for a lot you’re like oh it shouldn’t feel that way. And there are kind of like a bunch of patterns that I found that agents don’t typically do unless you explicitly ask them to. And this is my list. So we’ll go through them one by one. And the first one is like autosave. I found that if like let’s say I’m building some form of document editor, autosave is kind of like a table stakes feature. So rather than manually clicking save to save

[05:13] things, you just ask it to automatically save progress in the background and to make sure that it’s like a non-blocking action so that you can let’s say if as you’re typing you’re able to type and then it just automatically saves. And one other kind of like step further that you could do is to also prevent the browser tab from closing if there are unsafe changes. So it’s kind of like this these two layers that kind of guarantee that whatever it is that

[05:44] you’re working on is just not going to be lost. Now you can also go a step further and to add like real-time collaboration so that you can have like concurrent edits. And again, my agent didn’t struggle at all with adding the feature. It was like, I don’t know, asking about it, reviewing how it would work, and then once that’s done, >> just 700 million tokens later, I had real time. So, I would say in general, this is the first thing that I find agents just don’t do well from a product

[06:16] experience perspective. Another pattern I found that agents completely forget to implement is optimistic updates. So rather than showing your users a bunch of loading spinner whenever they’re taking any action, you essentially show them the success state you know optimistically and in the background you’re going to sync whatever change they made. Now if the sync or the operation fails for whatever reason you just roll it back and then tell them like oh the operation work. Now of course you shouldn’t blindly have optimistic updates for

[06:46] everything. There are some scenarios where you want to show the user a loading spinner and you’re going to wait to check that everything worked properly. But in general, having optimistic updates makes the overall experience feel significantly faster, much snappier, and it will just feel much more instant. So pretty sure you can just ask your agent like, “Hey, I would like to implement optimistic updates where it makes sense. Let’s come up with a plan.” And it will tell you all the areas where it makes sense to do. Again, it’s like it’s not difficult for the agent to build it. You just need

[07:19] to ask and know exactly what to ask for. Now, an extension of optimistic updates, in my opinion, is giving users the ability to undo certain actions. Now, for example, if you ask your agent to implement the ability to delete records, what it will typically do is it will give you a delete button. You click it, might show a confirmation dialogue, you hit confirm, and then it will actually do the deletion. But a much nicer experience is actually allowing the user to undo that action. So they hit delete,

[07:49] you immediately remove the item they want to delete from the UI, but you tell them like, hey, you have like a couple of seconds where you could change your mind. And if they don’t do anything, that means you actually want to delete a thing. Then you actually implement the operation. Otherwise, if they hit undo, you just bring back the change. So it’s kind of like you do the operation in the background as well. It’s just kind of a delayed action which kind of ties into the next point which is archiving. You

[08:20] should tell your agent you want the ability to archive records and be able to unarchive them because sometimes you want to hide something from the UI completely or let’s say from search results and archiving will be the way to do it and you shouldn’t force your user to be like well if you don’t want to see this you have to delete it. and a much better experience is just the ability to walk out records. So I think it is a pattern that should definitely exist. Another big one for me is URL state. you should ask your agent to persist in the URL whenever it makes sense of course

[08:51] and it’s so useful because whenever you have let’s say a list of records and you want the ability to filter or sort them and you just have a bunch of like conditions maintaining these things in the URL makes it trivial for you to give them to someone else and then let’s say another team member is just going to be able to see exactly what you want them to see now another small detail that agents don’t implement out of the box is infinite scroll I don’t want to be clicking on load more over and over and over or like a next page button as I

[09:22] scroll I should just get the data I shouldn’t need to click next page and then in the end I’ll just see that oh I’ve reached the end it’s a very minor thing but also when you use something every day I think it makes a huge difference now another pattern I found that made the output significantly better is telling the agent explicitly to use existing pages as references when it comes to the UI the data fetching and how it works works and how the thing is overall structured and that made it possible for me to essentially define

[09:53] what good looks like once and then just reuse it for more features. Now to be completely honest sometimes even when you tell the agent like hey use page X as a reference sometimes it just doesn’t follow it. I don’t know if models like get dumber sometimes but sometimes it does happen. But overall, I would say that my success rate is higher whenever I tell the agent to like, well, use an existing page as a reference because you also just end up with a more consistent experience. So like as you’re using your

[10:24] app, you’re like, oh, this just matches the other part of the app if they both share like the same concept. So like if two parts of the app are essentially lists of records that you can create update and delete and like list well both of these parts should be pretty much identical. This list kind of brings me to my next point which is whenever you have opinions about something they should be packaged as agent skills and then this way your agent whenever it’s building something it will actually follow those skills pretty closely. And

[10:56] as I was building all of our internal tooling, I found myself reaching for three Asian skills. Uh two of them are related to design engineering. So one made it easier to have better UI, better typography, better layouts as well as like better error messages in general. And the second one was a set of design engineering skills that made it easier to just have better animations and other things like that. And then last but not least is the railway Asian skills, of course. So like everything that I built for us internally at railway runs on

[11:27] railway of course like everything. So like buckets, databases, the app itself, the real-time server, everything. And for the agent to effectively work with railway and be able to deploy everything, you just give it the Asian skills and it was just able to do it. And yeah, so like once you have all of your Asian skills and everything, in my opinion, the final step and I think this the most important step is verification. So the agents typically whenever you ask it to build something, it’s going to be like, okay, I implemented the feature,

[11:59] build passed, test pass, all good, right? But what I found is when you actually try out what happens, you sometimes end up with just like a very broken experience. So once you have like a verification loop in place, it’s like a night and day difference because the agent you can literally see it be like, “Okay, I built this thing. I tried it. It failed. I’m going to fix it.” And it just keeps going. And then in the end, it’s like, “Okay, I fully tested it.” And I felt this breakthrough with computer use once it got really, really

[12:30] good. And now everything every time I want to add a new feature I literally just in the end say well you should verify that the feature works end to end and use it by actually running infrastructure and to test things end to end and the agents are very capable of doing this. You just have to tell them and once you have all those pieces I would say you will end up with solid internal tools that you can build quickly that work properly and work in a consistent way. And that’s it. This was

[13:01] my list of principles that I use whenever I’m building any internal tools. Hope you found them useful, but more importantly, that you’re inspired to build your own internal tools that feel good, that are polished, and spark joy. And I hope that you too can become your company’s SAS layer. And with that, thank you so much for watching and I’ll see you in the next