An update on Acheron, a few long-term projects, and some thoughts on the future of software development.
This post is going to take a bit of a detour from Acheron, the decompiler I’ve been working on, to talk a little more openly about some of the other projects I’ve had in the works over the past year or so, what I’ve learned along the way, and something that’s been weighing on me more and more lately: the changing landscape of software development in the age of AI.
I’ve been fortunate enough to spend a considerable amount of time working on things I’m genuinely passionate about. Some of these projects are still far from being in a state where I can share meaningful details or show off the work publicly, but that doesn’t mean there isn’t plenty worth talking about. There’s the VST I’ve been developing alongside a friend and fellow engineer I admire greatly, the UI library I’ve spent over a year trying to bring to life, and, of course, Acheron itself.
Each of these projects has taught me something different. Some have pushed me to become a better engineer, some have forced me to reconsider decisions I once thought were perfectly reasonable, and others have reminded me just how much work goes into creating software that feels good to use and is built to last.
But there’s another side to all of this.
As someone who spends a considerable amount of time building software independently, or alongside a very small team, I’ve found myself increasingly concerned about the direction our industry is heading. Specifically, the way AI is changing our relationship with intellectual property, original work, and the people who spend years developing the skills necessary to create something meaningful.
I see an increasingly worrying future where genuinely original work can be reverse-engineered, reproduced, and redistributed with very little regard for the people who created it in the first place. A future where the incentive to build something new is gradually eroded by the knowledge that someone else can simply come along and replicate it.
This isn’t going to be a tutorial, a technical deep dive, or an attempt to present myself as someone who has all the answers. Consider this more of an update, a bit of a memoir, and an opportunity to put some thoughts into words that I’ve wanted to share for a while.
So, with that out of the way, let’s get into it.
A quick update on what I’ve been building
Acheron: Taking a step back to move forward
As I mentioned earlier, I’ve been taking a bit of a break from Acheron while I focus on some of my other projects. That doesn’t mean I’ve abandoned it or lost interest in where I want to take it. If anything, some of the time away has given me an opportunity to reconsider a few things about the project.
One of the biggest changes I’m planning is a complete overhaul of the UI. To put it bluntly, I’m not particularly happy with the current implementation, and I’d rather acknowledge that now than continue building on top of something I don’t feel good about.
I’ve also been reconsidering my choice of UI framework. I’ve been working with Slint, but I’m increasingly interested in exploring alternatives that might provide a more enjoyable development experience and give me greater flexibility as the project grows.
At the moment, I’m weighing up Tauri and Vizia, both of which offer different approaches to building the kind of interface I want. There’s also the possibility of eventually using my own UI library, provided I can get it into a state where I’m comfortable relying on it for a project of this size.
That last option is particularly appealing to me, although I don’t want to let the desire to use something I’ve built myself get in the way of making the right engineering decisions.
Ultimately, I want Acheron to be something I’m proud of, both in terms of its functionality and its overall user experience. If that means stepping back, reconsidering some decisions, and rebuilding certain parts, then so be it.
Sometimes the best thing you can do for a project is stop trying to force the existing implementation to work and give yourself the space to rethink it properly.
A VST project that’s taught me a lot
One of the other major projects I’ve been working on for roughly the past year is a VST, developed alongside my friend and colleague Tim.
I can’t share too many details about the project just yet, but I can say that it’s been one of the most rewarding engineering experiences I’ve had to date. It’s also been one of the most challenging.
A considerable amount of our time has gone into architectural decisions, thinking ahead about maintainability, documenting the codebase, and trying to anticipate the kinds of problems we’ll encounter as the project grows. We’ve spent a lot of time considering not just how to implement something, but how to implement it in a way that makes sense six months or a year down the line.
That distinction has become increasingly important to me.
It’s easy to get caught up in making something work. It’s much harder to build something that continues to make sense as the requirements evolve, that another developer can understand without spending days deciphering your intentions, and that doesn’t become a nightmare to maintain as new features are introduced.
Honestly, this is probably the most thoughtfully structured and best-engineered piece of software I’ve had the opportunity to work on.
And I can’t take all the credit for that.
Tim is a fantastic engineer, and I admire his approach to software development enormously. I’ve largely let him take the lead on architectural decision-making because he brings a level of industry experience that I don’t yet have. That isn’t to say I consider my own decisions bad, nor does it mean I’m simply following someone else’s lead without contributing. It’s that working alongside someone with a different level of experience has given me the opportunity to challenge my assumptions, understand alternative approaches, and become more deliberate about the decisions I make myself.
I think there’s something particularly valuable about working with someone who can push you to become a better engineer without making you feel like your contributions are any less meaningful.
I’ve learned a tremendous amount from this project, and I genuinely believe the experience has made me a better developer. It’s also reinforced how important it is to think beyond the immediate implementation and consider the long-term consequences of the choices we make.
For now, I’ll have to keep the specifics under wraps. But I’m excited to share more about this project when the time is right, because it’s something we’ve put a lot of thought, effort, and care into.
The UI library: Knowing when to start over
The other major project I’ve been working on in my spare time is a UI library I’ve been developing from scratch.
This one has been a challenge, to put it mildly.
The original idea was to build something flexible enough to support both VST development and standalone desktop applications. At the time, that seemed like a reasonable goal. Why build two separate approaches when I could create a library that would accommodate both?
Looking back, however, I think that was the wrong approach.
Trying to design a library that could comfortably serve two somewhat different use cases introduced complexity that I hadn’t fully accounted for. What initially seemed like a way to make the project more versatile gradually became a source of architectural friction.
Some of the decisions I made early on also seemed perfectly reasonable at the time, but working on the VST project with Tim has given me a different perspective. I’ve had the opportunity to reflect on those decisions and recognize where my original approach was making things unnecessarily difficult.
And that’s the frustrating part of software development: sometimes you don’t fully understand the consequences of a decision until you’ve spent months living with it.
You can plan, research, and think through your architecture as carefully as possible, but there will always be things you only learn through experience. Sometimes you get it right. Sometimes you discover that the foundation you built everything on isn’t quite as solid as you thought it was.
I eventually reached a point where I had to make a decision: continue trying to patch up the existing implementation or start again with a clearer understanding of what I actually wanted to build.
I’ve decided to start from scratch.
I know that might sound counterproductive after spending over a year working on something, but I genuinely believe it’s the right call. At this point, the time and complexity involved in untangling the existing architecture would likely be comparable to rebuilding it properly. More importantly, starting over gives me the opportunity to apply everything I’ve learned rather than continuing to work around decisions I no longer agree with.
I’m not particularly interested in preserving code simply because I’ve already written it. If something isn’t serving the project anymore, I need to be willing to let it go.
That doesn’t mean the time I’ve spent on the library has been wasted. Quite the opposite. I’ve learned a great deal about UI architecture, the trade-offs involved in designing reusable components, and the importance of establishing a clear scope before trying to solve every possible use case at once.
Those lessons will carry over into the next iteration, and hopefully they’ll help me build something considerably better.
I’ll have more to say about the library in a future post, because there’s a lot to unpack there. For now, though, I’m looking forward to approaching it with a fresh perspective and a much clearer idea of what I want it to become.
The part I’ve really wanted to talk about: AI and the future of software development
This is where things get a little more personal.
It should come as no surprise to anyone that AI has advanced at an extraordinary pace over the past year. The capabilities available to developers today are substantially more powerful than what many of us were working with even relatively recently.
And while I’ve never been particularly fearful of AI itself, I can’t say I feel the same way anymore about the direction in which it’s being developed and, more importantly, how it’s being used.
My concern isn’t simply that AI can write code. It’s that the combination of increasingly capable AI systems, increasingly accessible reverse-engineering tools, and an industry that often prioritizes speed and profitability above everything else could fundamentally change what it means to build software for a living.
I’ve seen plenty of discussions about AI replacing artists, writers, designers, and people in other creative industries. Those concerns are certainly valid. But I don’t think software developers are nearly as insulated from these changes as some people would like to believe.
In fact, I think we’re already seeing the effects.
Junior developer roles, in particular, seem increasingly vulnerable. Tasks that were once assigned to entry-level engineers can now be partially or substantially automated, and companies have obvious financial incentives to reduce the number of people they need to hire to get a project across the finish line.
I’m not going to claim that every junior developer role is disappearing or that AI can independently replace every engineer today. That would be an overstatement. But I do worry that the traditional entry point into the industry is becoming harder to access.
And that creates a problem that extends well beyond the people currently looking for their first job.
Junior developers don’t just provide companies with an additional pair of hands. They learn through experience, develop engineering judgment, and eventually become the senior developers who design and maintain the systems those companies depend on. If businesses collectively decide that training junior engineers is no longer worth the investment, where exactly are the experienced engineers of tomorrow supposed to come from?
It’s a question I don’t think the industry has adequately answered.
For someone like me, who’s largely self-taught and trying to establish a career through the work I build, this is particularly concerning. Getting your foot in the door has never been easy without a conventional path into the industry. Now, the very roles that might provide that initial opportunity appear to be under increasing pressure.
But employment is only one part of the problem.
The issue that concerns me most is what AI means for people who create original software independently, or as part of a small team.
When your life’s work becomes someone else’s shortcut
There’s a distinction I think is becoming increasingly important in conversations about AI: the difference between using AI to help you create something and using it to reproduce something someone else has already created.
Those aren’t the same thing, and I don’t think we should pretend they are.
I have absolutely no issue with tools that help developers work more efficiently, understand unfamiliar systems, or explore ideas that would otherwise take considerably longer to investigate. As someone who’s spent years developing skills in software reverse engineering, I understand firsthand how valuable those tools can be.
What worries me is the possibility that the same capabilities can be used to take the work of someone who has spent years building something original and turn it into a commodity that anyone can reproduce.
We’re already seeing more attention given to large-scale reverse-engineering projects, software reimplementations, and efforts to make previously closed or abandoned software available again. There are legitimate benefits to this work. Preserving software that would otherwise disappear, improving interoperability, and allowing people to study how systems operate can all be worthwhile pursuits.
I don’t want to dismiss those benefits.
But there’s a side to this conversation that I think deserves considerably more attention.
What happens when the software being reproduced isn’t abandoned? What happens when it isn’t an old project that nobody maintains anymore, but an actively developed product that a small team has spent years building, refining, and supporting?
What happens when that team’s work becomes the foundation for someone else’s competing product, without the original creators receiving any meaningful recognition or compensation?
For a large corporation, this might be an inconvenience. They have legal departments, established revenue streams, and the resources to defend their intellectual property or adapt to a changing market.
For an independent developer, the consequences can be much more severe.
Imagine spending years developing a product. You make sacrifices, learn new skills, work through countless technical problems, and gradually turn an idea into something real. Perhaps you’re finally approaching a point where the project can support you financially, allowing you to dedicate more of your time to its development.
Then someone comes along, uses AI to accelerate the process of reproducing your work, and releases a competing implementation.
Suddenly, the thing you’ve spent years building can be offered by someone who hasn’t had to make the same investment of time, effort, or money.
Even if their implementation isn’t identical, even if it lacks some of the nuances that make the original special, it may be good enough for a significant portion of your audience.
And that can be enough to undermine the business you’ve spent years trying to build.
This is what frightens me about the current trajectory. Not simply that people can copy software, because copying and reverse engineering have always existed, but that the barrier to doing so could fall dramatically while the consequences for the original creator remain just as real.
For small developers, the time invested in a project isn’t an abstract resource. It’s often the majority of what they have to offer.
We don’t necessarily have investors, large teams, or the financial runway to absorb the consequences of a competing product appearing overnight. We have our skills, our time, and the hope that the things we build will be valuable enough for us to continue building them.
If that hope becomes increasingly difficult to justify, what incentive is left to take the risk in the first place?
The people creating the tools aren’t necessarily creating the original ideas
A fellow VST developer, Mark Speechrezz, expressed something in a conversation that resonated with me quite strongly. I think it captures the heart of this concern better than I could explain it myself:
While there are benefits to being able to revive abandoned software and such, as far as I’ve seen AI is particularly good at copying/cloning/reverse-engineering, but not at creating new original software/algorithms. This sucks because that means when someone does create something original by pouring a lot of time, energy, and maybe money into a project, someone else can come along, ask AI to reverse engineer it and repackage it.
The way I see it, this will remove a lot of the incentive for people to push boundaries and create new things. And if people aren’t doing it and AI cant do it, then we will see software stagnate.
I think there’s an important distinction in that observation.
A tool that makes it easier to reproduce existing work isn’t necessarily a tool that makes it equally easy to produce something genuinely original.
Those are different challenges.
Creating something new often involves experimentation, intuition, a deep understanding of a particular problem, and a willingness to pursue ideas that might not work. It requires people to take risks and invest considerable time in solutions that may have no immediate commercial payoff.
Reproducing an existing solution starts from a fundamentally different position. The end result, or at least much of the behavior that needs to be reproduced, is already available to observe.
AI can help with both, of course. It can assist with brainstorming, implementation, experimentation, and entirely new projects. I don’t think it’s accurate to say that AI is incapable of contributing to original work.
But the ease with which an existing product can be analyzed and replicated creates a very different economic incentive from the one involved in creating something new.
Why spend years developing an original algorithm, a novel audio-processing technique, or a carefully engineered application if a competitor can use your finished product as a blueprint and rapidly produce something similar?
More importantly, why would the next generation of developers take that risk if they believe the rewards of being first to solve a problem will be short-lived?
I don’t think those questions are hypothetical. They’re becoming increasingly relevant as the capabilities of these tools improve.
And I think Mark’s concern about stagnation deserves serious consideration.
Could software development actually stagnate?
When people talk about technological progress, there’s often an assumption that things will continue getting better simply because our tools are getting more powerful.
I’m not entirely convinced that’s guaranteed.
We can certainly become more efficient at implementing software. We can reduce the time it takes to write boilerplate, build prototypes, identify bugs, and understand unfamiliar codebases. Those are meaningful improvements, and I don’t want to downplay them.
But efficiency in implementation isn’t necessarily the same thing as progress in ideas.
A world in which software can be reproduced more quickly isn’t automatically a world in which more original software gets created.
If the financial and professional incentives that encourage people to experiment, innovate, and take risks are weakened, we could end up in a situation where reproducing existing ideas becomes more attractive than developing new ones.
Imagine a market flooded with increasingly capable imitations of existing software. Products that were once differentiated by years of engineering become difficult to distinguish from one another. Developers find it harder to justify investing in ambitious projects because the commercial advantages of doing so are less predictable.
Some people will continue creating new things simply because they love doing it. I know I will, at least as long as I’m able to.
But passion doesn’t pay everyone’s bills, and it doesn’t eliminate the opportunity cost of spending years on a project.
There’s a limit to how much unpaid work most people can reasonably sustain. There’s also a limit to how much uncertainty people are willing to accept when they have other responsibilities and need to earn a living.
If we make it progressively harder for the people creating original software to sustain themselves, we risk undermining the very ecosystem that produces the work everyone else wants to use.
And I don’t think that problem is exclusive to software.
I can easily see parallels with music, visual art, writing, and other creative disciplines. In each case, the ability to reproduce existing work at scale could put pressure on the people whose livelihoods depend on creating something original.
The details differ between industries, but the underlying concern is similar: what happens when the ability to reproduce creative work becomes more profitable than the process of creating it?
I don’t have a definitive answer. I don’t even know whether stagnation is the outcome we’ll ultimately see.
What I do know is that I don’t think we should assume the market will automatically find a healthy balance simply because the technology is advancing.
Progress isn’t just about what our tools can do. It’s also about whether the people using those tools still have a meaningful reason and a viable opportunity to create something new.
An increasingly noisy market
There’s another consequence of all this that I think is already becoming difficult to ignore: the sheer volume of software being produced.
We’re seeing more tools, more applications, more plugins, and more products competing for attention. Some of them are genuinely useful. Others feel rushed, poorly thought out, or built primarily to capitalize on whatever happens to be popular at the moment.
The VST space is a particularly interesting example for me because it’s an industry I actively participate in as a developer.
There are already countless plugins available, and the barrier to releasing yet another one is becoming lower. As AI-assisted development becomes more accessible, I expect the number of products entering the market to continue growing.
The problem is that a larger quantity of software doesn’t necessarily translate into a larger quantity of worthwhile software.
When anyone can produce and release something with relatively little effort, it becomes increasingly difficult for genuinely thoughtful projects to stand out. Users are left to navigate a growing sea of products, and developers have to compete not only on quality and functionality but also on their ability to get noticed.
Discovery becomes its own challenge.
A developer can spend years refining an application, making careful architectural decisions, testing edge cases, and trying to deliver something genuinely useful. Yet their work might struggle to reach the people who would appreciate it because the market is already saturated with alternatives.
Meanwhile, someone else might release a hastily assembled product, flood social media with promotional content, and attract attention simply by being louder or faster.
That isn’t an entirely new problem. Marketing has always played a role in the success of software, and low-quality products have always existed.
But I worry that the scale of production enabled by AI could make the problem considerably worse.
There is also a growing fatigue associated with having to evaluate so many products that promise to solve the same problems. At some point, users may become less willing to explore unfamiliar tools, and developers may find themselves competing for an increasingly fragmented pool of attention.
I don’t think the answer is to discourage people from building things. Far from it.
I want more people to have the opportunity to create software. I want independent developers to succeed, and I want people to experiment with ideas they might never have had the resources to pursue otherwise.
But I’d like to see an environment where the ability to create something quickly doesn’t overshadow the value of creating something well.
The two aren’t mutually exclusive, but they aren’t interchangeable either.
The future I’m struggling to imagine
All of this brings me to a broader concern that extends beyond software development itself.
I’m worried about what happens when AI-driven automation begins to displace significant numbers of people across industries, particularly in white-collar work.
We’ve spent decades building an economy in which people’s ability to sell their time and skills is central to how they earn a living. If AI systems can perform an increasing number of those tasks at a lower cost, what happens to the people whose work is no longer considered economically necessary?
What happens when companies can reduce their operating costs by replacing entire categories of work with automated systems, while the people displaced by those decisions are left to figure out what comes next?
I don’t think anyone has a complete answer to that question.
There are arguments that new industries will emerge, that new jobs will replace old ones, and that the productivity gains from AI could ultimately benefit society as a whole. Those outcomes are possible, and history offers examples of technological changes that initially disrupted employment before creating new opportunities.
But I don’t think historical precedent guarantees that this transition will be painless, equitable, or even comparable to previous ones.
The speed and breadth of these changes matter. So does the question of who actually benefits from the productivity gains.
If the benefits are concentrated among a relatively small number of companies and individuals while the economic security of everyone else becomes increasingly uncertain, I struggle to see how we can simply assume things will work themselves out.
I also worry about our growing dependence on digital systems whose integrity may become more difficult to establish.
As AI-assisted analysis and reverse engineering become more capable, maintaining confidence in proprietary software and the systems built around it could become more challenging. Financial institutions, businesses, and governments all depend on complex software infrastructure, much of which is difficult to replace or thoroughly audit.
That doesn’t mean AI will suddenly make banking software obsolete, render financial transactions impossible to verify, or inevitably cause stock markets to collapse. Those are extreme outcomes, and I can’t claim to know whether any of them will occur.
But I do think the broader questions about software integrity, security, authenticity, and the long-term viability of proprietary systems deserve serious attention.
The more dependent we become on software, the more important it becomes to understand what that software is doing, who maintains it, and whether the systems around it can be trusted.
And as the tools used to analyze and reproduce that software become more accessible, the implications extend well beyond individual developers and their projects.
What concerns me most isn’t one specific catastrophe. It’s the possibility that we’re moving toward a future in which many of the systems we’ve built our livelihoods around change faster than our institutions, economies, and social structures can reasonably adapt.
Maybe we’ll find ways to navigate that transition successfully. Maybe new opportunities will emerge that I can’t currently anticipate.
I sincerely hope they do.
But I don’t think it’s unreasonable to feel apprehensive about the direction things are heading, particularly when so much of the conversation focuses on what AI makes possible without giving equal consideration to what we might lose along the way.
Where does that leave someone like me?
I want to be clear about something: despite everything I’ve written here, I still love software development.
I love taking an idea and figuring out how to make it real. I love understanding how things work beneath the surface, working through difficult engineering problems, and gradually turning something rough into something I’m genuinely proud of.
I love the process of learning, even when that process involves making mistakes, scrapping an implementation, and admitting that the approach I spent months pursuing wasn’t the right one.
That’s a big part of why I’ve continued working on these projects, even when progress has been slow and the outcome hasn’t always been certain.
I don’t write software simply because I expect it to make me money. I write it because I find the process deeply rewarding, and because I want to contribute something of my own to the world.
But I’d be lying if I said the prospect of making a living from that work hasn’t become more daunting.
I’m an autodidact. Much of what I’ve learned has come from working on projects, researching unfamiliar topics, making mistakes, and gradually developing the skills I need to tackle increasingly difficult problems.
It’s a path that has required a considerable amount of time and effort, and it hasn’t always been easy to demonstrate the value of that experience in a conventional hiring process.
For a long time, I saw independent software development as another possible route. If I could build something useful, something people genuinely wanted, perhaps I could eventually create an opportunity for myself that didn’t depend on getting my foot in the door at an established company.
That possibility has always meant a great deal to me.
Now, however, I find myself questioning how attainable it really is.
If the traditional route into the industry becomes increasingly difficult, and the independent route becomes increasingly risky because of the ease with which original work can be replicated, where does that leave someone in my position?
How do you justify investing years into a product when you can’t reasonably predict whether you’ll be able to sustain it?
How do you compete with businesses that can reproduce substantial portions of your work without having to make the same investment?
And how do you build a future around something you love when the economic conditions that might allow you to pursue it professionally seem increasingly uncertain?
I don’t have answers to those questions.
I know that there will always be a place for people who care about building good software. I know that AI isn’t going to eliminate every engineering problem, and I know that there are aspects of software development that extend well beyond simply producing code.
But knowing that doesn’t make the uncertainty disappear.
My hope of becoming a full-time developer feels increasingly distant, and that’s a difficult thing to reconcile with how much time I’ve spent working toward that goal.
It isn’t that I’ve lost faith in my own abilities or that I suddenly believe the work I’ve done has no value. It’s that I’m increasingly unsure whether those abilities will be enough to create the kind of future I’ve been working toward.
And I think there’s a difference between those two things.
For now, all I can really do is continue learning, keep building, and try to make decisions that give my projects the best possible chance of succeeding.
I’ll continue using the tools that help me work more effectively, including AI where it makes sense. I don’t believe ignoring new technology is the answer, and I have no interest in pretending that software development should remain unchanged simply because the old way of doing things is familiar.
What I do want is an industry that recognizes the value of the people behind the software, rather than treating their work as an inexhaustible resource that can be reproduced and repackaged without consequence.
I want an environment where people can still take risks, experiment with original ideas, and build things that matter without having to wonder whether the very act of succeeding will make their work easier for someone else to exploit.
I don’t think that’s an unreasonable thing to want.
And I don’t think we should have to choose between embracing technological progress and preserving the conditions that allow people to contribute meaningfully to it.
Until next time
I realize this post has been a bit heavier than my usual updates, but I wanted to take the opportunity to talk about something that’s been on my mind for a while.
It’s easy to spend all your time talking about what you’re building, the technical challenges you’re working through, and the things you’re excited to share. Those things matter, and I’ll continue doing exactly that.
But I think it’s also worth occasionally stepping back and talking about the broader circumstances in which we’re building these things, particularly when those circumstances have the potential to affect our ability to keep doing what we love.
I don’t know what the next few years of software development will look like. I don’t know whether my concerns about AI, intellectual property, and the future of independent development will ultimately prove justified in the ways I currently fear.
I hope I’m wrong about some of them.
What I do know is that I intend to keep writing software for as long as I’m able to. I’ll keep working on the projects that interest me, keep learning from the people I work with, and keep trying to build things that I’m proud to put my name on.
There’s still plenty I want to accomplish, and plenty I want to share.
I’ll have more to say about the VST and the UI library as they develop, and I’m looking forward to getting back into Acheron once I’ve figured out the direction I want to take its interface.
Until then, thank you to everyone who’s taken the time to follow along with my work.
And if you’re another independent developer, a fellow engineer, or someone who’s been thinking about these same questions, I’d genuinely love to hear your perspective. I’m certainly not claiming to have everything figured out, and I’d be interested to know how other people are navigating this changing landscape.
For now, I’ll keep building.
Here’s hoping the future gives us good reason to keep doing so.