Thank you for having me.

So, I mean, the full story of it goes back quite a ways. I actually used to work a job that had a very significant commute every day. I, at the time, picked up a lot of podcasts. This is back about 2016. And so I picked up a lot of podcasts, one of them being the PHP Ugly podcast way back in its infancy. And I started following them, started hanging around there because PHP is a language I use. Again, it's not my main language anymore, but it is a language I reach for quite a bit. And I still go to as my kind of default backend language whenever time I'm building a mobile app or any sort of tooling that needs backend support. So it was something that was good to keep me fresh when I wasn't using the language on a regular basis. So I started listening to John and Eric on a regular basis there. And that kind of progressed and over the years as PHP Tech got taken over by Eric and is being hosted in Chicago, which is fairly close to me, I started coming down there to attend. This year, as it was, I was speaking with Eric and he had made the sad announcement that the developer was unable to get an app built in time. And I said, no, we had 3 weeks, we're getting it done. So, um, anybody who ships code knows that's not the right answer. I've done short-term projects like that before with a terrible deadline, and they often don't go well. But kind of in the new world we live in with AI tooling and all those kinds of things available I thought that was a very realistic project to get done, and we made it. I don't know how many of you know the, the timeline. We literally got it approved by Apple and into the App Store at about 5 AM on the Tuesday that the conference started. So, um, very, very tight deadline, but we made it, and I'm really proud of how that app turned out.

Yeah, I made the mistake of giving Eric that ability, but he actually didn't abuse it too badly at all, and it turned out really well for them being able to communicate with all the kind of unexpected changes and room changes that happened during the conference this year.

So my two primary languages are Swift and Kotlin. They are the ones that I use every— literally every single day. And I can jump into those between the code bases and have very little transition period between them because I use them every day and so fluently. And so that was my original hope, was that maybe I could do it with native PHP to start with, but I'm not as familiar with those libraries. And that with the condensed timeline, I knew that would be a little bit of an extra overhead that could have been problematic. Um, so as I've got about 15 years experience in doing mobile apps, it was just kind of this the first-class choice to use the native platform tooling. The other part of it then is using spec-first development, the code is immaterial. The designing things, the declaring what the behaviors are intended to be all the way through. Once I had that done for iOS, it was kind of a simple one-shot, now generate the Android version and then go through and kind of do the nitpicking versions on that. So the previous perception of doing two native apps is twice as much code is no— like, I mean, it's still twice as much code, but it's not twice as much work anymore. Most of it can be done in 10 minutes of generating code through an LLM.

So it's kind of the basis of the talk I gave at PHP Tech. If you took any new developer, it doesn't matter how senior, experienced, and knowing the platform that they are, and you throw them into your codebase, it's going to take them a ramp-up period. And, you know, for, for most senior developers, that is weeks to months before they're even competent in any sizable code base. So the idea that you can take an LLM, even if it is perfect, even if it has no flaws of its own, which is not the case, um, LLMs are inherently bad. That's where the vibecoding kind of memes come from. But the idea of throwing that into your code base and telling it to fix things is is a kind of a, a crazy notion on its own. So what I've found works really well is to first declare what the behaviors should be. It gives the opportunity for the LLM to look at the spec, see what the intended behavior is, look at the code to see how the code matches it, modify the code then to compare to the spec, and it gives it that feedback loop. So it's kind of test-driven development for an LLM. So you've already written that the spec to say what it's supposed to do. Now the LLM generates the code and modifies the code to see, does this now match that declared behavior? And when you generate new context, when you have, you know, you close your window for the day, you open a new fresh context the next day, you didn't lose all that information of what you were working on. It's all there in the spec to say, well, we declared this to be one behavior. I think it's going to be able to continue working this way. And the other aspect of it is that the strength of an LLM is translating languages from one to another. That's actually how they kind of came to be was translating spoken word from English to French, Spanish, whatever I'll say. Code is just another language. So once you have this written in English and you have all the behaviors declared, translating that to code is LLM strength.

So a company I worked for did exactly that. They had a very rigid procedure where if somebody had an idea for something, they'd first draft a one-pager, which is kind of your pie-in-the-sky goals. Then they would draft a PRD, a product requirements document. Based on that, the engineering team would draft a technical requirements document. This kind of condenses that process down to one where if you have an idea, build the spec, the AI can even find, can even parse that spec and look for things that are conflicting. It can help you draft it. It's very good at writing language from your conversations. Mm-hmm. The idea is to keep that persistent log of what the intended functionality is and If you have, instead of having, I'm picking on Notion. I actually really like Notion. So it's not going to sound like that, but I really do like Notion. But if you have a Notion document, Notion is in a lot of cases where documents go to die. People draft documents, they throw them in there, say, look what I made, and no one ever looks at it again. And that's not very useful. Meanwhile, if you keep that spec, all the detailed documentation in the repository with your code, it can be checked out. It can be versioned. It can be reviewed through PR process, it gives you a lot of flexibility for that. So in the case of like the PHP Conference app, what I had done was to use a monorepo pattern with separate folders for iOS, Android, and Laravel. And then I had a separate spec folder that had all these spec documents in there that declared the behavior, declared the interfaces, declared how the JSON schemas were. And now every time that I needed to modify something, I went through and I just checked and like, okay, let's look at the spec. What does it say? During the conference, I had a couple people who would point out 2 or 3 different errors that were in the app. Eric found one, for example, the plenum sessions where they were like the opening and closing sessions said they were in all rooms. And as much as I'd love to blame Eric for my problems and say it was a data issue, Actually, I found that bug and it was written in the spec. And that was my own mistake that as I was drafting this, I had wanted for the floating room bubble, if you will, to appear to be in all rooms. Instead, I drafted it to say it should be in all rooms and the LLM mistook my intention with that. Every bug that was presented to me, everything that we found, it wasn't a code issue. It was a— I declared a bug in my spec.

It is like we, as developers, we all look back and we say like, oh, who wrote this garbage code? And it's always you. Uh, most of the time the worst victim is always yourself or the person who left before you. That's always fun to blame that person.

So little do you, and so do you know they had the same problem you face right now and they've, they just solved it in the best way they But, uh, I'm really, I, I'm always a guilty party there. I'm sorry. Continue.

I'm actually going to push back a little bit even on my own idea for a moment. This is going to sound odd, but I have not historically been a fan of monorepos. In fact, coworkers of mine will know that I protested against it when the idea of moving to a monorepo pattern came up. Generally, I am against it because making small incremental pull requests has been the ideal workflow for a very long time in development. If you put up a pull request of more than 300, 400, 500 lines, a lot of the times that meant that you're, you're not chunking your work properly or anything of that nature. It is only with the AI-driven development that I think those rules have gone out the window. All the rules that we've had over the years that made development effective have changed dramatically. We now have the— having that ability to have multiple repository— multiple code bases rather, in a single repository allows AI tools to build better context for themselves and to update both ends of like a wire communication, for example, a JSON schema or anything like that, update both sides of that at the same time in the same PR. And that is incredibly powerful.

You know, I've heard— I don't work at any— I've never have worked at any of the big FAANG companies, but I've heard rumors that Windows is a single code, a single repository, and the idea that that probably 100 gigabyte, probably way more than that now actually, but that massive codebase could be a single repository. I think it has so many strengths, but it also probably gives them a lot of problems at this point. So I think there's a balance to be struck and we'll probably talk about at the end. I have a blog going up that's not up yet, but the name is important to me. It's Eventually Wrong. That like everything I do has its limits. Everything I've found, every time I've set a hard rule, there's always a point where it's— I'm eventually wrong. If you find a monorepo pattern is not the right answer, well, now it is. Or you find that it is, well, it has its limits. There is no absolute truth. There's no hard lines to draw in development. And that's where I have the mentality for just trying to ship code, just get it out there, and we can always revise it. We can always make it better, but let's just get it out there.

You know, even before I was working in PHP, I learned in Quick Basic when I was in third grade. And then when I was in high school, I got excited about learning OpenGL. I wanted to be a game designer like every other coder in that, at that age. And so I started learning C and QBasic. C, neither of them really have objects. Moved to PHP 4, there's no objects. PHP 5 came out, why would I need objects? This is, this was ridiculous. Why would anybody ever need these tools? And here we are today and objects rule the world and we just live there. Yeah.

So I started in mobile development in iOS 3.2 to, to put this into perspective. It was right as the iPad had been announced but not released. I got kind of challenged to building a mobile app for somebody, an iPad app for someone. Um, they literally said, we don't think you can do it, but we'll give you the opportunity anyways because we don't have anybody who's an experienced developer. And I jumped on that and I loved it. And that's kind of where I stuck for quite a while. Back then, mobile could do things that the web could not. That was what it was for, is because the Objective-C code or even the Java code on Android around the same time could compile down, it could be faster than what JavaScript, what the web was able to give a person. Even the JavaScript engines were not as performant as they are now. And that gave native a huge advantage, but it came at the cost of we had to manage your own memory, you had to manage threads and thread safety. There was a lot of sharp edges. The tools were bad. But that's what we did so we could do things that were incredible you couldn't do on the web. 2026, Chrome is amazing and it can do almost everything that a native app can do. And so the questions come in, why do mobile apps really even exist anymore? And the answer to that is kind of what, what I feel and what I push for to guide if a mobile app should even exist. A lot of people, and this is— a lot of people will take and say, well, I can take my Laravel website, put it into a PhoneGap, Cordova, any of those Ionic kind of wrappers, and I can ship my website as an application. There's no point in doing that if your users can already do all the functionality on the website. What makes a mobile app special is usually more about the persistence. About having that data pooling, the offline capabilities, then things like that, if your app is not one that benefits from that kind of thing, it generally doesn't need to exist. That's why a lot of the mobile apps I worked in over my career have been for banking, for finance, and things like that, where the security gains of having access to fingerprint sensors and biometric data in general, Those have been crucial and having that platform as a kind of a second factor authentication rather than having every new login requires the MFA and cookies getting deleted and all that kind of stuff. That persistent storage and persistent data of the user is crucial. So it's one of the areas I kind of push back whenever anybody's designing a new app today. What should this app do? What makes it special? And the PHP tech app's a good example of that. It wasn't just a calendar. It wasn't just showing like, here are the available ones. Every user, the moment you download it, you got to pick your own schedule for it. It gave you a consolidated list of it. It gave you the persistent communications channels with the backend. I don't— I didn't have analytics in there, but I didn't see anybody at the conference using the live activities on iOS or the widget functionality on Android. But those were other elements that I'd put in there. Um, the discoverability on them was not great, so I did— I was not hurt. But, um, those are the kinds of things that native apps bring to the table, and they are the main reason to have a native app today rather than just building a website and letting people access your tool in there.

On the iOS side, um, it was a button on the, on the agenda screen. There was a button on the top right corner that nobody noticed what it even was there for. I, I realized that after the fact, that was my mistake of discoverability. But again, given the timeline, I think we did okay.

Yeah, I thought it went really well. And again, handful of small bugs, but they weren't code bugs, they were design bugs or they were oversights. And as we were building it, that I was really happy to see that. The other thing, actually, I'll mention this, and I mentioned it in my talk a little bit. One of the strengths and weaknesses of spec-first is that you can do a lot very quickly. The downside of it is when you deploy, if you find out that there's some change that needs to be made and you just make it at that backend and you make it at a code level, that becomes a liability. Now, every single time you try and make a change, the spec says one thing, the code says another. The AI bot is told, err to the side of the spec, give the deference to the spec. And so it makes that change or reverts whatever change you have made there. So there are a few times in there when Eric, as he's trying to deploy our backend or my backend under the PHP Architect infrastructure, he had to make a few changes and those became liabilities as we were doing rapid iterations.

So yeah, and I've been working on getting a really— I've been playing a little bit with CodeRabbit for this. That is one of my goals, to have a very good bot for analyzing that and having a rule of like the spec must be updated to reflect the code changes. I haven't quite worked it out yet, but that is on my roadmap, something I'm really trying to get perfected.

So I have come to like love and hate CodeRabbit and CursorBot, Cursor's bug bot. They are simultaneously, they've caught some great bugs, but they can be kind of brutal at times and it can hurt your feelings sometimes. Like I worked really hard and the bot doesn't care.

Have you had any luck with the poems?

Okay.

Oh, it's not a Eric's installation of CodeRabbit. For PHP Architect. It was generate— it generated a poem on every time I did a pull request. Oh, it was a poem about the changes. You could argue it's kind of a waste, maybe boiling the oceans for nothing, but I rather enjoyed it. And there was one in particular that it, um, it was for the entire version of vendor mode for the app. I had done another probably 8,000 lines and I did it through a single PR. That's a bad practice, I'm aware. That was terrible. But It gave CodeRabbit enough material to actually write a reasonable poem about the contents and what it did. And it was just like a little 8-line thing, and it was just fascinating and made my day.

Yeah, it might be a feature to turn on or off. And usually if you do a 1 or 2 line code change, it like doesn't make sense, right? Because you can't write an 8-line poem about that. But if you do an 8,000-line change, that it actually has enough to write about.

You know, I'm happy to always talk to anybody in the community, uh, or anybody who's interested in becoming part of the community. As I mentioned kind of in my intro, I love this community. They are great people, and I think more people should join, even if you're not coding every day in PHP. There are so many great people here, so many great minds, that I love to reach out and talk to them and bring them in to meet people. So I'm always there in Discord. You can find me, I'm TheCodeLorex. Um, I also have, um, my Mastodon that you could reach out to me there, um, TheCodeLorex@lgbt.tech. Uh, either one of those, I'm happy to reach out and always available to talk. So that's about it.

Thank you.

Thank you for having me.