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 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 are excellent at producing code, but quantity is a misleading signal. We could easily end up with a lot of syntactically correct but architecturally messy software.

Why AI-Generated Code Can Inflate the Wrong Numbers

Imagine this scenario:

Human developer approach

  • Implements a payment validation service in 50 lines.
  • Uses existing abstractions, adds unit tests, and ensures long-term maintainability.

vs AI-generated approach

  • Produces a 500-line solution with redundant logic, overly generic abstractions, and unnecessary boilerplate.
  • Works today, but in 3 months, another engineer spends days cleaning it up.

If you measure productivity by “lines of code checked in,” the AI looks 10x more productive. But if you measure by long-term cost of ownership, the AI just created technical debt.

The irony is that AI often defaults to verbosity. It tries to be “helpful” by filling in every possible branch, every possible configuration, every possible error case. That’s useful in some contexts, but often it leads to bloat instead of clarity.

Better Metrics for AI-Assisted Development

If we agree that lines of code isn’t the answer, what should we be looking at?

Here are a few ideas:

Cycle time to value

  • How quickly can a feature go from idea → production → value delivered to the business?
  • If AI speeds this up without adding long-term drag, that’s true productivity.

Code quality and maintainability

  • Static analysis scores, cyclomatic complexity, duplication, and readability.
  • AI should be measured on whether it improves or degrades these metrics.

Bug rate and rework cost

  • How often do AI-generated contributions introduce regressions?
  • How much effort do humans spend debugging or rewriting AI code?

Developer experience

  • Are engineers spending less time on repetitive boilerplate?
  • Do they feel empowered to focus on architecture, problem-solving, and innovation?

Business outcomes

  • Does AI accelerate delivery of meaningful features, reduce time-to-market, and improve customer satisfaction?
  • Or does it just fill up the repo with more stuff to manage?

    Where This Leaves Us

    We are only at the beginning of figuring out how AI fits into modern software development. There will be new metrics, new practices, and new patterns of collaboration between humans and machines.

    But one thing is certain: lines of code is the wrong measure of productivity.

    In fact, if you see your AI adoption leading to more lines of code, you should pause and ask:

    • Is this actually solving problems more effectively?
    • Or are we just accumulating more technical debt at machine speed?

    The future of engineering with AI will belong to those who focus on outcomes, maintainability, and business value not vanity metrics.

    Conclusion

    AI is not going to replace developers; it’s going to reshape what productivity looks like. The teams that succeed will be the ones that look beyond shallow metrics and focus on sustainable velocity.

    The next time someone tells you their AI is producing 70% of the code, ask them:

    • 70% of what?
    • Is that 70% value, or 70% debt?

    Because in software, less is often more.

    On AI-Generated Code, Maintainability, and the Possibility of Disposable Software

    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 true when I’ve tested more advanced setups where you let an agent plan and generate entire components, classes, or services. It sounds great in theory, but in practice it causes a lot of changes, inconsistencies, and small bugs that end up being more trouble to fix than if I had just written it myself from the start.

    So for now, I stay close to completions. Code at the scale of a line or a method. It’s easier to understand, easier to control. I can be the architect, and the AI can be the assistant.

    The Self-Fulfilling Trap

    There’s a strange loop forming in AI development. Since the generated code is harder to reason about or maintain, people often treat it as throwaway. And because it’s throwaway, nobody bothers to make it better. So it stays bad.

    Self-fulfilling prophecy.

    The more AI you use to generate logic, the more you’re tempted to not go back and polish or structure it. You get into a loop of “just generate something that works,” and soon you’re sitting on a pile of glue code and hacks that’s impossible to build on.

    But maybe that’s okay? Maybe we need to accept that some code isn’t meant to last.

    Disposable Software Might Be the Point

    This is where I’m starting to shift my thinking a little. I’ve always approached code as something you build on something that lives and evolves. But not all code needs that.

    A lot of software today already is disposable, even if we don’t admit it. One-off internal dashboards, ETL jobs, scripts for events, MVPs for marketing campaigns, integrations that won’t live beyond a quarter. We often pretend we’re building maintainable systems, but we’re not. We just don’t call them disposable.

    With AI in the mix, maybe it’s time to embrace disposability for what it is. Write the code, run the code, get the result, throw it away. Next time, generate it again maybe with better context or updated specs.

    This mindset removes a lot of the pressure around maintainability. And it fits the strengths of today’s AI tools.

    When Not to Use Agentic Systems (Yet)

    I’ve played with more autonomous agent systems what people call “agentic AI” or multi-agent code platforms. Honestly? I’m not sold on them yet. They generate too much. They make decisions I wouldn’t make. They refactor things that didn’t need to be touched.

    And then I spend more time reading diff views and undoing changes than I saved by delegating in the first place.

    Maybe in the future I’ll be comfortable letting an AI agent draft a service or plan out an architectural pattern. But today, I’m not there. I use these tools more like smart autocomplete than autonomous developers. It’s still very much my code and they’re just helping speed up the flow.

    Final Thoughts

    There’s a real risk of overhyping what AI can do for codebases today. But there’s also an opportunity to rethink how we treat different classes of software. We don’t need to hold everything to the same standards of longevity. Not every project needs to be built for 10 years of feature creep.

    Some software can (and should) be treated like scaffolding and built quickly, used once, and removed without guilt.

    And that’s where AI shines right now. Helping us build the things we don’t need to keep.

    I’ll keep experimenting. I’ll keep writing most of my own code, and using AI where it makes sense. But I’m also watching carefully because the balance between what’s worth maintaining and what’s better thrown away is shifting.

    And we should all be ready for what that means.

    The AI isn’t going to be on call at 2 AM when things go down.

    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 quality might even degrade over time, it becomes an average of an average.

    This is not just about style or design patterns. It affects how you:

    • Deliver software
    • Observe and monitor systems
    • Debug real-world issues
    • Write secure applications
    • Handle private user data responsibly

    LLMs don’t truly understand these things. They don’t know what matters in your architecture, how your team works, or what your specific constraints are. They just parrot what’s most statistically likely to come next in the code.

    A Fast Start, Then a Wall

    So yes, LLMs speed up the easiest part of software engineering: writing code.

    But the hard parts remain:

    • Understanding the domain
    • Designing for change
    • Testing edge cases
    • Debugging production issues
    • Keeping systems secure and maintainable over time

    These are the parts that hurt when the codebase grows and evolves. These are the parts where “fast” turns into fragile.

    Example: Generated Code Without Accountability

    Imagine you ask an LLM to generate a payment service. It might give you something that looks right, maybe even works with your Stripe keys or some basic error handling.

    But:

    • What happens with race conditions?
    • What if fraud detection fails silently?
    • What if a user gets double-charged?
    • Who is logging what?
    • Is the payment idempotent?
    • Is sensitive data like credit cards being exposed in logs?

    If no one really “owned” that code because it was mostly written by an AI and these questions might only surface after things go wrong. And in production, that can be very costly.

    So What’s the Better Approach?

    LLMs can be great tools, especially for experienced engineers who treat them like assistants, not authors.

    To use LLMs responsibly in your team:

    • Review AI-generated code with care.
    • Assign clear ownership, even for generated components.
    • Add context-specific tests and documentation.
    • Educate your team on the why, not just the how.
    • Make accountability a core part of your development process.

    Because in the end, you are shipping the product. The AI isn’t going to be on call at 2 AM when things go down.

    Final Thoughts

    LLMs give us speed. But they don’t give us understanding, judgment, or ownership. If you treat them as shortcuts to ship more code, you may end up paying the price later. But if you treat them as a tool and keep responsibility where it belongs they can still be part of a healthy, sustainable development process.

    Thanks for reading. If you’ve seen this problem in your team or company, I’d love to hear how you’re dealing with it.

    AI Isn’t Leveling the Playing Field, it’s Amplifying the Gap

    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, not a tool.

    Good engineering still requires:

    • Judgment
    • Pattern recognition
    • Systems thinking
    • Curiosity
    • Accountability

    AI doesn’t teach these. Mentorship does.

    Where Is the Mentorship?

    In many teams, mentorship is already stretched thin. Now we’re adding AI to the mix, and some companies expect juniors to “just figure it out with ChatGPT.”

    That’s not how this works.

    The result? Juniors are missing the critical lessons that turn coding into engineering:

    • Why things are built the way they are
    • What trade-offs exist and why they matter
    • How to debug a system under load
    • When to break patterns
    • How to think clearly under pressure

    No AI can give you that. You only get it from real experience and real guidance.

    What We Can Do

    If you’re a senior engineer, now is the time to lean into mentorship not pull away.

    Yes, AI helps you move faster. But if your team is growing and you’re not helping juniors grow too, you’re building speed on a weak foundation.

    If you’re a junior, use AI but don’t trust it blindly. Try to understand everything it gives you. Ask why. Break it. Fix it. Learn.

    Because here’s the truth:

    AI won’t make you a better engineer. But it will make great engineers even better.

    Don’t get left behind.

    Final Thoughts

    AI isn’t the enemy. But it’s not a shortcut to seniority either. We need to be honest about what it’s good for and where it’s failing us.

    Let’s stop pretending it’s a magic equalizer. It’s not.

    It’s a magnifier.
    If you’re already strong, it makes you stronger.
    If you’re still learning, it can hide your weaknesses until they blow up.

    May 1st, Workers’ Day: Reflecting on the Future of Developers in the Age of AI

    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 is redefining the developer’s role:

    • From a pure code generator → to a system designer and critical thinker.
    • From solving known problems → to exploring unknown problems.
    • From typing faster → to asking better questions.

    The core of great software development will become less about how many lines of code you can write, and more about:

    • How clearly you understand the problem.
    • How creatively you design the solution.
    • How effectively you validate assumptions with real users.

    In short: technical execution is being democratized, but insight, creativity, and judgment are becoming even more valuable.

    Workers’ Rights and Respect in a Post-AI World

    Workers’ Day isn’t just about jobs, it’s about dignity, fairness, and the value of human effort.

    As AI reshapes engineering, companies, leaders, and communities must ensure that:

    • Developers are given opportunities to reskill and evolve.
    • Workplaces value critical thinking and creativity over brute-force output.
    • Workers are recognized for their judgment, leadership, and empathy, not just their typing speed.

    The dignity of developer work must evolve but it must not disappear.

    The risk is that companies, chasing efficiency, might treat developers like “AI supervisors” or “prompt engineers” only undervaluing the strategic, human essence of great engineering work.

    This May 1st, we should celebrate not just what developers do but how they think, imagine, and create.

    The Future of Developer Work: What Matters Now

    So, if you’re a developer, or leading a tech team, what skills and mindsets will matter most in the future?

    1. Product Thinking
    Understanding user needs, business goals, and the “why” behind the “what” will be essential.

    2. Critical Reasoning
    Knowing when AI-generated code is wrong, incomplete, or misaligned with real-world requirements.

    3. Creativity and Innovation
    Thinking beyond what’s obvious. AI can suggest patterns, but it can’t invent bold new paradigms yet.

    4. Collaboration and Empathy
    Working with designers, PMs, stakeholders, and users will become even more central.

    5. Strategic Use of AI
    Knowing how to use AI, when to trust it, and when human judgment must take over.

    A New Kind of Craftsmanship

    In many ways, the evolution we’re living through isn’t the end of craftsmanship in software, it’s a renaissance.

    The tools have changed. The basic tasks have changed. But the core spirit of the developer the builder, the solver, the creator remains vital.

    If anything, AI makes the human parts of engineering even more valuable:

    • Vision.
    • Judgement.
    • Ethical thinking.
    • Originality.
    • Connection to human needs.

    That’s worth celebrating this Workers’ Day and fighting for in the years ahead.

    Final Thoughts: Building the Future Intentionally

    This May 1st, let’s honor developers not for how fast they can code but for how thoughtfully they can shape the future.

    Let’s champion workplaces that invest in human skills, not just AI tools.

    And let’s remember that while technology evolves, the heart of work the pursuit of meaning, the quest to make things better remains uniquely, beautifully human.

    Need help preparing your tech team for the AI era?

    I help companies and teams rethink their product strategies, evolve their engineering practices, and align AI innovation with real-world user needs.

    With 20+ years of experience across tech, fintech, and startup ecosystems, I can help your organization:

    • Embrace AI smartly and strategically
    • Foster product thinking across engineering
    • Future-proof your development practices

    📩 Contact me here or visit ivanturkovic.com to learn more.

    Let’s build a smarter, more human-centered future together.

    AI Can Write Code. But Can It Build the Right Product?

    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 is using AI to crank out code at lightning speed. The other spends time talking to users, validating assumptions, and only writing code when it’s clear what matters most.

    Which one wins in the long run?

    The second team. Every time.

    Great companies aren’t made by productivity alone. They’re built by making smarter bets.

    There are already countless stories of AI-powered engineering orgs that pushed out entire platforms only to discover they’d misread the market or misunderstood the user. The cost of wrong decisions compounds faster when you’re building faster.

    Insight: Your AI stack isn’t your differentiator. Your user understanding is.

    Engineering Without Context Is a Risk and AI Just Amplifies It

    One of the most overlooked risks of AI in development is that it can further isolate engineers from the real-world problems their users are facing.

    Here’s how it plays out:

    • AI makes coding easier and faster.
    • Engineers get deeper into flow states.
    • Less time is spent in discovery, user feedback, or product discussions.
    • Features are built from assumptions, not insights.

    In short, AI widens the gap between builders and users, unless leaders intentionally close it.

    Your engineers don’t need to be product managers. But they do need context:

    • Who are we solving for?
    • What pain are we addressing?
    • What does success look like for the user?

    Without that, they’re just solving technical puzzles. And AI makes that even easier to do without questioning the why.

    AI Strategy Is Not Product Vision: Lessons for CTOs and Founders

    In 2025, one of the most common strategic mistakes I see from tech leadership is confusing “having an AI strategy” with “having a product vision.”

    CTOs and founders proudly proclaim their AI initiatives, touting LLM integrations and Copilot productivity gains. But often, the product itself lacks a core value proposition. There’s no unique insight. No user obsession. Just surface-level tech hype.

    Warning sign: If your AI roadmap is longer than your product roadmap, you’re probably heading in the wrong direction.

    AI should support your vision, not become it. It’s a tool to accelerate clarity not a substitute for it.

    How Smart Teams Use AI in Product Development

    So how should high-performing teams approach AI?

    They don’t ignore it. But they use it intentionally, not reactively. Here’s how they do it:

    • Start with product clarity: AI gets plugged in after the problem is well understood.
    • Use AI to prototype, not finalize: It’s a great tool for drafts, ideas, and quick iterations, but not for skipping over design thinking.
    • Build user feedback loops into engineering: Teams that talk to users frequently make better use of AI because they know what’s actually needed.
    • Avoid cargo culting AI features: Just because you can plug in an LLM doesn’t mean you should.

    A simple framework for alignment:

    1. Write a 1-page problem brief before building.
    2. Identify the user pain, not the feature.
    3. Validate with a real customer, not a teammate.
    4. Use AI to build faster once the path is clear.

    What Investors Should Really Look For

    If you’re an investor evaluating AI-native startups, this part is for you.

    Don’t just look at AI usage. That’s table stakes. Instead, dig deeper:

    • Are they solving a real user problem with a compelling insight?
    • Is the team obsessed with learning, not just launching?
    • Are engineers looped into product and customer conversations?
    • Is AI being used for leverage, or as a distraction?

    The best startups in the AI era won’t be those with the flashiest demos. They’ll be the ones with:

    • Small teams.
    • Sharp thinking.
    • Deep user insights.
    • Relentless focus.

    In an AI World, Thinking Is Your Edge

    AI is raising the average. It’s making every developer a little more productive. It’s removing drudge work and unlocking new workflows.

    But it’s not a silver bullet.

    The teams that will truly win in this era are the ones that combine AI with critical thinking, product obsession, and strategic clarity.

    They’ll ask better questions. They’ll build less but better. And they’ll move faster because they know exactly where they’re going.

    So, how is your team using AI?
    To generate more code or to make smarter decisions about what to build in the first place?

    Like this post?
    🔁 Share it with a founder or CTO who’s too hyped about AI.
    💬 Drop a comment or DM me with how your team is integrating product thinking into AI workflows.
    📩 Subscribe for more thoughts on tech, product, and the future of software.

    Let’s Build Smarter, Not Just Faster

    AI isn’t going away. But how we use it and what we choose to build with it will define which teams win and which ones waste time.

    If you’re a founder, CTO, or product leader trying to navigate this new AI-powered world, and you’re serious about building the right product, I can help.

    I bring over 20 years of experience across fintech, crypto, payments, and startup ecosystems as a developer, CTO, and product strategist. I’ve helped teams go from messy ideas to crystal-clear roadmaps and scalable platforms.

    🔧 What I help with:

    • Defining product strategy in AI-heavy contexts
    • Aligning engineering teams with real user needs
    • Avoiding technical overbuild and feature bloat
    • Building lean, fast-moving MVPs with Ruby on Rails and modern stacks
    • Coaching tech teams to think product-first, code-second

    If you want clarity, speed, and smarter decisions baked into your product and engineering culture, let’s talk.

    📩 Get in touch with me or visit ivanturkovic.com to learn more.

    Let’s build something that matters.

    AI “Vibe” Coding Will Increase Demand for Software Engineers; Here’s Why

    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 Still Be Needed

    Let’s go through three common scenarios that show why engineers aren’t going anywhere.

    1. The Startup Founder MVP

    A non-technical founder uses AI to create a prototype. It works and gains users. But now they need:

    • API design that scales
    • Data security and privacy compliance
    • Frontend polish and accessibility
    • DevOps for deployment pipelines and monitoring

    They’ll be hiring engineers soon.

    2. The Corporate DIY Tool

    A marketing team builds an internal dashboard with AI. It’s fast — until:

    • Traffic grows and it starts crashing
    • Security holes appear
    • It can’t integrate with enterprise systems

    Enter: The IT and engineering team to fix and rebuild it.

    3. The Indie Hacker Problem

    An indie developer builds a cool tool with AI and gets traction. Now users want new features. Stripe integration is flaky. Bugs start piling up.
    Suddenly, vibe coding hits its limits — and real development work begins.

    Just Like Excel… But Bigger

    We’ve seen this before with Excel. Millions use it for complex calculations, planning, and even pseudo-apps. But when the stakes rise — in finance, logistics, or reporting — companies bring in:

    • Excel consultants
    • VBA programmers
    • Business analysts

    The same will happen with AI-built software. It’ll democratize access, but it’ll also raise expectations.

    Engineers Will Be the New Advisors, Builders, and Maintainers

    Software engineers in the AI age won’t just code. They’ll:

    • Audit AI-generated systems
    • Refactor MVPs into production-ready platforms
    • Coach teams on maintainability and design thinking
    • Design better APIs and AI integration points
    • Create guardrails and tooling that make AI-generated code safer and smarter

    In other words: we’ll be more important than ever.

    AI Is the New Hammer — But You Still Need Builders

    AI coding tools are like giving hammers to the world.

    Some people will build amazing things. Others will build something that looks good but falls apart in the rain.

    And just like the Swedish renovation boom, someone will need to fix, maintain, and scale all that newly built infrastructure.

    That someone is you — the software engineer.

    About the Author

    Ivan Turkovic is a seasoned tech expert, fintech and blockchain platform architect, and former CTO of multiple startups. With 20+ years of experience building products and teams using Ruby on Rails, TypeScript, and cloud-native platforms, he helps businesses turn complex systems into reliable, scalable solutions.

    Whether you’re an early-stage founder, a company struggling with technical debt, or a team trying to level up your AI integration strategy — Ivan can help.

    🖥️ Visit ivanturkovic.com for more articles, insights, and contact info
    📧 Reach out via LinkedIn or email ivan.turkovic@gmail.com

    The Age of AI: Why Experienced Tech Architects and CTOs Are More Crucial Than Ever

    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. Tesla’s Autopilot has been criticized for failing in such edge cases, sometimes leading to accidents.
    • AI chatbots: Microsoft’s Tay AI was released in 2016 and quickly turned into a PR disaster when users manipulated it into making racist and offensive statements. The lack of robust content moderation mechanisms exposed the bot’s vulnerability to adversarial manipulation.
    • Healthcare AI: A medical AI model trained primarily on data from Western countries may perform poorly when deployed in regions with different demographic data, leading to incorrect diagnoses or biased treatment recommendations.

    To prevent such failures, experienced architects must proactively model possible failure scenarios and ensure that fallback mechanisms are in place. Anticipating these issues requires deep knowledge of system architecture and an understanding of human behavior—qualities that experienced CTOs and technical leaders bring to the table.

    Data Modeling: The Foundation of AI Success

    AI systems are only as good as the data they are trained on. Poorly modeled data can introduce biases, inaccuracies, and unpredictable behaviors. This is another reason why experienced tech architects are invaluable.

    • Bias in AI systems: Amazon once had to scrap an AI-powered recruiting tool that discriminated against women because it was trained on past hiring data, which was predominantly male. An experienced AI architect would have identified this risk and designed the system to counteract historical biases.
    • Data drift: AI models degrade over time as real-world data changes. If data pipelines aren’t continuously monitored and updated, performance will decline. Google’s AI for identifying diabetic retinopathy struggled when deployed in real-world clinics because the image quality was lower than in its training dataset.
    • Scalability challenges: AI models that work well in development often fail at scale due to inefficient data pipelines. A well-designed architecture ensures that data ingestion, preprocessing, and storage can handle increasing loads without performance bottlenecks.

    Tech architects who understand data engineering, pipelines, and real-time processing can build more resilient AI systems that stand the test of time.

    Security and Data Privacy: A Major Concern in AI Systems

    One of the biggest risks with AI-driven systems is security and data privacy leaks. Companies without experienced leadership often underestimate the attack surface that AI systems create. Some high-profile failures include:

    • Samsung’s AI mishap (2023): Employees used ChatGPT for internal coding assistance, accidentally leaking sensitive source code. The lack of internal security policies and oversight allowed this breach to happen.
    • Deepfake abuse: AI-generated deepfakes have been used for identity fraud, political misinformation, and even scams impersonating executives. Companies need AI-specific security measures to detect and prevent such misuse.
    • GDPR violations: AI models that store or process personal data without clear consent can lead to massive fines. Meta (Facebook) has faced repeated regulatory scrutiny for mishandling user data.

    Experienced CTOs and security-focused architects play a vital role in identifying potential AI security risks before they become major breaches. This includes designing secure data pipelines, implementing differential privacy techniques, and ensuring AI models do not memorize sensitive information.

    Why Experienced CTOs and Tech Architects Will Thrive

    AI is reducing the need for repetitive coding, but it is increasing the demand for high-level system thinking, security awareness, and strategic planning. Companies that blindly rely on AI without understanding its risks are setting themselves up for failure.

    The future belongs to tech leaders who can:

    • Design AI-powered systems that handle edge cases gracefully.
    • Build scalable and unbiased data models.
    • Prioritize security and data privacy in every AI-driven product.

    While junior developers and AI automation can accelerate coding and prototyping, only experienced architects can prevent catastrophic failures before they happen. As AI continues to reshape industries, those with deep technical expertise will be in higher demand than ever.

    If you’re a CTO or tech architect, now is the time to double down on your expertise. AI is not replacing your role—it’s making it more valuable than ever.

    Looking for Expert Help? Let’s Work Together!

    If you need expert guidance to bring your ideas to life, I’m here to help. Whether it’s building innovative solutions, refining your tech strategy, or tackling complex challenges, let’s connect and create something great. Reach out today on ivan.turkovic@gmail.com, and let’s make things happen!

    The Inevitable Churn of AI-Powered Development Platforms

    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 cloud environments, ORMs, or different types of data persistence strategies.
    • Authentication & Security Concerns: Many platforms generate basic authentication flows, but real-world implementations require fine-tuning for access control, session management, and compliance with security standards.
    • API Integrations & Rate Limits: AI may generate API calls, but it doesn’t always handle edge cases, pagination, throttling, or error responses properly.
    • Frontend Hydration & State Management: AI-generated frontend code often runs into hydration errors, especially in React or other component-based frameworks.
    • CORS Policy Errors & DevOps Challenges: Cross-Origin Resource Sharing (CORS) issues plague AI-generated projects, requiring manual intervention. Similarly, deployment is far from a one-click experience, as infrastructure knowledge is often required.

    These problems aren’t just annoyances; they are project killers for those without the technical expertise to debug them.

    Why Churn is Inevitable

    Many people jumping into AI-powered development tools do so because of FOMO (Fear of Missing Out). They see impressive demos and believe they can bypass years of software engineering experience. However, after a few frustrating attempts, reality sets in. Without a foundational understanding of software engineering principles, many will abandon these tools entirely.

    Mismatched Expectations

    The expectation is that AI will do everything for them. The reality is that AI can accelerate certain aspects of development but cannot (yet) replace the problem-solving skills of an experienced developer. This gap between expectation and reality inevitably leads to frustration and churn.

    Lack of Debugging & Support

    Unlike traditional development, where countless Stack Overflow threads, GitHub issues, and community discussions exist, AI-generated code can be unpredictable. Debugging issues with AI-generated code often requires real software engineering skills, something many early adopters of these tools do not have.

    Dependency on Experts

    In my own experience, I only got past these obstacles because I had access to people who actually understand software engineering. Many others won’t have that same support network, making it even more frustrating when things don’t work.

    The Future of AI-Powered Development

    Despite these challenges, I’m still building with AI and learning a ton. AI-assisted development is undoubtedly the future—but it’s not the present solution many believe it to be. Here’s what needs to happen before these tools can truly democratize software development:

    • Better Abstraction of Complexity: AI tools need to handle real-world complexities like authentication, database management, and security without requiring deep expertise from users.
    • Improved Debugging & Documentation: There must be AI-assisted debugging and more robust documentation around generated code.
    • Integration with Traditional Development Workflows: Instead of aiming to replace engineers, AI tools should become better copilots that assist rather than automate everything.

    AI-powered development will continue to evolve, but the current wave of enthusiasm will likely be followed by a period of disillusionment. Many will churn out of frustration, while others—especially those willing to learn and adapt—will reap the benefits of being early adopters.

    For now, AI-generated code is a powerful tool, but not a replacement for the art and science of software engineering. The hype is real, but so are the limitations. Those who acknowledge and navigate these challenges will be the ones who truly benefit from this technological shift.

    AI vs. Experience: The Real Cost of Knowing What Works

    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 vulnerabilities
    • Performance bottlenecks
    • Maintainability nightmares
    • Scalability limitations
    • Legal and compliance risks

    Here are some real-world examples where blindly trusting AI (or generic code from the internet) can lead to disaster.

    Example 1: SQL Injection – The Classic Security Oversight

    Let’s say you ask an AI to generate a login system in Python using Flask and SQLite. You get something like this:

    @app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    query = f"SELECT * FROM users WHERE username = '{username}' AND password = '{password}'"
    result = db.execute(query).fetchone()
    if result:
        return "Login successful"
    return "Invalid credentials"

    It works! You enter a username and password, and it checks if they exist in the database. But here’s the problem—this code is vulnerable to SQL injection. Anyone with basic knowledge of security can enter a malicious string like:

    ' OR '1'='1' --

    And suddenly, they’re logged in as an admin.

    An experienced developer would know that SQL queries should always use parameterized statements:

    query = "SELECT * FROM users WHERE username = ? AND password = ?"
result = db.execute(query, (username, password)).fetchone()

    But if you don’t know what to look for, you wouldn’t even realize there’s a problem—until it’s too late.

    Example 2: “Just Use This AI-Generated Smart Contract”

    With blockchain and smart contracts becoming more popular, AI can generate Solidity contracts for you. But Solidity is tricky—one wrong move and you could introduce vulnerabilities that cost millions.

    For example, imagine an AI generates this Solidity contract:

    contract SimpleBank {
    mapping(address => uint256) public balances;
    
    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }
    
    function withdraw(uint256 amount) public {
        require(balances[msg.sender] >= amount);
        payable(msg.sender).transfer(amount);
        balances[msg.sender] -= amount;
    }
}

    It looks fine, right? But this contract is vulnerable to reentrancy attacks. A malicious actor can drain the contract using a recursive function call before the balance updates. An experienced blockchain developer would immediately see this issue and fix it by using the checks-effects-interactions pattern or a reentrancy guard.

    Example 3: The Nightmare of Scaling Bad Code

    An AI can generate a sorting algorithm for you. But let’s say you need to process millions of data points efficiently. An AI might give you something like:

    def sort_list(lst):
    return sorted(lst)

    For small datasets, this works fine. But what if you’re sorting billions of records? An experienced developer would ask:

    • What’s the computational complexity of this approach?
    • Is there a more efficient algorithm like Merge Sort, Quick Sort, or even a parallelized approach?
    • How does this impact memory usage?
    • Should I use a database index instead of sorting in memory?

    AI won’t always make those considerations for you. Without experience, you might not even realize there’s a problem—until your system grinds to a halt under real-world loads.

    Why Experience Is Priceless

    The AI tools available today are powerful, but they are not a replacement for deep expertise. The ability to:

    • Anticipate edge cases
    • Understand security implications
    • Optimize for performance and scalability
    • Write maintainable code
    • Know the right architecture for the problem

    …is something that only comes with experience. AI can be an incredible assistant, but it won’t teach you intuition. It won’t tell you what’s actually going to work in production. It won’t warn you when something is subtly broken.