ranger-ross

AI and (Docker) containers aren't so different

2025-10-18T00:00:00+00:00

Over the last few months I have been noticing a shift in the public perception of AI and how it will impact the software industry. The utopic vision of AI automating all aspects of the development lifecycle is quickly eroding. There are a wide variety of views on this and I of course have my own. But I have been struggling to come up with a way to articulate my thoughts on where I think the future of AI in software development is going until earlier this week.</p>

I believe that AI will have a similar impact on the software industry as Docker and containers did in the 2010s. I’d like to make the case that AI will</strong> have a large impact on software industry but not as large some may believe.</p>

Why containers?</h2>
The idea of containers has been around for a long time but really took off in the mid-2010s with the introduction of Docker which adds nice ideas like images and layering. These concepts made working with containers much easier and the trend of using containers exploded. Fast forward to the 2020s and most modern systems are deployed using containers.</p>
Containers changed the way we deploy and distribute our applications. Containers allowed you to deploy without the worry of if the server you deploy to had the correct dependencies installed. This portability was a game changer for complex applications, especially during the rise of cloud computing. Containers also made it very easy to distribute applications and tools with others. It’s fairly common to spin up a database using docker during development with a single `docker compose up</code> command.</p>`
`My point here is that containers undoubtly changed the way we write and develop software. My claim is that AI will have a similar level impact but in different ways.</p>`
Agents and false dreams</h2> For the past 2 years, there has been a huge push to operationalize AI agents. The idea behind an agent is that it is autonomous and does not require continual input from a human. This frees up the human to do other more important work (or allows the companies replace them if you are cynical).</p> The deployment of agents has been mixed thus far. There are sparks of brilliance with a lot of mediocre results in between. The fundamental issue that has emerged is AI is not reliable on non-trivial problems in real codebases. This is really bad for those that have the vision of replacing humans with agents because until they are reliable a human is needed to double check their work. AI reliability is not likely to dramatically improve without a fundamental reachitecture.</p> The latest trend I have seen is the idea that a human operator will orchestrate many AI agents. A small army of AI agents would process in parallel and the human would verify and course correct as needed. Having the AI do segments of work in the background would theoretically still be a productity win even if limited to the review speed of a single human. I think there is some reasonable application here but we are limited by the cognative load of the human operator. I don’t see a world where we are scale pass 3-5 agents per human on any non-trivial problems. There are just too many code changes for a human to reasonably be able to keep in their head and think about the edge cases where the AI may be doing something wrong.</p> Agents may work in some limited areas but we are nowhere near a general purpose AI agent for for software development.</p> A more realistic impact</h2> AI is going to be a tool</strong> for engineers just like containers. I believe the future is going to largely dominated by high focused AI tools that accompish a very specific task in the development lifecycle. Similar to when containers were introduced, the overall approach we take to develop software will not change but the tools will. I believe the true advantage of AI is to get small frequent wins that add up overtime instead of trying to have an AI do large higher level tasks.</p> In fact, I think a large amount of these tools are already available to us.</p> GitHub Copilot (not the agent) provides a AI autocomplete. This is generally focused to a single function making the possible number of mistakes smaller and being low overhead of a human to review and iterate on.</li> Using AI to review human created work (in fact I used ChatGPT to review this blog post)</li> Using AI to orient yourself when working on a unfamiliar problem. Its great to get a rough overview a of problem space and learn some terminology so that you can refine your Google searches to find trust worthy sources.</li> </ul> The important thing to note is that the high level functions of software development are not going anywhere. Software engineering, engineering/project management, and designer roles will still exist. There will still need to be planning, development, testing, etc. Each of these roles and processes will likely change in some ways (hopefully for the better) but the overall software process will largely remain unchanged, just like when containers became popular in the 2010s.</p>

A more stable Rust Ecosystem 2025-09-23T00:00:00+00:00 Rust is often praised for its ecosystem of packages (aka crates). While crates.io</a> and its ecosystem of crates is indeed a big feather in Rust’s cap, there has been a lingering issue with the wider ecosystem that has been irking me for sometime. This being the hesitancy by the community to publish 1.0 versions for crates. This post is my attempt to articulate my thoughts on this trend and why I think its holding back Rust.</p> The Rust community is quite disciplined in following SemVer</a> and avoiding breaking changes, at least compared to other languages. 1</a></sup> It’s generally considered best practice to avoid breaking changes when making updates to a package. This is because when you make a breaking change in a popular crate, it causes a lot of churn downstream. Users need to read and comprehend the changes and modify their code requiring them to invest time in the upgrade. Frequent breaking changes cause a lot of pain for users!</p> Since crate authors feel pressure to avoid breaking changes, they will avoid publishing a 1.0.0</code> of their crates. In SemVer versions prior to 1.0.0</code> consider MINOR changes as breaking changes. This means that going from 0.1.0</code> to 0.2.0</code> is a breaking change. 2</a></sup> Once a crate publishes a 1.0.0</code> its considered “stable” signifying breaking changes are expected less often.</p> When Rust was early on many core crates were 0.x.x</code> to indicate to users that they were still trying to flesh out their APIs and experimenting with functionality. Crate authors did not want to commit to the current API and leave room for future changes. This was fine in 2015-2020, however fast forward to 2025 and we are in a very different landscape. We still have many core crates that have not stabilized.</p> The case for stabilizing</h2> If you are a crate author, I want to make the case for you to consider pushing for a 1.0.0</code> release.</p> Eventually what you got is what you got</h3> The most common argument to keeping a crate 0.x.x</code> is the author not wanting to “lock themselves into an API.” This is understandable and reasonable when your crate is early on, but at some point your crate is what it is. I have seen many crates, that have no active feature development but the author is still hesitant to publish a 1.0.0</code>. Your crate will never be perfect. If your crate is multiple years old, you should seriously consider publishing a 1.0.0</code>. It would be a better service to your users to stabilize your crate and consider a 2.0.0</code> if you really want to change the API in the future.</p> Your crate is not the standard library</h3> I believe one of the reasons crate authors are hesitant to publish a 1.0.0</code> is because they see the backwards compatibly promises from the Rust Project (official tooling like Rustc, libstd, Cargo, etc) and feel pressure to have similar guarantees. While a noble aspiration, it’s unreasonable for every crate to have such stability guarantees. While Rust 2.0.0</code> is not planned, that should not prevent your crate from making a 2.0.0</code> release.</p> Unblocking your dependents from stabilizing</h3> Another good reason to consider stabilizing your crate is if your crate is a dependency for other crates. When low level crates are 0.x.x</code>, it prevents high level crates that depend on the low level crate from stabilizing. This has a compounding effect when their are multiple layers of dependencies.</p> If some key crates hit 1.0.0</code> it would allow entire ecosystems of crates to stabilize.</p> Tooling</h3> Many tools leverage the SemVer semantics for functionality including cargo update</code>. These tools are less effective when crates are 0.x.x</code>. This is because MINOR changes are considered breaking changes so cargo update</code> cannot safely update MINOR versions prior to 1.0.0</code>. Once a crate is 1.x.x</code> cargo update</code> can update to the latest MINOR version allowing users to get new features of a crate much easier.</p> The social component</h3> Even if your crate has been around for a long time and is reliable, being 0.x.x</code> gives the impression that its still alpha software. I believe having so many 0.x.x</code> core crates gives people outside the community the impression that it’s not ready for production deployments. Often enterprises have policies preventing 0.x.x</code> packages from being used in production. Sometimes these policies lead teams to use another language for their problem when Rust might have been an optimal choice. Whether you agree or disagree these kinds of policies, they exist and likely aren’t going anywhere.</p> Wrapping up</h2> I hope that the arguments above at least make some crate authors consider stabilizing their crates. If you are still on the fence, I’d implore you to at least start a discussion in your issue tracker and consider a roadmap to 1.0.0</code> for your crate. I want to point out that there are some crates like serde</code> that reached 1.0.0</code> fairly early on and I believe the Rust ecosystem is better because of that. We have also seen many other crates like thiserror</code> and derive_more</code> hit 1.0.0</code> recently which is very important for the long term health of the ecosystem.</p> So much so that a tool cargo-semver-checks</a> has been created simply to make not publishing breaking changes by mistake ↩</a></p> </li> This behavior is convenient when you are early on in development of a crate and rapid breaking changes are common. ↩</a></p> </li> </ol> </section> AGI is not guaranteed 2025-08-09T00:00:00+00:00 I have seen a lot of bold claims about AI lately around its potential implications for the workforce. For example, the Anthropic CEO said that “in 3 to 6 months, AI will be writing 90% of code.” 1</a></sup> Recently at work, a coworker said “Coding will become like art, where humans will only do it for pleasure” implying that AI will be so much more productive than humans. These conversations have led me to reflect on the state of AI and its future.</p> Where we are today</h2> To think about the future we need to understand where we are currently. It’s been nearly 3 years since the initial release of ChatGPT at the time of writing. Since then we have seen a lot of improvement to the underlying models. Improved context windows, better weights through better training, new protocols that allow them to interact with external systems, etc. The latest frontier is agentic models with a heavy focus on coding.</p> The current focus of many large tech firms is operationalizing AI agents to accelerate development and reduce the engineering headcount needed to deliver new features. With the state of current AI agents, they are capable of producing usable code in small and medium sized codebases. However, even in medium sized codebases these agents run into context window limitations and need to be used in short bursts or use some workarounds like “summarizing” context to make it smaller. Agents can be useful tools, but they appear to be just that, tools</strong>. Even with the state of the art models, they still need to be operated by a human that has some idea of what they are doing. At least in the short term the idea of a completely autonomous agent is not anywhere near practical.</p> Looking to the future</h2> While the current focus of many companies is agents, many AI companies have their eyes on artificial general intelligence or AGI. There are many definitions of AGI, but I am going to define it as: A machine or software that can match peak human performance at any task. In other words, anything you can do, it can do better. Many of the leaders in the AI space and government institutions believe that we are on a crash course to achieving AGI.</p> This is concerning to me as there is nothing guaranteeing AGI will happen or even exists. There are important questions we need to answer first:</p> Is AGI even possible?</li> Is the current approach to AI a local minima?</li> How will we know if AGI is achieved?</li> </ol> The concept of AGI can certainly exist in a perfect world. However, we do not live in a perfect world. There are many equations in physics that have theoretical solutions but realistically will never happen due to environmental constraints. I believe the bar for AGI is not completely out of reach as it only needs to surpass humans, which are also imperfect. But we still need to take in the environmental constraints like energy production, training data, etc.</p> Current AI models are notoriously resource intensive. Given that we do not even have a known end point for achieving AGI we also do not know how much energy is required to achieve AGI. For all we know the energy required to operate AGI could exceed the amount of available energy in our solar system. If this is the case, AGI would not be practically possible in my lifetime. I tend to believe it should be possible with much less energy, but the fact of the matter is we do not know.</p> This leads me to ask is the current approach to AI even optimal in the first place? LLMs and RAGs have given us a great leap forward on AI progress but there is a potential that we are approaching a local minimum. In the short term, we see great improvements to AI capabilities but in the long term we hit limits to the algorithms and hardware. I tend to believe this is the case. Our models are very impressive from previous AI capabilities but we are starting to see diminishing returns on training and model/context size. If we want to see more large leaps it will require going backwards (likely for years) to develop a new approach to model reality.</p> </p> Finally we have no way of knowing if we have achieved AGI. The best we have now are AI benchmarks and anecdotal evidence. AI benchmarks are a useful tool but it is unclear if scores relate to real world performance. We also see AI companies prioritizing these benchmarks while neglecting areas that are not tested by benchmarks.</p> Given the state of AI capability measurement, I suspect we will see an AI company (or government) prematurely declare AGI has been achieved. There are many incentives to do so, so I would not find this as shocking to see in the next 5 years.</p> Is all lost?</h2> I tend to view the current AI hype cycle as a bubble no different than the dotcom bubble in the 1990s. All of the large AI companies are bleeding money and investors will only wait so long to see a return. The hype behind AI has not been what it can do, but what it can do now but what it will do in the future. Eventually, these companies will need to provide some path to sustainability and we have not seen any sign of that.</p> However, this does not mean that all AI tools are useless. In the dotcom bubble of the 1990s, many companies failed but the actually useful products like Google survived and thrived. But for us to get there we will need to live through the AI bubble.</p> We see a lot of companies feeling pressured to adopt AI. While there are legitimate use cases for AI, many companies are jumping on AI to please investors or simply out of FOMO</a>. This is unfortunate for consumers of software but unlikely to change in the near future.</p> Once the VC money eventually dries up and hype has died down, I am optimistic that trend of putting AI into everything will stop and we will see a more conservative thoughtful use of AI in applications. AI unlocks use cases that were previously not possible but it is not a silver bullet that solves all problems and we are not guaranteed to see AGI anytime in the near future.</p> https://www.businessinsider.com/anthropic-ceo-ai-90-percent-code-3-to-6-months-2025-3</a> ↩</a></p> </li> </ol> </section> The Evolution of Rust 2025-05-03T00:00:00+00:00 I started learning Rust</a> in late 2022 after finally giving into the hype. Two and a half years later I now completely understand why there is so much buzz around this language. It solves so many of the pain points I have had in other languages and I generally just find writing Rust more engaging.</p> However, Rust is not all sunshine and rainbows. There are real pain points that need to be addressed if Rust wants to compete with other popular programming languages. Many of these pain points are well known (slow compile times, steep learning curve relative to other languages, etc) and I do not have much to add. But I do want to explore a topic that is less talked about but is very important in my mind.</p> Rust’s selection of new features and managing the complexity of the language</strong></p> Rust has been changing rapidly over the past 10 years and this has helped fuel it’s success. After 10 years since 1.0, Rust has a gained a lot of features. I have began to wonder if the pace of new feature additions is healthy long term. It begs the question “What will Rust look like in 2035?”</p> To be clear, we need new Rust language features as we do not want to stagnate. But at what point is a language solidified and the pace of which large language features added slowed down? I am not saying Rust is at that point yet but its an interesting question to ponder.</p> Onboarding Friction</h2> Rust has a reputation for being difficult to learn/use compared to “higher” level languages like Javascript and GoLang. I feel this is a bit overblown, especially for modern Rust. Personally I find that I am nearly as fast if not faster in coding in Rust as I am in other languages. However, I did find the learning experience quite difficult compared to other languages.</p> Rust has a lot going on. It has a lot of features that you need to interact with in even simple programs. When learning Rust, one of the pain points I felt was the sheer amount of new concepts I had to learn to get up and running. While many of the features in Rust are worth while and improve the development experience they increase the learning curve of the language.</p> As someone who has introduced Rust at their workplace and is viewed as the “Rust expert” 1</a></sup>, I spend a lot of time teaching Rust and helping teams migrate to Rust. A good amount of effort for teams onboarding is getting up to speed with all of the features in Rust.</p> New Syntax</h2> At this point in Rust’s life, new features should have pass high bar of scrutiny to be accepted. This is especially true for features that introduce new syntax. We already have a lot of syntax in Rust relative to other languages. Adding new syntax is a tradeoff between making things easier to write (and sometimes read) while requiring users to be aware of this semantics behind the syntax.</p> Every time we add a new keyword it adds more things for the user to be familiar with to understand what a program does. The Rust type system gives the user many ways to express their problem, which is great but comes with the drawback of increasing burden to understand code that you did not write. I sometimes feel this in code reviews when the author uses a syntax that I do not commonly use.</p> To point to a specific example where I think this is applicable is RFC 3680</a>. To summarize the RFC (as currently written on May 3, 2025), It proposes that we reuse the use</code> in a few new ways to make working with Arc</code>/Rc</code> a more ergonomic. As currently written, I do not think this RFC provides enough benefits to outweigh the downsides of introducing new syntax to the language. There are many comments on this RFC that echo similar sentiments.</p> My goal is not to pick on this RFC (as the goal is noble) but simply to illustrate that bar to introduce new syntax/keywords should be very high and needs to meaningfully solve existing problems.</p> Refining Existing Features</h2> One interesting data point in the 2024 State of Rust Survey</a> was the results of “What is your opinion on how fast Rust evolves?”</p> </p> With the options provided I would probably fall into the “I am satisfied with the current pace of development” bucket. However, the current options miss the difference between introducing new features and improving existing features.2</a></sup></p> I find that I often desire improvements to existing Rust features rather than new features entirely.</p> A great example of this is the “Async Rust”. Async Rust is not a new feature, but it still does not feel “complete”. Async traits are still not dyn comptaible without using async_trait</a>, Async closures (this was stabilized in Rust 1.85), Async Drop</a> is still unstable. In 2025, I am the most excited about the project goal</a> to refine async rust.</p> Tooling Features</h2> Until now, I have been primarily talking about language features and not the greater Rust ecosystem. I have a very difficult perspective on adding new features to tools in the Rust ecosystem.</p> Above I argue that introducing language features make the language more complex and introduces development friction when working in a team. For tooling features, this usually does not apply. For example, cargo build</code> hides a lot of the complexity of interacting with rustc</code> and makes Rust development vastly more approachable. Most tooling features reduce the complexity of Rust users need to deal with on a daily basis.</p> I hope to see the ecosystem of Rust tools continue to expand and mature in the coming years. 3</a></sup></p> Recap</h2> Rust is already a relatively complex language. We need to be conservative when adding new features.</li> New language features need to meaningfully solve problems that real users have.</li> Refining existing features is not the same as introducing completely new features.</li> New tooling features do not increase the language complexity in the same way as new language features.</li> </ol> None of this is particularly ground breaking, but I think there is some value in having it written down as other may have opposing thoughts on how Rust should evolve. I am largely optmistic on Rust’s future but we as a community should be selective on which features we introduce into the language.</p> I would not call myself a “Rust expert”, but from my discussions with other in the community this is often how people that introduce Rust at their workplace are viewed. ↩</a></p> </li> It’s worth noting that this was discussed</a> in the Rust Zulip. And the survey will likely be tweaked to take this into account. ↩</a></p> </li> While introducing Rust at my workplace, many of the pain points I ran into were trying to make the Rust tools play nice with our existing systems. ↩</a></p> </li> </ol> </section> YakMan 2023-11-30T00:00:00+00:00 </span></a> What and why</h1> YakMan</a> is a config manager for applications. In modern software development its very common to need to abstract some configuration out of applications so that it can be quickly changed without rebuilding/deploying.</p> There are already many solutions out there for managing config so why bother creating yet another?</p> Let me answer this with a short story…</p> </span></a> Why</h3> I recently joined a new project and most of our configurations were either:</p> Hardcoded in the app</li> Stored in Kubernetes manifest files</li> </ol> Both of these required an application restart which at the time was slow and required a lot of red tape cutting to do.</p> I thought surely there was some open source solution that would make this easy. But after researching for a few days, I felt that there was not a solution that I really loved.</p> This lead me to create YakMan.</p> </span></a> Goals</h3> What I really wanted was a config manager that is:</p> Language agnostic</li> Support basic organziation/grouping features</li> Bring your own storage. No vendor lock in and does not require a specific cloud</li> Ability to hotswap config with application restarts</li> Modular with the ability to extend if desired</li> Some basic access control</li> Free and open source</li> </ol> </span></a> Tech Stack</h1> Rust</li> Actix</li> SvelteKit</li> Tailwind</li> </ul> </span></a> Why this tech stack</h3> I started with the “core” config manager API. One of my goals is a modular design and being able to swap the UI for your own custom UI is important to the project. For that reason, I decided to go with Rust+Actix for the backend service to create a REST API. Rust is nice for its amazing DX and great type system.</p> For the UI, I originally tried to use Leptos</a> to keep everything in a single language (Rust). However, I ran into some challenges with Leptos:</p> Leptos at the time was very new (like a few month old) and this might it was still very rough around the edges.</li> Lots of lifetime issues and fighting the borrow checker constantly.</li> </ol> I think that Leptos has an awesome community and a bright future. The Discord was always very helpful for newcomers and there are a lot of smart people in it. But with being relatively new to Rust and Leptos being so young I had to make the hard decision to move to another frontend framework.</p> I did some researching and considered my options, and finally landed on SvelteKit. I wanted YakMan to feel lightweight and very snappy, so I was hoping to avoid many V-Dom like React and Angular. I landed on Svelte because offers a very nice DX and makes state management very simple.</p> And after a very large PR to replace Leptos with SvelteKit, I was left with the current tech stack for YakMan.</p> </span></a> Lessons Learned</h1> </span></a> The adapter pattern is awesome</h3> One of the goals for this project is to be able to “bring your own storage” meaning if you on AWS you can S3. If you are GCP you can use Cloud Storage. If you already have a MySQL database and want to use that sure. Just want to store the files locally on an EC2 server, I probably wont reccomened it but you can. One of YakMan’s biggest features is being (somewhat) storage agnostic.</p> To implement feature I used the adapter pattern</a>. I create a StorageAdapter</code> trait in Rust (similar to an interface in our languages) that provided methods to read/write data to different storage services. This was probably my best decision I made during the early development of this project.</p> To add support for new storage service, I just needed to implement the StorageAdapter</code> trait for that service and it would “just work.” It was honestly amazing to see YakMan run bug free on a completely different database after just 30 minutes of coding to add a new adapter.</p> </span></a> OAuth and SSO can be tricky</h3> OAuth 2 is a very complicated protocol. There are many different “flows” and it a be tricky to work with especially if the OAuth provider does not follow all of standards.</p> When implementing Single Sign On for YakMan, I ran into a handful of issues where OAuth providers just did not implement some part of the OAuth protocol. This was frustrating but taking a step back I can understand why. OAuth has been a constant work in progress for over a decade now. It has been implemented many RFCs and there are many flows that serve different purposes. It is understandable that not all providers support every feature to the latest RFC.</p> This introduced some challenges and now I understand why many SaaS products charge for SSO. Its a lot of effort to maintain and very difficult to support all identity providers.</p> Nihongo Stats 2022-06-16T00:00:00+00:00 </span></a> What and why</h1> Nihongo Stats</a> is an Open Source webapp I built while learning Japanese. Learning a second language is a long process, and it is difficult to see your progress. I wanted a way to see some progress… I use various language learning apps, that happen to provide APIs. So the programmer in my thought</p> I could use this data to visualize my progress</p> </blockquote> So I built a React app that fetches and displays graphs of various metrics.</p> </p> </span></a> Tech Stack</h1> React</li> Vite</li> TanStack Query (aka React Query)</li> React Chart</li> Nginx</li> Cloud Run (Google Cloud Platform)</li> GitHub Actions</li> </ul> </span></a> Why I picked these</h3> React/JSX is my preferred why to write UIs. I started this project with “Create React App” but I migrated to Vite because the build/dev speed is so much better. I considered NextJS but currently, it does not offer much due to the API rate limiting forcing the data fetching to be done client side.</p> I use Cloud Run because, at the time GCP was what I was most familiar with. Cloud Run allows me to simply deploy a container and not worry about scaling. If I were to re-do this project, I would consider using Vercel due to its great CI/CD.</p> </span></a> Lessons Learned</h1> </span></a> Typescript</h3> My biggest lesson learned during this project was that Typescript is basically a requirement in 2023. I started this project in Javascript because I thought</p> This will be a simple project and I’ll be done quicker with Javascript since I won’t have to worry about types.</p> </blockquote> I couldn’t have been more wrong…</p> This project does a lot of data mapping and the lack of types quickly made the code a mess. So many bugs were due to a property not existing or being named slightly differently (ie. reviewDate</code> vs reviewTimestamp</code>).</p> Adding Typescript to this project fixed many of those types of bugs.</p> In my opinion, there are very few scenarios/projects where not using Typescript is the better choice.</p> </span></a> Caching is hard</h3> Due to the rate-limiting restrictions on Wanikani’s API, caching is data is very important for this app. When I started, this project I naively added my own cache… 🤦‍♂️</p> Caching seems simple on the surface but quickly becomes very complex. I have moved my caching from a custom solution to using the browsers’ built-in cache and leveraging libraries like Tanstack Query.</p>