Opinion

From Alien Translators to Human Translators

February 15, 2026 AI, Opinion No comments

Just wanted to share some quick thoughts on AI again. It does change our jobs (see my earlier thoughts “AI is asteroid and your tech job is a dino”, “Is AI redefining software craftsmanship?”). It completely rewrites how much can be done in a short period of time (see a bunch of vibe coding posts from me: blogger agent, typing game, AI powered snake, etc). And while I expressed some doubts and expected a ceiling to its advancements, I am now more deeply convinced that the time to fully embrace AI is now. Almost any knowledge work you do with your brain can get some help from AI. And while I advocate for limited use of AI in writing (“Don’t outsource your thinking to AI”) it has undeniably changed how I do my writing and what value I think I bring or don’t bring. Writing generic advice, anything that can be searched online, is an absolute waste of time, unless it is supplemented with opinions or experiences. Writing coding blog posts with technical details, as I used to do in the past, is also worthless. The entire stack overflow is now not receiving much traffic.

I liked to think about Software Engineers as these super smart almost alien-like translators. We used to translate requirements and business needs into cryptic code that most people couldn’t understand, just to make the software work. While fundamental knowledge is still relevant and our role as translators still remains, the destination language is changing to be more English-like. Instead of typing code we orchestrate AI work. What still matters is what AI cannot do and is very unlikely to be able to do soon, which is doing human things. The things that revolve around judgment, our lived experience, and our authentic connections.

An LLM can write technical documentation, generate a summary, and write lots of code. It works perfectly for transfer of knowledge, but it still is not good at transfer of experience and understanding what we really need and mean as humans. Translators are still needed, but instead of being more alien-like we might need to be more human-like and do more human things.

P.S. I resisted the urge to use AI for this blog post.


No comments


Built a personal “AI Slop” Generator in 3 Hours

February 8, 2026 AI, Opinion No comments

Presenting you with AI Slop by Andriy Buday and Gemini: https://aislop.andriybuday.com 

I was recently challenged on why my weekly blog posts are not written by AI. I do have my strong opinions on this and arguments against it but before I delve into them I wanted to accept the challenge. So in about 3 hours of vibe coding I built an automated GitHub and Google Gemini powered workflow that picks either an idea from ideas.md file or one of my older blog posts on this website and (re-)writes a new blog post based on that and then uploads it to my dedicated aislop subdomain.

Solution based on GitHub Actions, FTP, Google Gemini

The entire project took about 3 hours from initial concept to deployment. This was pure vibe coding of ~40 git commits, a bit of setup in my bluehost, and some setup on github.

I learned about GitHub Actions fairly recently, but basically you can build a workflow based on yaml definition that would be triggered on a periodic basis. Additionally you can put your secrets into GitHub repo configuration. I placed my Gemini API key into secrets as well as I then placed my FTP access details (yes, I know it’s insecure and old school, but this is a 3-hour hack project). For FTP I created a dedicated account and only allowed a specific folder on my bluehost, where I also created a subdomain.

How it works: The workflow and Tech Specs

I asked Claude to summarize the technical details because this is what AI shines at:

Workflow:

  • GitHub Actions → triggers workflow daily → Python script picks unprocessed blog post or idea from ideas_tracking.json or blog_posts.json → load content and prompt Gemini via API with custom prompt → postprocess text to HTML → create HTML file and update blog_posts.json (database) → connect to FTP and upload files → git push changes for tracking and backup

Core Development Phases

  • Scaffolding & Engine (75m): Establishing the repository and building the Python script to handle web scraping via BeautifulSoup4 and AI integration.
  • Automation & Queueing (35m): Configuring GitHub Actions for CI/CD and implementing a JSON-based status tracker to manage 370+ URLs.
  • Refinement & UI (80m): Enhancing Gemini’s prompting for authoritative content, fixing Markdown-to-HTML rendering bugs, and building a responsive progress dashboard.

Technical Stack Highlights

  • AI & Logic: Python 3.9+, Google Generative AI (Gemini 2.0 Flash), and markdown2
  • Infrastructure: GitHub Actions for scheduling, Bluehost via FTP, and GitHub Secrets for API key management
  • Frontend & Data: Vanilla HTML/CSS/JS for the dashboard, with JSON and CSV files handling all state-tracking without a database

Thoughts (Why I am against AI generated content)

Is this the future of blogging? Maybe. Is it a future I’m excited about? Not entirely. I am definitely not going to share my AI Slop sub-blog unless that is purely to prove the point. I can barely stand all of these huge walls of text that are clearly written by AI but presented as if humans had written it. Why would you read it? You can just prompt your favorite LLM to give you answers you really need. I almost want to vomit from all this clearly AI generated text with no personal substance or real opinions. Sorry for being this vivid, but again: AI would not write that it wants to vomit because of the text it has written. 

And just to be clear, I do use LLM as a tool to help with my writing, but just not to write instead of me: Don’t Outsource Your Thinking: Why I Write Instead of Prompt

So where does the value of blog posts come from?

In my opinion the value comes from giving your own perspective, from sharing your opinions, driving your own arguments, and, yes, while bloggers can and do use LLM to find blind spots and to arrive at a stronger argument, the arguments should still come from the author, otherwise it is all just crappy AI Slop (unless that was the intention originally).

My ‘AI Slop’ bot can publish 100 posts a day, but it can’t build its own perspective. It can only synthesise perspective based on data it has received before.

My concluding argument is that efficiency in generating text does not equal value in reading text.


No comments


Excellence as Flight

February 1, 2026 Opinion, Success No comments

Note: This is a non-technical post exploring drive for excellence.

I was thinking about what drives people who are top of their field? What makes Alex Honnold climb Taipei 101 without ropes, what makes David Goggins run ultramarathons with broken ankle, what makes Elon Musk sleep on the floor at the factory, what makes Jensen Huang and other top CEOs keep grinding, what makes Bryan Johnson (the “don’t die” guy) blueprint his life, or Tiger Woods, or MrBeast, or whoever you can think is out there pushing the boundary of whatever they are doing.

What makes you do what you do and push for more?

AI generated image based on the text of this blog (damn, so dark)

When I was in high school I was best in class, kind of. Anything STEM absolutely. Physics, math, chemistry were my best subjects and I went on to win many regional competitions and almost made it to nationals. But at the same time I was one of the worst students in physical education and music. I could not run and could not sing. I still remember those classes as some of the traumatic experiences of my life. Not being popular, fearing rejections I poured my energy into what I knew worked, which was the deterministic world of coding, math, and hard sciences. Many of us do the same throughout our lives. 

When I think about people I read about or people I know and admire there is always something in their story that made them push for that excellence. On the outside sometimes it looks just like a bit of luck or good upbringing, which do help for sure, but there is always something else. I will try to build my point by running down some names and you will see how the story adds up.

David Goggins didn’t run ultramarathons because he loves running. He ran to kill the weak person he was. His “cannot hurt me“ and “never finished” books are a great testament to that. I read both of those and it is obvious that the man was drowning his psychological pain in physical pain, much like some alcoholics.

Alex Honnold free soloed so much because he didn’t like the idea of having people around him (from one of the interviews) and because this is the way to cancel all the noise. When you are free-soloing El Capitan, you cannot worry about your taxes, your relationship, or your awkward childhood. You must be 100% present, or you die. I rock climb myself, here is my “rock climbing as a way to cope” post.

Jensen Huang famously said that “greatness comes from character, and character isn’t formed out of smart people, it is formed out of people who suffered”. He pushes for excellence because he views ease as a threat to survival and if you watch some of his interviews he constantly mentions the fear of running out of business.

I asked my daughter what she thinks drives MrBeast. Her first response was “money”. I poked more and she said “power”. I think on the surface this is true, but by looking at extreme obsessiveness over metrics and quality I think he is terrified of mediocrity and plateauing. He said explicitly “I am terrified of the day the line goes flat.” 

Bryan Johnson is probably an example of almost pathological fear and unacceptance of death. I am glad the guy is there experimenting on himself for all of us.

I’m not into golf, but by reading about Tiger Woods it becomes clear that for him the only way to feel safe and worthy was to win, all installed by childhood trauma.

I asked my wife to give me an example of someone famous, she gave me Coco Chanel, looking up her early life, her mom died at 12, dad abandoned her, she was raised in an orphanage sewing there and her designs are a desperate need to never go back to being the abandoned girl in the orphanage.

“You are either the best or you are nothing” – not quoting anyone famous, just one of my colleagues describing the harsh truth of some of the upbringings.

I tried to come up with counterarguments to my theory that people that drive for excellence are those that sacrifice something and struggle. I thought of Richard Feynman, Usain Bolt and a few others, and also  looked up some more names like Bill Gates, Larry Page, Charles Darwin, those who showed up as those with highly favorable upbringings. It is clear that not everyone perfectly fits the narrative I’m building. Indeed many of these people lucked out, were born at the right time and had the right start or were driven by some pathological curiosity or something unusual about them. But at the same time, when you think about it, Bill Gates was famously paranoid, remembering the number plates of employees. He definitely wasn’t running from poverty, but he was running from the terror of losing. Even the “lucky” ones are often running from something, like fear of failure, fear of irrelevance, or something we don’t know, which is more likely.

We often romanticize excellence as a pursuit of happiness. But looking at all of the examples above, it becomes clear that excellence is rarely a pursuit of happiness. It is very often a flight. It is running away from mediocrity, away from trauma, away from the noise.

By definition, to be the best, others have to be behind you. But the real race isn’t against them. It’s against the version of yourself you are terrified of becoming. Struggle does not guarantee success or excellence, actually it is survivorship bias to think so, millions of people struggle and get nowhere, many people struggle in destructive manner, so I see it only as necessary fuel on the path of excellence. Combine that fuel with agency and focused obsession, and you have the way to reach the peak.


No comments


Passion vs. Fear: What Tony Fadell’s BUILD Taught Me About Overthinking

December 14, 2025 Book Reviews, Opinion, Personal No comments

I needed a reminder today that things sometimes get tough. It is important to understand that everybody ‘fights their own demons’ and you are not alone. Everyone around is struggling, sometimes you see this, but most of the time you don’t. 

To be brutally honest, I’m a big overthinker. I go through all possible and impossible scenarios in my head. This often leads to me spending too much time on some problem, almost getting to the state of paralysis, but sometimes this does pay off. I remember years ago, I worked on a migration of a service, I simply could not get to sleep before checking each and every edge case. The thing worked perfectly, but how much mental capacity it had consumed was probably overboard.

Even the most successful founders and people around have similar struggles. I just finished reading “Build: An Unorthodox Guide to Making Things Worth Making” by Tony Fadell, creator of iPod and Nest. I’m bringing it in this context because there are chapters on personal growth, struggles of building something, making mistakes, learning from those mistakes, and rising again after making those mistakes. Fadell doesn’t pretend the anxiety and stress aren’t there. Instead, he offers a framework for navigating the chaos. Here are some takeaways:

Killing Yourself for Work

One of the chapters in the book talks about the difference between ‘working hard’ and ‘killing yourself’, one coming from passion and being driven to build great things, and another coming from fear (being terrified of what happens if you don’t work hard). I found for myself that I do like to work hard, but also need to be honest about the source of that drive. If passion that’s sustainable, if fear then it is not.

Failure is the Data; Fear of being wrong

Fadell talks about his time at General Magic as a spectacular failure that taught him everything. It reminded me that my ‘overthinking’ is really just fear of being wrong. I am often fixated on avoiding mistakes, but the only people who do nothing make no mistakes. Failure is just data for the next iteration.

Data vs. Opinion; Avoiding “analysis-paralysis”

My paralysis usually comes when I’m looking for data that doesn’t exist. The book simply says that sometimes data isn’t there (yet) and it is ok to bet on your intuition and just move (“just do it” as Nike’s slogan says). Overthinking without data or with made up data is just spinning wheels and wasting energy.

The Crisis Point

The author argues that any meaningful project will have a ‘Crisis’ point. I realized that in my career I had so many projects where it really felt that things were about to fall apart only to find a way to still ship things in the end. Stress during those times is normal, it is just part of the process. If you had zero stress, then it is likely you were not pushing yourself or your team outside of the comfort zone.\

Conclusion

There are so many other great chapters in the book, like “Why Storytelling”, “Assholes”, “Heartbeats and Handcuffs”, “How to spot a great idea”, and so many more, but one lesson I’m taking from the book today is that the path of success and growth is always hard, often filled with failures, stress, and hard work. If you are driven by passion and wanting to make a difference, then push for this, but if your hard work is coming purely from fear, it might be a good time to take a break and see what you can learn.


No comments


Don’t Outsource Your Thinking: Why I Write Instead of Prompt

November 23, 2025 AI, Blog, Opinion, Personal No comments

Original content by Andriy Buday

I’ve been asked multiple times about my writing process, how I keep consistency, and why I write blog posts at all. Who in their right mind spends multiple hours weekly to write when there are LLMs that generate the same quality text within a minute? Let me share my secrets and answer these 4 questions:

  1. Why do I write at all?
  2. Isn’t it all just a waste of time because of LLMs?
  3. What’s my writing process?
  4. How do I stay consistent?

Image credit: Gemini Nano Banana Pro. I admit the image is cheesy, lol, but it’s also fun.

Why do I write at all?

Writing is structured thinking

Over time I confirmed to myself that ‘writing is thinking’ but also unlike speaking or thinking in my head writing is a structured way of thinking. You get the privilege of ‘parking’ some thoughts for further elaboration, you get the privilege to validate your thoughts with external research, you get all the privilege to mold things and shuffle them around, decompose and synthesize again.

Writing is a transferable skill

Undeniably writing is a skill, but, in my opinion, it is a transferable one. By working on improving my process of writing it becomes easier for me to write documents at work and the easier for me it becomes to write my personal documents (financial planning, goal setting, emails, etc). The more I write the easier it is to overcome that initial ‘hurdle’ of starting a new document. I am a doc producing machine at work: meeting notes – I’ve got it; short design doc – I’ve got it; just documenting my work trip – I’ve got it; producing ‘announcement’ document – I’ve got it. None of it seems daunting. I also wrote a post on “Why documenting everything you do at work matters” believing it is beneficial for your career, especially performance reviews and promos.

Isn’t it all just a waste of time because of LLMs?

Producing vs. Consuming

Here is a big secret, my dear readers: I’m writing mostly for myself, and I have a strong argument why it is worth my time instead of just prompting LLMs. For the sake of argument, I just kicked-off Gemini’s ‘Deep Research’ on the topic of tech writing, answering 4 questions from above. I’m confident that in ~3 minutes I will have a PhD level research paper on this topic. What do I gain from that research? What do you gain from that LLM research? Well, we become consumers – I can read that research paper and, for sure, that will have many punchy arguments and external pointers to like 100+ websites to learn from, but this trains our “info => brain” path, this does not train our “brain => info synthesis” path. Very specifically, next time when you need to produce new information, your retrieval/producing ‘paths’ in your brain are not trained for that.

Numbers

Let’s also do some numbers to see the worthiness of this activity:

  • Range of 2-5 hours per week writing blog posts. It is closer to 2h for writing itself like this post and closer to 5h for larger technical/coding posts.
  • 370 blog posts so far.
  • 800 comments with praise/admiration and additional insights I was missing.
  • Only 3k pageviews/month and only 50 mail subscribers.
  • I have no ad income (I made some <200$ in the past as an experiment).
  • In a way, the blog is an ‘Ad’ of myself.
  • Up-scalling my tech writing skills.
  • Hardly measurable influence on my career growth, but it’s definitely there.

What’s my writing process?

Sourcing Topics and Info

To be honest, at times it is very challenging to come up with new blog post ideas and even when I have an idea expanding on it is also quite a tedious process. I have a “blog post ideas” document which just sits there in my Google docs. Whenever something crosses my mind I would add it there. Another source of ideas is just some question I would get from someone either at work or in my personal conversations. For instance, this blog post was inspired by a person asking about my writing process as he was struggling a bit with writing some roadmap/design document at work. I hear you. This blog post is for you.

Writing Process Itself

At very early stages I usually start with just pouring thoughts and ideas in raw, unfiltered, and very unstructured ways. This is just the expansion step of my framework of dealing with ambiguity. At this stage focusing on quality, perfection, structure is counter-productive. If this is a technical design document, then some template for structure is usually already given, so that ‘pouring’ thoughts happens in compartments. Then, once I have lots of unstructured thoughts, I do more of research, I try to find key points and rephrase where needed, this is where trimming also happens. At later stages I would use LLMs to help me out, but I am generally against using LLMs for everything, and definitely not using for my blog writing. At work, generating summary or bullet points or initial structure is definitely easier with LLMs, and it would be a mistake not to use it.

LLMs

Yeah, I do use LLMs – but not for writing or structuring my thoughts but for other purposes. The main one: finding blind spots in my thinking. I have made many profound realizations of missing some key arguments thanks to LLMs, not only that, even in my personal life I came to realize that there are things I perceive simply differently to other people – eye opening. Another use of LLM is to suggest refinements to text, but not so much proof-reading, unless this is obvious typo catches. Honestly, sometimes, I just cannot stand all this ‘sophisticated flowery’ text generated by LLMs. When I see people write ‘significant impact drastically improving leverage of comprehensive coverage of’ – I know it is LLM and it sucks. You can know these are my own words, because LLMs avoids confrontation. Another way I’m using LLM for my writing is coming up with a common theme in my thinking and generating ideas for the best title.

Focusing on Experience and own Opinions

In the light of LLMs I found it to be ever more important to focus on my own experiences, strong opinions, and on building my own personal expertise. That’s the main distinguishing factor. No LLM has my brain or knows my thoughts.

How do I stay consistent?

Connect Inspiration Periods in One Continuous Chain

This is another question I get quite often. The answer: Consistency is Hard. The way it works for me is a multi-year habit building. I failed many times and I had to re-start it over and over again until it actually started working in a connected chained manner. The analogy I give is from rock climbing: to climb a mountain you connect multiple single pitch climbs. We get inspired at times (new year resolution, someone inspires you) and then you do a few iterations and then you fail. I say: get inspired more often, on purpose, and then connect into a continuous chain! Get inspired by books, people you admire, your mentors, your super-smart colleagues, someone you love, and last but most importantly, your future self!

Conclusion

Writing is not always just the output, but also the process. I see writing as “gym for the brain”. For sure, LLMs can lift weights for you, but that won’t make your thinking and writing stronger. It is like watching fit and strong people on Instagram and wishing you will be one like them without doing anything. The world is dominated by consumption and in my opinion being able to structure your thoughts and clearly articulate is something that will make you stand out.



APPENDIX: Additions by Gemini 3 PRO LLM

Below are some interesting extracts from the 17 page ‘Research Paper’ produced by Gemini on my ‘deep research’ request about technical blow writing and from analysis of the above text:

Blind spot: The “Quality” Trap

You mention LLMs generate “flowery” text that sucks. While often true, advanced prompting can mimic style fairly well. Suggestion: Strengthen the argument that the value isn’t the final text, but the struggle to produce it. Even if an LLM wrote a perfect post in your style, it would still be a “waste” because you didn’t do the cognitive lifting to get there. It’s like sending a robot to the gym for you.

Luck Surface Area

Blogging increases an engineer’s “Luck Surface Area.” This concept suggests that the amount of serendipity (job offers, speaking invitations, consulting opportunities, co-founder inquiries) one encounters is directly proportional to the number of people who know what one is doing.

Beyond the internal mechanics of a current employer, blogging functions as a potent “sales aid” for the engineer’s broader career trajectory.2 Recruiters and hiring managers at elite firms increasingly value communication skills as a primary differentiator. According to industry data, a significant majority of recruiters prioritize communication skills, sometimes even above raw technical proficiency, because technical knowledge can be taught, whereas the ability to articulate complex logic is a rarer trait.

Linearization of Thought and Feynman Technique

The process of writing requires the linearization of thought. Code can be non-linear; it jumps between functions, modules, and asynchronous callbacks. Prose, however, must flow logically from premise to conclusion. This forcing function exposes gaps in understanding. As noted in the analysis of engineering blogging benefits, writing a blog post often reveals that the author does not understand the code as well as they thought they did. This aligns with the “Feynman Technique,” which posits that one does not truly understand a concept until one can explain it in simple terms to a layperson.

Transfer of Experience

However, LLMs struggle with context, nuance, and novelty. They cannot hallucinate genuine experience. They can explain what a circular dependency is, but they cannot explain how it felt to debug one at 3 AM during a Black Friday traffic spike, nor can they navigate the specific political and technical constraints that led to that dependency in the first place.

The value of human writing has shifted from Transfer of Information to Transfer of Experience. The “Small Web” movement is a reaction to this; it is a flight to authenticity. Readers are looking for the “red hot branding iron” of human personality—the idiosyncrasies, the opinions, and even the biases that signal a real person is behind the text.15 As AI content proliferates, the premium on “human-verified” knowledge increases.

Case Study: Gergely Orosz (The Pragmatic Engineer)

Gergely Orosz serves as the gold standard for the modern technical writer. His transition from engineering manager at Uber to full-time writer was built on a specific process 39:

  • Crowdsourcing via Surveys: Orosz often gathers data before writing. For an article on “Developer Productivity,” he surveyed 75+ engineers and managers across the industry.39 This provides proprietary data that no LLM can access.
  • Structured Workflow: He treats writing with the discipline of coding, using outlines and working with editors/publishers to force progress.41
  • Mimicry: He openly advises starting by mimicking role models.42 If you admire a specific engineering blog, analyze its structure and replicate it until you find your own voice.


No comments


The Hurdles vs. The Levers: A Framework to Think About Personal Productivity as Software Engineer

November 16, 2025 Opinion No comments

I was thinking about what makes a software engineer productive. There are so many things that come to mind: enough focused time, right tooling, fundamental knowledge, soft and hard skills, energy, motivation, attitude. So much of everything and you can definitely find arguments online for one or the other being the most critical. In this post I want to argue, what is more critical, but rather want to make a point that generally there are two categories and then suggest some action items in the end based on this. Additionally, I will try to present examples with personal stories.

Image credit: Gemini

The Hurdles: Logarithmic/Sigmoid Blockers

These are examples of things where being good enough is usually sufficient to get a great boost in productivity but where pushing for being world-class good only gives smaller diminishing returns and only makes you good in that specific area.

Typing speed. Naive example, but for its simplicity it’s easy to understand. Extremely slow typing speed would slow you down. But the difference between really fast 100wpm and 150wpm is tiny for your productivity as a software engineer. To give a personal flavor, back in my university I trained my typing so I could type fast but then when I was in a sports programming competition (speed matters there), the guy who was a slow typer but a ‘big brain’ easily would beat me on hardest problems.

Tooling familiarity. For example, your IDE. If you get lost on how to use it at all, doing anything even simple is extremely tedious. Remember how frustrating it is to find some simple functionality that should be there right at your fingerprints. I would say this is logarithmic as well, but the curve bends at a much higher elevation compared to typing, so you do need to spend deliberate time to learn core functionality of IDE and your entire productivity will be elevated. Knowing some nice rarely used features probably won’t help too much. Back at my first job, I learned how to be productive with JetBrains ReSharper and could execute large refactorings quickly – this distinguished my productivity from others, but not too much from others who knew these tools as well.

Physical and mental health. Being sick sucks for productivity so it is clear the healthier you are the better your productivity is going to be. The difference between being “generally healthy” and “an elite athlete” on your ability to code is not 10x, lol. My intensive Muay Thai classes don’t help me with my coding at all, but general weekly activities help maintain a healthy baseline that doesn’t make you ‘tired’. Arguably this becomes more important as you age. With age our mental capabilities degrade a bit as well as needs for rest increase. 

… there are more …

The Levers: Exponential Multipliers

This is a category I have for things where being better actually makes your productivity be higher, either just linearly or even exponentially, being good is good, being better is much better, and being great makes you 10x.

Fundamental knowledge and understanding. The way I imagine it is that fundamental knowledge is setting the upper limit on your productivity. If you don’t have enough fundamental knowledge it would be hard to break through the “ceiling” and come up with something truly innovative. Yeah, that’s why big tech is chasing those ML PhDs with ludicrous pay as this is what is pushing that most upper boundary limit. That’s why new grads, people who acquired some strong knowledge, are like those big unknowns with huge potential. I know many folks who studied with me, but having had more in-depth knowledge, have achieved greater results sooner.

Consistency. If you are productive consistently, the progress might not be visible immediately but over time it will become apparent and accumulated and it will get you really far. This time I think of this somewhat as linear dependency up to a point, but I also think there is a ‘breaking point’ where this converts into exponential uptrend – there aren’t many people in that space to even compare with you. Imagine someone with great knowledge, but just not consistently utilizing it.

Mental resilience and attitude. Having the right attitude towards dealing with stress, projects, being ‘can handle anything’, being resilient usually sets apart people who get stuck at some point and those who get more done. Resilience is what allows you to tackle a complex, multi-month project without giving up. It’s what allows you to take criticism in a design review and turn it into a better product. This one is arguably hard, but I would also say this psychological factor is huge.

Soft interpersonal skills. If you are a single engineer trying to do something your productivity is capped. Someone who can clearly articulate a technical vision, persuade a team, and mentor others can be that “multiplier” of their impact across the entire organization.

… there are more …

Conclusion

So where am I going with these two buckets of Hurdles vs Levers or whatever we call them? Why does it matter?

IMO it does matter a lot as most engineers spend their time optimizing the wrong thing.

  • Sometimes I notice both in myself and others that we are trying to pull a “lever”, like learning a totally new programming language, all the while some simple “hurdle” is not cleared, like being burned out or not knowing how to use IDE.
  • And other way around, say all the hurdles are cleared but we keep optimizing them, like I might be trying to bring my system design documents to perfection, when I probably should gain a new foundational knowledge on the complex system itself so I push my upper limit on future designs and become innovative with insightful knowledge.

Let’s conclude this as a framework:

  1. First, identify and clear your hurdles. Are you fighting your tools? Are you exhausted? Are you constantly sick? Your workstation setup sucks? Crappy keyboard? Forgetting git and linux commands? Fix these first. You can’t be productive if you’re running with a sprained ankle.
  2. Then, focus all your energy on the levers. Build consistency. Go deep on fundamental knowledge. Have mentorship (both as mentor and mentee). Practice your communication skills. Be better at prioritization. This is how you stop being just busy and start being truly productive.”

What are your thoughts? What obvious examples have I missed? Do you generally agree with this categorization or think there is even a 3rd category?


No comments


The Practical Ceiling: AI, Diminishing Returns, and Our Future

October 19, 2025 AI, Opinion No comments

I would like to discuss a dilemma between near science fiction predictions of development of AI and grounded practical applications of AI.

Image credit: me + Gemini
Gemini or any other LLM does NOT take credit for the contents of the blog post, though!

First of all, it is completely undeniable that AI is changing our lives and will have a transformative effect on the future. We can argue that humanity has lived through many transformative events over and over again: invention of fire, agriculture, writing, electricity, industrialization, information technologies, so AI can be seen as just one more invention on our part. Now, is AI really just one more invention or something that would absolutely change what it is to be a human as we know it? Is this our last invention?

I just finished reading the book “The Singularity is Nearer”. The book is arguing that we will eventually extend the capabilities of our biological brains and go beyond the limits of our organic bodies. At first we would come up with inventions that would greatly extend and improve our lives (reaching “longevity escape velocity” in mid 30s) and that we will build brain-computer interfaces (think of phones now, AR glasses or something of the like next, brain implants next, nanorobots next, with eventual consciousness upload to the information network). As another book “Homo Deus” (my review) argues – we eventually become god-like and gain the ability to control life and environment and Homo Sapiens go extinct. We might eventually lose our carbon-based existence and just become information.

To my way of thinking, while much of that, like nanorobots repairing our bodies, may sound like science fiction, as long as it doesn’t break the laws of physics I’m on board that it can and may happen.

Now, let’s look at some more practical examples.

  • From transportation technology: Crossing the Atlantic would be 6 weeks sailing in the 1800s, 6 days in early 1900s with fast liners, 1950s – 8 hours by plane, 1970s – concorde doing that in <4h, and technically 90min possible from anywhere on planet to anywhere by rockets, but we are still flying boring 8h from London to NY.
  • Military: We came up with ever larger nuclear bombs, but post “Tsar Bomba” in 1961 it simply doesn’t make sense to make any larger ones.
  • Digital: digital camera resolution, audio quality, single processor’s clock speed, and many more examples where more has diminishing returns and becomes impractical.

This same pattern of hitting a practical limit is not just a historical curiosity because I can see it already happening in the world of AI. Let’s have a look at some examples:

  • LLMs are now reaching the plateau of information saturation where they basically learned everything there is to learn from the internet.
  • Vibe coding is mostly hype in my opinion. Yes, I do vibe-coding as well for fun, like my previous post about doing 3h multiplayer typing game, and it is a huge productivity booster, but I believe it fundamentally is like many other tools [post pending] – having logarithmic benefits – huge at the beginning and eventually ever more diminishing.
  • Plateau in image recognition. This once was a grand challenge of computer science, and is now a largely solved problem for most practical purposes, but pushing models to 99.9% accuracy is not practical.
  • Parameter count race. All those 7B to 70B to 1T parameter models. There is no point in multi-T models and the cost is just not worth it. I recently ran 7B LLM model on my mac air and it is not that bad at all. 

My point is that in many individual fields where AI is applicable we will be reaching the some kind of optimal point between theoretical possibility and practical application. In the process we will be seeing major transformations, like the entire sector of jobs associated with driving will be replaced by self-driving vehicles. There is a good chance this could create socio-economic disruptions and ripple effects. Just imagine, some rich “haves” can give their child superpowers while some poor “have nots” could not afford that. But I agree to the point that this is only “in-transite”, because now people in some poor countries can afford a phone that would be multi-billion worth of technology if this was mid last century.

My own predictions are that:

  • AGI is still very far away, a much longer time-frame than “The singularity is nearer” is arguing for. Maybe 10-30 years from now.
  • Each and every AI application will reach its optimal practical point.
  • Human lives will improve as they did with other technologies. 
  • Software engineering jobs won’t get extinct, but they will transform and we need to adopt.
  • I will die, but someone born next century might not.


No comments


Finding Your Voice at Work

October 5, 2025 Opinion, RandomThoughts No comments

If you stay silent as a mouse you will just stay where you are.

This was the advice I got from a team lead at my first job, right after I’d rushed through the office to complain about a broken system that endangered a delivery to our client the next week. He praised me and didn’t want to shut me down, even if I might have overdone it. For many of us, finding that voice is the hardest part. We hold back our ideas, questions, and concerns for a number of reasons. Let’s break down the four most common ones:

  • We assume that something is obvious.
  • We assume that others know better.
  • Deference to authority.
  • Physiological: not feeling safe, fear of judgement.

Stating the Obvious

One of the biggest mistakes we make is assuming that others have the same knowledge or perspective as we do. What seems obvious to you is often the result of your unique experiences, learning, and context. But others may not have the same background.

One of my university professors used to say there are only three types of proof: by contradiction, by reasoning, and obvious. I struggled with the 3rd one because when something is somehow “obvious”, it wasn’t that obvious to me at all.

Quickly re-stating that “obvious” part often removes the ambiguity from the discussion and sets the common baseline. Without being aligned on the same baseline the entire conversation doesn’t make sense, that’s why it is super-important to simply re-state the “obvious” and explicitly list what the assumptions are.

Sometimes I notice how very senior leaders would ask very basic questions about something only to witness that not everybody in the room was on the same page about this basic truth.

Sharing the “obvious” has very little drawback. While there may be a small cost, say a bit more document space or an extra minute in a meeting, that cost is a cheap insurance policy against catastrophic misalignment. A little information overhead is always better than massive miscommunication.

Others know Better

It is oftentimes true that others know better (to state the obvious). But this shouldn’t be a blocker, rather it should be an incentive! If you speak up and you’re wrong, you become the main beneficiary: you get corrected and learn a critical piece of information. If you’re silent, you leave the meeting still misinformed. If a question is forming in your mind, it’s highly likely that several other people in the room are thinking the exact same thing but are too afraid to ask. By asking, you don’t expose your ignorance; you serve the collective need for clarity.

Deference to Authority

Sometimes it’s not fear or lack of clarity, but simple deference to authority. When senior leaders are present, people instinctively stay quiet, assuming their ideas matter less or that others will take the lead. This one is tricky as it also includes some cultural aspects of how you were raised and also cultural aspects of your company.

More often than not, however, leaders actually want more people to speak. They value a challenging question or divergent perspective far more than a room full of nodding heads. In fact, leaders sometimes speak first precisely to kick-start the conversation, and they often intentionally hold back because they don’t want their presence to silence the room. In fact, sometimes leaders don’t speak at all precisely because they want to ensure others feel there is room to contribute. Silence out of deference is perceived as alignment, which can lead to misguided decisions. Don’t assume your idea matters less. Assume your perspective is a critical puzzle piece the decision-maker needs.

Physiological Safety

This one is a tough one because it’s rooted in our fundamental human desire for psychological safety. This is a need that is not always easy to satisfy in high-pressure environments, such as the big tech corporate world.

Google has done this famous study “Project Aristotle” which concluded that psychological safety was the number one predictor of a team’s effectiveness, more so than the individual skills, intelligence, or seniority of the team members. The “how” a team worked together was more important than the “who.” Safety there means that team members are confident that no one will embarrass or punish them for admitting a mistake, asking a question, or offering a new idea.

Being comfortable taking “interpersonal risks,” such as challenging the status quo, offering divergent ideas, or asking for help is a lot more beneficial than taking another risk of closing in and solving the problem on your own.

Conclusion

The path from “mouse” to “wolf” isn’t about aggression or volume. It’s about recognizing that your unique perspective is a crucial piece of the collective intelligence. Your job isn’t to be an expert on everything, but to ensure that the room has all the information it needs: whether that’s stating the obvious, asking the ‘dumb’ question, or challenging the senior leader. So:

Ask the ‘n00b’ question. Challenge the status quo. State the obvious. Share your ideas. You lose virtually nothing, but the collective clarity and your growth is a big win. Speak up!


No comments


Talk Is Cheap; The Smallest Code Change Speaks Loudest

September 28, 2025 Opinion No comments

How many times have you been in a meeting where a brilliant idea was discussed, only to have it disappear into thin air? “Talk is Cheap; Show me the code” by Linus Torvalds perfectly captures the frustration, which roughly means that ideas, promises, or arguments don’t carry much weight until they’re backed by action. In software, the ultimate proof is working code. To be brutally honest, I often talk more than I code, and while talking is important at more senior roles, the ultimate delivery is still code.

From “Wouldn’t It Be Nice” to “I Did It”

I have been in multiple discussions where we were talking about some tool or some product and we all thought, “oh, it would have been nice if the tool had this capability or just this extra command flag we can use”, but because none of us had familiarity with the tool it basically stayed with that “would have been nice”. Over time I noticed: diving into the code is usually less intimidating than it looks. Once you do, you not only solve the problem but also gain familiarity others don’t have.

Why don’t people do this more often? It’s simple: it requires effort taking time away from your main project and has a high risk of failure. My proposal is to time-box your effort. There is definitely a sweet spot where you can spend y hours on the thing, where uncertainty reduces the most drastically, to make the final call if more effort is worth it. The ‘y’ should be somewhat proportional but limiting to the benefit ‘x’ you get, maybe y = sqrt(x).

The Approval Stamp: Reducing Friction

Another example: I was using some internal tool and it had a simple UI validation bug. One path to take was to file a ticket with the team owning the tool, someone would look it up, which would definitely be low priority on their plate, and this would get fixed in few weeks or not at all, but I needed the fix right now to avoid workarounds, so I published the fix code change – literally 2 lines of code. It would have probably taken 2x more time to file the ticket and communicate with the tool owners. They only had to stamp the change.

A bit more abstract: let’s say you are using a system owned by someone else, and you need to change something from x to y. In one way you know that’s a simple change and the person is likely to agree, but explaining it and waiting for them to apply the change causes friction. Instead if you just do the change on your own, and getting Y instead of X is just an “approve” stamp on the other side you will get your stuff really soon.

How about Alignment?

But won’t you come across as someone for pushing for a change without aligning first? – Yup, there is such a risk. There is a very simple way to avoid this: just soften how you propose the change. Ideas: 1) give a quick short “heads-up” message “I have this idea to improve Z by changing x to y, I will share a preview change to show what I mean”; 2) frame your code change as a light proposal, a “preview”, a “suggestion”.

Conquering Uncertainty with Code

This is perhaps where the ‘smallest code change’ provides the most value. Many of us, myself included, can get lost in the abstraction of system design by drawing diagrams and talking through every possibility. While this is a necessary step, it’s not a substitute for engaging with the actual code. I’ve worked with software architects in the past who were so detached from the codebase that their designs were completely unworkable. They simply didn’t know what they were talking about. The solution is to complement your high-level design with ‘on the ground’ code.

The key learning for myself: whenever working on the design of something: do more code digging and make small refactorings along the way (even if a bit unrelated).

Feeling of Doing instead of Talking

This one is a bit subjective, but we are humans as well as software engineers. There’s a fundamental difference between talking about progress and actually making it. Pushing code feels a lot better than just talking about it. Wouldn’t you agree?

Next time you’re tempted to keep talking, try the smallest code change instead. It speaks louder than a hundred conversations. This is one lesson for me.


No comments


Conway’s Law Is Bi-Directional: How Teams Shape Systems and Systems Shape Teams

September 20, 2025 Opinion, TeamWork No comments

I once worked on a product where two Tech Leads couldn’t agree on direction. The result? Two different UIs for the same set of users. That’s Conway’s Law in action: systems mirrored organizational misalignment.

My personal observations over 17 years in large enterprise companies align with Conway’s. But I also believe this goes deeper. Causality runs both ways: organizations shape systems, and systems reshape organizations. In addition to this I think the technical problems the system is experiencing are reflections of communication dynamics.

Conway’s Law and Examples

A quick reminder of Conway’s Law: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”. There are other variations of this. A simpler one I like to personally use in my conversations could be “Organizations design and build systems that mirror their own communication structure”.

For instance, if the company has extremely autonomous teams/orgs the company may end up in a situation where different systems are built with different tech stack and are fully decoupled but also hard to integrate if needed, but, let’s say if within an individual team/org communication is frequent and multi-directional their system might be tightly coupled and un-modular.

Direction of Causality: Org <=> System

So is it that once you have your organization you will end up with a particular system or is it while you build the system the organizational structure will simply organically mimic it?

That’s an important question and I’m of the opinion that this works both ways, meaning you can do re-orgs which will eventually lead to changes in technical aspects of the system, or you can make and push for design choices that over time will lead to org changes (like creating a team for a sub-module).

Companies sometimes deliberately reorganize teams or how they communicate (“Inverse Conway Maneuver”) to influence product architecture. This is one of the other reasons why re-orgs happen, but probably less frequently.

Take Amazon’s mandate for all of the internal teams to use AWS? I was on one of such teams and had to migrate some of our services to use AWS. This approach allowed Amazon to mimic external communication internally (external companies using AWS => internal teams using AWS). Internal engineers were both users and builders, so AWS could iterate quickly on real pain points. In this way feedback loop was that new communication channel that influenced how the systems evolved.

While Conway’s Law is usually stated as “organizations shape systems,” in practice I’ve seen a feedback loop. As soon as you draw a boundary in code, questions of ownership arise, and soon an organizational boundary emerges. Conversely, when leadership merges teams, systems often collapse back into monoliths or shared modules. Architecture creates new communication needs, which shape team structure, and team structure in turn reinforces or redefines architecture. This is why I argue causality is bi-directional: the system and the organization co-evolve.

When Communication Breaks Down

Communication bottlenecks eventually show up in code. Where teams don’t talk, APIs and integration points often become pain points. One team might be making assumptions about how the system behaves, they built their system based on that assumption and eventually operational issues show up. I personally observed this more frequently in micro-service based architectures, but monolithic systems are also susceptible to this.

Sometimes it takes introducing a liaison or two between two teams/orgs to fix things up. I have been working for one division at IAEA (UN) but was given to work on the project for another division, we were able to successfully integrate systems owned by two divisions. It is not so much just my contribution but rather a good decision to introduce new communication channels which resulted in changes to system integration.

Highly cross-functional teams often produce more rounded, cohesive, end-to-end systems. I’ve been on teams where many different roles were involved and worked very closely together (Meta seems to be very strong at this) as well as on teams where product management, database engineers were working in disconnected mode, producing outputs in sequence, which resulted in delays and systems that didn’t really do what they were supposed to. 

Conclusion

Over and over I’ve observed mirroring between systems and communications structures, and I believe the causality is bi-directional, as such you can influence the system not just directly via design but by making organizational changes. The practical lesson is that you don’t always fix a broken system in the codebase alone. Sometimes the fastest path is changing how people talk, or who talks at all.


No comments