The year was 2012, and I was still a regular web developer with a very mixed array of skills - think Delphi, C#, PHP, Flash, and others. It was a Frankenstein of a skill set, but it helped me develop a deeper understanding of the differences and paradigms in each. i.e., I started understanding when one thing was suitable in favor of another.
The company was a market leader in the Bulgarian online media industry. They had acquired a few companies and were expanding their offerings portfolio with games, adverts, and other interesting products. It was still mid-sized, though, and as not yet that much corporate, people were able to pick up new technologies and suggest solutions which were at least considered.
It was a very useful experience for all the developers who went through it.
One day, one of my peers with whom I’ve been working the most on the latest projects said something that raised an eyebrow, and the following conversation ensued:
— Someday, I want to invent a programming language that would listen to me and would simply produce the output.
— Like… Talk to it?
— Yes!
Five people simultaneously LOLed, my colleague included. It sounded like an idea from Star Wars at the time. If only we all knew better…
We started asking a bunch of questions - How would that work? Text recognition was not even polished at the time?! Not to mention the fact that “it” can’t possibly know all the design patterns and architectural possibilities. And again, not to mention the fact that everything was changing extremely fast in our field.
Let’s face it, back in the day, programming meant knowing the language, the concrete framework used, the database, the various servers used, the build and deployment processes, and all the other unpleasantries that go with it. Debugging tiny mistakes was a daily routine (Did I mention mid-level?). Reading documentation, and most frustratingly - learning that a piece of software might just work on your machine, but not on the server, or another one. It was tough!
And the idea of simplifying that to “only tell the machine what you want to do” and actually see it produced sounded really detached from reality. And for the moment it was…
Come 2026, and things are vastly different. Nowadays people are using what my friend described as the norm. It’s even strange when you talk to someone who is still not properly using Agents and prompt engineering. And yes, I am still encountering companies like this. It will just take them some time, but getting there is inevitable.
It is not magic, and people do need to deeply understand what AI is doing under the hood for them. In order to be able to harness these superpowers, you would still need to invest some time in understanding patterns, software architecture, paradigms, and critical thinking. You would want to know about QA and product design. How else would you become that product engineer who could do 10x?
For most of my career, I believed crafting software was really hard (had frequent arguments with friends and family), slow, and dependent on careful line-by-line human construction. Writing the code was always anywhere between 10% and 15%, and doing the actual thinking and architectural work behind the scenes was the rest of it. This still holds to some extent. But the scenery has changed big time.
While my Nostradamus-like friend didn’t really invent a new language, he was far better a visionary than the rest of that team. And now I’ve learned not to laugh at something if I don’t understand that it just might be too early.
The new reality is just using a new way of expressing intent.
Software is still hard when the stakes are real, and production systems still punish vague thinking. Edge cases pop up in the form of live bugs, and following the proper security standards is even more important than before. Ai is not removing the hardness of data pipelines and various integrations. In fact, it can be much more exhausting, as you need to be careful with what you’re producing and the amount is a few times more.
My failure of imagination has taught me to try and look far beyond just my nose. And “I cannot imagine this working” is still very different than “this is impossible”.
In operating work, the confusion could be quite expensive. And it’s not only a reputational risk, but also a time and material one.
Sometimes a company would prefer to wait until another 10k companies have tried and validated that the ridiculous idea is actually pretty valuable. But the cost might be falling behind and badly needing to catch up.
The lesson here is not “believe every wild idea”. But it is rather to know and test the idea properly before dismissing it. Stress test it:
— What would need to change in order for it to become a reality?
— List the constraints and categorize them as technological, economic, and behavioral.
— Is there a constraint that is just a habit - “We’re used to doing it like this around here!”? Maybe this is the only way we know.
Ambitious ideas should be challenged hard, and not dismissed merely because they sound unfamiliar. Find the missing pieces and evaluate. And if you don’t know where to start, ask a Senior Operator for help.
When this matters
How has AI changed what is possible in software development?
Execution, not consulting.
If you are looking for another strategy deck, Safyron is probably not the right fit. If you need someone who will still be there when the difficult work starts, read how Safyron operates.