My opinion about
AI has reshaped the way developers write code by acting as a powerful partner that speeds up and simplifies the entire process. Modern AI tools can suggest functions, detect bugs, refactor code, and even generate full solutions.
Nevertheless, most companies and company leaders tend to be overhyped about LLMs and automation in code generation. They tend to see those models as a magic bullet that will solve all their problems overnight.
In reality, as I see it at the time of writing, AI is a tool that requires careful integration and thoughtful use. It works best when combined with human expertise and creativity. Companies that understand this balance will be the ones that truly benefit from such models in the long run. Automated code generation can make human more productive, not replace them.
Now, let's talk about production - where things matter the most. My opinion for using AI blindly in production stands with Linus Torvalds - vibe coding is fine but not for anything that matters. Any programmer who has used LLMs to generate code knows that the output almost always requires significant review and adjustment to fit the specific context and requirements of the project. Even if you try to fix those issues with more prompts, you will likely end up with a bloated, inefficient, and hard-to-maintain codebase.
Therefore, I believe that AI should be used as a tool. Running code generated automatically where you have no idea how it works or what it does is a recipe for disaster. This opinion is backed up by numerous real-world examples with the leading example being GNOME where GNOME Shell Extensions store has updated its review guidelines to include a new section specifically stating that “extensions must not be AI-generated”.
LinksIn modern software development, the choice of programming language and framework for building web applications is often shaped by evolving project requirements and industry trends. As the ecosystem continues to expand, a wide range of tools and technologies is being adopted to streamline workflows, enhance performance, and improve developer experience. This ongoing evolution has led to frequent discussions about which languages and frameworks are best suited for creating scalable, maintainable, and efficient web solutions.
Choosing the “best” language for web development has always felt like chasing a moving target. When I first started out, Java was my comfort zone - a language with structure, reliability, and a certain elegance that made backend development feel solid and predictable. It shaped the way I think about software: strong typing, clear architecture, and long‑term maintainability. Those values still matter to me, but the web ecosystem has evolved in ways that Java alone can’t fully capture.
As modern web applications became more dynamic and user‑centric, I found myself looking for tools that could match that pace without sacrificing the engineering discipline I appreciated. That’s where Next.js started to stand out. It brings a level of cohesion to frontend development that reminds me of what I loved about Java frameworks, but with the flexibility and speed that today’s web demands. Features like server‑side rendering, API routes, and file‑based routing make it feel like a full-stack framework rather than just a frontend tool.
What really convinced me, though, is how Next.js simplifies the entire development lifecycle. Instead of juggling separate technologies for rendering, routing, and backend endpoints, everything lives in one unified environment. That means faster iteration, cleaner architecture, and fewer mental context switches - all qualities that resonate with someone who grew up in the Java ecosystem. It’s opinionated enough to guide you, but flexible enough to let you build the way you want.
For new projects, especially ones that need to move quickly while staying scalable, Next.js feels like the most balanced choice. It captures the spirit of modern web development without abandoning the engineering principles that matter. In many ways, it feels like the natural evolution of what I always appreciated about Java - just adapted for the web‑first world we’re building in today.
In recent years, remote work has become a defining element of modern professional life, particularly within the software development industry. As technological capabilities expand and digital collaboration becomes increasingly seamless, the traditional expectation of physical presence in an office warrants thoughtful reconsideration. What follows is my view on why remote work is not simply a preference, but a logical and forward‑looking approach to programming today.
In the field of software development, remote working is not merely a convenient alternative - it is, in my view, the most valid and effective model for contemporary programming. The nature of our work is inherently digital, requiring focus, uninterrupted concentration, and access to the same tools regardless of physical location. When a programmer uses the company’s laptop and digital infrastructure in both home and office environments, the practical distinction between the two settings becomes minimal. Under these conditions, requiring physical presence without a clear operational need appears inefficient and counterproductive.
This is not to say that remote work eliminates the need for human connection. Team cohesion, shared culture, and interpersonal rapport remain essential components of a healthy workplace. However, these goals can be achieved through intentional communication practices, structured virtual interactions, and periodic in‑person gatherings when they serve a genuine purpose. Forcing employees to commute simply to perform tasks they can execute equally well (or better) from home does not strengthen teams; it erodes morale and wastes valuable time.
A company that actively resists remote work signals, intentionally or not, indicates an inability to adapt to modern professional realities. More importantly, it may reveal a lack of trust in its employees or a reliance on outdated management practices. Today’s workforce values autonomy, flexibility, and results-driven evaluation. Organizations that fail to recognize this shift risk undermining their own credibility and competitiveness.
While remote work is the most effective and logical model for programming, there are specific circumstances in which on‑site presence provides clear, practical value. These include situations involving hardware‑dependent development, where engineers must interact directly with physical devices or prototypes; security‑restricted environments, in which regulatory or compliance frameworks require work to be performed within controlled facilities; and critical incident response scenarios that demand physical access to infrastructure or equipment. Additionally, certain forms of complex design collaboration, early‑stage architectural planning, or training that relies on hands‑on demonstration may benefit from in‑person interaction. Finally, targeted relationship‑building events such as onboarding, project transitions, or structured team gatherings, can strengthen cohesion when used sparingly and purposefully. Outside these clearly defined cases, mandatory office attendance offers little operational advantage and risks undermining both productivity and employee trust.
Ultimately, embracing remote work is not about rejecting tradition; it is about aligning workplace practices with the realities of modern life and the demands of a digital profession. Companies that recognize this will continue to attract and retain talent. Those that resist may find themselves struggling to keep pace with an industry that evolves faster than any office policy ever could.