# Signal Through the Noise > Honest takes on code, AI, and what actually works --- ## Pages - [Hire Me](https://www.ivanturkovic.com/hire-me/): I don’t hand you a PDF and disappear. I work inside your repository, asynchronously, on the same GitHub your team... - [](https://www.ivanturkovic.com/the-ai-job-title-reference-guide-2026/): The AI Job Title Reference Guide 2026 40 roles. Definitions, salaries, differentiators, and verdicts. Companion to Everyone Is an Engineer... - [Newsletter](https://www.ivanturkovic.com/newsletter/) - [Privacy Policy](https://www.ivanturkovic.com/privacy-policy-2/): Last updated: 10th December, 2025 This privacy policy explains how ivanturkovic. com collects, uses, and protects your personal data. I... - [Services](https://www.ivanturkovic.com/services/): I help companies build technology that works. Whether you need strategic guidance, hands-on development, or someone to tell you the... - [Experience](https://www.ivanturkovic.com/experience/): I’ve spent nearly two decades building software, leading teams, and architecting systems across fintech, blockchain, and enterprise platforms. My work... - [Sample Page](https://www.ivanturkovic.com/sample-page/): This is an example page. It’s different from a blog post because it will stay in one place and will... - [Privacy Policy](https://www.ivanturkovic.com/privacy-policy/): Last updated: 10th December, 2025 This privacy policy explains how ivanturkovic. com collects, uses, and protects your personal data. I... - [Blog](https://www.ivanturkovic.com/blog-posts/) - [Contact Me](https://www.ivanturkovic.com/contact/): Currently Available for Hire You can contact me on the following addresses Email: ivan. turkovic@gmail. com Skype: ithora Google+: https://plus.... - [My Story](https://www.ivanturkovic.com/about-ivan-turkovic/): I Help Companies Ship Products That Actually Work Over 20 years, I’ve built platforms that serve millions of users, led... --- ## Posts - [Everyone Is an "Engineer" Now, and Nobody Knows What Anyone Does](https://www.ivanturkovic.com/2026/04/24/ai-job-titles-2026-naming-chaos/): A CTO’s field guide to the 2026 AI job title theater, with a companion reference guide covering all 40 roles.... - [The Engineering Age That's Ending, and the One We Haven't Named Yet](https://www.ivanturkovic.com/2026/04/18/engineering-age-ending-ai-software-future/): The best engineers I know write less code than they did two years ago. They ship more. Everyone wants the... - [Open Source Security Is Everyone's Problem Now](https://www.ivanturkovic.com/2026/04/14/open-source-security-axios-attack/): Two weeks ago, a North Korean state actor compromised the lead maintainer of Axios and published malicious versions to npm.... - [Vibing Fatigue: Why Tracking AI Usage Is the Wrong KPI](https://www.ivanturkovic.com/2026/04/11/vibing-fatigue/): A developer I know got pulled into a “productivity review” last month. Not because their output dropped. Because their AI... - [Almost Solved Is the Most Dangerous Phase in Engineering](https://www.ivanturkovic.com/2026/03/31/ai-coding-almost-solved-most-dangerous-phase/): Everyone agrees AI is transforming how we write code. Adoption is through the roof, productivity metrics look promising, and a... - [Complexity Is Never Eliminated. It Is Only Relocated.](https://www.ivanturkovic.com/2026/03/24/complexity-never-eliminated-only-relocated/): COBOL moved complexity from machine instructions to business logic specification. 4GLs moved it from code to data modeling. No-code moved... - ["Done" Is Not Merge: Why Your Definition of Done Is Probably a Lie](https://www.ivanturkovic.com/2026/03/18/done-is-not-merge/): The most dangerous lie in software engineering is a two-word status update: “It’s done. ” In most teams, done means... - [AI Made Learning Feel Pointless. That's Exactly When It Matters Most.](https://www.ivanturkovic.com/2026/03/06/ai-made-learning-feel-pointless/): A week ago my blog post got noticed by developers. I got so many messages and there was a recurring... - [The Training Data Paradox: What Happens When AI Replaces the Engineers Who Trained It](https://www.ivanturkovic.com/2026/03/01/training-data-paradox-ai-replacing-engineers-who-trained-it/): There is a question hiding in plain sight behind every celebration of AI-generated code, every prediction that developers are obsolete,... - [AI Made Writing Code Easier. It Made Being an Engineer Harder.](https://www.ivanturkovic.com/2026/02/25/ai-made-writing-code-easier-engineering-harder/): Yes, writing code is easier than ever. AI assistants autocomplete your functions. Agents scaffold entire features. You can describe what... - [The First 1,000 Lines Determine the Next 100,000 in AI Coding](https://www.ivanturkovic.com/2026/02/24/first-1000-lines-determine-next-100000-ai-coding/): I learned this the hard way while working with Claude Code. AI looks at your existing code and copies the... - [How to Make Your Website Agent-Ready With WebMCP: A Practical Guide](https://www.ivanturkovic.com/2026/02/23/webmcp-tutorial-make-website-agent-ready/): In my previous post on WebMCP, I covered what WebMCP is and why it matters. The response told me something... - [Coding Is Changing. Software Engineering Is Not Going Anywhere.](https://www.ivanturkovic.com/2026/02/22/coding-changing-software-engineering-not-obsolete/): At the World Economic Forum in Davos on January 20, 2026, Anthropic CEO Dario Amodei said something that landed like... - [The "Build It Yourself" Trap: How AI Enthusiasm Is Quietly Killing Core Product Development](https://www.ivanturkovic.com/2026/02/21/build-it-yourself-trap-ai-tooling-vs-core-product/): A new kind of logic is spreading through developer communities, startup circles, and engineering Slack channels. It goes something like... - [When ADD Is Wrong: Recognizing the Limits](https://www.ivanturkovic.com/2026/02/20/when-add-is-wrong-recognizing-limits/): Every methodology has boundaries. Waterfall fails when requirements change frequently. Agile struggles with fixed-scope contracts. TDD is awkward for exploratory... - [Software Companies Are Dead. Just Nobody Told Them.](https://www.ivanturkovic.com/2026/02/19/software-companies-are-dead-just-nobody-told-them/): Software companies are dead. Just nobody told them. Or so everyone keeps saying. LinkedIn is flooded with Claude Code hype.... - [ADD Meets TDD, BDD, and Agile: Combining Methodologies](https://www.ivanturkovic.com/2026/02/18/add-meets-tdd-bdd-agile/): ADD is not a replacement for existing development methodologies. It is a complement to them. Teams already practicing Test-Driven Development,... - [ADD in Context: Greenfield, Legacy, Refactoring, and Testing](https://www.ivanturkovic.com/2026/02/16/add-in-context-greenfield-legacy-refactoring/): The ADD cycle is consistent across contexts: Specify, Generate, Evaluate, Integrate. But how you apply each phase changes depending on... - [WebMCP Is Coming: How AI Agents Will Reshape the Web](https://www.ivanturkovic.com/2026/02/15/webmcp-is-coming-how-ai-agents-will-reshape-the-web/): On February 10, 2026, the Chrome team quietly published a blog post announcing something called WebMCP. It was framed as... - [No, Average People Will Not Build Their Own Software With AI](https://www.ivanturkovic.com/2026/02/14/average-people-will-not-build-software-with-ai/): There is a narrative gaining traction in tech circles, on social media, and in breathless conference keynotes that goes something... - [Full-Time CTO vs. Fractional: The Real Math Nobody Shows YouThe Math on Hiring a Full-Time CTO (And Why It Rarely Adds Up)](https://www.ivanturkovic.com/2026/02/13/full-time-cto-vs-fractional-the-real-math-nobody-shows-youthe-math-on-hiring-a-full-time-cto-and-why-it-rarely-adds-up/): Every startup founder eventually faces the same inflection point. The product is gaining traction. Technical decisions are getting more complex.... - [Architect or Extinct: Why Software Developers Must Evolve Beyond Writing Code](https://www.ivanturkovic.com/2026/02/12/architect-or-extinct-software-developers-must-evolve/): A house architect does not lay bricks. They do not mix concrete, install plumbing, or wire electrical panels. They design... - [Integrate: Completing the ADD Cycle for AI-Driven Development](https://www.ivanturkovic.com/2026/02/11/integrate-completing-add-cycle/): Code that passes evaluation is ready for integration. This is the final phase of the ADD cycle, where generated code... - [Evaluation Checklists: Building Your Quality Gate for AI Code](https://www.ivanturkovic.com/2026/02/10/evaluation-checklists-quality-gate/): In the previous post, I covered the five dimensions of evaluating AI-generated code: correctness, fitness, security, performance, and maintainability. Understanding... - [You Don't Want a Claude Code Guru](https://www.ivanturkovic.com/2026/02/09/you-dont-want-a-claude-code-guru/): The job posting practically writes itself these days. “Looking for a senior developer proficient with AI coding tools. Must be... - [An Honest Take on Deploying Rails with Kamal: What Works and What Doesn't](https://www.ivanturkovic.com/2026/02/06/honest-take-kamal-rails-deployment/): Kamal has been positioned as the answer to a question Rails developers have asked for years: how do you deploy... - [The New Bottleneck: Why Clarity Matters More Than Code](https://www.ivanturkovic.com/2026/02/05/the-new-bottleneck-clarity-over-code/): For two decades, the fastest engineers were the ones who could write code quickly. They knew the shortcuts, the patterns,... - [Evaluate: Why Human Judgment Is Non-Negotiable](https://www.ivanturkovic.com/2026/02/03/evaluate-human-judgment-non-negotiable/): We have arrived at the phase of ADD where the most important human skill comes into play. You have written... - [Prompt Patterns Catalog, Part 2: Iteration, Verification, and Persona](https://www.ivanturkovic.com/2026/02/02/prompt-patterns-iteration-verification-persona/): In the previous post, I introduced three foundational prompt patterns: Decomposition for breaking complex tasks into manageable units, Exemplar for... - [Prompt Patterns Catalog: Decomposition, Exemplar, Constraint](https://www.ivanturkovic.com/2026/02/01/prompt-patterns-decomposition-exemplar-constraint/): Software developers are familiar with design patterns. The Gang of Four cataloged reusable solutions to recurring problems in object-oriented design.... - [Generate: The Art of Effective AI Collaboration](https://www.ivanturkovic.com/2026/01/31/generate-effective-ai-collaboration/): Generation is where the visible work happens. You provide input, and the AI produces code. This is the moment most... - [Specification Templates: A Practical Library for AI Development](https://www.ivanturkovic.com/2026/01/30/specification-templates-practical-library/): In the previous post, I made the case that specification is the highest-leverage skill in AI-driven development. A precise specification... - [The Quiet Builders: A History of Introverts in Engineering and What AI Means for the Future](https://www.ivanturkovic.com/2026/01/29/introverts-engineering-history-ai-future/): Throughout human history, there has always been a place where the quiet ones could excel. A domain where deep thinking... - [Specify: The Most Important Skill in AI-Driven Development](https://www.ivanturkovic.com/2026/01/28/specify-the-most-important-skill-in-ai-driven-development/): If you take one thing from this entire series, let it be this: the quality of AI-generated code is bounded... - [From Waterfall to ADD: Why AI Demands Its Own Methodology](https://www.ivanturkovic.com/2026/01/27/waterfall-to-add-ai-methodology/): Software development methodologies do not emerge from academic theory or conference talks. They emerge from pain. Practitioners encounter problems that... - [The Unstructured AI Problem: Why Most Teams Are Using AI Wrong](https://www.ivanturkovic.com/2026/01/26/unstructured-ai-problem-teams-using-ai-wrong/): Every developer I know uses AI tools now. Copilot suggestions appear mid-keystroke. ChatGPT tabs stay permanently open. Claude conversations stretch... - [ADD: AI-Driven Development as a Methodology for the Future Engineer](https://www.ivanturkovic.com/2026/01/25/ai-driven-development-add-methodology/): Software development has always evolved through methodologies that structure how we think about building systems. Waterfall gave way to Agile.... - [The Future Engineer: What Software Development Looks Like When AI Handles the Code](https://www.ivanturkovic.com/2026/01/24/future-engineer-ai-software-development-skills/): The software industry has entered a period of genuine transformation. After decades of incremental tooling improvements, AI-assisted development is introducing... - [Code Is for Humans, Not Machines: Why AI Will Not Make Syntax Obsolete](https://www.ivanturkovic.com/2026/01/23/code-is-for-humans-not-machines-why-ai-wont-make-syntax-obsolete/): With AI, “everybody is a programmer. ” You do not need to learn syntax anymore. Just describe what you want,... - [The Eternal Promise: A History of Attempts to Eliminate Programmers](https://www.ivanturkovic.com/2026/01/22/history-software-simplification-cobol-ai-hype/): When I look back at the history of software, one pattern emerges with remarkable consistency: the promise to simplify software... - [AI-Powered Fixed-Cost Development: A New Model for Agencies](https://www.ivanturkovic.com/2026/01/21/ai-fixed-cost-development-agencies-consultants/): Software development has always carried an uncomfortable truth: nobody really knows how long it will take. Clients want certainty. They... - [The AI Orchestration Developer: Why Team Leaders Will Define the Next Era](https://www.ivanturkovic.com/2026/01/19/ai-orchestration-developer-team-leaders-software-engineering/): There is a particular kind of developer who has spent years doing something that most of the industry undervalues: building... - [Why Ruby Might Be the Most AI-Friendly Language Nobody's Talking About](https://www.ivanturkovic.com/2026/01/17/ruby-token-efficiency-llm-ai-friendly-language/): A few weeks ago, Martin Alderson published something that caught my attention: a systematic comparison of how token-efficient different programming... - [How AI Saved $2 Million in a Single Day; And It Wasn't Vibe Coding](https://www.ivanturkovic.com/2026/01/13/ai-saved-2-million-not-vibe-coding/): I recently came across a story that perfectly encapsulates something I’ve been thinking about for months. It’s about a CPO... - [What Makes Ruby Different: Unique Structures vs Python, Java, JavaScript](https://www.ivanturkovic.com/2026/01/10/ruby-unique-structures-vs-other-languages/): In my previous post on Ruby’s building blocks, I covered when to use Struct, Data, Class, and Module. But I... - [Ruby's Building Blocks: When to Use What (And Why)](https://www.ivanturkovic.com/2026/01/08/ruby-struct-data-class-module-when-to-use/): Ruby gives us an abundance of organizational tools. Struct, Data, classes, modules as namespaces, modules as mixins, service objects, and... - [A CTO Would Be Bored by Tuesday](https://www.ivanturkovic.com/2026/01/07/a-cto-would-be-bored-by-tuesday/): Founder: “I need a CTO. ” Me: “For what? ” Founder: “Technical leadership. ” Me: “What technical decisions are you... - [What I Wrote About in 2025](https://www.ivanturkovic.com/2025/12/29/what-i-wrote-about-in-2025/): Looking back at the year, my blog became a running commentary on how AI is fundamentally reshaping software development, and... - [A Christmas Eve Technology Outlook: Ruby on Rails and Web Development in 2026](https://www.ivanturkovic.com/2025/12/24/a-christmas-eve-technology-outlook-ruby-on-rails-and-web-development-in-2026/): As we gather with loved ones this Christmas Eve, wrapping presents and reflecting on the year behind us, it’s the... - [The Future of Language Frameworks in an AI-Driven Development Era](https://www.ivanturkovic.com/2025/12/23/the-future-of-language-frameworks-in-an-ai-driven-development-era/): As artificial intelligence increasingly writes the code that powers our digital world, we’re standing at a fascinating crossroads in software... - [From Intentions to Impact: Your 2025 Strategy Guide (Part 2)](https://www.ivanturkovic.com/2025/12/22/from-intentions-to-impact-your-2025-strategy-guide-part-2/): The Resolution Graveyard It’s December 22nd. In nine days, millions of people will make promises to themselves that they won’t... - [Stop Procrastinating in 2025: Part 1 - Building Your Foundation Before New Year's Resolutions](https://www.ivanturkovic.com/2025/12/15/stop-procrastinating-in-2025-part-1-building-your-foundation-before-new-years-resolutions/): Why December Is Actually the Best Time to Stop Procrastinating As we approach 2025, most people are preparing their New... - [The Corporate Culture Charade Part 2: How AI Is Killing What Little Culture We Had Left](https://www.ivanturkovic.com/2025/12/13/the-corporate-culture-charade-part-2-how-ai-is-killing-what-little-culture-we-had-left/): While executives blame remote work for destroying company culture, they’re missing the real culprit: AI-generated content is creating a closed... - [Company Culture](https://www.ivanturkovic.com/2025/12/11/company-culture/): The article critiques the modern obsession with corporate culture, arguing it is often a superficial construct designed to appease executives... - [Building a Decentralized Credit Card System Part 2: Solidity Smart Contract Implementation](https://www.ivanturkovic.com/2025/12/09/building-a-decentralized-credit-card-system-part-2-solidity-smart-contract-implementation/): In the first part of this series, we explored the conceptual architecture of a blockchain-based credit card system using multi-signature... - [Building a Decentralized Credit Card System with Multi-Signature Smart Contracts](https://www.ivanturkovic.com/2025/12/07/building-a-decentralized-credit-card-system-with-multi-signature-smart-contracts/): This post outlines a proof-of-concept for a blockchain-based credit card system integrating multi-signature cryptography and smart contracts to manage spending.... - [Ruby 5.0: What If Ruby Had First-Class Types?](https://www.ivanturkovic.com/2025/12/05/typed-ruby-what-if-ruby-had-first-class-types/): The article envisions a reimagined Ruby with optional, inline type annotations called TypedRuby, addressing limitations of current solutions like Sorbet... - [TypedScript: Imagining CoffeeScript with Types](https://www.ivanturkovic.com/2025/12/03/typedscript-imagining-coffeescript-with-types/): The content envisions a hypothetical programming language called "TypedScript," merging the elegance of CoffeeScript with TypeScript's type safety. It advocates... - [A Love Letter to CoffeeScript and HAML: When Rails Frontend Development Was Pure Joy](https://www.ivanturkovic.com/2025/12/01/a-love-letter-to-coffeescript-and-haml-when-rails-frontend-development-was-pure-joy/): The author reflects on the nostalgia of older coding practices, specifically with Ruby on Rails, CoffeeScript, and HAML. They appreciate... - [The Hidden Economics of "Free" AI Tools: Why the SaaS Premium Still Matters](https://www.ivanturkovic.com/2025/11/28/the-hidden-economics-of-free-ai-tools-why-the-saas-premium-still-matters/): This post discusses the hidden costs of DIY solutions in SaaS, emphasizing the benefits of established SaaS tools over "free"... - [Rails Templating Showdown: Slim vs ERB vs Haml vs Phlex - Which One Should You Use?](https://www.ivanturkovic.com/2025/11/26/rails-templating-showdown-slim-vs-erb-vs-haml-vs-phlex-which-one-should-you-use/): This guide compares Ruby on Rails templating engines: ERB, Slim, Haml, and Phlex. It highlights each engine's pros and cons,... - [Why AI Startups Should Choose Rails Over Python](https://www.ivanturkovic.com/2025/11/20/why-ai-startups-should-choose-rails-over-python/): AI startups often fail due to challenges in supporting layers and product development rather than model quality. Rails offers a... - [The AI-Native Rails App: What a 2025 Architecture Looks Like](https://www.ivanturkovic.com/2025/11/19/the-ai-native-rails-app-what-a-2025-architecture-looks-like/): Introduction For the first time in decades of building products, I’m seeing a shift that feels bigger than mobile or... - [The Two Hardest Problems in Software Development: Naming Things & Cache Invalidation](https://www.ivanturkovic.com/2025/11/18/the-two-hardest-problems-in-software-development-naming-things-cache-invalidation/): The post discusses the common struggles developers face with naming conventions and cache invalidation, humorously portraying them as universal challenges... - [PgVector for AI Memory in Production Applications](https://www.ivanturkovic.com/2025/11/16/pgvector-for-ai-memory-in-production-applications/): PgVector is a PostgreSQL extension designed to enhance memory in AI applications by storing and querying vector embeddings. This enables... - [Saving Money With Embeddings in AI Memory Systems: Why Ruby on Rails is Perfect for LangChain](https://www.ivanturkovic.com/2025/11/14/saving-money-with-embeddings-in-ai-memory-systems-why-ruby-on-rails-is-perfect-for-langchain/): In the exploration of AI memory systems and embeddings, the author highlights the hidden costs in AI development, emphasizing token... - [The SaaS Model Isn’t Dead, it’s Evolving Beyond the Hype of “Vibe Coding”](https://www.ivanturkovic.com/2025/11/11/the-saas-model-isnt-dead-its-evolving-beyond-the-hype-of-vibe-coding/): The article critiques the rise of "vibe coding," emphasizing the distinction between quick prototypes and genuine MVPs. It argues that... - [Artisanal Coding (職人コーディング): A Manifesto for the Next Era of Software Craftsmanship](https://www.ivanturkovic.com/2025/10/30/artesanal-coding-%e8%81%b7%e4%ba%ba%e3%82%b3%e3%83%bc%e3%83%87%e3%82%a3%e3%83%b3%e3%82%b0-a-manifesto-for-the-next-era-of-software-craftsmanship/): Artesanal coding emphasizes the importance of craftsmanship in software development amidst the rise of AI and "vibe coding. " It... - [Brainrot and the Slow Death of Code](https://www.ivanturkovic.com/2025/10/28/brainrot-and-the-slow-death-of-code/): The rise of AI tools in software development is leading to a decline in genuine coding skills, as developers increasingly... - [The Art of Reusability and Why AI Still Doesn’t Understand It](https://www.ivanturkovic.com/2025/10/24/the-art-of-reusability-and-why-ai-still-doesnt-understand-it/): AI can generate code but lacks understanding of design intent, making it struggle with reusability. True reusability involves encoding shared... - [The AI Detox Movement: Why Engineers Are Taking Back Their Code](https://www.ivanturkovic.com/2025/10/23/the-ai-detox-movement-why-engineers-are-taking-back-their-code/): In 2025, AI tools transformed coding but led developers to struggle with debugging and understanding their code. This sparked the... - [When 200,000 Lines of AI Code Disappeared and Nothing Broke](https://www.ivanturkovic.com/2025/10/21/when-200000-lines-of-ai-code-disappeared-and-nothing-broke/): A team deleted 200,000 lines of AI-generated code yet maintained app functionality, highlighting the pitfalls of unchecked AI development. AI... - [Why AI Can’t (Yet) Write Maintainable Software](https://www.ivanturkovic.com/2025/10/17/why-ai-cant-yet-write-maintainable-software/): In the past few years, large language models (LLMs) have burst onto the software development scene like a meteor bright,... - [Returning to the Rails World: What’s New and Exciting in Rails 8 and Ruby 3.3+](https://www.ivanturkovic.com/2025/10/16/returning-to-the-rails-world-whats-new-and-exciting-in-rails-8-and-ruby-3-3/): It’s 2025, and coming back to Ruby on Rails feels like stepping into a familiar city only to find new... - [What You Should Learn to Master but Never Ship](https://www.ivanturkovic.com/2025/10/15/what-you-should-learn-to-master-but-never-ship/): Every engineer should build a few things from scratch search, auth, caching just to understand how much complexity lives beneath... - [AI Vibe Coding vs. Outsourcing vs. Local Developers. What Really Works Best](https://www.ivanturkovic.com/2025/10/11/ai-vibe-coding-vs-outsourcing-vs-local-developers-what-really-works-best/): The way we build software is changing fast. You can now code alongside AI in real time. You can hire... - [?? → BI → ML → AI → ??](https://www.ivanturkovic.com/2025/10/08/%e2%86%92-bi-%e2%86%92-ml-%e2%86%92-ai-%e2%86%92/): AI’s past and the future Where acronyms in business come from, what they sold, who won, and what might come... - [The Vibe Code Tax](https://www.ivanturkovic.com/2025/09/29/the-vibe-code-tax/): Momentum is the oxygen of startups. Lose it, and you suffocate. Getting it back is harder than creating it in... - [Is AI Slowing Everyone Down?](https://www.ivanturkovic.com/2025/09/25/is-ai-slowing-everyone-down/): Over the past year, we’ve all witnessed an AI gold rush. Companies of every size are racing to “adopt AI”... - [20+ Years as a CTO: Lessons I Learned the Hard Way](https://www.ivanturkovic.com/2025/09/14/cto-lessons-leadership-product-ai/): Being a CTO isn’t what it looks like from the outside. There are no capes, no magic formulas, and certainly... - [Cocoa, Chocolate, and Why AI Still Can’t Discover](https://www.ivanturkovic.com/2025/09/12/cocoa-chocolate-and-why-ai-still-cant-discover/): Imagine standing in front of a freshly picked cocoa pod. You break it open, and inside you find a pale,... - [When to Hire Real Engineers Instead of Freelancers for Your MVP](https://www.ivanturkovic.com/2025/09/08/hire-real-engineers-mvp/): Building a startup is a race against time. Every day you wait to ship your idea is a day your... - [Why "Lines of Code" Is the Wrong Way to Measure AI Productivity in Software Development](https://www.ivanturkovic.com/2025/08/25/why-lines-of-code-is-the-wrong-way-to-measure-ai-productivity-in-software-development/): Last week, I had a conversation with another CTO that got me thinking about how we measure productivity in the... - [On AI-Generated Code, Maintainability, and the Possibility of Disposable Software](https://www.ivanturkovic.com/2025/07/28/ai-generated-code-maintainability/): Over the past two years, I’ve been using various AI-assisted tools for programming like Codeium, GitHub Copilot, ChatGPT, and others.... - [The AI isn't going to be on call at 2 AM when things go down.](https://www.ivanturkovic.com/2025/05/22/llm-generated-code-liability/): Large Language Models (LLMs) like ChatGPT, Copilot, and others are becoming a regular part of software development. Many developers use... - [AI Isn't Leveling the Playing Field, it's Amplifying the Gap](https://www.ivanturkovic.com/2025/05/15/ai-widening-gap-juniors-vs-seniors/): We were told that AI would make development more accessible. That it would “level the playing field,” empower juniors, and... - [May 1st, Workers' Day: Reflecting on the Future of Developers in the Age of AI](https://www.ivanturkovic.com/2025/05/01/workers-day-ai-future-developers/): Every May 1st, we celebrate Workers’ Day a moment to recognize the hard work, progress, and dignity of people across... - [AI Can Write Code. But Can It Build the Right Product?](https://www.ivanturkovic.com/2025/04/26/ai-coding-and-product-thinking/): AI is changing how we write code. But there’s a critical question not enough teams are asking: Is it helping... - [AI “Vibe” Coding Will Increase Demand for Software Engineers; Here’s Why](https://www.ivanturkovic.com/2025/04/15/ai-coding-demand-software-engineers/): Today, my LinkedIn feed was overflowing with hot takes about AI and the future of programming. A recurring theme? That... - [The Age of AI: Why Experienced Tech Architects and CTOs Are More Crucial Than Ever](https://www.ivanturkovic.com/2025/04/11/ai-product-design-experienced-ctos-importance/): Artificial intelligence is transforming industries at an unprecedented pace, redefining the way we design, develop, and deploy products. However, with... - [The Inevitable Churn of AI-Powered Development Platforms](https://www.ivanturkovic.com/2025/04/07/ai-development-churn-expectations-vs-reality/): AI-powered development tools like Lovable, Bolt, and others have captured the imagination of developers and non-developers alike. The promise? Build... - [AI vs. Experience: The Real Cost of Knowing What Works](https://www.ivanturkovic.com/2025/03/31/ai-vs-experience-coding-mistakes/): Copy and Paste from AI: $20 Actually Knowing What’s Going to Work: $150,000 Knowing Where to Place It: Priceless The... - [No Easy Coding in AI: The Most Common Mistakes and How to Improve Yourself](https://www.ivanturkovic.com/2025/03/30/best-practices-ai-assisted-coding/): Artificial Intelligence (AI) has revolutionized software development, making it faster and more efficient. However, many developers still struggle with AI... - [Can AI Replace Junior Developers, or Should We Train Them to Become Seniors?](https://www.ivanturkovic.com/2025/03/27/can-ai-replace-junior-developers-or-should-we-train-them-to-become-seniors/): The rapid advancement of AI has sparked an ongoing debate in software development: Should companies replace junior developers with AI-powered... - [When Product Owners Ignore Security: Why Experienced Developers Matter](https://www.ivanturkovic.com/2025/03/24/when-product-owners-ignore-security-why-experienced-developers-matter/): In the modern tech landscape, product owners often assume that software will “just work” safely. But security isn’t automatic, and... - [The Rise of AI Wrappers: Are AI Providers the New Telecoms?](https://www.ivanturkovic.com/2025/03/21/the-rise-of-ai-wrappers-are-ai-providers-the-new-telecoms/): Artificial intelligence has experienced an explosion of growth in recent years, with companies like OpenAI, Anthropic, and Google leading the... - [AI: A Gift for Junior Developers, a Curse for Tech Leads](https://www.ivanturkovic.com/2025/03/18/ai-a-gift-for-junior-developers-a-curse-for-tech-leads/): Artificial intelligence is revolutionizing software development, making it easier for less experienced developers to write code, generate solutions, and build... - [Decisions, decisions, decisions](https://www.ivanturkovic.com/2021/01/03/decisions-decisions-decisions/): Year 2020 has taught us many things but not everyone was listening to the lectures. We are living in constantly... - [Homebrew: How to start and stop background services](https://www.ivanturkovic.com/2015/04/10/homebrew-start-stop-services/): View image | gettyimages. com Anyone that has installed application running in the background from Homebrew, knows how to use... - [Stop procrastinating! How to prevent it.](https://www.ivanturkovic.com/2014/11/27/stop-procrastinating-and-be-productive/): Still trying to stop procrastinating? There are probably numerous days that you site behind the computer to do some research... - [AngularJS ngInclude directive and scope inheritance](https://www.ivanturkovic.com/2014/11/26/angularjs-nginclude-directive-scope/): ngInclude directive and scope There are many times when you want to include a html snippet code from another file... --- # # Detailed Content ## Pages - Published: 2026-04-24 - Modified: 2026-04-24 - URL: https://www.ivanturkovic.com/hire-me/ I don't hand you a PDF and disappear. I work inside your repository, asynchronously, on the same GitHub your team is already using. No slide decks. No quarterly reviews. Just a senior technical partner who reads every important PR and tells you, plainly, where the risk is. My approach is shaped by 20+ years of shipping production software in fintech, payments, and high-traffic platforms, combined with a deep working thesis on how AI changes what engineering actually is. I've written extensively about both. You can read the argument on the blog. This page is about how we'd work together. "AI amplifies whatever direction your codebase is already heading. The first 1,000 lines determine the next 100,000. "Ivan Turkovic, ivanturkovic. com The approach Production scars meet AI-era engineering judgment Two decades in fintech and payments taught me one thing that no framework or AI tool will ever replace: a sense for where a codebase will break under real load, real regulation, and real money. You can't learn that from a book. You learn it the hard way, the first time an on-call pager wakes you at 3 AM because a background job silently double-charged customers. The AI era didn't retire that experience. It made it rarer. AI writes code that looks senior. Reviewing it, steering it, and refusing it when it's wrong is now the central skill of the job. That's the lens I bring to every engagement. 01. Read the whole before the parts Every review starts with the domain... --- - Published: 2026-04-24 - Modified: 2026-04-24 - URL: https://www.ivanturkovic.com/the-ai-job-title-reference-guide-2026/ The AI Job Title Reference Guide 2026 40 roles. Definitions, salaries, differentiators, and verdicts. Companion to Everyone Is an Engineer Now. Updated April 2026 By Ivan Turkovic 40 titles covered Use search and filters below Every AI-related job title currently in use in 2026, in one reference. Use this to standardize your hiring, decode a job posting, benchmark a salary band, or figure out which titles are real work versus marketing theater. Each role card includes: definition, day-to-day, tech stack, differentiator from adjacent roles, seniority ladder, US and EU compensation, representative companies, origin, and a verdict. Verdicts use four tags: Stable Fading Theater Predicted. Sources: Levels. fyi Q3 2025, Glassdoor April 2026, ZipRecruiter, Indeed Hiring Lab, Cognizant press release (Aug 29, 2025), Pragmatic Engineer, Simon Willison, Andrej Karpathy, FT, LangChain State of Agent Engineering 2025, GuruSup CAIO 2026 report. All figures are total compensation unless noted. All Core AI Developer ML Infra Product Specialized Predictions 40 roles Jump to section A. Core AI Engineering 10 B. Developer-Adjacent 5 C. Traditional ML 6 D. Infrastructure & Ops 6 E. Product & Business 5 F. Specialized 6 G. Turkovic Predictions 2 H. Differentiation Matrix I. Growing vs Declining J. HR Standardization A. Core AI Engineering Titles Titles for engineers who build AI-powered features on top of pretrained models. The largest and most overloaded category. 1. AI Engineer # Stable & Growing DefinitionBuilds AI-powered application features, primarily using pretrained models via API. The default general-purpose title for production LLM work in 2026. Day-to-dayIntegrates... --- - Published: 2026-03-02 - Modified: 2026-03-02 - URL: https://www.ivanturkovic.com/newsletter/ Visible only to administrators. Edit this content. I write about what's actually happening in software engineering, not what LinkedIn wants you to believe. New posts land in your inbox. No spam, no fluff, no paid promotions. Just honest takes on code, AI, architecture, and the reality of building software in 2026. I unsubscribe from newsletters that waste my time. I expect you to do the same if this one does. Email I accept the privacy policy --- - Published: 2026-03-02 - Modified: 2026-03-02 - URL: https://www.ivanturkovic.com/privacy-policy-2/ Last updated: 10th December, 2025 This privacy policy explains how ivanturkovic. com collects, uses, and protects your personal data. I take your privacy seriously and comply with the EU General Data Protection Regulation (GDPR). Who I Am This site is operated by Ivan Turkovic. You can contact me at any time through ivanturkovic. com/contact with any questions about this policy or your data. What Data I Collect Newsletter subscription: If you subscribe to my newsletter, I collect your email address. That is the only personal information I ask for. I use this to send you new blog posts and occasional updates. Nothing else. Comments: If you leave a comment on a blog post, I collect your name, email address, and the comment itself. Your email is never displayed publicly. Comments may be checked through the Akismet anti-spam service, which may store your IP address and browser user agent string. Server logs: Like most websites, my hosting provider automatically collects technical data when you visit. This includes your IP address, browser type, referring page, and time of visit. This data is used for security and performance monitoring only. Cookies: WordPress sets functional cookies required for the site to work properly. If you leave a comment, cookies may store your name and email so you do not have to re-enter them. The Newsletter plugin may set a cookie to remember whether you are already subscribed. No tracking or advertising cookies are used on this site. Why I Collect This Data I collect... --- - Published: 2026-01-07 - Modified: 2026-03-01 - URL: https://www.ivanturkovic.com/services/ I help companies build technology that works. Whether you need strategic guidance, hands-on development, or someone to tell you the truth about your technical decisions I've spent 20 years doing exactly that. How I Work With Companies Fractional CTO What it means: You get an experienced technology leader without hiring one full-time. I become part of your team for 10-20 hours a month attending key meetings, guiding your developers, and making sure your technology decisions align with your business goals. Who it's for: Growing companies that need senior technical leadership but aren't ready for a $250K+ executive hire. Startups where the founder handles technology but needs a seasoned partner. Companies where the CEO needs someone to translate between the board and the engineering team. What you get: A technical leader in your corner for strategic decisions Roadmap planning that balances speed with sustainability Help building and structuring your development team Someone to represent technology in investor and board conversations Architecture oversight so you don't build yourself into a corner Technical Advisor What it means: Ongoing access to experienced technical guidance typically 5-10 hours a month. Think of it as having a trusted expert on speed dial for the decisions that keep you up at night. Who it's for: Early-stage founders making technical decisions without a technical co-founder. Companies evaluating agencies, vendors, or potential hires. Leaders who want a second opinion before committing to major technology choices. What you get: Regular calls to discuss challenges and decisions Async access for urgent... --- - Published: 2025-12-29 - Modified: 2026-01-07 - URL: https://www.ivanturkovic.com/experience/ I've spent nearly two decades building software, leading teams, and architecting systems across fintech, blockchain, and enterprise platforms. My work sits at the intersection of deep technical expertise and strategic leadership helping companies transform ideas into scalable, production-ready products. What I Bring to the Table Technical Leadership at Scale As CTO and Chief Architect across multiple ventures in San Francisco, London, and beyond, I've led teams through the full product lifecycle from pre-MVP chaos to production systems serving thousands of users. I know how to build teams, establish engineering culture, and ship products that work. Blockchain & DeFi Architecture I've been building on blockchain since before it was fashionable. From creating one of the first cryptocurrency implementations integrated with social platforms to architecting multi-chain wallets across Ethereum, Polygon, Solana, and Sui, I understand both the promise and the pitfalls of decentralized technology. Smart contracts, AMMs, NFT platforms, tokenization, compliance-first design (ERC-3643, ERC-4626). I've built it all. Full-Stack Development Ruby on Rails. Node. js. React. TypeScript. Go. Python. I write code that ships. More importantly, I write code that lasts the kind that doesn't require deletion six months later because nobody understands it. Cloud & DevOps AWS, GCP, Terraform, CI/CD pipelines; I've migrated monoliths to microservices, scaled platforms to handle millions of transactions, and built infrastructure that teams can actually maintain. Selected Experience CTO; Snowball Money (2021–2024) Led development of a multi-chain crypto wallet supporting swaps, staking, and DeFi bundles across five major blockchains. Built and scaled the engineering team while... --- - Published: 2018-08-26 - Modified: 2018-08-26 - URL: https://www.ivanturkovic.com/sample-page/ This is an example page. It's different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this: Hi there! I'm a bike messenger by day, aspiring actor by night, and this is my website. I live in Los Angeles, have a great dog named Jack, and I like piña coladas. (And gettin' caught in the rain. ) ... or something like this: The XYZ Doohickey Company was founded in 1971, and has been providing quality doohickeys to the public ever since. Located in Gotham City, XYZ employs over 2,000 people and does all kinds of awesome things for the Gotham community. As a new WordPress user, you should go to your dashboard to delete this page and create new pages for your content. Have fun! --- - Published: 2018-08-26 - Modified: 2026-03-02 - URL: https://www.ivanturkovic.com/privacy-policy/ Last updated: 10th December, 2025 This privacy policy explains how ivanturkovic. com collects, uses, and protects your personal data. I take your privacy seriously and comply with the EU General Data Protection Regulation (GDPR). Who I Am This site is operated by Ivan Turkovic. You can contact me at any time through ivanturkovic. com/contact with any questions about this policy or your data. What Data I Collect Newsletter subscription: If you subscribe to my newsletter, I collect your email address. That is the only personal information I ask for. I use this to send you new blog posts and occasional updates. Nothing else. Comments: If you leave a comment on a blog post, I collect your name, email address, and the comment itself. Your email is never displayed publicly. Comments may be checked through the Akismet anti-spam service, which may store your IP address and browser user agent string. Server logs: Like most websites, my hosting provider automatically collects technical data when you visit. This includes your IP address, browser type, referring page, and time of visit. This data is used for security and performance monitoring only. Cookies: WordPress sets functional cookies required for the site to work properly. If you leave a comment, cookies may store your name and email so you do not have to re-enter them. The Newsletter plugin may set a cookie to remember whether you are already subscribed. No tracking or advertising cookies are used on this site. Why I Collect This Data I collect... --- - Published: 2012-11-09 - Modified: 2012-11-09 - URL: https://www.ivanturkovic.com/blog-posts/ Blog - Signal Through the Noise Skip to content Signal Through the Noise Honest takes on code, AI, and what actually works Menu Home Hire Me How I work Experience Services Contacts My Story AI Job Title Reference Guide Menu Blog Leave a Reply Cancel replyYou must be logged in to post a comment. This site uses Akismet to reduce spam. Learn how your comment data is processed. Ivan Turkovic Let's talk Got something to build or fix? Hiring, architecture, a product you want a second opinion on, or a project that needs a senior hand. If you're stuck or just want to think out loud, book a call. No pitch, no pressure. Schedule a 30-minute call Free. Honest answer guaranteed, even if it's "you don't need me." Recent Posts Everyone Is an “Engineer” Now, and Nobody Knows What Anyone Does The Engineering Age That’s Ending, and the One We Haven’t Named Yet Open Source Security Is Everyone’s Problem Now Vibing Fatigue: Why Tracking AI Usage Is the Wrong KPI Almost Solved Is the Most Dangerous Phase in Engineering Search for: TOP 3% TALENT Vetted by Hire me PhoneGap Essentials by Ivan Turkovic Instagram Facebook GitHub LinkedIn Recent CommentsAI Job Titles in 2026: A CTO's Guide to the Naming Chaos on Contact MeThe Engineering Age That's Ending, and the One Starting on Contact MeOpen Source Security Is Everyone's Problem Now on Contact MeVibing Fatigue: Why Tracking AI Usage Is the Wrong KPI on Contact MeAlmost Solved Is the Most Dangerous... --- - Published: 2010-12-01 - Modified: 2026-01-07 - URL: https://www.ivanturkovic.com/contact/ Currently Available for Hire You can contact me on the following addresses Email: ivan. turkovic@gmail. com Skype: ithora Google+: https://plus. google. com/u/0/+IvanTurkovic Facebook: http://www. facebook. com/ivanturkovic Twitter: http://www. twitter. com/ithora LinkedIn: http://www. linkedin. com/in/ivanturkovic OR Send contact inquiry directly ← BackThank you for your response. Name(required) Email(required) Website Comment(required) Submit Δ --- - Published: 2010-07-30 - Modified: 2025-12-29 - URL: https://www.ivanturkovic.com/about-ivan-turkovic/ I Help Companies Ship Products That Actually Work Over 20 years, I've built platforms that serve millions of users, led engineering teams through critical pivots, and turned ambitious ideas into production systems. I'm the technical partner you bring in when shipping fast matters, but shipping broken doesn't. What I actually do: I help startups and established companies build AI-powered products, modernize legacy systems, and make technical decisions that won't come back to haunt you in six months. What Sets Me Apart I write the code and run the teams. I'm not a consultant who hands you a deck and disappears. I'm hands-on with architecture, implementation, and the messy reality of getting software into production. Whether you need a technical co-founder, a fractional CTO, or someone to unfuck your current architecture, I can do all three. I've been through the full cycle. Founded startups. Scaled them. Watched them fail. Learned why. Built the next one better. I know what works in theory versus what works when your database is on fire at 3 AM. I speak business and code fluently. I can translate between your board's concerns and your engineering team's constraints. I've pitched to investors, closed enterprise deals, and debugged production issues, often in the same week. How I Can Help You Right Now If You're a Founder or Executive: AI Strategy & Implementation - Not the hype. The actual integration of LLMs, vector databases, and ML pipelines into products people will pay for. I've shipped AI features that increased... --- --- ## Posts - Published: 2026-04-24 - Modified: 2026-04-24 - URL: https://www.ivanturkovic.com/2026/04/24/ai-job-titles-2026-naming-chaos/ - Categories: AI, AI development, AI software engineering, AI-Driven Development - Tags: ai, AI Engineer, Context Engineer, CTO, Forward-Deployed Engineer, hiring, HR, job titles, LLM Engineer A CTO's field guide to the 2026 AI job title theater, with a companion reference guide covering all 40 roles. I have been a CTO for most of my adult life. I have hired, fired, onboarded, mentored, and occasionally been forced to explain to finance why a "Senior Applied Generative AI Engineer II" and a "Staff LLM Engineer" should sit in the same comp band. What I can tell you, after twenty years in this circus, is that the AI job title situation in 2026 is the worst naming disaster the industry has produced since we decided "DevOps" was a person rather than a practice. Let me give you the tour. In a single week last month I saw open roles for: AI Engineer, Applied AI Engineer, AI Software Engineer, Generative AI Engineer, GenAI Engineer, LLM Engineer, Prompt Engineer, Context Engineer, Agent Engineer, Agentic AI Engineer, RAG Engineer, AI Systems Engineer, AI Platform Engineer, AI Infrastructure Engineer, AI Reliability Engineer, Model Deployment Engineer, LLMOps Engineer, AI Ops Engineer, AIOps Engineer, AI Evaluator, Evals Engineer, AI Red Teamer, AI Alignment Engineer, AI Safety Engineer, Model Behavior Engineer, AI Trainer, Forward-Deployed Engineer, AI Solutions Architect, AI Product Manager, AI Strategist, Chief AI Officer, Head of AI, AI-Native Developer, AI-Augmented Engineer, and my personal favorite, "Builder. " Boris Cherny from Anthropic actually predicted on Lenny's Podcast that the title "software engineer" would disappear and be replaced by "builder," because calling it a quarter to noon on Wednesday clearly wasn't stupid enough. Here is... --- - Published: 2026-04-18 - Modified: 2026-04-24 - URL: https://www.ivanturkovic.com/2026/04/18/engineering-age-ending-ai-software-future/ - Categories: AI, AI development - Tags: AI coding, AI in programming, engineering career, future of software engineering, junior developers, software engineering 2030, spec-driven development The best engineers I know write less code than they did two years ago. They ship more. Everyone wants the clean story. AI replaces developers. AI makes developers 10x. Juniors are cooked. Juniors are saved. Pick a side. The reality is messier. Big Tech new grad hires dropped to 7% of all new hires, down from 25% in 2023. Computer engineering graduates now have the second-highest unemployment rate of any US major. Higher than philosophy. Only physics is worse. Then Klarna replaced 700 agents with AI in 2024 and reversed in 2025. Duolingo went "AI-first" in April 2025 and walked it all the way back in April 2026. Netflix hired a junior engineer last year for the first time in 25 years. OpenAI and Anthropic are hiring juniors for the first time ever. Both things are true. The old junior role is dying. A new one is forming. The next three years The bottom of the pyramid does not come back. Writing syntax, basic CRUD, standard integrations, these are prompts now, not jobs. But the middle gets squeezed hardest. The mid-level engineer whose main value was translating a ticket into working code has the weakest position in the industry. That translation layer is what the models eat first. Companies that killed their apprenticeship pipeline will spend these three years paying the bill. Code review debt. Architectural drift. Nobody under 35 who understands why the system looks the way it looks. The next five years By 2030 the word "programmer" will... --- - Published: 2026-04-14 - Modified: 2026-04-14 - URL: https://www.ivanturkovic.com/2026/04/14/open-source-security-axios-attack/ - Categories: javascript, Open Source, python, ruby, Security - Tags: attack, axios, code quality, development, javascript, python, ruby, security, software engineering, typescript Two weeks ago, a North Korean state actor compromised the lead maintainer of Axios and published malicious versions to npm. The library has roughly 100 million weekly downloads. The poisoned packages were live for about three hours before anyone noticed. Three hours. That is all it took to potentially compromise tens of thousands of development environments worldwide. The attacker did not find a bug in the code. They targeted the person. Social engineering, a compromised machine, stolen npm credentials. The malicious versions looked identical to legitimate releases. No code review would have caught it because the code never went through the project's CI/CD pipeline at all. This is the reality of open source security in 2026. The most popular packages in the world are maintained by small teams. Sometimes a single person. And that single person is now a target for nation-state attackers. We need to talk about what we can actually do about this. Independent release validators. Open source projects should introduce a validation layer. A small group of trusted reviewers, separate from the core contributors, whose only job is to confirm that a release contains no external risk before it goes live. Versions could ship with a "validated" flag so consumers can decide whether to accept unvalidated releases. For the most critical packages, those first few hours after a new version drops are exactly when the risk is highest. A validation gate would buy time. Hardware-based signing keys. Contributors on high-impact projects should self-enforce the use of hardware... --- - Published: 2026-04-11 - Modified: 2026-04-11 - URL: https://www.ivanturkovic.com/2026/04/11/vibing-fatigue/ - Categories: AI, Software Engineering - Tags: ai, cognitive load, developer experience, Engineering Management, productivity, vibing fatigue A developer I know got pulled into a "productivity review" last month. Not because their output dropped. Because their AI tool usage was below the team average. Their manager wanted to know why they weren't using AI for coding enough. Not why their code had fewer bugs. Not why their PRs moved through review faster. Why the dashboard said they weren't vibing with AI hard enough. This is where we are now. They even have a leaderboard in the company and the leader spent $52k in tokens last month. The metric that measures nothing Large companies love measurable adoption. They spent millions on AI tooling licenses. Somebody has to justify that spend. So they started tracking prompts per day, acceptance rates, lines generated. Some even built internal dashboards that rank teams by AI usage. The assumption is simple: more AI usage equals more productivity. If a developer writes 60% of their code with AI assistance, they must be 60% more productive. Right? Wrong. Completely wrong. Writing code was never the bottleneck. Not in any company I've worked with over the past twenty years. The bottleneck was always everything around the code. Meetings. Standups. Sprint planning. Backlog grooming. Architecture reviews. Stakeholder calls. Status reports. Slack threads that could have been a sentence. Follow-up meetings about the meeting you just had. In most large organizations, a developer is lucky to get three to four hours of actual coding time per day. Some get less. The rest is process. Necessary process, sometimes. Bureaucratic... --- - Published: 2026-03-31 - Modified: 2026-03-31 - URL: https://www.ivanturkovic.com/2026/03/31/ai-coding-almost-solved-most-dangerous-phase/ - Categories: AI, AI development, AI-Driven Development, Artificial Intelligence - Tags: AI agent swarms coordination, AI code review problem, AI coding tools productivity, AI software development challenges, developer productivity AI tools, technical debt AI, vibe coding limitations Everyone agrees AI is transforming how we write code. Adoption is through the roof, productivity metrics look promising, and a growing chorus of voices insists we are months away from this whole thing being "solved." They are probably wrong. Not because AI is bad, but because "almost solved" is the most dangerous phase in any engineering problem. There is a growing conviction in the software industry that building software with AI is essentially a solved problem. Or if it is not solved today, it will be within a year. The reasoning goes something like this: a dwindling minority of naysayers at large, slow-moving companies are pretending AI is still bad, while a rapidly growing majority is adopting AI tools daily and actively improving their setups. The good ideas are sticking. The bad ones are fading. Momentum is undeniable. And the momentum part is true. It really is. According to Stack Overflow's 2025 Developer Survey, 84% of developers now use or plan to use AI tools in their development process, up from 76% the year before. Over half of professional developers use AI tools daily. GitHub Copilot alone has surpassed 20 million cumulative users. Reports suggest that around 42% of all committed code is now AI-assisted. By any adoption metric, this technology has crossed the threshold from experimental to standard practice. But here is where the narrative cracks. While adoption has surged, developer trust has moved in the opposite direction. In 2023 and 2024, over 70% of developers had a favorable view of AI tools. By 2025, that number dropped to 60%. Nearly half of developers now say they do not trust the accuracy of AI output, and only 3% report high trust. Among experienced developers, the skepticism is even sharper, with the lowest trust and highest distrust rates of any cohort. This is not a story about... --- - Published: 2026-03-24 - Modified: 2026-03-24 - URL: https://www.ivanturkovic.com/2026/03/24/complexity-never-eliminated-only-relocated/ - Categories: AI development, AI-Driven Development, Artificial Intelligence, Behavior-Driven Development, Code Review, Software Development, Software Engineering, Software Testing, Uncategorized - Tags: abstraction layers complexity, AI code verification, AI generated code audit, code review AI era, complexity conservation law, essential complexity software, Fred Brooks no silver bullet, Tesler's Law complexity, verification debt COBOL moved complexity from machine instructions to business logic specification. 4GLs moved it from code to data modeling. No-code moved it from programming to workflow configuration. LLMs are moving it from syntax to verification. The complexity never disappeared. It accumulated at the new boundary. And the new boundary is arguably harder than the old one. When I published The Eternal Promise, tracing sixty years of attempts to eliminate programmers from COBOL through to today's AI coding tools, the post resonated far beyond what I expected. It reached the front page of Hacker News and generated hundreds of comments from engineers who recognized the pattern in their own careers. But one response in particular stopped me. A commenter articulated something I had been circling for years without ever naming precisely: Each abstraction layer does not eliminate complexity. It relocates it. That single sentence reframes the entire history of software development. It explains why every wave of "simplification" creates new specialists instead of eliminating old ones. It explains why AI-assisted coding feels simultaneously easier and harder. And it points to the most important, and most undervalued, skill in modern software engineering. The Conservation Law of Software In 1986, Fred Brooks published "No Silver Bullet," arguing that software development contains two kinds of complexity: essential and accidental. Essential complexity comes from the problem itself. If your banking system needs to handle thirty different regulatory requirements, that complexity must live somewhere in your software. Accidental complexity comes from the tools and implementation choices we make along the way. Brooks argued that most of the easy gains had already been captured by reducing accidental complexity through better languages, better tools, and better practices. The essential complexity, the hard part, remained stubbornly resistant to any single technological breakthrough. There would be no silver bullet. What Brooks described conceptually, Larry Tesler formalized... --- - Published: 2026-03-18 - Modified: 2026-03-18 - URL: https://www.ivanturkovic.com/2026/03/18/done-is-not-merge/ - Categories: Software Engineering - Tags: CI/CD, Definition of Done, deployment, DevOps, DORA Metrics, engineering culture, Production, Quality Assurance, Software Delivery, software engineering The most dangerous lie in software engineering is a two-word status update: "It's done. " In most teams, done means the pull request was merged. The CI pipeline turned green. The ticket moved to the right column on the board. Someone wrote "Done" in Slack, maybe with a checkmark emoji for extra confidence. And then everyone moved on to the next thing. But merging code into a main branch is not shipping software. It is the beginning of a process that too many teams treat as the end. And this confusion, this quiet redefinition of what "done" means, is responsible for more production incidents, more midnight pages, more customer trust erosion, and more burned-out engineers than almost any other cultural failure in our industry. Done is not merge. Done is tested, deployed, and stable in production. That distinction sounds simple. It is not. Getting it right requires rethinking how teams work, what they measure, what they reward, and what they are willing to slow down for. Let me explain why. The Merge Illusion There is a specific moment in the software development lifecycle that feels like completion but is not. It is the moment a pull request gets approved, the last comment is resolved, the branch merges cleanly, and the CI checks pass. There is even a satisfying visual cue: the merge button turns green, the branch disappears, and the commit lands in main. Psychologically, this feels like closure. The problem is solved. The feature is built. The work is... --- - Published: 2026-03-06 - Modified: 2026-03-06 - URL: https://www.ivanturkovic.com/2026/03/06/ai-made-learning-feel-pointless/ - Categories: AI, Software Engineering - Tags: ai, career, developer mindset, learning, software engineering A week ago my blog post got noticed by developers. I got so many messages and there was a recurring theme. They feel helpless and anxious with the ever growing AI dominance in writing code that might not be perfect but it is almost good enough in many cases. But one question stood out more than others. "What's the point? " of continuing to practice and learn the skills. As we know most engineers pride themselves in their work. In their free time they spend reading tech books, attend meetups. It is not just a job for them, it is their lifestyle. Almost a purpose of living. I didn't have a real answer until today and I will try to write it. Twenty years. I spent more than that since I got my first real work as a developer. I picked up and forgotten countless programming languages until I settled on a few that I still use to this day. New shiny frameworks that felt so futuristic yet so many are forgotten right now and only a few developers are still left maintaining the legacy code that used them. There were some paradigms that rewired how my brain works and writes code and until this day I use them. Some of it mattered. Some of it was just restlessness. Hard to tell which was which at the time. Now AI writes the code. Good code. Not always great, but good enough in many cases and getting better faster than most... --- - Published: 2026-03-01 - Modified: 2026-03-12 - URL: https://www.ivanturkovic.com/2026/03/01/training-data-paradox-ai-replacing-engineers-who-trained-it/ - Categories: AI, Critical Thinking, Software Engineering - Tags: ai, junior developers, knowledge management, model collapse, Software Development, Stack Overflow, synthetic data, training data There is a question hiding in plain sight behind every celebration of AI-generated code, every prediction that developers are obsolete, every LinkedIn post about building an app 100x faster with a prompt. It is a question that almost nobody in the current hype cycle is asking, and it may be the most important question of all. Where did the AI learn to write that code? The answer is straightforward: from decades of human engineering work. From millions of Stack Overflow answers written by developers who spent hours debugging real problems. From open source repositories maintained by people who understood not just syntax, but architecture, tradeoffs, and the messy realities of production systems. From technical documentation, conference talks, blog posts, and code reviews, all produced by human beings who earned their knowledge through years of practice. Now consider what is happening simultaneously. Stack Overflow's monthly question volume has collapsed from over 200,000 at its peak in 2014 to fewer than 4,000 by December 2025, a 78% drop from the previous year alone. Junior developer hiring has plummeted by 67% since 2022. A Harvard study tracking 62 million workers across 285,000 U. S. firms found that junior employment drops 9 to 10 percent within six quarters of companies adopting generative AI, while senior employment barely changes. Computer science graduates now face 6. 1% unemployment, nearly double the national average. Meanwhile, over 74% of newly published web pages contain detectable AI-generated content. Researchers estimate that more than half of all new English-language articles... --- - Published: 2026-02-25 - Modified: 2026-03-12 - URL: https://www.ivanturkovic.com/2026/02/25/ai-made-writing-code-easier-engineering-harder/ - Categories: Artificial Intelligence, Career Development, Software Development - Tags: ai, AI Tools, career development, code review, developer burnout, developer experience, engineering culture, engineering leadership, junior developers, productivity paradox, role expansion, software engineering, Technical Leadership, workload creep Yes, writing code is easier than ever. AI assistants autocomplete your functions. Agents scaffold entire features. You can describe what you want in plain English and watch working code appear in seconds. The barrier to producing code has never been lower. And yet, the day-to-day life of software engineers has gotten more complex, more demanding, and more exhausting than it was two years ago. This is not a contradiction. It is the reality of what happens when an industry adopts a powerful new tool without pausing to consider the second-order effects on the people using it. If you are a software engineer reading this and feeling like your job quietly became harder while everyone around you celebrates how easy everything is now, you are not imagining things. The job changed. The expectations changed. And nobody sent a memo. The Baseline Moved and Nobody Told You There is a phenomenon happening right now that most engineers feel but struggle to articulate. The expected output of a software engineer in 2026 is dramatically higher than it was in 2023. Not because anyone held a meeting and announced new targets. Not because your manager sat you down and explained the new rules. The baseline just moved. It moved because AI tools made certain tasks faster. And when tasks become faster, the assumption follows immediately: you should be doing more. Not in the future. Now. A February 2026 study published in Harvard Business Review tracked 200 employees at a U. S. tech company over... --- - Published: 2026-02-24 - Modified: 2026-02-23 - URL: https://www.ivanturkovic.com/2026/02/24/first-1000-lines-determine-next-100000-ai-coding/ - Categories: AI development, AI-Driven Development, Artificial Intelligence, Software Development - Tags: AI coding, claude code, CLAUDE.md, code architecture, code quality, coding agents, greenfield projects, software engineering, software foundations, technical debt, Vibe Coding I learned this the hard way while working with Claude Code. AI looks at your existing code and copies the patterns it finds. If you start with clean code, the rest stays clean. If you start messy, the problems pile up faster than any human team could create them. And unlike a junior developer who might occasionally question a strange pattern, AI agents replicate what they see with perfect consistency and zero judgment. This is the lesson that most conversations about AI-assisted development completely miss. Everyone is talking about which model is smarter, which agent writes faster code, which IDE integration has the best autocomplete. Almost nobody is talking about the thing that actually determines whether AI makes your codebase better or destroys it: the quality of the code that already exists when the AI starts working. The first 1,000 lines of code determine the next 100,000. And in the age of AI coding agents, that statement has never been more literally true. AI Is an In-Context Learner, Not a Standards Enforcer To understand why foundations matter so much in AI-assisted development, you need to understand a fundamental truth about how these tools work. AI coding agents are in-context learners. They do not arrive with an opinionated stance on how your code should be structured. They arrive, scan your codebase, identify the patterns you have established, and then replicate those patterns as faithfully as they can. This is both their greatest strength and their most dangerous quality. When Claude Code... --- - Published: 2026-02-23 - Modified: 2026-02-23 - URL: https://www.ivanturkovic.com/2026/02/23/webmcp-tutorial-make-website-agent-ready/ - Categories: AI development, AI-Driven Development, WebMCP - Tags: Agentic Web, AI Agents, Chrome 146, javascript, MCP, Model Context Protocol, navigator.modelContext, React, ruby on rails, Tutorial, W3C, Web Standards, WebMCP In my previous post on WebMCP, I covered what WebMCP is and why it matters. The response told me something important: developers do not want another think piece about the future of the web. They want to know how to actually build with it. So this is the practical companion. No philosophy. No speculation about whether this will matter. Just code, setup instructions, and patterns you can apply to a real website today. The W3C specification was updated on February 12, 2026. Chrome 146 ships with a working DevTrial behind a feature flag. The MCP-B polyfill provides navigator. modelContext for browsers that do not support it natively yet. There are already framework integrations for React, vanilla JavaScript, and Ruby on Rails. The tooling is real, the documentation is solid, and there are working reference implementations you can study. Here is everything you need to make your website agent-ready. Setting Up Your Environment Before writing any WebMCP code, you need a browser that supports it. Right now, that means Chrome 146 with a feature flag enabled. Open Chrome 146 (Canary or later). Navigate to chrome://flags. Search for "Experimental Web Platform features" or "WebMCP for testing. " Enable the flag and relaunch Chrome. That is it. Your browser now understands the navigator. modelContext API. For testing and debugging, install the Model Context Tool Inspector extension from the Chrome Web Store. This extension lets you view all registered tools on any page, test tool invocations manually, validate schemas, and monitor agent calls in... --- - Published: 2026-02-22 - Modified: 2026-02-20 - URL: https://www.ivanturkovic.com/2026/02/22/coding-changing-software-engineering-not-obsolete/ - Categories: ADD Methodology, AI development, AI-Driven Development, Quality Assurance - Tags: agentic engineering, AI coding tools, AI replace engineers, Anthropic, career advice, coding vs engineering, CTO perspective, Dario Amodei, future of software engineering, software architecture, software engineering At the World Economic Forum in Davos on January 20, 2026, Anthropic CEO Dario Amodei said something that landed like a grenade across the technology industry. In an interview with The Economist, he claimed that AI models could do "most, maybe all" of what software engineers currently do within six to twelve months. He pointed to engineers at Anthropic who told him they no longer write code from scratch at all. "I just let the model write the code, I edit it," he said they told him. The reaction was immediate and predictably polarized. Panic in developer forums. Dismissal from senior engineers. Viral posts alternating between "we're cooked" and "he's wrong and here's why. " Zoho founder Sridhar Vembu went further than Amodei, publicly advising software developers to begin considering alternative livelihoods. Elon Musk posted about building an AI-based software competitor to Microsoft. The discourse reached the kind of intensity that guarantees more heat than light. I want to offer a different reading of this moment. Not a dismissal of what Amodei said, and not a panic-driven response to a headline that almost certainly oversimplifies what he actually meant. A careful, honest look at what is actually changing, what is not, and what this shift means for the engineers, architects, and technical leaders navigating it in real time. Because I think Amodei is right about something important, and importantly wrong about something else. And the distinction between those two things matters enormously for how software engineers should be thinking about... --- - Published: 2026-02-21 - Modified: 2026-02-20 - URL: https://www.ivanturkovic.com/2026/02/21/build-it-yourself-trap-ai-tooling-vs-core-product/ - Categories: AI development, AI-Driven Development, Artificial Intelligence, Best Practices, Requirements - Tags: AI coding tools, build vs buy, core product opportunity cost, CTO perspective, engineering leadership, engineering strategy, product roadmap, SaaS, software architecture, total cost of ownership, Vibe Coding A new kind of logic is spreading through developer communities, startup circles, and engineering Slack channels. It goes something like this: why pay a monthly subscription for software someone else built when you now have access to AI coding assistants powerful enough to help you build it yourself? The reasoning sounds compelling on the surface. The economics look attractive in a spreadsheet that has not been filled in all the way. And the energy behind it is real, driven by genuine breakthroughs in what AI tools can do. But there is a significant gap between what AI coding tools make possible and what they make wise. And in my experience building and operating real systems across fintech, blockchain, and high-traffic platforms over the past two decades, I have seen this exact pattern before, dressed in different clothing. This post is not a defense of every SaaS product that has ever existed. Many deserve to be replaced. Some are overpriced, underbuilt, and held together by aggressive pricing locked behind annual contracts. But the current wave of enthusiasm for building everything yourself, powered by AI assistants and a three-weekend sprint, deserves serious scrutiny before engineering teams and founders stake their infrastructure on it. How a Reasonable Idea Becomes an Expensive Distraction The sequence tends to follow a recognizable pattern. It starts with a legitimate grievance. A SaaS tool your team has been using raises its prices. Or adds a feature behind a higher tier that you need. Or the product has simply... --- - Published: 2026-02-20 - Modified: 2026-02-16 - URL: https://www.ivanturkovic.com/2026/02/20/when-add-is-wrong-recognizing-limits/ - Categories: ADD Methodology, AI-Driven Development, Best Practices, Critical Thinking - Tags: ADD methodology limits, AI coding limitations, AI development wrong approach, when not to use AI coding Every methodology has boundaries. Waterfall fails when requirements change frequently. Agile struggles with fixed-scope contracts. TDD is awkward for exploratory prototyping. No approach works everywhere, and pretending otherwise leads to poor outcomes. ADD is no exception. There are tasks where AI-Driven Development is not the right approach. Recognizing these situations is a skill that separates effective practitioners from those who try to force every problem into the same solution. This post is an honest assessment of where ADD falls short and when you should step away from AI assistance and write code yourself. Tasks Requiring Deep Innovation AI models generate code by recombining patterns from training data. They are excellent at applying known approaches to new contexts. They are not sources of genuine innovation. When you need something truly novel, AI cannot help. New algorithms, new architectural patterns, unprecedented approaches to unsolved problems. These require human creativity that AI cannot provide because the patterns do not exist in training data. Signs you need innovation, not generation: The problem has no established solution approach Existing solutions do not work and you need a fundamentally different approach You are trying to do something that has not been done before The value comes from the novelty itself, not from execution of known patterns In these situations, AI assistance can actually be counterproductive. The AI will generate something that looks like a solution but is actually a remix of approaches that do not apply. You waste time evaluating plausible but wrong suggestions instead of... --- - Published: 2026-02-19 - Modified: 2026-02-16 - URL: https://www.ivanturkovic.com/2026/02/19/software-companies-are-dead-just-nobody-told-them/ - Categories: AI-Driven Development, Career Development, Software Engineering - Tags: AI coding assistants, AI hype cycle, AI tools for developers, developers replaced by AI, future of software development, no-code replace developers, software companies dead, software development market growth Software companies are dead. Just nobody told them. Or so everyone keeps saying. LinkedIn is flooded with Claude Code hype. Cursor is "changing everything. " Every founder on your feed is screaming that developers will be redundant by Q2. The revolution is here, they say. Pack your bags. This is now the third consecutive year of this narrative. Three years of breathless predictions. Three years of "this time it is different. " And yet, software development companies still exist. Programmers still have jobs. Humans are still an essential part of every serious project. The global software development market hit $824 billion in 2025 and is projected to nearly triple to $2. 25 trillion by 2034. The developer population has grown to 47. 2 million worldwide, a 50% increase from 2022. Custom software development is expanding at over 20% compound annual growth. These are not the numbers of a dying industry. These are the numbers of an industry accelerating. So what exactly is going on with all this hype? The Pattern We Keep Forgetting If you have been in this industry long enough, the current AI hysteria feels less like a revolution and more like a rerun. The script is always the same. A new technology emerges. It generates genuine excitement. Then the hype machine takes over, and suddenly the technology is not just useful, it is existential. It will not just improve things, it will replace everything that came before. We have seen this show before. In the late 1980s,... --- - Published: 2026-02-18 - Modified: 2026-02-16 - URL: https://www.ivanturkovic.com/2026/02/18/add-meets-tdd-bdd-agile/ - Categories: ADD Methodology, AI-Driven Development, Behavior-Driven Development - Tags: ADD methodology integration, Agile AI development, behavior-driven development AI, combining development methodologies, test-driven development AI ADD is not a replacement for existing development methodologies. It is a complement to them. Teams already practicing Test-Driven Development, Behavior-Driven Development, or Agile workflows have a head start with ADD because these methodologies share underlying principles with AI-Driven Development. This post explores how ADD integrates with each methodology and how the combinations create practices stronger than any single approach. ADD and Test-Driven Development Test-Driven Development follows a simple cycle: write a failing test, write code to make it pass, refactor. Red, green, refactor. This cycle ensures that code is always testable and that tests document expected behavior. ADD and TDD are natural partners. Tests as specification components. In pure TDD, tests serve as the specification. In ADD, tests become part of the specification you provide to the AI. "Here are the tests. Generate implementation that passes them. " The tests define behavior precisely, and the AI generates code to satisfy them. This is the Test-First Pattern from Post 8, but it is also just TDD practiced with AI assistance. The discipline remains: write the test first, then generate implementation. TDD within the Evaluate phase. After generating code, evaluation includes running tests. But ADD evaluation goes beyond test passage. Code that passes tests might still have fitness problems, security issues, or maintainability concerns. TDD provides a strong foundation for the Correctness dimension of evaluation while ADD's broader evaluation covers dimensions that TDD does not address. Red-Green-Refactor meets Specify-Generate-Evaluate-Integrate. The cycles nest. Within a single ADD cycle, you might have multiple... --- - Published: 2026-02-16 - Modified: 2026-02-16 - URL: https://www.ivanturkovic.com/2026/02/16/add-in-context-greenfield-legacy-refactoring/ - Categories: ADD Methodology, AI-Driven Development, Legacy Code, Refactoring, Software Engineering - Tags: ADD methodology applications, AI greenfield development, AI legacy code, AI refactoring, AI test generation The ADD cycle is consistent across contexts: Specify, Generate, Evaluate, Integrate. But how you apply each phase changes depending on what you are building and where you are building it. Greenfield projects offer freedom that legacy codebases do not. Refactoring has constraints that new feature development lacks. Test generation inverts the typical flow. This post covers how ADD adapts to different development contexts. The cycle remains the same, but the emphasis shifts. ADD for Greenfield Projects Greenfield projects offer maximum flexibility. There is no existing code to constrain your choices, no legacy patterns to follow, no technical debt to navigate. This freedom is valuable, but it comes with responsibility. Establish patterns early. The first components you build become exemplars for everything that follows. If you generate a sloppy API endpoint early, that sloppiness propagates when you use it as an exemplar for subsequent endpoints. Invest extra time in the Specify and Evaluate phases for your first few generations. Get the patterns right, and the AI will replicate them. Get them wrong, and you will replicate the problems. Build your context library as you go. In greenfield development, you do not have existing code to provide context. But after your first few ADD cycles, you do. Extract the patterns that work. Document the conventions you establish. Build the context library that will guide future generations. The earlier you start, the more consistent your codebase becomes. Specify architectural decisions explicitly. The AI does not know your architectural intentions unless you state them.... --- - Published: 2026-02-15 - Modified: 2026-02-12 - URL: https://www.ivanturkovic.com/2026/02/15/webmcp-is-coming-how-ai-agents-will-reshape-the-web/ - Categories: Uncategorized On February 10, 2026, the Chrome team quietly published a blog post announcing something called WebMCP. It was framed as an "early preview," tucked behind a feature flag in Chrome 146. If you blinked, you missed it. But if you understand what it actually does, you realize it might be the most consequential browser feature since the introduction of JavaScript itself. WebMCP stands for Web Model Context Protocol. It is a proposed W3C web standard, co-authored by engineers from Microsoft and Google, that lets websites expose structured tools directly to AI agents. Instead of agents scraping your DOM, clicking buttons, or guessing how your forms work, your site explicitly tells them: here is what I can do, here is how to invoke it, and here is what I need from you. That might sound incremental. It is not. WebMCP is the first serious attempt to build a parallel interface layer for the web, one designed not for humans, but for machines. And if you are a developer, a CTO, or anyone who builds products that live on the internet, the implications of this shift deserve your full attention. Two Internets Are Emerging For thirty years, the web has had one audience: people. Every design decision, every UX pattern, every pixel on every page was optimized for human eyes and human hands. Navigation menus exist because humans need visual wayfinding. Buttons are styled to look clickable because humans need affordances. Forms have labels and placeholders because humans need instructions. AI agents... --- - Published: 2026-02-14 - Modified: 2026-02-12 - URL: https://www.ivanturkovic.com/2026/02/14/average-people-will-not-build-software-with-ai/ - Categories: AI development, Software Development, Software Engineering - Tags: ai, AI Tools, No-Code, Product Thinking, software architecture, Software Development, Software Maintenance, Vibe Coding There is a narrative gaining traction in tech circles, on social media, and in breathless conference keynotes that goes something like this: AI will soon let anyone build their own software. Need a budgeting app? Just describe it to an AI and it will create one for you. Want a custom CRM for your small business? A few prompts and you are up and running. Personal software, built on demand, by anyone, for anything. It sounds revolutionary. It also fundamentally misunderstands what software actually is. I have spent more than twenty years building, deploying, and maintaining production software across fintech, blockchain, and high-traffic platforms. What I have learned in that time is that writing code has never been the hardest part of software development. It is everything else. And that everything else is precisely what this "everyone can build software" narrative conveniently ignores. The Seductive Simplicity of the Demo If you have watched any AI coding demonstration in the last two years, you have seen something genuinely impressive. Someone types a natural language prompt, and within seconds, working code appears. A to-do app. A landing page. A simple game. The audience gasps. Twitter threads go viral. The conclusion seems obvious: if AI can build a working app in sixty seconds, why would anyone pay a developer? But this is the demo trap. Demos are designed to show the best possible outcome in the most controlled possible environment. They work because the problem is well-defined, the scope is tiny, the requirements... --- - Published: 2026-02-13 - Modified: 2026-02-12 - URL: https://www.ivanturkovic.com/2026/02/13/full-time-cto-vs-fractional-the-real-math-nobody-shows-youthe-math-on-hiring-a-full-time-cto-and-why-it-rarely-adds-up/ - Categories: Uncategorized Every startup founder eventually faces the same inflection point. The product is gaining traction. Technical decisions are getting more complex. Investors are asking who's driving the technology strategy. The board wants a name next to the CTO title. And so the search begins for the person who will own the technical vision, build the engineering team, and make the architectural decisions that will define the company's trajectory for years to come. It sounds like a straightforward hire. Find someone brilliant, give them the title, and let them build. But the reality of hiring a full-time Chief Technology Officer in the US market is a story written in hidden costs, extended timelines, misaligned incentives, and opportunity losses that most founders don't fully appreciate until they're deep into the process. Let's do what surprisingly few founders do before launching this search. Let's actually run the numbers. The Sticker Price That Isn't the Real Price When founders think about hiring a CTO, they usually start with the salary. In the US market, particularly in major tech hubs like San Francisco, New York, Austin, or Seattle, a qualified CTO with the experience to lead a growing startup commands a base salary in the range of $300,000 to $400,000. Let's use $325,000 as a reasonable midpoint for a Series A or Series B company that needs real technical leadership but isn't yet at the scale of a public company. That number alone should give any founder pause. But it's just the beginning. Employer payroll taxes... --- - Published: 2026-02-12 - Modified: 2026-02-12 - URL: https://www.ivanturkovic.com/2026/02/12/architect-or-extinct-software-developers-must-evolve/ - Categories: Artificial Intelligence, Career Development, Software Engineering - Tags: AI Agents, AI coding, career evolution, Developer Career, engineering leadership, future of programming, software architecture, software design A house architect does not lay bricks. They do not mix concrete, install plumbing, or wire electrical panels. They design the building. They decide how spaces connect, where light enters, how loads distribute, and how the structure will age over decades of use. The actual construction is performed by skilled tradespeople following the architect's plans. Nobody considers this arrangement strange. Nobody argues that architects should spend their days on scaffolding to prove they understand buildings. The profession evolved past that point generations ago. Software development is approaching the same inflection point. And most developers are not ready for it. For decades, the value of a software developer was measured largely by their ability to write code. How fast they could implement features. How fluently they navigated a framework. How many lines they could produce in a sprint. The implementation itself was the bottleneck, and the people who could push through that bottleneck fastest were the most valuable. That equation is changing fundamentally, and the developers who don't recognize the shift will find themselves in the same position as the stonemason who refused to acknowledge that architects had taken over building design. The Architect Analogy Is Not Hypothetical Consider how the construction industry actually evolved. In ancient times, the person who designed a building was often the same person who built it. Master builders directed construction while participating in the physical work. Over centuries, as structures became more complex and the science of materials, load bearing, and environmental factors advanced, a... --- - Published: 2026-02-11 - Modified: 2026-02-10 - URL: https://www.ivanturkovic.com/2026/02/11/integrate-completing-add-cycle/ - Categories: ADD Methodology, AI-Driven Development, Code Integration, Software Engineering, Software Testing - Tags: ADD Methodology, AI-driven development cycle, code integration best practices, integrate AI generated code, software integration testing Code that passes evaluation is ready for integration. This is the final phase of the ADD cycle, where generated code becomes part of your system. But integration is more than merging a pull request. It is where AI-generated code meets the full reality of your codebase, your testing infrastructure, your deployment pipeline, and your team's practices. Integration also closes a feedback loop. What you learn during integration informs your next specification. The cycle continues, each iteration building on the lessons of the previous one. What Happens After Code Passes Evaluation Evaluation answers the question: "Is this code correct and appropriate? " Integration answers a different question: "Does this code work within the system? " These questions are related but not identical. Code can be correct in isolation and still fail in context. It can pass evaluation and still break when it encounters real data, real load, or real edge cases that neither you nor the AI anticipated. The Integrate phase has five components: testing, documentation, CI/CD validation, system-level review, and technical debt tracking. Each addresses a different aspect of bringing new code into an existing system. Testing AI-Generated Code AI-generated code requires the same testing as human-written code, but the testing focus should account for how AI tends to fail. Test the edge cases explicitly. AI models are trained on examples, and examples tend to show common cases. The happy path is usually well-handled. Edge cases are where AI-generated code most often fails. Empty inputs, maximum sizes, unusual character encodings,... --- - Published: 2026-02-10 - Modified: 2026-02-10 - URL: https://www.ivanturkovic.com/2026/02/10/evaluation-checklists-quality-gate/ - Categories: ADD Methodology, AI-Driven Development, Code Review, Quality Assurance, Software Engineering - Tags: AI code quality, AI-Driven Development, code review best practices, code review checklist, evaluation checklist template In the previous post, I covered the five dimensions of evaluating AI-generated code: correctness, fitness, security, performance, and maintainability. Understanding these dimensions is essential. But understanding is not enough. Under time pressure, even experienced developers skip evaluation steps. They focus on the dimensions they find most interesting or most familiar, and they neglect the others. When different team members evaluate code, they check different things, and nobody notices the gaps until a bug reaches production. Checklists address this problem. They transform evaluation principles into repeatable practice. They ensure that every evaluation covers the same ground, regardless of who performs it or how much time pressure exists. This post provides complete checklists you can use immediately, plus guidance on adapting them to your context and evolving them based on what you learn. Why Checklists Work for Evaluation The case for checklists comes from fields where the cost of missing something is high: aviation, surgery, construction. In these domains, professionals with decades of experience still use checklists because human memory and attention are unreliable under pressure. Software development shares these characteristics. The cost of missing a security vulnerability or a performance problem can be severe. The pressure to ship is constant. And evaluation requires checking many things in sequence, which is exactly the situation where checklists provide the most value. Checklists work because they externalize memory. You do not need to remember what to check. The checklist remembers for you. This frees cognitive resources for the actual evaluation: looking at the code,... --- - Published: 2026-02-09 - Modified: 2026-02-09 - URL: https://www.ivanturkovic.com/2026/02/09/you-dont-want-a-claude-code-guru/ - Categories: ADD Methodology, AI development, AI-Driven Development, Artificial Intelligence, Career Development, Development Methodology, Software Development, Software Engineering - Tags: AI coding tools, AI developer productivity, building software teams, claude code, engineering leadership, product vision, software architecture The job posting practically writes itself these days. "Looking for a senior developer proficient with AI coding tools. Must be comfortable using Claude Code, Cursor, or Copilot to rapidly produce production-ready code. We need someone who can 10x our output. " I have seen variations of this everywhere over the past year. Companies scrambling to find someone who can sit in front of an AI assistant and generate mountains of code every single day. The promise is irresistible: plug an AI-fluent engineer into your team and watch features materialize at unprecedented speed. But here is the uncomfortable truth that two decades of building software keeps teaching me, over and over again: that is not actually what you want. And if you think it is, you are about to learn an expensive lesson. The Bottleneck Was Never Typing Speed Think about the last project that failed or stalled at your company. Was the root cause that your developers could not write code fast enough? Almost certainly not. The project stalled because requirements were unclear. Because three departments had conflicting visions for the product. Because someone made an architectural decision in month one that created compounding technical debt by month six. Because nobody truly understood the user's actual problem, so the team built an elegant solution to the wrong question. This pattern has repeated itself across every company, every team, and every technology generation I have worked with. From early startups wrestling with monolithic architectures to fintech platforms processing millions of transactions,... --- - Published: 2026-02-06 - Modified: 2026-02-18 - URL: https://www.ivanturkovic.com/2026/02/06/honest-take-kamal-rails-deployment/ - Categories: ruby on rails - Tags: ci/ci, deployment, kamal, ruby, ruby on rails Kamal has been positioned as the answer to a question Rails developers have asked for years: how do you deploy to your own servers without the overhead of Kubernetes or the cost of a managed platform? And in many ways, it delivers. But the gap between what Kamal promises and what it actually requires in a production environment is wider than most tutorials suggest. I have been using Kamal to deploy Rails applications across multiple projects. Some of those deployments were clean and straightforward. Others turned into multi-day debugging sessions that made me question whether I should have just stayed on the platform I was migrating from. This is an honest account of both sides. The Promise: Heroku on Your Own Servers The pitch is compelling. Kamal, built by the team at 37signals, uses Docker containers and SSH to deploy your Rails application to any VPS. It handles zero-downtime deployments, rolling restarts, and SSL certificates through its built-in kamal-proxy. You write a single deploy. yml configuration file, run kamal setup, and your application is live. No Kubernetes manifests. No Terraform files. No $500/month Heroku bills for what amounts to a few Puma processes and a database. For a fresh application deployed to a clean VPS, this promise is largely kept. And that is worth acknowledging before diving into the complications. Where Kamal Genuinely Shines If you are deploying a new Rails application to a fresh server with no existing infrastructure to work around, Kamal is genuinely excellent. The initial setup... --- - Published: 2026-02-05 - Modified: 2026-02-05 - URL: https://www.ivanturkovic.com/2026/02/05/the-new-bottleneck-clarity-over-code/ - Categories: ADD Methodology, AI development, AI-Driven Development - Tags: AI coding assistants, AI-augmented development, developer productivity, implementation vs specification, letting go, specification clarity For two decades, the fastest engineers were the ones who could write code quickly. They knew the shortcuts, the patterns, the frameworks. Their fingers moved faster than their competitors. That era is ending. The new bottleneck isn't your typing speed or your syntax recall. It's your clarity. I've spent twenty years building software, leading teams, and watching the industry evolve through multiple technological shifts. I've seen developers panic over every new abstraction layer, from ORMs to cloud platforms to containerization. Each time, the prediction was the same: this will eliminate the need for real programmers. Each time, the opposite happened. The technology created demand for more sophisticated engineering, not less. But something genuinely different is happening with AI coding assistants. Not because they're replacing programmers. They're not. But because they're shifting where the bottleneck sits in the development process. And most engineers haven't adjusted yet. The Old Bottleneck: Implementation Speed Think about how software development worked before AI assistants became capable. You had a task. You understood what needed to be built. The constraint was how quickly you could translate that understanding into working code. This created a specific set of valuable skills. Typing speed mattered. Syntax fluency mattered. Knowing framework APIs by heart mattered. The developer who could write a React component from memory in three minutes had a real advantage over the one who needed to look up the lifecycle methods every time. We optimized for this bottleneck. We created snippets, templates, boilerplate generators. We memorized keyboard shortcuts.... --- - Published: 2026-02-03 - Modified: 2026-02-02 - URL: https://www.ivanturkovic.com/2026/02/03/evaluate-human-judgment-non-negotiable/ - Categories: ADD Methodology, AI, AI development, AI-Driven Development, Artificial Intelligence, Development Methodology, Uncategorized We have arrived at the phase of ADD where the most important human skill comes into play. You have written a specification. You have generated code using appropriate context and patterns. Now you must determine whether that code is actually correct. This is not a formality. AI-generated code can be syntactically correct, pass basic tests, and still be fundamentally wrong. It can implement something plausible that is not what you specified. It can handle the happy path while silently failing on edge cases. It can introduce subtle vulnerabilities that no linter or automated tool will catch. Evaluation is the quality gate that separates disciplined AI usage from hope-based development. And it requires skills that only humans bring. Why Evaluation Cannot Be Skipped or Automated Away The temptation to skip evaluation is real. You wrote a detailed specification. You used good prompt patterns. The generated code looks clean and well-structured. Why not just run the tests and move on? Because the tests themselves might be incomplete. Because "looks clean" is not the same as "is correct. " Because the AI's failure modes are subtle, not obvious. There is also a temptation to automate evaluation entirely: let the linter check style, let the tests check correctness, let static analysis check security. These tools are valuable. They catch real issues. But they check for known patterns of failure, not for the kinds of novel errors that AI can introduce. An AI might generate a function that perfectly implements a caching layer but invalidates... --- - Published: 2026-02-02 - Modified: 2026-02-02 - URL: https://www.ivanturkovic.com/2026/02/02/prompt-patterns-iteration-verification-persona/ - Categories: ADD Methodology, AI development, AI-Driven Development, Artificial Intelligence, Software Development, Software Engineering - Tags: code quality, development, leader, software engineering In the previous post, I introduced three foundational prompt patterns: Decomposition for breaking complex tasks into manageable units, Exemplar for teaching by example, and Constraint for defining boundaries. These patterns address the most common generation challenges. This post completes the catalog with three more patterns, then addresses the practical question of building and maintaining a pattern library for your team. The Iterative Refinement Pattern When to use: The task is complex enough that first-attempt output is unlikely to be complete or correct, but the general direction is likely to be useful. You want to build toward a solution through structured conversation rather than hoping for perfection in one shot. Core idea: Treat the first generation as a draft. Use structured follow-up prompts to refine specific aspects while preserving what works. Each iteration addresses a defined concern rather than asking the AI to vaguely "improve" the output. How it works: Iterative Refinement is not the same as the ad-hoc iteration that characterizes unstructured AI usage. In unstructured usage, you see something wrong, mention it, and hope the AI fixes it. In the Iterative Refinement Pattern, you plan the iteration sequence before you start. The structure follows a predictable sequence. First generation: Core logic. Provide the full specification and ask for the core implementation. Do not expect perfection. Expect a working foundation. Second generation: Error handling. Review the core logic. If the foundation is sound, ask the AI to add comprehensive error handling. Provide specific error scenarios and expected responses. "Now add... --- - Published: 2026-02-01 - Modified: 2026-02-02 - URL: https://www.ivanturkovic.com/2026/02/01/prompt-patterns-decomposition-exemplar-constraint/ - Categories: AI development, AI-Driven Development, Artificial Intelligence - Tags: code quality, development, software craftsmanship, software engineering Software developers are familiar with design patterns. The Gang of Four cataloged reusable solutions to recurring problems in object-oriented design. You learn patterns like Strategy, Observer, and Factory not because they are theoretically interesting but because they solve problems you encounter repeatedly. Once you know the pattern, you recognize the problem and reach for a proven solution. Prompt patterns serve the same purpose for AI collaboration. They are reusable approaches to recurring challenges in the Generate phase. Like design patterns, they have names, contexts where they apply, and structures you can follow. Like design patterns, they become more valuable as you internalize them and recognize when to apply them. This post covers three foundational patterns. The next post will cover three more, plus guidance on building your team's pattern library. Why Patterns Matter Without patterns, every generation is an improvisation. You face a task, think about how to prompt the AI, and construct an approach from scratch. Sometimes this works well. Sometimes it does not. The inconsistency means you cannot predict outcomes or improve systematically. Patterns provide structure for this process. When you recognize that a task is too complex for single-shot generation, you reach for the Decomposition Pattern. When you need the AI to match your codebase's style, you reach for the Exemplar Pattern. When the AI keeps introducing unwanted elements, you reach for the Constraint Pattern. Over time, patterns become habitual. You stop thinking about how to structure your prompts and start thinking about which pattern fits the... --- - Published: 2026-01-31 - Modified: 2026-01-30 - URL: https://www.ivanturkovic.com/2026/01/31/generate-effective-ai-collaboration/ - Categories: ADD Methodology, AI development, AI-Driven Development, Software Development, Software Engineering - Tags: ADD Methodology, AI Collaboration, AI-Driven Development, Code Generation, software engineering Generation is where the visible work happens. You provide input, and the AI produces code. This is the moment most developers think of when they imagine AI-assisted development. It is also where most developers start, jumping directly to generation without the specification work that should precede it. In the ADD cycle, generation is the second phase, not the first. This ordering is deliberate. Generation without specification produces code built on hidden assumptions. Generation with specification produces code you can evaluate against explicit criteria. But even with a good specification, generation requires its own disciplines. Context management, iteration strategy, and resistance to premature acceptance all determine whether generation produces useful output or creates more work than it saves. Generation in Context The Generate phase sits between Specify and Evaluate. This position shapes how generation should work. From specification, generation receives clear requirements, constraints, and context. The specification defines what success looks like. It provides the criteria against which output will be judged. Without this input, generation is guessing. With it, generation has direction. To evaluation, generation provides candidate code. This code is not finished until it passes evaluation. The discipline of the Generate phase is to produce output worth evaluating, not to produce final code. Treating generated code as a draft rather than a finished product changes how you interact with the AI and how you respond to its output. This positioning means generation is not about getting the AI to produce perfect code on the first try. It is about... --- - Published: 2026-01-30 - Modified: 2026-01-30 - URL: https://www.ivanturkovic.com/2026/01/30/specification-templates-practical-library/ - Categories: ADD Methodology, AI, AI development, AI-Driven Development - Tags: ADD Methodology, AI-Driven Development, software engineering, Specification, Templates In the previous post, I made the case that specification is the highest-leverage skill in AI-driven development. A precise specification produces better output, requires less iteration, and surfaces ambiguity before it becomes a bug. But writing detailed specifications from scratch is cognitively demanding. You must simultaneously consider functional requirements, constraints, context, edge cases, and integration points. Holding all of this in your head while also thinking about the actual problem you are trying to solve is exhausting. Templates solve this problem. A specification template is a reusable structure that prompts you to provide the information AI needs. Instead of remembering what to include, you fill in sections. Instead of inventing structure, you follow a proven format. This post provides a library of specification templates for common development tasks. Each template is complete enough to use immediately and annotated with guidance on customization. By the end, you will have practical tools that make specification-first development sustainable. Why Templates Matter Templates provide three benefits that compound over time. Consistency. When every developer on a team uses the same template structure, specifications become predictable. Code reviewers know where to find constraint information. New team members can read specifications without learning idiosyncratic formats. The AI receives consistently structured input, which improves output consistency. Completeness. A well-designed template includes sections for everything that matters. You cannot forget to specify error handling if the template has an error handling section staring at you. Templates encode the lessons of past omissions. Every time a missing specification element... --- - Published: 2026-01-29 - Modified: 2026-01-27 - URL: https://www.ivanturkovic.com/2026/01/29/introverts-engineering-history-ai-future/ - Categories: AI development, Artificial Intelligence, Career Development, Introduction, leadership, Uncategorized - Tags: development, leader, leadership, software craftsmanship, success Throughout human history, there has always been a place where the quiet ones could excel. A domain where deep thinking mattered more than small talk, where careful analysis outweighed charisma, and where the quality of your work spoke louder than the volume of your voice. That place has been engineering. From the mathematicians of ancient Alexandria to the software architects of Silicon Valley, engineering has served as a sanctuary for introverts. It offered them not just employment, but genuine fulfillment. A space where their natural tendencies toward deep focus, systematic thinking, and solitary problem-solving were not merely tolerated but actively rewarded. Now, as artificial intelligence reshapes how technical work gets done, many introverted engineers are asking a troubling question: Is our safe haven about to disappear? Will AI force us to become salespeople, relationship managers, and perpetual collaborators just to remain relevant? The short answer is no. But the longer answer requires us to understand how we got here in the first place. The Ancient Origins: When Solitary Thinkers Built Civilizations The relationship between introversion and technical work is not a modern phenomenon. It stretches back to the earliest civilizations, where the quiet mastery of numbers, measurements, and construction principles determined who built the structures that lasted millennia. Consider ancient Egypt. While pharaohs commanded armies and priests performed public rituals, a different class of professionals worked in relative obscurity: the scribes and engineers who designed the pyramids. These were individuals who spent years mastering complex mathematical calculations, understanding the properties... --- - Published: 2026-01-28 - Modified: 2026-01-27 - URL: https://www.ivanturkovic.com/2026/01/28/specify-the-most-important-skill-in-ai-driven-development/ - Categories: ADD Methodology, AI-Driven Development, Requirements, Software Engineering, Specification - Tags: ai, development, software craftsmanship, Software Development, software engineering If you take one thing from this entire series, let it be this: the quality of AI-generated code is bounded by the quality of your specification. No amount of model capability, prompt engineering tricks, or iteration can overcome a vague specification. The ceiling of what AI can produce for you is set by the clarity of what you ask for. This is why specification is the first phase of the ADD cycle, and why I consider it the most important skill in AI-driven development. Everything else depends on getting this right. Why Specification Comes First In unstructured AI usage, specification is often an afterthought. You have a task in mind. You describe it quickly to the AI. You see what comes back. If the output is not quite right, you iterate with follow-up prompts. The specification emerges through conversation rather than preceding it. This approach feels efficient. Why spend time writing detailed specifications when you can just ask and see what happens? The AI is fast. Iteration is cheap. You can course-correct as you go. But this efficiency is illusory. Each iteration costs more than it appears. You must read and evaluate output that may be entirely wrong. You must formulate follow-up prompts that address gaps you only discovered by seeing incorrect output. You accumulate context in the conversation that makes it harder to start fresh if needed. And you often accept "good enough" output because you have already invested time iterating and do not want to start over. More... --- - Published: 2026-01-27 - Modified: 2026-01-27 - URL: https://www.ivanturkovic.com/2026/01/27/waterfall-to-add-ai-methodology/ - Categories: AI development, AI-Driven Development, Development Methodology, Software Development, Software Engineering - Tags: Agile, AI-Driven Development, Development Methodology, software engineering, Software History Software development methodologies do not emerge from academic theory or conference talks. They emerge from pain. Practitioners encounter problems that existing approaches cannot solve, and they develop new disciplines to address those problems. Understanding this history matters because AI-assisted development is at an inflection point. The unstructured approaches I described in my previous post are producing real problems: subtle bugs, security vulnerabilities, architectural drift, and skill erosion. These problems will not be solved by better AI models or smarter prompts. They require methodology. To understand why, let us look at how methodologies have emerged before. The Waterfall Era and Its Limitations In the early decades of software engineering, the dominant model was borrowed from manufacturing and construction. You gathered requirements, designed the system, implemented it, tested it, and deployed it. Each phase completed before the next began. Progress flowed downward like water over a falls, hence the name. Waterfall made intuitive sense. It mapped to how physical products were built. You would not start constructing a building before the blueprints were complete. You would not wire the electrical system before the walls were framed. Sequential phases with clear handoffs seemed like the obvious way to manage complexity. For certain projects, waterfall worked adequately. When requirements were stable and well understood, when the problem domain was familiar, when the technology was mature, the sequential approach could deliver results. Government contracts, embedded systems with fixed specifications, and projects with regulatory constraints often succeeded with waterfall methods. But software turned out to be... --- - Published: 2026-01-26 - Modified: 2026-01-25 - URL: https://www.ivanturkovic.com/2026/01/26/unstructured-ai-problem-teams-using-ai-wrong/ - Categories: AI development, Software Development, Software Engineering - Tags: AI Tools, AI-Driven Development, code quality, Development Methodology, software engineering Every developer I know uses AI tools now. Copilot suggestions appear mid-keystroke. ChatGPT tabs stay permanently open. Claude conversations stretch across multiple projects. The adoption curve was vertical, faster than any technology shift I have witnessed in two decades of software engineering. But here is the uncomfortable truth: most of us are using these tools without any real methodology. We treat AI as fancy autocomplete, accepting plausible output and hoping for the best. We have adopted revolutionary capability while keeping amateur practices. This is the unstructured AI problem, and it is quietly undermining our codebases. How Developers Actually Use AI Today Let me describe what I observe in my own work and in conversations with other developers. I am not here to judge; I am here to name what is happening. The typical AI interaction looks something like this: You have a task. You open your AI tool. You describe what you need, often in a single sentence or a rough paragraph. The AI produces something. You glance at it. It looks reasonable. You paste it into your codebase, maybe tweak a variable name or two, and move on. Sometimes you iterate. The output was not quite right, so you add a follow-up prompt. "Actually, can you make it handle null values? " The AI adjusts. You accept the new version. Done. This workflow has three characteristics that define unstructured AI usage. First, the input is vague. We describe what we want in the same casual language we might use... --- - Published: 2026-01-25 - Modified: 2026-01-25 - URL: https://www.ivanturkovic.com/2026/01/25/ai-driven-development-add-methodology/ - Categories: Artificial Intelligence, Development Methodology, Software Engineering - Tags: ADD, ai, BDD, Code Generation, Development Process, Engineering Practices, Methodology, Prompt Engineering, Software Development, TDD Software development has always evolved through methodologies that structure how we think about building systems. Waterfall gave way to Agile. Test-Driven Development changed how we approach correctness. Behavior-Driven Development shifted focus toward specifications that non-technical stakeholders could understand. Each methodology emerged because the existing approaches no longer fit the reality of how software was actually being built. We are at another such inflection point. AI-assisted coding is no longer experimental. It is production reality for millions of developers. Yet most teams are using these powerful tools without any coherent methodology, treating AI as a faster autocomplete rather than a fundamentally different way of building software. This article introduces AI-Driven Development (ADD), a methodology for structuring how engineers work with AI throughout the software development lifecycle. Like TDD or BDD before it, ADD is not about the tools themselves but about the discipline of using them effectively. What AI-Driven Development Is (and Is Not) AI-Driven Development is a structured approach where AI serves as an active collaborator throughout the development process, with humans providing direction, evaluation, and quality control at defined checkpoints. It treats AI not as a code generator to be invoked occasionally but as a persistent development partner whose output requires systematic oversight. ADD is not about removing humans from the loop. It is about redefining where human attention adds the most value. Instead of spending cognitive effort on implementation details, engineers focus on specification, evaluation, and architectural coherence. The methodology creates explicit practices for each of these activities.... --- - Published: 2026-01-24 - Modified: 2026-01-23 - URL: https://www.ivanturkovic.com/2026/01/24/future-engineer-ai-software-development-skills/ - Categories: Artificial Intelligence, Career Development, Software Development - Tags: ai, Architecture, Career Growth, Engineering Skills, Future of Work, Software Development, System Design, Technical Leadership The software industry has entered a period of genuine transformation. After decades of incremental tooling improvements, AI-assisted development is introducing changes that feel qualitatively different from what came before. Code completion, automated testing, and intelligent refactoring are no longer experimental features but daily realities for many developers. This shift raises uncomfortable questions about the future of software engineering as a profession. What happens to the value of deep technical expertise when AI can generate working code in seconds? How do engineers maintain their skills when the machine handles an increasing share of implementation work? And perhaps most importantly, what does it actually mean to be a software engineer when the nature of the work itself is changing? Having spent more than two decades building and scaling software systems, I find myself thinking about these questions differently than many of the breathless predictions suggest. The answer is neither the utopian vision of effortless productivity nor the dystopian fear of mass obsolescence. The reality is more interesting and more demanding. The Shift from Implementation to Orchestration For most of software engineering's history, the job has been fundamentally about implementation. You understand a problem, design a solution, and then spend the majority of your time translating that solution into working code. Syntax, language idioms, framework conventions, and API quirks consume most of your attention. AI changes this equation by compressing the implementation phase. Tasks that once required hours of careful coding can now be accomplished in minutes with the right prompts and oversight.... --- - Published: 2026-01-23 - Modified: 2026-01-22 - URL: https://www.ivanturkovic.com/2026/01/23/code-is-for-humans-not-machines-why-ai-wont-make-syntax-obsolete/ - Categories: AI, Artificial Intelligence, Software Development - Tags: ai, AI coding assistants, code quality, code readability, debugging, programming, programming fundamentals, software craftsmanship, software engineering, syntax With AI, "everybody is a programmer. " You do not need to learn syntax anymore. Just describe what you want, and the machine will write the code for you. If you have spent any meaningful time in this profession, you are probably laughing right now. Or at least shaking your head. This narrative has become extraordinarily popular. It appears in breathless LinkedIn posts, product marketing copy, and the excited proclamations of people who have just discovered that ChatGPT can generate a working Python script. And I understand the appeal. The idea that programming could become as simple as having a conversation is genuinely compelling. It democratizes access. It removes barriers. It sounds like progress. But it fundamentally misunderstands what programming actually is, why code exists, and what happens after the initial script is generated. Let me explain why experienced engineers are skeptical, and why understanding syntax and language structure remains not just useful but essential. The Persistent Fantasy of Eliminating Programmers Before we examine the current AI moment, it is worth recognizing that we have been here before. Many times. In the 1980s, CASE tools were supposed to make programming obsolete. Business analysts would draw diagrams, and working systems would emerge. In the 1990s, visual programming environments and RAD tools promised the same. The 2000s brought model-driven development. The 2010s gave us low-code and no-code platforms with identical promises. Each generation of tools genuinely improved productivity for certain tasks. And each one failed to eliminate the need for people who... --- - Published: 2026-01-22 - Modified: 2026-03-12 - URL: https://www.ivanturkovic.com/2026/01/22/history-software-simplification-cobol-ai-hype/ - Categories: AI, Career Development, Software Development - Tags: development, leadership, software craftsmanship When I look back at the history of software, one pattern emerges with remarkable consistency: the promise to simplify software creation, to make it cheaper, and ultimately to eliminate the need for programmers altogether. This is not a new idea. It has been the driving ambition of our industry since the 1960s. And while each generation believes they are witnessing something unprecedented, they are actually participating in a cycle that has repeated itself for over six decades. Today, as large language models generate code and AI assistants pair-program with developers, we hear familiar refrains: programming as we know it is ending, software development will be democratized, and soon anyone will be able to build complex systems without writing a single line of code. These claims deserve scrutiny, not because they are entirely wrong, but because they echo promises made in 1959, in 1973, in 1985, and in 2015. Understanding this history is essential for anyone trying to make sense of where we actually are and where we might be going. The Original Sin: COBOL and the Business User Dream The story begins in the late 1950s, when programming was genuinely arcane. Programmers wrote in assembly language or machine code, manipulating registers and memory addresses directly. The work required deep technical knowledge and was painfully slow. Businesses needed software, but the people who understood business problems rarely understood computers, and the people who understood computers rarely understood business problems. Enter Grace Hopper and the CODASYL committee. In 1959, they created COBOL,... --- - Published: 2026-01-21 - Modified: 2026-01-20 - URL: https://www.ivanturkovic.com/2026/01/21/ai-fixed-cost-development-agencies-consultants/ - Categories: AI, Business Strategy, Software Development - Tags: agency, ai, automation, code review, development, fixed cost, project management Software development has always carried an uncomfortable truth: nobody really knows how long it will take. Clients want certainty. They want a number, a deadline, a budget they can plan around. Agencies and independent consultants want to deliver that certainty, but they have learned through painful experience that software estimation is more art than science. The gap between what clients need and what developers can promise has created decades of tension, scope creep, budget overruns, and strained relationships. AI is changing this equation in ways that most people have not yet fully understood. This is not about replacing developers or automating creativity away. It is about controlling the most unpredictable variable in software projects: the time between understanding what needs to be built and actually building it correctly. The Real Problem with Software Estimation Before we talk about solutions, we need to be honest about the problem. Software estimation fails for predictable reasons. The initial requirements are never complete. Edge cases emerge during implementation. Technical debt in existing systems creates unexpected friction. Developers underestimate complexity because optimism is a survival trait in our industry. Clients change their minds as they see the product take shape, which is actually healthy behavior but devastating to fixed timelines. The traditional response has been time-and-materials billing. You pay for hours worked, and the final cost is whatever it turns out to be. This protects the agency from estimation risk but transfers all uncertainty to the client. It also creates misaligned incentives: the agency profits... --- - Published: 2026-01-19 - Modified: 2026-01-19 - URL: https://www.ivanturkovic.com/2026/01/19/ai-orchestration-developer-team-leaders-software-engineering/ - Categories: AI, Career Development, leadership, personal development - Tags: AI Agents, AI-Assisted Coding, code quality, Developer Career, Engineering Management, Software Development, Team Leadership, Technical Leadership There is a particular kind of developer who has spent years doing something that most of the industry undervalues: building people, not just systems. They review code not to gatekeep, but to teach. They pair with junior developers not because it's efficient, but because they understand that growth compounds. They know that a team's ceiling is determined not by its strongest member, but by how well everyone elevates each other. These developers the ones who build teams are about to become the most sought-after professionals in software engineering. Not because the industry has suddenly decided to value mentorship (though it should), but because the skills required to orchestrate AI agents effectively are almost identical to the skills required to lead a team of human developers. This is not a prediction about some distant future. The tools are here now. AI coding assistants have matured from curiosities into genuine productivity multipliers. The question is no longer whether AI will change software development, but who will be equipped to harness it responsibly. The Parallel That Changes Everything Consider what it takes to be an effective technical lead. You need to break down complex problems into discrete, well-scoped tasks. You need to communicate requirements with enough context that someone else can execute without constant supervision. You need to review work critically, catching not just bugs but architectural drift, maintainability issues, and violations of established patterns. You need to know when to trust and when to verify. You need to recognize when someone is... --- - Published: 2026-01-17 - Modified: 2026-01-17 - URL: https://www.ivanturkovic.com/2026/01/17/ruby-token-efficiency-llm-ai-friendly-language/ - Categories: AI, ruby, ruby on rails - Tags: ai, claude code, context window, developer productivity, llm, ruby, token efficiency A few weeks ago, Martin Alderson published something that caught my attention: a systematic comparison of how token-efficient different programming languages are when fed to large language models. The findings were fascinating. And if you've been following my writing on Ruby, you won't be surprised to hear that Ruby came out looking very good indeed. But this isn't just about bragging rights for Ruby developers. It points to something bigger: a fundamental shift in how we should think about programming language design in an age where AI is increasingly writing and reading our code. The Constraint Nobody Saw Coming Here's the thing about LLMs that breaks most of our mental models about computing: they don't care about CPU cycles the way traditional programs do. What they care about, desperately, is context window. The context window is the amount of information an LLM can hold in its working memory at once. Think of it as the size of the desk where you're working. No matter how fast you can think, if you can only fit three pages on your desk at a time, that's a hard limit on how much information you can work with simultaneously. For software development agents, this matters enormously. A significant portion of your context window is going to be code: the files you're working with, the changes you're making, the diffs you're reviewing. A more token-efficient language means you can fit more code in the window, which means longer productive sessions and better context for the... --- - Published: 2026-01-13 - Modified: 2026-01-13 - URL: https://www.ivanturkovic.com/2026/01/13/ai-saved-2-million-not-vibe-coding/ - Categories: AI, productivity - Tags: AI Strategy, CTO Insights, Product Development, Product-Market Fit, Startup Growth, User Research, Vibe Coding I recently came across a story that perfectly encapsulates something I've been thinking about for months. It's about a CPO who was handed an unlimited token budget and told to vibe code three MVPs for Q1 2026. They did something unexpected instead. Rather than firing up Lovable or Bolt to start generating code, they opened Claude Code with the browser extension. Their first prompt wasn't "build me a dashboard. " It was "load the top 100 users from our app. " The second prompt: "Send each user a personal email asking what they would like to see in the app. " That afternoon, instead of debugging AI-generated React components, this CPO was having real conversations with their most valuable customers. Eighty-five responses came back. One hundred fifty feature requests. Three common asks emerged from the noise. A week later, those three small features shipped. Not three MVPs. Three focused improvements that users actually wanted. By month's end, sales were up 10% on $20M ARR. That's $2 million in new revenue. From a single prompt. And not a single new app was built. The Seduction of Vibe Coding I get the appeal. I really do. There's something intoxicating about describing an app in plain English and watching it materialise in front of you. It feels like magic. It feels like the future. And honestly, it is impressive technology. The demos are incredible. Someone types "build me a project management tool with Kanban boards and real-time collaboration" and boom there's a working... --- - Published: 2026-01-10 - Modified: 2026-01-08 - URL: https://www.ivanturkovic.com/2026/01/10/ruby-unique-structures-vs-other-languages/ - Categories: Uncategorized - Tags: blocks, eigenclass, java, javascript, metaprogramming, method_missing, mixins, modules, python, ruby, ruby features In my previous post on Ruby's building blocks, I covered when to use Struct, Data, Class, and Module. But I glossed over something important: many of these constructs don't exist in other languages - or exist in such diminished forms that they barely count. Ruby isn't just another object-oriented language with different syntax. It has genuinely unique structures that change how you think about code. If you're coming from Python, Java, JavaScript, or C#, these are the things that will make you say "wait, you can do that? " This isn't about Ruby being "better" in some abstract sense. It's about understanding what Ruby offers that others don't - and why those differences matter for writing expressive, maintainable code. Struct: Class Generation as a First-Class Feature Most languages make you write classes by hand. Ruby lets you generate them. Person = Struct. new(:name, :email, :age) That single line creates a complete class with: A constructor accepting three arguments Getter and setter methods for each attribute Equality comparison based on values A sensible to_s representation Hash and array-like access (person, person) What Other Languages Offer Python has namedtuple and @dataclass: from dataclasses import dataclass @dataclass class Person: name: str email: str age: int This is close, but it's a decorator that modifies a class you still have to define. You need type annotations (even if you don't want them). And it was added in Python 3. 7 - Struct has been in Ruby since the beginning. JavaScript has nothing built-in. You... --- - Published: 2026-01-08 - Modified: 2026-01-08 - URL: https://www.ivanturkovic.com/2026/01/08/ruby-struct-data-class-module-when-to-use/ - Categories: ruby, ruby on rails - Tags: class, data, mixin, module, object-oriented programming, ruby, ruby 3.2, ruby patterns, service objects, struct Ruby gives us an abundance of organizational tools. Struct, Data, classes, modules as namespaces, modules as mixins, service objects, and the include/extend/module_function trinity. Each is well-documented individually, but there's a gap: when and why to choose one over another. This isn't about rules. Ruby's philosophy encourages pragmatism-take what you need and move forward. But pragmatism doesn't mean arbitrary choices. There's idiomatic intent behind each construct, and understanding that intent makes your code clearer to others and to your future self. Ruby is not C++, and we shouldn't think in C++ limitations. But I also don't subscribe to the view that we should avoid classes whenever possible. Classes are a powerful tool when used appropriately. The goal is fit-choosing the construct that best expresses your intent. Struct: The Lightweight Data Container What It Is Struct is a class factory. It generates a new class with named attributes, an initializer, accessor methods, equality comparison, and a reasonable to_s. All from a single line. Person = Struct. new(:name, :email) alice = Person. new("Alice", "alice@example. com") When to Use Struct 1. Quick data grouping without ceremony When you need to bundle a few related values together and don't want the overhead of defining a full class: # Returning multiple related values from a method Result = Struct. new(:success, :data, :errors) def process_order(order) # ... processing logic ... Result. new(true, processed_order, ) end 2. Replacing hashes for clarity When you find yourself passing hashes with consistent keys, a Struct adds structure and catches typos: #... --- - Published: 2026-01-07 - Modified: 2026-01-07 - URL: https://www.ivanturkovic.com/2026/01/07/a-cto-would-be-bored-by-tuesday/ - Categories: Uncategorized Founder: "I need a CTO. " Me: "For what? " Founder: "Technical leadership. " Me: "What technical decisions are you making? " Founder: "Which tools to use. How to connect them. What to build vs buy. " Me: "You need a technical advisor. Maybe 5 hours a month. " Founder: "Not a full-time hire? " Me: "You're pre-product-market-fit with 2 clients. A CTO would be bored by Tuesday. " This conversation happens more than you'd think. And every time, I watch the founder's face shift from confusion to relief. They came in thinking they needed a $250K hire. They left with a solution that actually fits their stage. The Expensive Mistake Nobody Talks About Last year, I got a call from a fintech founder. Let's call him Marcus. Marcus had just raised a seed round and his investors were pushing him to hire a CTO. "You need someone senior to own the technical vision," they said. Good advice in theory. Terrible advice for his situation. Marcus's startup had a working MVP built by a freelancer. Two paying customers. A burn rate that gave him 14 months of runway. And his investors wanted him to spend 30% of his raise on a single hire who'd spend most of their time... doing what, exactly? At that stage, the technical decisions that mattered could fit on a napkin: Should we rebuild the MVP or iterate on it? Which payment processor integrates best with our stack? Do we need to think about compliance infrastructure... --- - Published: 2025-12-29 - Modified: 2025-12-29 - URL: https://www.ivanturkovic.com/2025/12/29/what-i-wrote-about-in-2025/ - Categories: AI, development, productivity, ruby, ruby on rails Looking back at the year, my blog became a running commentary on how AI is fundamentally reshaping software development, and not always in the ways people expect. I've been splitting my attention between technical deep-dives and broader observations about where this whole industry is heading. Here's what caught my attention month by month. March 2025: Learning to Work With AI Without Losing Your Skills Most Common Mistakes Developers Make With AI-Assisted Coding (And How to Fix Them) In March, I tackled something that was bothering me about the explosion of AI coding tools. Everyone was celebrating how fast they could ship code, but nobody was talking about the mistakes piling up underneath. I wrote about the most common mistakes developers were making with AI-assisted coding, and more importantly, how to actually get better at working with these tools instead of just letting them do everything. The piece focused on practical stuff like understanding what the AI is actually generating, verifying its output, and not treating it like a magic black box. Because here's the thing: AI can write code faster than you can, but it can't understand your business logic, your edge cases, or why that weird workaround exists in your codebase. That's still on you. April 2025: Why AI Won't Replace Software Engineers (And Might Create More Jobs) Why AI Coding Tools Will Increase Demand for Software Engineers, Not Decrease It By April, the "AI will replace all developers" narrative was reaching fever pitch, so I pushed back with... --- - Published: 2025-12-24 - Modified: 2025-12-24 - URL: https://www.ivanturkovic.com/2025/12/24/a-christmas-eve-technology-outlook-ruby-on-rails-and-web-development-in-2026/ - Categories: AI, ruby, ruby on rails As we gather with loved ones this Christmas Eve, wrapping presents and reflecting on the year behind us, it's the perfect moment to gaze into the technology crystal ball and envision what 2026 holds for web development and particularly for Ruby on Rails, the framework that's been delighting developers for over two decades. While children dream of what Santa might bring tomorrow morning, we developers can't help but wonder: what gifts will the tech world deliver in the year ahead? Spoiler alert: 2026 looks to be one of the most transformative years in Rails history. The State of Rails as We Enter 2026 Ruby on Rails enters 2026 in a fascinating position. After years of obituaries prematurely declaring the framework dead, Rails has experienced a remarkable renaissance. The community is energized, adoption is growing, and most importantly, Rails is evolving faster than it has in years. Rails 8, which recently launched, brought us significant improvements in deployment simplicity, background job processing with Solid Queue, and database-backed caching with Solid Cache. But these aren't just incremental improvements, they represent a philosophical shift toward making Rails deployment radically simpler and more cost-effective. The framework that once required complex infrastructure setups can now be deployed to a single server with SQLite handling everything from the primary database to job queues and caches. This isn't a step backward to simplicity, it's a leap forward to sophistication without complexity. AI-Powered Development: Rails' Secret Weapon Here's what might surprise you: Rails is uniquely positioned to thrive... --- - Published: 2025-12-23 - Modified: 2025-12-23 - URL: https://www.ivanturkovic.com/2025/12/23/the-future-of-language-frameworks-in-an-ai-driven-development-era/ - Categories: AI - Tags: development As artificial intelligence increasingly writes the code that powers our digital world, we're standing at a fascinating crossroads in software development history. The fundamental question looming over our industry is deceptively simple yet profoundly complex: if AI is writing our code, do we still need the elaborate conventions, configurations, and architectural patterns that have defined programming for decades? The Human-Centric Origins of Programming Conventions To understand where we're heading, we need to appreciate where we came from. Every convention in modern programming exists because of human limitations and needs. We created naming conventions because humans struggle to parse meaning from abbreviated variable names. We built framework architectures with separation of concerns because human brains can only hold so many concepts simultaneously. We established coding standards because teams of humans need consistent patterns to collaborate effectively. Consider React's component lifecycle methods or Django's MTV pattern. These weren't designed for machines; they were designed to help human developers reason about complex state management and data flow. The elaborate configuration files we maintain, from webpack. config. js to build. gradle, exist primarily because humans need explicit, readable instructions to understand how systems connect. The AI Shift: Writing Code Without Human Constraints Large language models like GPT-4, Claude, and their successors are fundamentally changing this calculus. These systems don't experience cognitive load the way humans do. An AI can effortlessly track hundreds of variables across thousands of lines of code without losing context. It doesn't need mnemonic variable names or carefully structured modules to... --- - Published: 2025-12-22 - Modified: 2025-12-23 - URL: https://www.ivanturkovic.com/2025/12/22/from-intentions-to-impact-your-2025-strategy-guide-part-2/ - Categories: development, personal, personal development, productivity The Resolution Graveyard It's December 22nd. In nine days, millions of people will make promises to themselves that they won't keep. They'll join gyms they'll stop visiting by February. They'll buy courses they'll never finish. They'll write goals in fresh notebooks that will gather dust by March. Why? Because they skipped Part 1. If you haven't read Part 1 of this series, go back and do the work. Seriously. Building a goal system on top of broken productivity habits is like trying to run a marathon while smoking a pack a day. But if you've spent this past week implementing the foundation blocking distractions, building focus systems, reclaiming your attention then you're ready for this conversation. Part 2 is about what comes next: turning your reclaimed time into a life that actually matters. The Hard Truth About New Year's Resolutions Let me share something uncomfortable: I've written New Year's resolutions every year since 2010. Fifteen years of goal-setting. Want to know how many I actually achieved? About 30%. Not because I'm lazy. Not because the goals were wrong. But because I was playing the wrong game entirely. Traditional New Year's resolutions fail for three reasons: 1. They're Outcome-Focused Instead of System-Focused "Lose 20 pounds" is an outcome. What's your system? How will you actually do it? Most people have no idea, so they wing it and wonder why willpower runs out by January 15th. 2. They're Disconnected From Your Actual Life You write goals in a moment of inspiration, usually... --- - Published: 2025-12-15 - Modified: 2025-12-15 - URL: https://www.ivanturkovic.com/2025/12/15/stop-procrastinating-in-2025-part-1-building-your-foundation-before-new-years-resolutions/ - Categories: personal development, productivity, start, success Why December Is Actually the Best Time to Stop Procrastinating As we approach 2025, most people are preparing their New Year's resolutions. But here's the uncomfortable truth: 91% of New Year's resolutions fail by February. Why? Because people try to build new habits on top of broken systems. Before you write that ambitious list of goals for 2025, let's address the elephant in the room: procrastination. You can't build a skyscraper on quicksand, and you can't achieve your dreams while drowning in digital distractions. Back in 2014, I wrote about my battle with procrastination, and the core principles still hold true. But the battlefield has changed dramatically. We're no longer just fighting Facebook and Twitter we're battling algorithmic dopamine machines designed by the smartest engineers in the world to keep us scrolling. This is Part 1 of our pre-New Year series: Building your foundation. Consider this your December homework before the calendar flips to January 1st. The 2025 Procrastination Landscape: What's Different Let me be honest with you. If I could travel back to 2014 and show myself what 2025 looks like, I'd be horrified. Here's what's changed: The New Threats TikTok and Short-Form Video: In 2014, the worst distraction was clicking through articles. Now? You can lose 3 hours watching 15-second videos without even realizing it. The average user spends 95 minutes per day on TikTok alone. AI-Powered Feeds: Every social platform now uses machine learning to show you exactly what keeps you engaged. They know you better than... --- - Published: 2025-12-13 - Modified: 2025-12-11 - URL: https://www.ivanturkovic.com/2025/12/13/the-corporate-culture-charade-part-2-how-ai-is-killing-what-little-culture-we-had-left/ - Categories: personal development, productivity, success - Tags: company culture, culture, success While executives blame remote work for destroying company culture, they're missing the real culprit: AI-generated content is creating a closed loop of meaningless communication where everyone is reading summaries of summaries, and nobody is thinking anymore. I need to start with a confession: I've used AI to write emails. I've used it to summarize meeting notes. I've watched colleagues use it to generate reports that get sent to other colleagues who use AI to summarize those reports. And I've realized we're all participating in the creation of a vast corporate content ouroboros a snake eating its own tail, except the snake is made of statistical predictions and nobody notices there's no actual substance being consumed. The Real Problem: It's Not Remote Work, It's Synthetic Work Leadership loves to blame remote work for the decline in culture. They point to the loss of hallway conversations, the absence of spontaneous collaboration, the way Zoom calls feel transactional. But they're looking in entirely the wrong direction. The actual culture killer isn't physical distance it's cognitive distance. It's the growing gap between the work people pretend to do and the work that actually matters. And AI is widening that gap exponentially. Here's what's actually happening in companies right now: Sarah uses AI to write a quarterly report. The report sounds professional, hits all the expected notes, includes data visualizations that look impressive. She sends it to her manager. Her manager, who receives dozens of such reports, uses AI to summarize it into three bullet... --- - Published: 2025-12-11 - Modified: 2025-12-11 - URL: https://www.ivanturkovic.com/2025/12/11/company-culture/ - Categories: productivity, success - Tags: company, company culture, success The article critiques the modern obsession with corporate culture, arguing it is often a superficial construct designed to appease executives rather than genuinely engage employees. The author emphasizes that true culture emerges organically from shared experiences, while corporate culture is manufactured, focusing on management control instead of addressing real employee needs such as fair compensation and meaningful work. There's an elephant in every conference room, and it's time someone pointed it out: corporate culture is mostly performance art for executives who've consumed one too many LinkedIn thought leadership posts. Here's the uncomfortable truth when it comes to company culture, there is really nothing cultural in it by itself at all. I recently came across yet another company memo about culture this one lamenting how remote work is supposedly destroying the magical "energy" and "spontaneous moments" that make a workplace special. The usual suspects were there: hallway conversations, shared excitement, the ineffable sense of belonging that apparently only happens when people share physical space. And I couldn't help but think: who is this actually for? How We Got Here: A Brief History of the Culture Obsession The corporate culture phenomenon didn't emerge from nowhere. To understand why every company now has a Chief Culture Officer and a dedicated culture budget, we need to look back at how this obsession began. The 1980s: Culture as Competitive Advantage The modern corporate culture movement can be traced back to the early 1980s, particularly to two influential books: "In Search of Excellence" (1982) by Tom Peters and Robert Waterman, and "Corporate Cultures" (1982) by Terrence Deal and Allan Kennedy. These books emerged during a time when American companies were losing ground to Japanese competitors, and consultants were desperately searching for explanations. The answer they landed on was culture. Japanese companies supposedly had superior cultures strong shared values, intense loyalty, collective purpose. American companies... --- - Published: 2025-12-09 - Modified: 2025-12-04 - URL: https://www.ivanturkovic.com/2025/12/09/building-a-decentralized-credit-card-system-part-2-solidity-smart-contract-implementation/ - Categories: blockchain In the first part of this series, we explored the conceptual architecture of a blockchain-based credit card system using multi-signature keys and encrypted spending limits. Now, let's dive into the technical implementation with concrete Solidity examples. This post will give you production-ready smart contract code that demonstrates how to build a secure, multi-signature credit card system on Ethereum or any EVM-compatible blockchain. Smart Contract Architecture Overview Our decentralized credit card system consists of five interconnected smart contracts: CreditFacility Contract: Manages the master account and credit line CardManager Contract: Handles individual card issuance and lifecycle SpendingLimits Contract: Enforces encrypted spending rules PaymentProcessor Contract: Executes and settles transactions MultiSigGovernance Contract: Handles high-value transaction approvals Each contract has a specific responsibility, following the principle of separation of concerns. This modular approach makes the system more maintainable, upgradeable, and secure. Note: These contracts are designed for educational and proof-of-concept purposes. Production deployment would require extensive security audits, gas optimization, and integration with off-chain systems. 1. The Credit Facility Contract This contract represents the bank account or credit line, the source of funds controlled by the master key. It implements multi-signature controls to ensure that no single party can unilaterally make critical decisions. Key Features Multi-signature authorization for sensitive operations Credit limit management with approval workflows Real-time tracking of available credit and outstanding balance Support for multiple authorized signers per account Emergency account suspension capabilities The Complete Contract // SPDX-License-Identifier: MIT pragma solidity ^0. 8. 0; /** * @title CreditFacility * @dev Manages the master... --- - Published: 2025-12-07 - Modified: 2025-12-03 - URL: https://www.ivanturkovic.com/2025/12/07/building-a-decentralized-credit-card-system-with-multi-signature-smart-contracts/ - Categories: blockchain This post outlines a proof-of-concept for a blockchain-based credit card system integrating multi-signature cryptography and smart contracts to manage spending. It emphasizes creating a secure, flexible architecture while addressing challenges like scalability and regulatory compliance. The proposed system aims to enhance transparency, security, and user control in financial transactions. The intersection of blockchain technology and traditional financial services opens fascinating possibilities for reimagining how we handle payments and credit. In this post, I'll explore a proof-of-concept architecture for a public blockchain-based credit card system that uses multi-signature cryptography and smart contracts to manage spending limits and access controls. The Core Architecture The fundamental challenge is creating a system that maintains the security and flexibility of traditional credit cards while leveraging blockchain's transparency and programmability. Here's how we can structure this: Multi-Signature Hierarchical Key System The system relies on a hierarchical key structure with different access levels: Master Private Key: This serves as the root authority for the bank account or credit facility. Think of this as the bank's vault key—it has ultimate control over the credit line and can set global parameters. This key would be held by the issuing institution or distributed among multiple parties using threshold signatures for enhanced security. Card Private Keys: Each physical or virtual card gets its own private key. These keys are subordinate to the master key but have specific permissions and spending limits defined by smart contracts. Users interact with the payment system through these card keys, which can be revoked or modified without affecting other cards linked to the same account. Smart Contract-Enforced Spending Limits This is where blockchain technology truly shines. Rather than relying solely on centralized databases, spending limits and transaction rules are encoded into smart contracts: Smart Contract Logic: - Maximum transaction amount - Daily/monthly spending caps -... --- - Published: 2025-12-05 - Modified: 2025-12-05 - URL: https://www.ivanturkovic.com/2025/12/05/typed-ruby-what-if-ruby-had-first-class-types/ - Categories: development, Introduction, ruby, ruby on rails, success - Tags: ruby, ruby on rails The article envisions a reimagined Ruby with optional, inline type annotations called TypedRuby, addressing limitations of current solutions like Sorbet and RBS. It proposes a syntax that integrates seamlessly with Ruby’s philosophy, emphasizing readability and gradual typing while considering generics and union types. TypedRuby represents a potential evolution in Ruby's design. After imagining a typed CoffeeScript, I realized we need to go deeper. CoffeeScript was inspired by Ruby, but what about Ruby itself? Ruby has always been beautifully expressive, but it's also been dynamically typed from day one. And while Sorbet and RBS have tried to add types, they feel bolted on. Awkward. Not quite Ruby. What if Ruby had been designed with types from the beginning? Not as an afterthought, not as a separate file you maintain, but as a natural, optional part of the language itself? Let's explore what that could look like. The Problem with Sorbet and RBS Before we reimagine Ruby with types, let's acknowledge why the current solutions haven't caught on widely. Sorbet requires you to add # typed: true comments and use a separate type checker. Types look like this: # typed: true extend T::Sig sig { params(name: String, age: Integer). returns(String) } def greet(name, age) "Hello #{name}, you are #{age}" end RBS requires separate . rbs files with type signatures: # user. rbs class User attr_reader name: String attr_reader age: Integer def initialize: (name: String, age: Integer) -> void def greet: -> String end Both solutions have the same fundamental problem: they don't feel like Ruby. Sorbet's sig blocks are verbose and repetitive. RBS splits your code across multiple files, breaking the single-file mental model that makes Ruby so pleasant. What we need is something that feels native. Something Matz might have designed if static typing had been a priority in 1995. Core Design... --- - Published: 2025-12-03 - Modified: 2025-11-30 - URL: https://www.ivanturkovic.com/2025/12/03/typedscript-imagining-coffeescript-with-types/ - Categories: productivity, ruby, ruby on rails The content envisions a hypothetical programming language called "TypedScript," merging the elegance of CoffeeScript with TypeScript's type safety. It advocates for optional types, clean syntax, aggressive type inference, and elegance in generics, while maintaining CoffeeScript's aesthetic. The idea remains theoretical, noting practical challenges with adoption in the current ecosystem. After writing my love letter to CoffeeScript, I couldn't stop thinking: what if CoffeeScript had embraced types instead of fading away? What if someone had built a typed version that kept all the syntactic elegance while adding the type safety that makes TypeScript so powerful? Let's imagine that world. Let's design what I'll call "TypedScript" (or maybe CoffeeType? TypedCoffee? We'll workshop the name). The goal: keep everything that made CoffeeScript beautiful while adding first-class support for types and generics. The Core Principles Before we dive into syntax, let's establish what we're trying to achieve: Types should be optional but encouraged. You can write untyped code and gradually add types. Syntax should stay clean. No angle brackets everywhere, no visual noise. Type inference should be aggressive. The compiler should figure out as much as possible. Generics should be elegant. No mess. The Ruby/Python aesthetic must be preserved. Significant whitespace, minimal punctuation, readable code. Basic Type Annotations Let's start simple. In TypeScript, you write: const name: string = "Ivan"; const age: number = 30; const isActive: boolean = true; In TypedScript, I'd imagine: name: String = "Ivan" age: Number = 30 isActive: Boolean = true Or with type inference (which should work most of the time): name = "Ivan" # inferred as String age = 30 # inferred as Number isActive = true # inferred as Boolean The colon for type annotations feels natural. It's what TypeScript uses, and it doesn't clash with CoffeeScript's existing syntax. Function Signatures TypeScript function types can... --- - Published: 2025-12-01 - Modified: 2025-11-30 - URL: https://www.ivanturkovic.com/2025/12/01/a-love-letter-to-coffeescript-and-haml-when-rails-frontend-development-was-pure-joy/ - Categories: ruby on rails - Tags: development, software craftsmanship, success The author reflects on the nostalgia of older coding practices, specifically with Ruby on Rails, CoffeeScript, and HAML. They appreciate the simplicity, conciseness, and readability of these technologies compared to modern alternatives like TypeScript. While acknowledging TypeScript's superiority in type safety, they express a longing for the elegant developer experience of the past. There's something bittersweet about looking back at old codebases. Recently, I found myself diving into a Ruby on Rails project from 2012, and I was immediately transported back to an era when frontend development felt different. Better, even. The stack was CoffeeScript, HAML, and Rails' asset pipeline, and you know what? It was glorious. I know what you're thinking. "CoffeeScript? That thing died years ago. TypeScript won. Get over it. " And you're right. TypeScript did win. It's everywhere now, and for good reasons. But let me tell you why, after all these years, I still get a little nostalgic pang when I think about writing CoffeeScript, and why part of me still thinks it was the better language. The Rails Way: Opinionated and Proud First, let's set the scene. This was the golden age of Rails, when "convention over configuration" wasn't just a tagline. It was a philosophy that permeated everything. The asset pipeline handled all your JavaScript and CSS compilation. You'd drop a . coffee file in app/assets/javascripts, write your code, and Rails would handle the rest. No webpack configs, no Babel presets, no decision fatigue about which bundler to use. Your views lived in HAML files that looked like this: . user-profile . header %h1= @user. name %p. bio= @user. bio . actions = link_to "Edit Profile", edit_user_path(@user), class: "btn btn-primary" = link_to "Delete Account", user_path(@user), method: :delete, data: { confirm: "Are you sure? " }, class: "btn btn-danger" And your JavaScript looked like this: class UserProfile... --- - Published: 2025-11-28 - Modified: 2025-11-30 - URL: https://www.ivanturkovic.com/2025/11/28/the-hidden-economics-of-free-ai-tools-why-the-saas-premium-still-matters/ - Categories: AI, development, productivity, startup, success This post discusses the hidden costs of DIY solutions in SaaS, emphasizing the benefits of established SaaS tools over "free" AI-driven alternatives. It highlights issues like time tax, knowledge debt, reliability, support challenges, security risks, and scaling problems. Ultimately, it advocates for a balanced approach that leverages AI to enhance, rather than replace, reliable SaaS infrastructure. This is Part 2 of my series on the evolution of SaaS. If you haven't read Part 1: The SaaS Model Isn't Dead, it's Evolving Beyond the Hype of "Vibe Coding", start there for the full context. In this post, I'm diving deeper into the hidden costs that most builders don't see until it's too late. In my last post, I argued that SaaS isn't dead, it's just evolving beyond the surface-level appeal of vibe coding. Today, I want to dig deeper into something most builders don't realize until it's too late: the hidden costs of "free" AI-powered alternatives. Because here's the uncomfortable truth: when you replace a $99/month SaaS tool with a Frankenstein stack of AI prompts, no-code platforms, and API glue, you're not saving money. You're just moving the costs somewhere else, usually to places you can't see until they bite you. Let's talk about what really happens when you choose the "cheaper" path. The Time Tax: When Free Becomes Expensive Picture this: you've built your "MVP" in a weekend. It's glorious. ChatGPT wrote half the code, Zapier connects your Airtable to your Stripe account, and a Make. com scenario handles email notifications. Total monthly cost? Maybe $20 in API fees. You're feeling like a genius. Then Monday morning hits. A customer reports an error. The Zapier workflow failed silently. You spend two hours digging through logs (when you can find them) only to discover that Airtable changed their API rate limits, and now your automation hits them... --- - Published: 2025-11-26 - Modified: 2025-11-30 - URL: https://www.ivanturkovic.com/2025/11/26/rails-templating-showdown-slim-vs-erb-vs-haml-vs-phlex-which-one-should-you-use/ - Categories: ruby, ruby on rails This guide compares Ruby on Rails templating engines: ERB, Slim, Haml, and Phlex. It highlights each engine's pros and cons, focusing on aspects like performance, readability, and learning curve. Recommendations are made based on project type, emphasizing the importance of choosing the right engine for optimal efficiency and maintainability. If you've been working with Ruby on Rails for any length of time, you've probably encountered the age-old question: which templating engine should I use? With ERB as the default, Slim and Haml as popular alternatives, and Phlex as the new kid on the block, the choice can feel overwhelming. In this comprehensive guide, I'll break down each option, compare their strengths and weaknesses, and help you make an informed decision for your Rails projects. Understanding the Landscape Before diving into specifics, let's understand what we're comparing. Template engines are tools that help you generate HTML dynamically by embedding Ruby code within markup. Each engine has a different philosophy about how this should be done. ERB (Embedded Ruby) What is it? ERB is Rails' default templating engine. It embeds Ruby code directly into HTML using special tags. Syntax Example Admin Pros Zero Learning Curve: If you know HTML and Ruby, you already know ERB. There's no new syntax to learn, making it perfect for beginners and mixed teams. Universal Support: Every Rails developer knows ERB. Every gem, tutorial, and Stack Overflow answer uses ERB. This ubiquity is valuable. No Setup Required: It works out of the box with every Rails installation. No gems to add, no configuration needed. Familiar to Other Ecosystems: The concept of embedding code in angle brackets exists in PHP, ASP, JSP, and many other frameworks. Developers coming from other backgrounds will feel at home. Cons Verbose: Writing closing tags for everything gets tedious. Your files become... --- - Published: 2025-11-20 - Modified: 2025-11-20 - URL: https://www.ivanturkovic.com/2025/11/20/why-ai-startups-should-choose-rails-over-python/ - Categories: AI, ruby, ruby on rails AI startups often fail due to challenges in supporting layers and product development rather than model quality. Rails offers a fast and structured path for founders to build scalable applications, integrating seamlessly with AI services. While Python excels in research, Rails is favored for production, facilitating swift feature implementation and reliable infrastructure. TLDR; Most AI startups fail because they cannot ship a productnot because the model is not good enoughRails gives founders the fastest path from idea to revenuePython is still essential for research but Rails wins when the goal is to build a business. The Real Challenge in AI Today People love talking about modelsbenchmarkstraining runstokenscontext windowsall the shiny parts But none of this is why AI startups fail Startups fail because the supporting layers around the model are too slow to build: Onboarding systems Billing and subscription logic Admin dashboards User management Customer support tools Background processing Iterating on new features Fixing bugs Maintaining stability The model is never the bottleneckThe product isThis is exactly where Rails becomes your unfair advantage Why Rails Gives AI Startups Real Speed Rails focuses on shippingIt gives you a complete system on day oneThe framework removes most of the decisions that slow down small teamsInstead of assembling ten libraries you just start building The result is simpleA solo founder or a tiny team can move with the speed of a full engineering department,Everything feels predictable,Everything fits together,Everything works the moment you touch it. Python gives you freedom,Rails gives you momentum,Momentum is what gets a startup off the ground. Rails and AI Work Together Better Than Most People Think There is a common myth that AI means PythonOnly partially truePython is the best language for training and experimentingBut the moment you are building a feature for real users you need a framework that is designed... --- - Published: 2025-11-19 - Modified: 2025-11-18 - URL: https://www.ivanturkovic.com/2025/11/19/the-ai-native-rails-app-what-a-2025-architecture-looks-like/ - Categories: Uncategorized Introduction For the first time in decades of building products, I’m seeing a shift that feels bigger than mobile or cloud. AI-native architecture isn’t “AI added into the app” it’s the app shaped around AI from day one. In this new world: Rails is no longer the main intelligence layer Rails becomes the orchestrator The AI systems do the thinking The Rails app enforces structure, rules, and grounding And honestly? Rails has never felt more relevant than in 2025. In this post, I’m breaking down exactly what an AI-native Rails architecture looks like today, why it matters, and how to build it with real, founder-level examples from practical product work. 1. AI-Native Rails vs. AI-Powered Rails Many apps today use AI like this: User enters text → you send it to OpenAI → you show the result That’s not AI-native. That’s “LLM glued onto a CRUD app. ” AI-native means: Your DB supports vector search Your UI expects streaming Your workflows assume LLM latency Your logic expects probabilistic answers Your system orchestrates multi-step reasoning Your workers coordinate long-running tasks Your app is built around contextual knowledge, not just forms A 2025 AI-native Rails stack looks like this: Rails 7/8 Hotwire (Turbo + Stimulus) Sidekiq or Solid Queue Postgres with PgVector OpenAI, Anthropic, or Groq APIs Langchain. rb for tooling and structure ActionCable for token-by-token streaming Comprehensive logging and observability This is the difference between a toy and a business. 2. Rails as the AI Orchestrator AI-native architecture can be summarized... --- - Published: 2025-11-18 - Modified: 2025-11-18 - URL: https://www.ivanturkovic.com/2025/11/18/the-two-hardest-problems-in-software-development-naming-things-cache-invalidation/ - Categories: AI, ruby, ruby on rails The post discusses the common struggles developers face with naming conventions and cache invalidation, humorously portraying them as universal challenges irrespective of experience or technology. It emphasizes that while AI and Ruby tools assist in these areas, the inherent complexities require human reasoning. Ultimately, these issues highlight the uniquely human aspects of software development. A joke. A reality. A shared developer trauma now with AI and Ruby flavor. Every industry has its running jokes. Lawyers have billable hours. Doctors have unreadable handwriting. Accountants battle ancient spreadsheets. Developers? We have two immortal bosses at the end of every level: 1. Naming things2. Cache invalidation These aren’t just memes. They’re universal rites of passage, the kind of problems that don’t care about your stack, your years of experience, or your productivity plans for the day. And as modern as our tools get, these two battles remain undefeated. 1. Naming Things: A Daily Existential Crisis You would think building multi-region distributed systems or designing production-grade blockchains is harder than deciding how to name a method. But no. Naming is where confidence goes to die. There’s something profoundly humbling about: Typing data, deleting it, typing result, deleting it, typing payload, staring at it, deleting it again, then settling on something like final_sanitized_output and hoping future-you understands the intention. Naming = Thinking A name isn’t just a word. It’s a miniature problem statement. A good name answers: What is this? Why does it exist? What is it supposed to do? Is it allowed to change? Should anyone else touch it? A bad name answers none of that but invites everyone on your team to ping you on Slack at 22:00 asking “hey what does temp2 mean? ” Not being a native English speaker? Welcome to the Hard Mode DLC For those of us whose brain grew up in Croatian... --- - Published: 2025-11-16 - Modified: 2025-12-01 - URL: https://www.ivanturkovic.com/2025/11/16/pgvector-for-ai-memory-in-production-applications/ - Categories: AI, productivity PgVector is a PostgreSQL extension designed to enhance memory in AI applications by storing and querying vector embeddings. This enables large language models (LLMs) to retrieve accurate information, personalize responses, and reduce hallucinations. PgVector's efficient indexing and simple integration provide a reliable foundation for AI memory, making it essential for developers building AI products. Introduction As AI moves from experimentation into real products, one challenge appears over and over again: memory. Large language models (LLMs) are incredibly capable, but they can’t store long-term knowledge about users or applications out-of-the-box. They respond only to what they see in the prompt and once the prompt ends, the memory disappears. This is where vector databases and especially PgVector step in. PgVector is a PostgreSQL extension that adds first-class vector similarity search to a database you probably already use. With its rise in popularity especially in production AI systems it has become one of the simplest and most powerful ways to build AI memory. This post is a deep dive into PgVector, how it works, why it matters, and how to implement it properly for real LLM-powered features. What Is PgVector? PgVector is an open-source PostgreSQL extension that adds support for storing and querying vector data types. These vectors represent high‑dimensional numerical representations embeddings generated from AI models. Examples: A sentence embedding from OpenAI might be a vector of 1,536 floating‑point numbers. An image embedding from CLIP might be 512 or 768 numbers. A user profile embedding might be custom‑generated from your own model. PgVector lets you: Store these vectors Index them efficiently Query them using similarity search (cosine, inner product, Euclidean) This enables your LLM applications to: Retrieve knowledge Add persistent memory Reduce hallucinations Add personalization or context Build recommendation engines And all of that without adding a new complex piece of infrastructure because it works inside... --- - Published: 2025-11-14 - Modified: 2025-12-01 - URL: https://www.ivanturkovic.com/2025/11/14/saving-money-with-embeddings-in-ai-memory-systems-why-ruby-on-rails-is-perfect-for-langchain/ - Categories: AI, development, ruby, ruby on rails In the exploration of AI memory systems and embeddings, the author highlights the hidden costs in AI development, emphasizing token management. Leveraging Ruby on Rails streamlines the integration of LangChain for efficient memory handling. Adopting strategies like summarization and selective retrieval significantly reduces expenses, while maintaining readability and scalability in system design. Over the last few months of rebuilding my Rails muscle memory, I’ve been diving deep into AI memory systems and experimenting with embeddings. One of the biggest lessons I’ve learned is that the cost of building AI isn’t just in the model it’s in how you use it. Tokens, storage, retrieval these are the hidden levers that determine whether your AI stack remains elegant or becomes a runaway expense. And here’s the good news: with Ruby on Rails, managing these complexities becomes remarkably simple. Rails has always been about turning complicated things into something intuitive and maintainable and when you pair it with LangChain, it feels like magic. Understanding the Cost of Embeddings Most people think that running large language models is expensive because of the model itself. That’s only partially true. In practice, the real costs come from: Storing too much raw content: Every extra paragraph you embed costs more in tokens, both for the embedding itself and for later retrieval. Embedding long texts instead of summaries: LLMs don’t need the full novel they often just need the distilled version. Summaries are shorter, cheaper, and surprisingly effective. Retrieving too many memories: Pulling 50 memories for a simple question can cost more than the model call itself. Smart retrieval strategies can drastically cut costs. Feeding oversized prompts into the model: Every extra token in your prompt adds up. Cleaner prompts = cheaper calls. I’ve seen projects where embedding every word of a document seemed “safe,” only to realize months later... --- - Published: 2025-11-11 - Modified: 2025-11-11 - URL: https://www.ivanturkovic.com/2025/11/11/the-saas-model-isnt-dead-its-evolving-beyond-the-hype-of-vibe-coding/ - Categories: AI, development, startup, success The article critiques the rise of "vibe coding," emphasizing the distinction between quick prototypes and genuine MVPs. It argues that while AI can accelerate product development, true success relies on accountability, stability, and structure. Ultimately, SaaS is evolving, prioritizing reliable infrastructure and reinforcement over mere speed and creativity. “The SaaS model is dead. Long live vibe-coded AI scripts. ” That’s the kind of hot take lighting up LinkedIn half ironic, half prophetic. Why pay $99/month for a product when you can stitch together 12 AI prompts, 3 no-code hacks, and a duct-taped Python script you barely understand? Welcome to vibe coding. It feels fast. It feels clever. Until the vibes break and no one knows why. The Mirage of Instant Software We live in an era of speed. AI gives us instant answers, mockups, and even “apps. ” The line between prototype and product has never been thinner and that’s both empowering and dangerous. What used to take months of product design, testing, and iteration can now be faked in a weekend. You can prompt ChatGPT to generate a working landing page, use Bubble or Replit for logic, and Zapier to glue it all together. Boom “launch” your MVP. But here’s the truth no one wants to say out loud:Most of these AI-fueled prototypes aren’t MVPs. They’re demos with good lighting. A real MVP isn’t about how fast you can ship; it’s about how reliably you can learn from what you ship. And learning requires stability. You can’t measure churn or retention when your backend breaks every other day. You can’t build trust when your app crashes under 20 users. That’s when the vibes start to fade. The Boring Truth Behind Great Products Let’s talk about what SaaS really sells. It’s not just the product you see it’s... --- - Published: 2025-10-30 - Modified: 2025-11-06 - URL: https://www.ivanturkovic.com/2025/10/30/artesanal-coding-%e8%81%b7%e4%ba%ba%e3%82%b3%e3%83%bc%e3%83%87%e3%82%a3%e3%83%b3%e3%82%b0-a-manifesto-for-the-next-era-of-software-craftsmanship/ - Categories: AI, development - Tags: AI ethics, AI in programming, artesanal coding, code quality, developer mindset, human creativity, software craftsmanship Artesanal coding emphasizes the importance of craftsmanship in software development amidst the rise of AI and "vibe coding." It advocates for intentional, quality-driven coding practices that foster deep understanding and connection to the code. By balancing AI assistance with craftsmanship, developers can preserve their skills and create sustainable, high-quality software. In an age where code seems to write itself and AI promises to make every developer “10x faster,” something essential has quietly started to erode our craftsmanship. I call the counter-movement to this erosion artisanal coding. Like artisanal bread or craft coffee, artisanal coding is not about nostalgia or resistance to progress. It’s about intentionality, quality, and soul; things that can’t be automated, templated, or generated in bulk. It’s the human touch in a field that’s rushing to outsource its own intuition. What Is Artisanal Coding (職人コーディング)? Artisanal coding is the conscious resistance to that decay. It’s not anti-AI, it’s anti-carelessness. It’s the belief that the best code is still handmade, understood, and cared for. Think of an artisan carpenter. He can use power tools but he knows when to stop and sand by hand. He knows the wood, feels its resistance, and adjusts. He doesn’t mass-produce he perfects. Artisanal coding applies that mindset to software. It’s about: Understanding the problem before touching the code. Writing it line by line, consciously. Refactoring not because a tool says so, but because you feel the imbalance. Learning from your errors instead of patching them away. It’s slow. It’s deliberate. And that’s the point. Artisanal coding is the deliberate act of writing software by hand, with care, precision, and understanding. It’s the opposite of what I call vibe coding the growing trend of throwing AI-generated snippets together, guided by vibes and autocomplete rather than comprehension. This is not about rejecting tools it’s about... --- - Published: 2025-10-28 - Modified: 2025-10-28 - URL: https://www.ivanturkovic.com/2025/10/28/brainrot-and-the-slow-death-of-code/ - Categories: AI, development The rise of AI tools in software development is leading to a decline in genuine coding skills, as developers increasingly rely on automation. This reliance dampens critical thinking and creativity, replacing depth with superficial efficiency. Ultimately, the industry risks producing inferior code devoid of understanding, undermining the essence of craftsmanship in programming. It’s an uncomfortable thing to say out loud, but we’re witnessing a slow decay of human coding ability a collective brainrot disguised as progress. AI tools are rewriting how we build software. Every week, new developers boast about shipping apps in a weekend using AI assistants, generating entire APIs, or spinning up SaaS templates without understanding what’s going on beneath the surface. At first glance, this looks like evolution a leap forward for productivity. But beneath that veneer of efficiency, something essential is being lost. Something deeply human. The Vanishing Craft Coding has always been more than just typing commands into a terminal. It’s a way of thinking. It’s logic, structure, and creativity fused into a single process the art of turning chaos into clarity. But when that process is replaced by autocomplete and code generation, the thinking disappears. The hands still move, but the mind doesn’t wrestle with the problem anymore. The apprentice phase the long, painful, necessary stage of learning how to structure systems, debug, refactor, and reason gets skipped. And that’s where the rot begins. AI gives us perfect scaffolding but no understanding of the architecture. Developers start to “trust” the model more than themselves. Code review becomes an act of blind faith, and debugging turns into a guessing game of prompts. The craft is vanishing. We Are Losing Muscle Memory Just like a musician who stops practicing loses touch with their instrument, coders are losing their “muscle memory. ” When you stop writing code line by... --- - Published: 2025-10-24 - Modified: 2025-10-23 - URL: https://www.ivanturkovic.com/2025/10/24/the-art-of-reusability-and-why-ai-still-doesnt-understand-it/ - Categories: AI, development, ruby AI can generate code but lacks understanding of design intent, making it struggle with reusability. True reusability involves encoding shared ideas and understanding context, which AI cannot grasp. This leads to overgeneralized or underabstracted code. Effective engineering requires human judgment and foresight that AI is currently incapable of providing. After writing about the team that deleted 200,000 lines of AI-generated code without breaking their app, a few people asked me: “If AI is getting so good at writing code, why can’t it also reuse code properly? ” That’s the heart of the problem. AI can produce code. It can suggest patterns. But it doesn’t understand why one abstraction should exist and why another should not. It has no concept of design intent, evolution over time, or maintainability. And that’s why AI-generated code often fails at the very thing great software engineering is built upon: reusability. Reusability Isn’t About Copying Code Let’s start with what reusability really means. It’s not about reusing text. It’s about reusing thought. When you make code reusable, you’re encoding an idea a shared rule or process in one place, so it can serve multiple contexts. That requires understanding how your domain behaves and where boundaries should exist. Here’s a small example in Ruby 3. 4: # A naive AI-generated version class InvoiceService def create_invoice(customer, items) total = items. sum { |i| i * i } tax = total * 0. 22 { customer: customer, total: total, tax: tax, grand_total: total + tax } end def preview_invoice(customer, items) total = items. sum { |i| i * i } tax = total * 0. 22 { preview: true, total: total, tax: tax, grand_total: total + tax } end end It works. It looks fine. But the duplication here is silent debt. A small tax change or business... --- - Published: 2025-10-23 - Modified: 2025-10-23 - URL: https://www.ivanturkovic.com/2025/10/23/the-ai-detox-movement-why-engineers-are-taking-back-their-code/ - Categories: AI, development, productivity - Tags: AI detox, Copilot, Cursor, developer productivity, engineering culture, focus, learning, programming, software craftsmanship In 2025, AI tools transformed coding but led developers to struggle with debugging and understanding their code. This sparked the concept of "AI detox," a period where developers intentionally stop using AI to regain coding intuition and problem-solving skills. A structured detox can improve comprehension, debugging, and creativity, fostering a healthier relationship with AI. The New Reality of Coding in 2025 Over the last year, something remarkable happened in the world of software engineering. AI coding tools Cursor, GitHub Copilot, Cody, Devin became not just sidekicks, but full collaborators. Autocomplete turned into full functions, boilerplate became one-liners, and codebases that once took weeks to scaffold could now appear in minutes. It felt like magic. Developers were shipping faster than ever. Teams were hitting deadlines early. Startups were bragging about “AI-assisted velocity. ” But behind that rush of productivity, something else began to emerge a quiet, growing discomfort. The Moment the Magic Fades After months of coding with AI, many developers hit the same wall. They could ship fast, but they couldn’t debug fast. When production went down, it became painfully clear: they didn’t truly understand the codebase they were maintaining. A backend engineer told me bluntly: “Cursor wrote the service architecture. I just glued things together. When it broke, I realized I had no idea how it even worked. ” AI wasn’t writing bad code it was writing opaque code. Readable but not intuitive. Efficient but alien. This is how the term AI detox started spreading in engineering circles developers deliberately turning AI off to reconnect with the craft they’d begun to lose touch with. What Is an AI Detox? An AI detox is a deliberate break from code generation tools like Copilot, ChatGPT, or Cursor to rebuild your programming intuition, mental sharpness, and problem-solving confidence. It doesn’t mean rejecting AI altogether. It’s about... --- - Published: 2025-10-21 - Modified: 2025-10-21 - URL: https://www.ivanturkovic.com/2025/10/21/when-200000-lines-of-ai-code-disappeared-and-nothing-broke/ - Categories: AI, development A team deleted 200,000 lines of AI-generated code yet maintained app functionality, highlighting the pitfalls of unchecked AI development. AI may accelerate chaos in weak systems, making existing issues worse. Effective engineering culture remains crucial; AI should enhance rather than replace human judgment in creating a quality codebase. A few weeks ago, someone I know a smart, capable engineering lead told me about their team’s strange success story. They deleted 200,000 lines of AI-generated code. And their app still worked. That alone tells you everything you need to know about the quiet cost of unchecked AI-assisted development. The project had originally been around 100,000 lines already a decent size for what it did. But over time, it ballooned to more than double that number. Most of the bloat came not from features or performance improvements, but from auto-generated boilerplate, duplicated logic, and abstractions no one really understood anymore. When they finally audited the system, they realized how much noise had crept in how much invisible entropy had been introduced under the banner of “productivity. ” They cleaned it up. They deleted code. They refactored by hand. And the product kept running, smoother than before. The Illusion of Productivity This is the side of AI coding no one talks about. Yes AI can make you faster. But “faster” at what, exactly? If your processes, architecture, and reviews are already weak, AI will accelerate your chaos. It doesn’t understand your domain. It doesn’t see the trade-offs. It just predicts what “looks right. ” And that’s exactly the problem: AI-generated code looks right. It compiles. It passes shallow tests. It feels complete. But under the surface, it’s often redundant, brittle, and opaque a kind of technical debt that doesn’t announce itself until you try to build on top of it. I’ve... --- - Published: 2025-10-17 - Modified: 2025-10-16 - URL: https://www.ivanturkovic.com/2025/10/17/why-ai-cant-yet-write-maintainable-software/ - Categories: AI, development In the past few years, large language models (LLMs) have burst onto the software development scene like a meteor bright, exciting, and full of promise. They can write entire applications in seconds, generate boilerplate code with ease, and explain complex algorithms in plain English. It’s hard not to be impressed. But after spending serious time testing various AI platforms as coding assistants, I’ve reached a clear conclusion: AI is not yet suitable for generating long-term, maintainable, production-grade software. It’s fantastic for prototyping, disposable tools, and accelerating development, but when it comes to real-world, evolving, multi-developer systems it falls short. And the root cause is simple but fundamental: non-determinism. The Non-Determinism Problem At the heart of every LLM lies a probabilistic process. When you ask an AI to write or modify code, it doesn’t “recall” what it said before it predicts the next most likely word or token based on the context it sees. Even when you give it the exact same prompt twice, you often get subtly (or wildly) different answers. In casual conversation, this doesn’t matter much. But in software engineering, determinism is sacred. A build must produce the same binary every time. Tests must behave consistently. A function’s output must depend solely on its input. LLMs break this rule by design. When you ask AI to “add a new field to this API,” it might add the field but it might also rename unrelated variables, adjust indentation styles, reorder imports, or subtly alter unrelated logic. These incidental changes... --- - Published: 2025-10-16 - Modified: 2025-10-16 - URL: https://www.ivanturkovic.com/2025/10/16/returning-to-the-rails-world-whats-new-and-exciting-in-rails-8-and-ruby-3-3/ - Categories: development, ruby, ruby on rails, startup, success It’s 2025, and coming back to Ruby on Rails feels like stepping into a familiar city only to find new skyscrapers, electric trams, and an upgraded skyline. The framework that once defined web development simplicity has reinvented itself once again. If you’ve been away for a couple of years, you might remember Rails 6 or early Rails 7 as elegant but slightly “classic. ”Fast-forward to today: Rails 8 and Ruby 3. 4 together form one of the most modern, high-performance, and full-stack ecosystems in web development. Let’s explore what changed from Ruby’s evolution to Rails’ latest superpowers. The Ruby Renaissance: From 3. 2 to 3. 4 Over the last two years, Ruby has evolved faster than ever. Performance, concurrency, and developer tooling have all received major love while the language remains as expressive and joyful as ever. Ruby 3. 2 (2023): The Foundation of Modern Ruby YJIT officially production-ready: Introduced a new JIT compiler written in Rust, delivering 20–40% faster execution on Rails apps. Prism Parser (preview): The groundwork for a brand-new parser that improves IDEs, linters, and static analysis. Regexp improvements: More efficient and less memory-hungry pattern matching. Data class proposal: Early syntax experiments to make small, immutable data structures easier to define. Ruby 3. 3 (2024): Performance, Async IO, and Stability YJIT 3. 3 update: Added inlining and better method dispatch caching big wins for hot code paths. Fiber Scheduler 2. 0: Improved async I/O great for background processing and concurrent network calls. Prism Parser shipped: Officially integrated,... --- - Published: 2025-10-15 - Modified: 2025-10-15 - URL: https://www.ivanturkovic.com/2025/10/15/what-you-should-learn-to-master-but-never-ship/ - Categories: AI, development, startup, success Every engineer should build a few things from scratch search, auth, caching just to understand how much complexity lives beneath the surface. But the real skill isn’t rolling your own; it’s knowing when not to. In the age of AI, understanding how things work under the hood isn’t optional it’s how you keep control over what your tools are actually doing. There’s a quiet rite of passage every engineer goes through. You build something that already exists. You write your own search algorithm. You design your own auth system. You roll your own logging framework because the existing one feels too heavy. And for a while, it’s exhilarating. You’re learning, stretching, discovering how the pieces actually work. But there’s a difference between learning and shipping. The Temptation to Reinvent Every generation of engineers rediscovers the same truth: we love building things from scratch. We tell ourselves our use case is different, our system is simpler, our constraints are unique. But the moment your code touches production when it has to handle real users, scale, security, and compliance you realize how deep the rabbit hole goes. Here’s a short list of what you probably shouldn’t reinvent if your goal is to ship something that lasts: Search algorithms Encryption Authentication Credit card handling Billing Caching systems Logging frameworks CSV, HTML, URL, JSON, XML parsing Floating point math Timezones Localization and internationalization Postal address handling Each one looks simple on the surface. Each one hides decades of hard-won complexity underneath. Learn It, Don’t Ship It You should absolutely build these things once. Do it for the same reason musicians practice scales or pilots train in simulators. You’ll understand the invisible edges where systems fail, what tradeoffs libraries make, how standards evolve. Build your own encryption to see why key rotation matters. Write your own caching layer to feel cache invalidation pain firsthand. Parse CSVs... --- - Published: 2025-10-11 - Modified: 2025-10-16 - URL: https://www.ivanturkovic.com/2025/10/11/ai-vibe-coding-vs-outsourcing-vs-local-developers-what-really-works-best/ - Categories: AI, development The way we build software is changing fast. You can now code alongside AI in real time. You can hire an offshore team across time zones. Or you can build with local developers right next to you the old-school way that suddenly feels new again. Each model works, but they work differently. And when it comes to product quality, iteration speed, and long-term success only one consistently delivers. Let’s unpack all three, step by step. AI Vibe Coding is Building at the Speed of Thought AI vibe coding is when you work directly with AI tools like ChatGPT, Claude, or GitHub Copilot as your pair developer. It’s not about asking for snippets it’s about co-developing live. You describe your intent, get code, refine it instantly, and iterate in a tight feedback loop. Process (Pseudocode-Style) while (building_feature): describe_intent_to_ai("Create an onboarding flow with email + OAuth") ai. generates_scaffold you. review_and_edit_live ai. adjusts_structure_and_tests run_tests deploy_if_ready Pros Extremely fast iteration Context-aware (if you prompt consistently) Great for prototyping and boilerplate Ideal for solo founders or small teams Cons Requires strong technical judgment AI lacks product intuition and domain empathy Risk of hidden bugs or overconfidence in generated code Limited long-term maintainability without review AI vibe coding accelerates early-stage building but it still needs human oversight, structured review, and context. It’s great for speed, not yet for strategy. Outsourcing Development, Slow Communication, Slow Momentum Outsourcing means hiring remote developers (often overseas) to build parts or all of your product. The promise: cost savings and flexibility.... --- - Published: 2025-10-08 - Modified: 2025-10-08 - URL: https://www.ivanturkovic.com/2025/10/08/%e2%86%92-bi-%e2%86%92-ml-%e2%86%92-ai-%e2%86%92/ - Categories: AI, startup, success AI's past and the future Where acronyms in business come from, what they sold, who won, and what might come after “AI” Acronyms are the currency of business storytelling. They compress complex technology into a neat package a salesperson can pitch in a single slide: CRM, ERP, BI, ML, AI. Each one marked a shift in what companies sold to their customers and how value was captured. I want to walk through that history briefly, honestly, with business examples and what “winning” looked like in each era and then make a practical, evidence-based prediction for what comes after AI. I’ll finish with concrete signs companies and entrepreneurs should watch if they want to be on the winning side next. The pre-acronym age: data collectors and automation (before CRM/ERP took over) Before the catchy three-letter packages, businesses bought automation and niche systems: financial ledgers, bespoke reporting scripts, and the earliest mainframe systems. The selling point was efficiency: replace paper, reduce human error, scale payroll or accounting. Winners: large system integrators and early software firms that could deliver reliability and scale. Value to the customer was operational: fewer mistakes, faster month-end closes, predictable processes. This era set the expectation that software replaces tedious human work an expectation every later acronym exploited and monetized. CRM / ERP the era of process standardization and cross-company suites Acronyms like ERP and CRM told customers what problem a vendor solved: enterprise resource planning for the core business, customer relationship management for sales and marketing. The message... --- - Published: 2025-09-29 - Modified: 2025-09-29 - URL: https://www.ivanturkovic.com/2025/09/29/the-vibe-code-tax/ - Categories: AI, development, startup, success Momentum is the oxygen of startups. Lose it, and you suffocate. Getting it back is harder than creating it in the first place. Here’s the paradox founders hit early: Move too slowly searching for the “perfect” technical setup, and you’re dead before you start. Move too fast with vibe-coded foundations, and you’re dead later in a louder, more painful way. Both paths kill. They just work on different timelines. Death by Hesitation Friendster is a perfect example of death by hesitation. They had the idea years before Facebook. They had users. They had momentum. But their tech couldn’t scale, and instead of fixing it fast, they stalled. Users defected. Momentum bled out. By the time they moved, Facebook and MySpace had already eaten their lunch. That’s hesitation tax: waiting, tinkering, second-guessing while the world moves on. Death by Vibe Coding On the flip side, you get the vibe-coded death spiral. Take Theranos. It wasn’t just fraud, it was vibe coding at scale. Demos that weren’t real. A prototype paraded as a product. By the time the truth surfaced, they’d burned through billions and a decade of time. Or look at Quibi. They raced to market with duct-taped assumptions the whole business was a vibe-coded bet that people wanted “TV, but shorter. ” $1. 75 billion later, they discovered the foundation was wrong. That’s the danger of mistaking motion for progress. The Right Way to Use Vibe Coding Airbnb is the counterexample. Their first site was duct tape. Payments were hacked... --- - Published: 2025-09-25 - Modified: 2025-09-25 - URL: https://www.ivanturkovic.com/2025/09/25/is-ai-slowing-everyone-down/ - Categories: AI, productivity, success Over the past year, we’ve all witnessed an AI gold rush. Companies of every size are racing to “adopt AI” before their competitors do, layering chatbots, content tools, and automation into their workflows. But here’s the uncomfortable question: is all of this actually making us more productive, or is AI quietly slowing us down? A new term from Harvard Business Review “workslop” captures what many of us are starting to see. It refers to the flood of low-quality, AI-generated work products: memos, reports, slide decks, emails, even code snippets. The kind of content that looks polished at first glance, but ultimately adds little value. Instead of clarity, we’re drowning in noise. The Illusion of Productivity AI outputs are fast, but speed doesn’t always equal progress. Generative AI makes it effortless to produce content, but that ease has created a different problem: oversupply. We’re seeing more documents, more proposals, more meeting summaries but much of it lacks originality or critical thought. When employees start using AI as a crutch instead of a tool, the result is extra layers of text that someone else has to review, fix, or ignore. What feels like efficiency often leads to more time spent filtering through workslop. The productivity gains AI promises on paper are, in practice, canceled out by the overhead of sorting the useful from the useless. Numbers Don’t Lie The MIT Media Lab recently published a sobering study on AI adoption. After surveying 350 employees, analyzing 300 public AI deployments, and interviewing 150... --- - Published: 2025-09-14 - Modified: 2025-09-14 - URL: https://www.ivanturkovic.com/2025/09/14/cto-lessons-leadership-product-ai/ - Categories: AI, development, success Being a CTO isn’t what it looks like from the outside. There are no capes, no magic formulas, and certainly no shortcuts. After more than two decades leading engineering teams, shipping products, and navigating the chaos of startups and scale-ups, I’ve realized that the real challenges and the real lessons aren’t technical. They’re human, strategic, and sometimes painfully simple. Here are the lessons that stuck with me, the ones I wish someone had told me when I started. Clarity beats speed every time Early in my career, I thought speed meant writing more code, faster. I would push engineers to “ship now,” measure velocity in lines of code or story points, and celebrate sprint completions. I was wrong. The real speed comes from clarity. Knowing exactly what problem you’re solving, who it matters to, and why it matters that’s what lets a team move fast. I’ve seen brilliant engineers grind for weeks only to realize they built the wrong thing. Fewer pivots, fewer surprises, and focus make a team truly fast. Engineers want to care, they just need context One of the most frustrating things I’ve witnessed is engineers shrugging at product decisions. “They just don’t care,” I thought. Until I realized: they do care. They want to make an impact. But when they don’t have context, the customer pain, the market reality, the business constraints,they can’t make informed decisions. Once I started sharing the “why,” not just the “what,” engagement skyrocketed. A well-informed team is a motivated team. Vision... --- - Published: 2025-09-12 - Modified: 2025-09-12 - URL: https://www.ivanturkovic.com/2025/09/12/cocoa-chocolate-and-why-ai-still-cant-discover/ - Categories: AI, development Imagine standing in front of a freshly picked cocoa pod. You break it open, and inside you find a pale, sticky pulp with bitter seeds. Nothing looks edible, nothing smells particularly appetizing. By every reasonable measure, this is a dead end. Yet humanity somehow didn’t stop there. Someone, centuries ago, kept experimenting, steps that made no sense at the time: Picking out the seeds and letting them ferment until they grew mold. Washing and drying them for days, though still inedible. Roasting them into something crunchy, still bitter and strange. Grinding them into powder, which tasted worse. Finally, blending that bitterness with sugar and milk, turning waste into one of the most beloved foods in human history: chocolate. No algorithm would have told you to keep going after the first dozen failures. There was no logical stopping point, only curiosity, persistence, and maybe a bit of luck. The discovery of cocoa as food wasn’t the result of optimization, it was serendipity. Why This Matters for AI AI today is powerful at recombining, predicting, and optimizing. It can remix what already exists, generate new connections from vast data, and accelerate discoveries we’re already aiming toward. But there’s a limit: AI doesn’t (yet) explore dead ends with stubborn curiosity. It doesn’t waste time on paths that appear pointless. It doesn’t ferment bitter seeds and wait for mold to form, just to see if maybe, somehow, there’s something new hidden inside. Human discovery has always been messy, nonlinear, and often illogical. The journey... --- - Published: 2025-09-08 - Modified: 2025-09-08 - URL: https://www.ivanturkovic.com/2025/09/08/hire-real-engineers-mvp/ - Categories: AI, development Building a startup is a race against time. Every day you wait to ship your idea is a day your competitors could gain an edge. That’s why many founders start with freelancers or “vibe coding” to launch their MVP (Minimum Viable Product) quickly. But this fast-track approach comes with hidden risks. There comes a point when hiring real engineers is no longer optional, it’s critical for your startup’s survival. In this post, we’ll explore when it’s the right time to transition from freelancers to full-time engineers, and why vibe coding with low-cost freelancers can be dangerous for your MVP. Why Start With Freelancers? Freelancers are often the first choice for early-stage founders. Here’s why: Speed: Freelancers can help you quickly prototype your idea. Lower Cost: You pay for work done, without the overhead of full-time salaries or benefits. Flexibility: You can scale the workforce up or down depending on the project stage. Freelancers are perfect for validating your idea, testing market demand, or building proof-of-concept features. However, relying on freelancers too long can create technical debt and slow your growth when your product starts attracting real users. The Hidden Dangers of Vibe Coding With Low-Cost Freelancers Many founders are tempted by freelancers offering extremely low rates. While the idea of saving money is appealing, vibe coding with bargain-rate developers comes with serious risks: Poor Code Quality: Low-cost freelancers may cut corners, leaving messy, unmaintainable code. Lack of Documentation: Your codebase may be difficult for future engineers to understand or build... --- - Published: 2025-08-25 - Modified: 2025-08-26 - URL: https://www.ivanturkovic.com/2025/08/25/why-lines-of-code-is-the-wrong-way-to-measure-ai-productivity-in-software-development/ - Categories: Uncategorized Last week, I had a conversation with another CTO that got me thinking about how we measure productivity in the age of AI-assisted software development. Here’s how it went: CTO: Right now, about 70% of our software output is generated by AI. Me: Interesting. How are you measuring that? CTO: By looking at the proportion of code that AI tools contribute during check-ins. Me: But what if the AI produces ten times more code than a human would to solve the same problem? Doesn’t that risk adding unnecessary complexity and future technical debt? That short exchange captures a much bigger problem: we are still in the earliest innings of understanding how AI fits into the software development lifecycle (SDLC). And one thing is already clear, measuring lines of code is not the way forward. The Myth of Lines of Code as a Metric The idea that "more lines of code = more productivity" has always been flawed. Good engineering has never been about who can write the most code. It's about solving problems in the most effective and maintainable way possible. A senior engineer might solve a business-critical feature in 20 lines of clean, tested code, while a less experienced developer or now, an AI might churn out 200 lines to accomplish the same thing. On paper, the latter looks "more productive," but in practice, they’ve just created more surface area for bugs, maintenance, and future refactoring. When AI is added into the mix, this risk multiplies. Large language models... --- - Published: 2025-07-28 - Modified: 2025-07-28 - URL: https://www.ivanturkovic.com/2025/07/28/ai-generated-code-maintainability/ - Categories: AI, development Over the past two years, I’ve been using various AI-assisted tools for programming like Codeium, GitHub Copilot, ChatGPT, and others. These tools have become part of my daily workflow. Mostly, I use them for code completion and to help me finish thoughts, suggest alternatives, or fill in repetitive boilerplate. I’m not doing anything too wild with autonomous agents or fully automated codebases. Just practical, incremental help. That said, even in this limited use, I’m starting to feel the friction. Not because the tools are bad but actually, they’re improving fast. Individual lines and even complete methods are cleaner than they used to be. The suggestions are smarter. The models are more context-aware. But one thing still nags at me: even with better completions, a lot of the output still isn’t good code in the long-term sense. Maintainability Still Matters The issue, to me, isn't whether AI can help me write code faster. It can. The issue is whether that code is going to survive over time. Is it going to be easy to understand, extend, or refactor? Does it follow a style or pattern that another human could step into and build on? This matters especially when you’re not the only one touching the code or when you come back to it after a few months and wonder, “Why did I do it this way? ” And here’s the contradiction I keep running into: AI helps you write code faster, but it often creates more problems to maintain. That’s especially... --- - Published: 2025-05-22 - Modified: 2025-05-22 - URL: https://www.ivanturkovic.com/2025/05/22/llm-generated-code-liability/ - Categories: AI, development Large Language Models (LLMs) like ChatGPT, Copilot, and others are becoming a regular part of software development. Many developers use them to write boilerplate code, help with unfamiliar syntax, or even generate whole modules. On the surface, it feels like a productivity boost. The work goes faster, the PRs are opened sooner, and there’s even time left for lunch. But there’s something underneath this speed, something we’re not talking about enough. The real issue with LLM-generated code is not that it helps us ship more code, faster. The real issue is liability. Code That Nobody Owns There’s a strange effect happening in teams using AI to generate code: nobody feels responsible for it. It’s like a piece of code just appeared in your codebase. Sure, someone clicked “accept,” but no one really thought through the consequences. This is not new, we saw the same thing with frameworks and compilers that generated code automatically. If no human wrote it, then no human cares deeply about maintaining or debugging it later. LLMs are like that, but on a massive scale. The "Average" Problem LLMs are trained on a massive corpus of public code. What they produce is a kind of rolling average of everything they’ve seen. That means the code they generate isn’t written with care or with deep understanding of your system. It’s not great code. It’s average code. And as more and more people use LLMs to write code, and that code becomes part of new training data, the model... --- - Published: 2025-05-15 - Modified: 2025-05-22 - URL: https://www.ivanturkovic.com/2025/05/15/ai-widening-gap-juniors-vs-seniors/ - Categories: AI, development We were told that AI would make development more accessible. That it would “level the playing field,” empower juniors, and help more people build great software. That’s not what I’m seeing. In reality, AI is widening the gap between junior and senior developers and fast. Seniors Are 10x-ing With AI For experienced engineers, AI tools like ChatGPT and GitHub Copilot are a multiplier. Why? Because they know: What to ask How to evaluate the answers What matters in their system How to refactor and harden code When to ignore the suggestion completely Seniors are using AI the same way a great chef uses a knife: faster, safer, more precise. Juniors Are Being Left Behind Many junior developers, especially those early in their careers, don’t yet have the experience to judge what’s good, bad, or dangerous. And here’s the issue: AI makes it look like they’re productive until it’s time to debug, optimize, or maintain the code. They’re often: Copy-pasting solutions without understanding the trade-offs Relying on AI to write tests they wouldn’t know how to write themselves Shipping code that works on the surface, but is fragile underneath What they’re building is a slow-burning fire of tech debt, and they don’t even see the smoke. Prompting Isn’t Engineering There’s a new kind of developer emerging: one who can write a great prompt but can’t explain a stack trace. That might sound harsh, but I’ve seen it first-hand. Without a foundation in problem-solving, architecture, debugging, and security prompting becomes a crutch,... --- - Published: 2025-05-01 - Modified: 2025-04-26 - URL: https://www.ivanturkovic.com/2025/05/01/workers-day-ai-future-developers/ - Categories: Uncategorized Every May 1st, we celebrate Workers' Day a moment to recognize the hard work, progress, and dignity of people across every profession. Traditionally, it’s a day to honor laborers, craftsmen, and knowledge workers alike. Today, in 2025, it’s worth asking: What does Workers' Day mean for developers, engineers, and tech builders when AI is rewriting the rules of work? Software development once a purely manual craft is being transformed. AI coding assistants, automated testing, and AI-driven architecture design are fundamentally reshaping what "developer work" looks like. This shift is both exciting and unsettling. And on a day meant to honor workers, it’s important to pause, reflect, and imagine the future of our profession. Developers and the Changing Nature of Work Writing software has historically been seen as highly skilled, highly manual labor an exercise in translating human logic and creativity into machine instructions. It’s an intellectual craft. But the arrival of advanced AI tools like GitHub Copilot, ChatGPT, and autonomous coding agents is shifting where the true value lies: Repetitive coding is being automated. Simple application patterns are being commoditized. Technical excellence is being augmented and sometimes replaced by strategic and creative excellence. Just as factory workers once faced automation during the industrial revolutions, developers today are facing an "intellectual automation" wave. The tasks that defined junior and even mid-level engineering roles are changing fast. AI Is Not Eliminating Developers. But It's Redefining Them There’s a common fear that AI will “replace” developers. That’s not exactly what's happening. Instead, AI... --- - Published: 2025-04-26 - Modified: 2025-04-26 - URL: https://www.ivanturkovic.com/2025/04/26/ai-coding-and-product-thinking/ - Categories: AI AI is changing how we write code. But there’s a critical question not enough teams are asking: Is it helping us build the right thing? From GitHub Copilot to ChatGPT and beyond, the latest AI tools are letting engineers generate code faster than ever before. But faster coding doesn’t automatically mean better outcomes. It just means we get to the wrong destination quicker unless we rethink how we build. If you’re a founder, CTO, engineer, or investor, this shift matters. Because in this new landscape, the real competitive edge isn’t AI-enhanced productivity. It’s clarity of vision, deep user understanding, and ruthless focus on solving the right problems. AI Code Generation: Speed Boost or Strategy Trap? The appeal of AI tools is obvious. With a few prompts or autocomplete suggestions, entire functions materialize. Repetitive boilerplate disappears. Developers feel empowered, moving quickly and staying in flow. But what are they building? The reality is: most teams don’t fail because they can’t ship fast enough. They fail because they’re solving problems no one cares about. “AI just helps you build the wrong thing faster if you’re not thinking critically about what matters. ” In a sense, AI has become the new baseline. It’s like cloud infrastructure everyone has access to it. It’s not the edge. It’s the new floor. And once everyone has the same tools, what matters most isn’t how fast you build but what you choose to build. Why Product Thinking Beats Faster Coding Imagine two teams building similar features. One... --- - Published: 2025-04-15 - Modified: 2025-04-15 - URL: https://www.ivanturkovic.com/2025/04/15/ai-coding-demand-software-engineers/ - Categories: AI Today, my LinkedIn feed was overflowing with hot takes about AI and the future of programming. A recurring theme? That AI will make software engineers obsolete. No-code platforms, AI-assisted builders, and vibe-based coding were all being hailed as the future. Here’s my take:AI is about to increase the demand for software engineers — not replace them. And we’ve seen this kind of thing before. The Swedish Renovation Effect Years ago in Sweden, a popular TV show demonstrated how easy it was to renovate your own house. Enthused by what they saw, thousands of Swedes began renovating their homes on their own. The result? Disaster. Half-done kitchens. Electrical fires. Poorly installed plumbing. And what followed was a massive surge in demand for professional carpenters, electricians, and contractors. AI-powered programming is heading down the same path. We’re about to see lots of excited builders — and just as many messes to clean up. What Is “Vibe” Coding? “Vibe” coding is the idea that you can build software by simply describing what you want in natural language. “Make me an app that helps me track my fitness and suggests recipes. ” And boom — AI tools like ChatGPT, GitHub Copilot, or Replit Ghostwriter produce working code. But building something functional isn’t the same as building something reliable. AI can’t: Ensure secure architecture Integrate across complex systems Handle scaling issues Manage technical debt Think critically about edge cases and long-term impact That’s where skilled software engineers step in. Real Examples of Where Engineers Will... --- - Published: 2025-04-11 - Modified: 2025-04-11 - URL: https://www.ivanturkovic.com/2025/04/11/ai-product-design-experienced-ctos-importance/ - Categories: AI Artificial intelligence is transforming industries at an unprecedented pace, redefining the way we design, develop, and deploy products. However, with great power comes great responsibility. As AI automates more processes and decision-making, the need for thoughtful product design, robust security, and meticulous attention to edge cases has never been more critical. While AI can handle vast amounts of data and make predictions, it lacks human intuition. The real challenge for companies leveraging AI is ensuring that the technology is implemented in a way that minimizes risks while maximizing efficiency and accuracy. This is where experienced tech architects and CTOs come in. Their deep understanding of system design, security, and data modeling is becoming a key differentiator in creating AI-powered products that are reliable and resilient. The Increasing Complexity of AI-Driven Product Design Unlike traditional software, AI-driven products require a fundamentally different approach to design and development. Instead of writing explicit rules for every scenario, AI models learn from data, which introduces new challenges in predicting behavior, handling unexpected cases, and preventing security vulnerabilities. One of the biggest challenges is handling edge cases. AI models are trained on data, but real-world applications often introduce unexpected situations that weren’t part of the training set. A lack of foresight in handling these cases can lead to significant issues. Consider these examples: Self-driving cars: AI systems are trained on millions of traffic scenarios, but rare or unusual events (like an overturned truck or a person walking with an unusual posture) can confuse the system.... --- - Published: 2025-04-07 - Modified: 2025-04-11 - URL: https://www.ivanturkovic.com/2025/04/07/ai-development-churn-expectations-vs-reality/ - Categories: AI AI-powered development tools like Lovable, Bolt, and others have captured the imagination of developers and non-developers alike. The promise? Build complete applications with just a few prompts. The reality? A much harsher learning curve, hidden complexities, and an eventual realization that these tools, while powerful, are not yet capable of fully replacing traditional software engineering. The Hype: Why AI-Powered Development Feels Revolutionary There's a reason why so many are flocking to AI-powered coding platforms. They offer something unprecedented—turning natural language descriptions into working code, reducing development time, and making software engineering more accessible to those without deep programming knowledge. For a while, it seems magical. With just a few prompts, a prototype can be generated, UI components materialize, and APIs are wired up. For solo entrepreneurs, product managers, and designers who have always relied on engineers to bring their ideas to life, AI-powered development tools feel like an emancipation. They provide the illusion of democratization, allowing anyone to create software—until they hit the brick wall of reality. The Reality: Why These Tools Are Not Enough (Yet) Building a functional app is not just about writing code. It involves architecture, performance optimization, security, state management, backend integrations, database design, debugging, and deployment. These aspects of software development are where AI-generated code often struggles or outright fails. Many, myself included, have tried to build and deploy simple applications using these AI tools, only to run into major roadblocks: Database Connection Issues: AI-generated code frequently struggles with database connections, especially when dealing with... --- - Published: 2025-03-31 - Modified: 2025-03-31 - URL: https://www.ivanturkovic.com/2025/03/31/ai-vs-experience-coding-mistakes/ - Categories: AI Copy and Paste from AI: $20 Actually Knowing What's Going to Work: $150,000 Knowing Where to Place It: Priceless The rise of AI-powered tools has made it easier than ever for people to generate code, write content, and create designs with minimal effort. Platforms like ChatGPT, Copilot, and other AI-driven assistants can spit out working solutions in seconds. But while AI can provide fast results, there’s an undeniable gap between “having code that runs” and “having code that works in the real world. ” Just because something compiles, doesn’t mean it scales. Just because it executes, doesn’t mean it’s secure. And just because AI gives you a function, doesn’t mean it’s the right one for your specific problem. This is the difference between merely copying and pasting code and actually knowing what will work—and more importantly, where to place it. In this post, we'll explore why experience is irreplaceable, the hidden costs of not knowing what you're doing, and examples of how things can go wrong when you rely solely on AI without the expertise to back it up. The Trap of "It Works, So It's Fine" One of the biggest pitfalls for beginners relying on AI-generated code is assuming that if something works, it must be correct. AI can generate code that runs, but without experience, it’s easy to overlook issues like: Security vulnerabilitiesPerformance bottlenecksMaintainability nightmaresScalability limitationsLegal and compliance risks Here are some real-world examples where blindly trusting AI (or generic code from the internet) can lead to disaster.... --- - Published: 2025-03-30 - Modified: 2025-03-30 - URL: https://www.ivanturkovic.com/2025/03/30/best-practices-ai-assisted-coding/ - Categories: AI Artificial Intelligence (AI) has revolutionized software development, making it faster and more efficient. However, many developers still struggle with AI coding tools, often making mistakes that lead to frustration, inefficiencies, and broken codebases. In this guide, we'll explore the best practices for AI-assisted coding, focusing on the most common mistakes and how to improve your workflow. 1. No Planning Jumping straight into coding without a plan is a recipe for disaster. A well-thought-out plan can save hours of debugging and restructuring later. My Planning Hack I turn on ChatGPT voice and have a one-on-one conversation about what I want to build. After 15 minutes, I ask: "Write me a well-structured draft on all the things we've finalized in this conversation. " This way, I use AI as my: Brainstorming buddyCritiqueWeb researcherDraft writer The result? A one-page document outlining the core features of my MVP. Don’t build blindly. Plan before you hunt. 2. No Knowledge Base for AI Models AI coding models work best when they have a reference point. Reducing hallucinations and irrelevant code generation requires a structured knowledge base. How to Build a Knowledge Base for AI Coding Models After drafting my idea, I create structured documentation: Product Requirements Document (PRD) – What the app doesApp Flow Document – How users interact with the appTech Stack Document – The technologies being usedFrontend Guidelines – UI/UX rulesBackend Structure – API architecture and database schema This documentation acts as a reference, ensuring AI models generate relevant and accurate code. Learn more... --- - Published: 2025-03-27 - Modified: 2025-03-27 - URL: https://www.ivanturkovic.com/2025/03/27/can-ai-replace-junior-developers-or-should-we-train-them-to-become-seniors/ - Categories: AI The rapid advancement of AI has sparked an ongoing debate in software development: Should companies replace junior developers with AI-powered tools and a few senior engineers, or should they invest in training juniors to become future seniors while leveraging AI to enhance their productivity? While both perspectives have merit, the ideal solution is often a balance. A well-structured team that combines the fresh enthusiasm of junior developers with the experience of senior engineers, amplified by AI, can outperform any one-dimensional approach. The Case for AI Replacing Junior Developers AI-powered coding assistants like GitHub Copilot, Tabnine, and ChatGPT have dramatically improved code generation, debugging, and even architectural decision-making. These tools allow senior developers to move faster and reduce the need for a large number of junior developers. Real-Life Example: Stripe Stripe, a leading fintech company, experimented with reducing its reliance on junior developers by leveraging AI-powered development tools. They streamlined their engineering teams, allowing senior engineers to complete tasks in half the time with AI assisting in boilerplate code, debugging, and automated testing. This helped Stripe reduce costs while maintaining high-quality output. Pros: Lower payroll costsFaster development cyclesFewer mistakes and more consistent code quality Cons: No pipeline for future senior developersLoss of diverse perspectives and innovationHigher risk if the senior developer leaves The Case for Training Junior Developers On the other hand, investing in junior developers creates long-term sustainability and cultivates a strong company culture. AI should be seen as a tool to accelerate their learning rather than a replacement. Real-Life... --- - Published: 2025-03-24 - Modified: 2025-03-21 - URL: https://www.ivanturkovic.com/2025/03/24/when-product-owners-ignore-security-why-experienced-developers-matter/ - Categories: AI In the modern tech landscape, product owners often assume that software will "just work" safely. But security isn't automatic, and a lack of foundational understanding can lead to serious vulnerabilities. While AI has become a valuable tool in development, it cannot replace the expertise of seasoned developers who can anticipate, diagnose, and resolve complex security flaws. In this article, we'll explore why relying solely on assumptions—or even AI—can put users at risk, and how experienced developers have rescued failing projects from disaster. The Illusion of Safety in Software Development Product owners, especially those without technical backgrounds, often focus on features, user experience, and business objectives. Security tends to be an afterthought—if it’s considered at all. They might assume: "Our framework handles security automatically. ""AI-generated code must be secure. ""Hackers won’t target us because we’re a small company. " These assumptions are dangerous. Security must be deliberately designed into a system, and failing to do so can lead to catastrophic breaches. Real-World Examples of Projects Gone Wrong (And How Developers Saved Them) 1. The E-Commerce Disaster: Exposed Customer Data A startup built an e-commerce platform using a popular low-code solution. The product owner assumed that security was baked into the platform. What they didn’t realize was that their database had been left publicly accessible, exposing thousands of customers' personal and payment data. How an Experienced Developer Saved It: A senior developer was brought in after an independent security researcher exposed the vulnerability. The developer: Implemented proper authentication and access controls. Added... --- - Published: 2025-03-21 - Modified: 2025-03-21 - URL: https://www.ivanturkovic.com/2025/03/21/the-rise-of-ai-wrappers-are-ai-providers-the-new-telecoms/ - Categories: AI Artificial intelligence has experienced an explosion of growth in recent years, with companies like OpenAI, Anthropic, and Google leading the charge in providing powerful foundational models. But despite their immense computational capabilities, these AI providers are increasingly finding themselves in a familiar position—one that resembles the fate of telecom giants in the past. In the telecom industry, infrastructure providers built the backbone of communication networks, yet they eventually found themselves competing not on innovation but on price, reliability, and scale. Meanwhile, a new wave of companies emerged, offering user-friendly interfaces and value-added services on top of these networks, becoming the real consumer-facing brands. Today, a similar pattern is emerging in AI, where a new breed of AI wrappers is rapidly capturing market attention and customer loyalty. AI Wrappers: The New Kings of the AI Economy AI wrappers are companies or platforms that use existing AI models but differentiate themselves by offering improved usability, domain-specific expertise, or additional automation capabilities. They act as intermediaries between the raw power of foundational models and the end user, providing a tailored, more accessible experience. These wrappers often build agentic systems that extend AI capabilities beyond simple text generation, integrating AI into real-world workflows more seamlessly. One of the most notable examples is Cursor, an AI-powered coding assistant that integrates deeply with software development environments. While OpenAI provides the underlying models, Cursor enhances them with context awareness, code-specific optimizations, and user-friendly interactions that cater specifically to developers. Similarly, Jasper has become a dominant force in... --- - Published: 2025-03-18 - Modified: 2025-03-19 - URL: https://www.ivanturkovic.com/2025/03/18/ai-a-gift-for-junior-developers-a-curse-for-tech-leads/ - Categories: AI Artificial intelligence is revolutionizing software development, making it easier for less experienced developers to write code, generate solutions, and build applications faster than ever before. But as AI lowers the barrier to entry, it creates an unexpected challenge—an increasing burden on tech leads who must navigate a landscape filled with AI-assisted code that often lacks structure, scalability, and maintainability. The Rise of AI-Assisted Development Tools like GitHub Copilot, ChatGPT, and other AI-powered coding assistants have significantly boosted developer productivity. Junior and mid-level developers can now produce complex code snippets, automate repetitive tasks, and solve problems they previously struggled with. While this sounds like a win for the industry, the reality is more nuanced. AI-generated code is often syntactically correct but semantically flawed. It may work in isolation but lack architectural integrity when integrated into a broader system. AI lacks the human intuition necessary to understand business logic, future scalability, and team-specific best practices. This means that while development velocity increases, so does the risk of accumulating technical debt. The Burden on Tech Leads Tech leads, already responsible for guiding teams, making architectural decisions, and ensuring high code quality, now face an additional challenge: reviewing and correcting AI-generated code. Here’s why AI can be a curse for tech leads: 1. Increased Review Workload AI accelerates code production, but not always in the right direction. More code means more pull requests, more code reviews, and more debugging. Tech leads spend significant time analyzing whether AI-assisted code is functionally correct and adheres to... --- - Published: 2021-01-03 - Modified: 2021-01-03 - URL: https://www.ivanturkovic.com/2021/01/03/decisions-decisions-decisions/ - Categories: Introduction - Tags: 2020, business, idea, reality, startup Year 2020 has taught us many things but not everyone was listening to the lectures. We are living in constantly evolving world and no matter how much we want to standardize our lives and how much we hate changes they happen all the time. Last year really showed us we cannot control the future and not even shape it based on our needs. This year should be different they say, there is a lot of hope but are there a lot of people who are willing to adjust to changes constantly. We love our comfortables lives and we don't want to take step back even if this would take us two or more steps forward in the future. I understand change is hard so hard we sometimes manage to distinguish between common sense and what we want to believe. Internet has evolved and managed to bring those distortion further than ever. I've decided to start writing about life, then changes that are ever lasting, the planning that make solid plans for the future, how to test our plans and how to get out and reach as many people possible with our plan. Whether this is a personal self improvement or a business idea. I have entered into third decades of working with technology, turning ideas into reality, making those ideas available to broad public, see what works and what it doesn't. I did learn a lot but I did a lot of mistakes as well. I think this is the... --- - Published: 2015-04-10 - Modified: 2021-01-03 - URL: https://www.ivanturkovic.com/2015/04/10/homebrew-start-stop-services/ - Categories: development View image | gettyimages. com Anyone that has installed application running in the background from Homebrew, knows how to use launchctl that actually runs every application when the computer restarts. It is pretty straight forward task but most of the time you need to know the location of the . plist file that defines how to run it installed with homebrew. Now there is a quicker path how to control them by simply adding following package to home-brew: brew tap gapple/services  And you have available to start, stop services directly from home-brew with following command to get a list of active services: brew services list So for example if you have installed postgresql you can start it as a background service with: brew services start postgresql or stop the service with brew services stop postgresql Which is much more easier and simpler than finding the right . plist file inside cellar folder of brew --- - Published: 2014-11-27 - Modified: 2014-11-27 - URL: https://www.ivanturkovic.com/2014/11/27/stop-procrastinating-and-be-productive/ - Categories: personal development, startup, success - Tags: procrastination, productivity Still trying to stop procrastinating? There are probably numerous days that you site behind the computer to do some research or get some work done and doing a short break to read some news or check social updates and as you done this you aren't aware that time passes as you jump from one link to another while the time is passing by rapidly. You have probably tried many things, like avoiding to use those sites, setting time aside for short breaks or some other solution but every time you spend more time doing nothing than to spend that time into something productive. My way of curbing procrastination time to minimum You probably procrastinate as everyone but you don't do it so efficiently, there are many ways to curb this behavior especially with avoiding reading the news updates all the time. We live in an era of information overload and we developed a habit of a need to be constantly updated with latest updates. I am using few tools which are completely free of cost for basic usage you will need to prevent procrastination. Here is how I do it: I have installed self control app on my computer and you can get it at this link. It is free of cost. Basically what it does is that you add a list of web sites that you want to block for a selected period of time. You are probably wondering now which pages should I add to this blacklist. Well... --- - Published: 2014-11-26 - Modified: 2014-11-26 - URL: https://www.ivanturkovic.com/2014/11/26/angularjs-nginclude-directive-scope/ - Categories: AngularJS, development - Tags: angularjs, development ngInclude directive and scope There are many times when you want to include a html snippet code from another file but preserve the scope of it. It is usually when you have different form fields for the various objects and you want to have a global controller that oversees the updating of different forms. So if you want to take the quickest route and use ngInclude directive you would be surprised that it is not properly linking to your controller and you cannot access the form instance. This is due to ngInclude internals and how they work. ngInclude creates for each use as a new child scope so overwriting anything inside the new included HTML file content will be written into child scope and not in the one you've anticipated to be. So there are few workaround around this as creating a new object inside the scope for example $scope. data = {} inside the controlling controller and then in the imported html file set values inside the This works if you don't have a problem with static value being inserted into all html files, but if you want maximum flexibility then this is not the perfect solution. So after inspecting the source code inside ngInclude. js, I have seen a room for improvement and created a similar directive to ngInclude called ngInsert, which instead of making new child scope it inherits the current scope and continue using it inside. You can pick up the whole source code at this... --- ---