What follows are three, deeply exaggerated, jokes the Universe played on software developers.

The collaborative function

What department comes to mind when you think about collaboration? Sales? Marketing? HR?

How about Tech?

Seriously. Sales vs Software Engineering?

Sales: Flashy onboarding events overflowing with enthusiasm. Maybe a pencil or three sold along the way. And then… Individual performance targets, assigned leads or territories, private conversations with prospects. And a monthly sync or two.

Engineering: Awkward smiles over coffee machine. Complaining about the interruptions and constant context switching. Debates about working from home or going to the office. Introverts comparing energy drains.

Also: Daily standups, three different team meetings, project kickoffs, architectural reviews, requirement alignments, and code reviews. So - many - code - reviews.

The analytical ambiguity

Two marketers talk over matcha lattes, a vibrant, dazzling explosion of imprecise vibes.

Of course software dev.. engineering! is nothing like that. Engineering is analytical. Precise! Ok, there’s always that one blasphemous weirdo who thinks of software as an Art. But alas, it’s all about optimizations, algorithms, and computer science. Science! And Engineering. It’s right there in the name!

And measurable KPIs? Measurable… Well, maybe?

But don’t you try to measure engineering productivity. No lines of code, no LoC removed, and for the love of all that we hold dear, no story points.

At least we can always agree on what is the best solution to any given problem. Like in architectural discussions.

The supposedly precise discipline where nothing can be quantified.

Engineer, the business specialist

I’m walking to get my coffee - just an espresso, thank you very much - and it’s hard not to overhear those two BizDevs talking about how detached engineers are from the business. Just terrible, engineers never seem to care about business! No expertise nor interest. Just doing engineering for engineering’s sake!

Except tech debt is a business continuity concern?

And of course developers don’t know how business processes work. Except they build the workflows that execute them? To the level of detail that stops with individual 0s or 1s? Hm.

And so the humble engineer turns out to be the ultimate business specialist.

Here comes AI

I can hear you already, muttering please don’t go there. But one for the road.

So there is this DevAI thing. And it’s very useful in software development. We just need to figure out how to embed it into our organisations.

And it.. removes the coding part, so that developers can do more talking with customers or debating architecture? And despite trillions of dollars, we still can’t measure the value it creates? While engineers are competing to unlock business value faster?

Turns out that blasphemous weirdo was right all along.
“Life imitates Art far more than Art imitates Life.”

“AI doesn’t matter, I tried it a year ago and it made silly mistakes.” A principal engineer, right before burying their head in the sand.

Two camps. Same conversation, different company, every week. Both sides convinced they’re right. Both ignoring what’s actually happening.

I’ve spent the last few hundred hours coding with AI. After my Executive-Coder Experiment, I kept going: more complex systems, harder problems. As CTPO leading a 300-person engineering department, I’ve also been driving AI adoption at scale.

Here is what I’ve learned about where AI helps, where it fails, and why both camps are missing the point.

The Bottom Line

AI makes engineers dramatically more productive at generating code—but code is a liability, not an asset. The productivity gains in raw code output are real. So is the faster path to unmaintainable systems.

Business shouldn’t expect 10x productivity gains in value output. Instead, expect faster prototyping, compressed timelines, and the need for stronger engineering discipline.

The engineers who will thrive are those who understand when to use AI to sprint and when to slow down and think. AI amplifies everything—your good practices and your bad ones. Requirements, software quality, and modularization matter more than ever.

That’s the conclusion, let’s explore why.

The Assembly Line Problem

The core misconception: confusing code output with business value.

It’s easy to think about software development as coding. Writing code is what engineers love and what business thinks we do all day. However, there’s more to developing software products.

There’s the full Software Development Life Cycle (SDLC): requirements, planning, design, implementation, verification, deployment, operations. You can deliberately skip some of these when building a prototype or MVP. But once real customers rely on your product, all these stages become essential.

GenAI used by developers—DevAI—helps us produce more code. So it is rather unfortunate that we have all those other activities where AI doesn’t help as much.

Picture software delivery as an assembly line. AI just supercharged one station—coding—so it pumps out 10x more components. Sounds great, right?

Except the assembly line doesn’t work that way. Components pile up at the next stations: verification, deployment, operations. Meanwhile, the coding station sits idle waiting for requirements and design decisions from upstream. As the line moves at the speed of its slowest station, value generation is bottlenecked by other SDLC stages.

Some voices yell about 10x or 100x more productivity. And there might be some truth to it, an engineer indeed can now produce 10x more code. But without significant improvement in value for the customers, this is a vanity metric.

I’ve trashed a 20000-line project after vibe-coding with AI—and started from scratch. Haven’t seen many people share such experiences. Turns out “LOC deleted” isn’t the flex metric people want to hear about.

Others retort cynically that there is no improvement, and that AI is destroying the industry. And there is a kernel truth here. If we just produce more code while ignoring other activities, the codebase rots and quickly delivers negative economic value.

Software creates value only when customers use it.

The Complexity Tax

One of our strongest engineers worked on a new project for 9 months. He’d been using DevAI for years with advanced tooling and AI-adjusted workflow. Early on in the project, he was unbelievably productive.

But as time progressed, that slowed. Six months in, he didn’t know what was implemented where. Adding new features felt like crawling rather than sprinting. When an opportunity came to join a new project, he jumped on it without looking back.

DevAI compresses timelines.

Every codebase follows the same arc: from greenfield to legacy. Meet the holy grail of the greenfield project and the depression-inducing legacy codebase.

We have:

1. Greenfield: A clean new codebase focused on rapid development and experimentation with minimal constraints or technical debt.
2. Maturing: A growing system where features are still actively added but development slows as stability and maintainability become priorities.
3. Legacy: An aging codebase with looming issues and complexity, where changes are risky and often avoided without significant refactoring.

Here’s why the two camps disagree: The 100x productivity people are often working on greenfield projects. They’re in the honeymoon stage. The codebase is simple, clean, and AI does a great job adding another 5000 lines of code while they sip their favorite warm beverage.

That same engineer told me with a straight face that he was 60x-120x more productive with AI. Until he wasn’t.

Codebases inevitably become legacy. Adding new features becomes exponentially harder. Skeptics have lived in legacy systems, where stress levels are off the charts as even minor changes might trigger production outages.

Who’s right? Both. And neither.

Adding new features adds complexity. Changes are rarely done with time to spare, so cut corners accumulate. Productivity drops. With DevAI, we’re blasting from greenfield to legacy at breakneck pace.

This accelerated decay isn’t just about volume—it’s also about the quality of what AI generates.

The Quality Problem

I asked AI to handle HTTP redirects. When it couldn’t fix the bug, it spawned a separate process to shell out to curl instead. This turned a simple HTTP client bug into a security hazard with external dependencies and fragile process management. Just lovely.

AI code generation comes with major quality challenges. I think of it as having a scatterbrained senior engineer with:

• Lack of Stability - AI generates varying solutions on different runs. It’s random whether you get a better or worse solution.
• Lack of Intent - AI does whatever you instruct it to do, without analyzing tradeoffs or asking for more context.
• Sycophant Behavior - AI prioritizes your mood towards it over correctness. It reaffirms your bad choices and flatters you.
• Inherently Average - LLMs are trained on both high- and low-quality code. The output is average.

When we use GenAI directly in customer-facing features, we write tests and evals to validate quality. Unfortunately, there’s no equivalent when using DevAI. Code is generated once, and it’s a roll of the dice whether you got simple or complex code, security-conscious or vulnerable, performant or inefficient.

Some are impressed with AI-generated code quality. Others are dismayed.

Developers with limited experience are often the most impressed. They lack the pattern recognition to spot subtle problems: tight coupling, poor separation of concerns, security gaps. AI output looks clean and works, so it must be good.

Experienced engineers have a more nuanced view. They know not all code is created equal. Some parts of a codebase should be optimized obsessively; others just need to work. Great engineers are happy to use average code when it fits the purpose. And they can recognize when it doesn’t.

Like the curl workaround, these problems share a pattern:

• APNs architecture disaster. AI insisted Expo mobile apps couldn’t access APNs credentials directly and insisted I route notifications through a third-party service. Weeks later, I discovered AI was wrong, direct access worked fine. We’d built an entire unnecessary infrastructure layer. More expensive, less secure, less performant. Because AI hallucinated a constraint.
• Test deletion. AI couldn’t fix failing unit tests after several attempts. Solution? Delete all the failing tests. And many unrelated passing tests as a bonus. Issue resolved!

AI optimizes for making issues disappear, not for solving problems correctly. Working with DevAI means constantly catching these bad decisions: wrong abstractions, unnecessary complexity, security vulnerabilities hidden behind working demos. Miss them and they compound. Fast.

The Knowledge Deficit

Last month, I discovered a beautiful command-pattern abstraction in my codebase. Perfect separation of concerns. Elegant middleware. The kind of code you’d show off in a conference talk. I stared at it for ten minutes, trying to remember why it existed.

Then it hit me: it didn’t need to. The entire abstraction—hundreds of lines of gorgeous, over-engineered code—solved a problem that didn’t exist. I had spent hours implementing it with AI just weeks earlier. Now I couldn’t even remember what we were trying to address.

Ugh. Delete. Commit. Push. A week of “productivity” gone.

The old engineering proverb goes: “Always code as if the person maintaining your code is a vengeful maniac who knows where you live.” We laugh because it’s true: that maniac is usually future-you. Three months later, staring at your own clever code with no memory of writing it.

With DevAI, that maniac arrives much faster. And angrier. That code you barely understood when AI generated it? Good luck debugging it next week. That clever abstraction AI added? You’ll curse past-you, and the AI, when it breaks production at 2 AM.

When AI writes the code, engineers don’t build mental models of the codebase. We don’t make micro decisions like naming variables or choosing between library functions. We don’t spend time optimizing code in our heads. Writing 100 lines versus 2000 lines is the difference between carefully reading a book and skimming it.

Not a big deal in a new greenfield project—there’s just not much there yet. But once the codebase grows, the difference becomes drastic. We remember less about what abstractions exist and where. Debugging becomes harder. Reuse drops and duplication skyrockets.

The Sweet Spots

Not everything is doom and gloom. With the right problems, DevAI’s speed translates to business value.

Despite limited frontend experience, I built a polished calendar flow managing multiple calendars in under a day. 1500 lines of React code that I barely understood when writing. Months later? Still working. Still expanding it. No catastrophic rewrites required. Bonus points: I don’t dread UI work anymore.

Simple frontend development is where DevAI shines. The UI provides immediate visual feedback, making it easier to spot problems and guide AI. Many frameworks enforce structure through conventions, giving AI natural guardrails.

Integrations are another sweet spot. Connecting to external services requires mapping data models to API responses. AI digests third party docs faster than we ever could, and excels at simple data transformations.

My calendar system connects with multiple providers via CalDAV and iCal—ugly protocol and data format I wasn’t familiar with. With DevAI, I completed the integration in just a few hours. Manually, it would’ve taken considerably longer, plus a pack of painkillers.

Given clear structure and immediate feedback loops, DevAI delivers. Building a calendar UI? Great. Designing your custom billing system? Good luck.

Matching Tools to Tasks

DevAI provides a powerful new toolbox. But you wouldn’t use a hammer to cut down a tree. You shouldn’t let AI generate code unsupervised for the most critical parts of your application either.

You have plenty of options along a spectrum:

• Hand-written - Critical auth logic, core algorithms
• Hand-written, AI improved - Complex business logic
• AI-written, manually edited - Feature scaffolding, API endpoints
• AI-written, human-reviewed - Standard CRUD operations
• AI-generated, AI-tested - Utility functions, simple data transformations
• AI-generated only - Throwaway prototypes, spike investigations

Prototyping is where DevAI truly shines. Using AI to quickly gather insights and build new prototypes is excellent. Just don’t fall in love with the result and confuse it for a production-ready system.

Speeding toward legacy can be exactly what you need.

For startups chasing product-market fit, fast legacy might be perfect. You need to validate assumptions, win first customers, close your next funding round. A legacy system that proves PMF is a massive win—regardless if you throw away the code later.

Be deliberate about the choice. Use DevAI to sprint when speed matters more than sustainability. Just don’t pretend you’re building for the long term when you’re not.

What Actually Works

Start with clear requirements. The better you can instruct AI on what to build, the more useful the generated code will be. Since DevAI produces more code faster, I invest proportionally more time in requirements. I learned this the hard way—working on a mobile app, I let AI create a 10000-line monster to manage notification delivery. By the end, I didn’t know what features it was supposed to have. Twenty hours wasted. With a sigh: git revert.

Design before you code. I iterate on a dedicated design document until I know precisely what I want to build. Then I work with AI on an implementation plan covering the full SDLC. Only then do I implement. Building a task management subsystem, I clarified data flow, chose storage, even wrote an Architecture Decision Record (ADR)—but I wasn’t precise about data modeling. Hours of rework followed.

Focus obsessively on modularization. Domain boundaries should be crystal clear. Without strong boundaries, AI creates a tangled mess faster than you can untangle it. I built a feature across backend and mobile with steps that were too large. I left validation for the end—surprise, the pieces didn’t fit. Had to extract common parts and rework both.

Hire experienced engineers who can guide AI. They know when to override bad suggestions, when to demand better abstractions, when to write code by hand. They help less experienced engineers make better design decisions. Mercifully, this one spared me the war stories.

Beyond Hype and Denial

Sustainable business value won’t come from engineers who dismiss AI or embrace it blindly. It will come from those who understand tradeoffs and use AI strategically.

AI is a force multiplier.

What are you multiplying?

I paused. This question perfectly captures the delegation paradox every leader faces: how to let go without losing control.

Your delegation skills shape your effectiveness as a leader. Great leaders not only get more done by delegating, they help others grow! Without burning the midnight oil themselves. Let’s dig into the mechanics of productive delegation.

Delegation approaches

Let’s consider two different delegation approaches:

• Delegating problem-solving: You delegate the whole topic, you set up the context and outcome expectations, the other person handles everything else. They decide how to break down the problem into manageable pieces, they make the plan, and they execute on it. You’re delegating away all of the ambiguity.
• Delegating execution: You delegate only the tasks. You make and own the plan and the breakdown to pieces. You are responsible to make it all come together, you manage the project and update the plan if needed. The other person only does what you tell them to do. You are addressing all of the ambiguity yourself, they execute under your instruction.

Consider an example when delegating improvements to a deployment process:

• Problem-solving: “Please reduce duration of our deployment process by 50%”.
• Execution: “Please implement this specific CI/CD pipeline configuration I’ve designed”.

The two approaches define a spectrum: on one end you set the expectations and delegate both planning and execution, while on the other end you tell them how and what exactly to execute. And in-between are all the messy mixes where you both work on the plan.

Another way to think about it is that you always delegate fully, but in the case of delegating execution, you’re actually delegating smaller pieces within the whole that you care about. The other person still needs to plan and deal with ambiguity, but now it happens at a lower level, when deciding how to execute smaller steps in your bigger plan.

Micro-management

Effective delegation requires steering clear of micro-management.

Micro-management happens when a person must execute according to your preferences, according to your plan, even when they could get good enough outcome with their own preferred way.

When delegating fully, you’re making the other person responsible. Being responsible literally means being able to respond. Making someone accountable for outcome without giving them agency is micro-management.

In our deployment example: if you delegate reducing deployment time but insist they use your specific parallelization approach when they’ve identified a better caching strategy, you’re micro-managing. The outcome matters, not whose solution gets implemented.

Context-setting

You’ll also want to set up for success the person you’re delegating to. Missing context often leads to failure in execution.

Set clear expectations

Clear expectations help the other person deliver what you’re looking for.

You want to have shared understanding of how success looks like:

• What is the scope of the problem to be solved?
• What quality of outcome is required? Should the solution be optimal or merely good enough?
• Are there some non-obvious guardrails you’d like them to respect?

Consider project management triangle when setting expectations. Is there shared understanding of scope, timeline, resources, and quality?

Going back to our example when delegating deployment improvements, expectation setting could consist of:

• Goal: Reduce deployment time by 50% within Q2.
• Scope: Focus on CI/CD pipeline, not the infrastructure.
• Quality: Must maintain existing success rate.
• Guardrails: Weekly sync on Fridays, escalate blockers immediately.

Anchor delegation in reality

Keep your delegation realistic to enable good outcomes. None of us have infinite resources or perfectly capable team members.

Consider the person you’re delegating to:

• Do they have the right skills and competences?
• Have they solved comparable problems in the past?
• Are you delegating towards their strengths or weaknesses?

I find that situational leadership helps. Is the person willing and able to solve the problem?

Share wider context

Whatever the problem you’re trying to solve, it is embedded in a wider context. Share:

• Why is the problem worth solving?
• How might the desired outcome be used?

When getting to outcome takes time, you also want to ensure that the person will be able to deal with changes in the context and that they’ll be able to adapt their plan. There aren’t many things that are as demotivating as someone doing their best, only to find that their work isn’t useful anymore.

Implicit vs explicit context

Establishing shared context doesn’t need to take hard work. A lot of it can be implicitly understood between you and the person you’re delegating to.

When you’re working longer with someone, you become more predictable in your expectations, style of communication, and ways of working.

Watch out for assuming shared context when it’s not there. Things go wrong when “obvious” or “common sense” are not that obvious nor common. A bit of over-communication can go a long way to mitigate risks.

However, context-setting is only half the equation.

You yourself?

Remember that success doesn’t depend only on the person you’ve delegated to, but on your behavior as well.

Be predictable. After setting context, keep doing your part throughout execution. By following up as expected. By being available when needed. Some of the common failure modes I’ve seen (and I’ve been guilty of most myself):

• The fire and forget: Dumping the topic and then disappearing.
• The rubber band: Delegating broadly but then over-managing.
• The helicopter: Delegating and then hovering around.
• The just do it: Delegating the what but not the why.
• The moving goalpost: Changing the success criteria mid-flight.

Balance ambiguity when delegating. Appropriately judging ambiguity is at the core of productive delegation. Too much ambiguity is unproductive—the person might feel overwhelmed and is likely to fail. Too little ambiguity isn’t much better—the person will be frustrated with micro-management, while you’re also preventing them from learning and growing.

Evaluating success

Delegating well increases the chances that you and the person you’re delegating to will both be happy with the experience and the outcome.

This, however, doesn’t guarantee that the result will be positive—that depends not only on delegation and execution and but also on the problem itself. Even perfect delegation, planning, and execution can fail. Risk outside of your control might manifest and derail everything. Or the problem might not have established solutions—it might even be impossible to solve.

When the dust settles down, don’t focus only on the outcome. The context and the journey matter. When thinking about the delegation, focus on what was actually in the person’s sphere of influence.

Conclusion

So how do you create delegations that empower people to succeed?

Match the level of ambiguity you delegate to the person’s capabilities and to the problem’s requirements. Too much ambiguity overwhelms; too little frustrates and stunts growth. Getting this balance right tends to separate effective delegation from micro-management or abandonment. And keeps your team from updating their LinkedIn profiles in frustration.

Remember: You’re not just delegating work. You’re delegating the opportunity to think, to solve, to grow.

There is no versus—being and becoming coexist in balance.

You are where you are, and you are enough. Accepting yourself is crucial, but this should never become an excuse for not growing. Why would you settle for a lesser version of yourself in the future?

Think of it as a vector anchored to a point:

• Origin: where you stand today
• Direction: where you’re heading
• Magnitude: how fast you’re moving

Be happy with who you are. Aim up, set meaningful goals. Focus on the rate of improvement to reach a brighter future.

Embedded in Culture

Not just a personal philosophy, this belief captures the essence of positive culture I’m trying to establish in my spheres of influence.

For culture, be happy with who you are translates to:

• Creating safe space
• Celebrating differences
• Assuming positive intent

And, strive to be more, works through:

• Pursuing continuous improvement
• Celebrating mistakes and learning from them
• Sharing feedback to grow together

Being and becoming is an individual’s point of view. Everyone is on their own growth path, competing only with themselves. But no person is an island. Positive culture embeds this individual growth in an environment where everyone learns from each other.

Much simpler to write about than to live day by day. Nonetheless, this principle is at the core of a humane high-performance culture that is worth striving towards.

Be while you’re becoming. Help others to do the same.

Thank you for reading the second entry in the Leadership Tidbits series, where I share insights from my meandering experience. Check out previous post: Managing Motivation.

For a deeper exploration of culture, listen to The Human Side of Tech Leadership podcast.

Self or Outcome?

A question many leaders contemplate. The leadership burden, especially in executive positions, is about doing what needs to be done. Personal interests must be subjugated to achieve the required outcomes.

So a leader, being only a human with limited supply of willpower, must manage self.

Managing Self

Any plan based on wishes over reality is doomed to fail.

A key part of the leadership role is being realistic in managing oneself, including motivation.

So what do you do when your battery is getting drained? When work is important but dull? I consciously prioritize an interesting topic. Something that isn’t immediately the highest priority, while still valuable for the organization.

If you burn out and quit, you remove your total future contribution to the company. This cause uncertainty, creates a vacuum, and overall has negative impact on the organization.

Managing self is a personal and a professional responsibility. To prioritize your self-motivation is in line with both your and company needs.

So take care of your well-being. At the same time, don’t use this as justification to avoid doing what needs to be done.

Besides choosing what you work on, don’t forget to prioritize rest.

Prioritizing Rest

• Understand that recharging is vital. Instead of thinking of resting as being lazy, realize that it’s often the most effective thing you can do to increase your impact.
• Find ways to recharge effectively. Take inspiration from others, but keep what works for you. I relax with music and a bathtub in winter, and read guilty pleasure books on the balcony in summer.
• Rest or Impact, avoid the in-between. I used to combine relaxing and intellectual YouTube channels. But that was neither very valuable nor the most restful. So I dropped those gray spaces.
• Understand where you are each day. Some people are always aware of their energy levels. Not me. So I have morning signals to check where I am today: How enthusiastic am I while stretching? How attentive am I to music? Does a smile come easily to my face?
• Use your most effective time carefully. For me, protecting mornings is crucial. Sometimes there is a frog to eat, sometimes the day is only a sequence of frogs. So I’ll use mornings for the highest priority or for recharging.

Thank you for reading this first entry in the new Leadership Tidbits series, where I share insights from my meandering experience. Check out the next post: Being and Becoming.

For deeper exploration of being human in leadership, check out The Human Side of Tech Leadership podcast.

This perspective emerged as a central theme during my recent conversation with Tobi on the Alphalist podcast, a platform hosting CTOs from companies like NVIDIA, GitHub, and Shopify. It captures what I’ve come to recognize as essential for modern technical leadership: the capacity to navigate complexity and uncertainty with confidence.

Throughout our discussion, we explored the intersection of technical complexity, leadership intuition, and the transformative impact of AI. The conversation covered renewable energy innovations, personal productivity systems, and the future of engineering organizations.

Embracing Complexity in Renewable Energy

At Enpal, we’re tackling the challenge of providing households with access to renewable energy.

During the podcast, we explored how our systems integrate solar panels, batteries, heat pumps, and EV chargers into cohesive household energy solutions.

Perhaps the most technically fascinating aspect we discussed was our Virtual Power Plant (VPP). This system exemplifies the layered complexity we navigate daily: reconciling a fragmented energy infrastructure with 950 different grid operators, orchestrating real-time energy flows across hardware-constrained households with diverse device generations, all while participating in sophisticated energy trading markets that require split-second decisions and precise execution over thousands of households across Germany. It’s ambiguity in action—where physical infrastructure, digital systems, regulatory constraints, and market dynamics intersect.

This complexity exemplifies the type of ambiguous, multifaceted challenges that modern technical organizations face. As I shared in the conversation, these environments require leaders who don’t just solve isolated technical problems but who can navigate effectively complex systems with many moving parts.

Intuition as a Leadership Compass

In the episode, we also explored the role of intuition in technical leadership. I shared how I’ve come to understand intuition not as something mystical or irrational, but manifestation of your past experience and accumulated knowledge.

I recounted a story from my earlier career when intuition led me to add last-minute change to a critical contract—a decision that would save a 100-people company just a few months later!

This illustrates how intuition serves as an impulse to explore—a trigger for deeper analysis and systems thinking, not a replacement for it. In complex engineering environments, this intuitive pattern recognition becomes increasingly valuable as systems grow more intricate.

For deeper exploration of intuition in leadership, check out The Human Side of Tech Leadership podcast.

AI’s Impact on Engineering Productivity

The podcast took an interesting turn when we discussed my recent experiment returning to hands-on coding after seven years away—driven by curiosity about AI’s impact on software development.

“I think that every single developer will be definitely using AI, maybe even within this year, definitely within next two years, anybody who does not start to using AI will be increasingly outdated.”

We explored nuances of coding with AI assistance—where productivity gains can be dramatic but vary significantly depending on the task.

I shared my mental model of AI as a scatterbrained senior engineer—highly capable but inconsistent, requiring guidance and oversight. This led to a fascinating discussion about how engineering organizations might need to evolve to harness AI’s strengths while mitigating its limitations. I explore this topic more deeply in Strategic AI Adoption blog post.

Managing Personal Productivity

When Tobi asked about my personal productivity systems, I shared my approach to managing the constant flow of ideas and priorities. I explained how I use Evernote as an extension of my brain—a place to capture, refine, and iterate on ideas, some taking months or even years to fully develop. We also discussed calendar management as a complementary system for time-relevant reminders.

The Path Forward: Navigating Ambiguity

Perhaps the most valuable takeaway from our conversation was about navigating ambiguity—a skill increasingly critical for technical leaders:

“Jump on every opportunity you have to deal with ambiguity and develop the tools to manage it. Change will not go away. Embrace it and you’ll be better off.”

In a world where technical complexity, geopolitical changes, and transformative technologies like AI create constant uncertainty, the ability to navigate ambiguity becomes the ultimate leadership skill.

The Full Conversation

Our discussion covered many more topics—from the daily challenges of coordinating 250 engineers to the specific tools for managing AI adoption in engineering organizations.

Want to hear the full conversation? You can find the episode on Spotify, Apple podcast, or alphalist website.

Embracing the AI Revolution in Software Engineering

AI is reshaping the technology landscape at breakneck speed, and few industries feel the impact more profoundly than software engineering.

In “The Executive-Coder Experiment: Returning to Code with GenAI After 7 Years”, I shared my personal journey using AI tools for development and concluded that “as an engineering executive, I can’t leave GenAI adoption to chance—the impact is too profound.” The true revolution happens when entire engineering organizations integrate AI—a shift far more complex than any single developer’s journey.

From a broader business perspective, engineering costs represent a significant portion of technology company budgets. Organizations that increase engineering productivity through AI will gain competitive advantages in time-to-market and resource efficiency.

AI adoption isn’t optional—it’s necessary for survival. The question is no longer whether AI will play a role, but how to harness it effectively while transforming our entire approach to software development.

This transformation requires deliberate strategy. Our ways of working will be fundamentally impacted, demanding thoughtful guidance at the organizational level.

In this post, I explore how to systematically adopt generative AI in engineering organizations—focusing not just on the productivity gains, but on the organizational challenges we must address.

The Benefits of GenAI

The productivity gains roughly fall into three categories:

Research support. AI functions as an extraordinary research companion. Engineers can explore topics directly through chat interfaces instead of jumping between documentation, articles, and forums. It excels at synthesizing concepts, highlighting tradeoffs, and exploring new technologies.

Bootstrapping. AI shines when quickly bootstrapping new functionality. Setting up projects, scaffolding modules, or implementing new cross-cutting concerns happens in minutes instead of hours. What once took days of configuration and boilerplate can now be accomplished in a single session.

Code generation. LLMs can generate reasonable code with remarkable speed. They can implement complex functionality, suggest refactorings, and write tests that would previously take significant effort.

AI Isn’t a Silver Bullet

Despite impressive capabilities, today’s AI models still fall short in key areas.

Software development encompasses far more than producing code. Engineers also:

• Clarify product requirements
• Design architectures
• Operate software in production
• Respond to incidents
• Resolve conflicting stakeholder priorities
• Maintain codebase health
• Manage technical risk
• Collaborate with other engineers

Engineers constantly navigate alignment challenges and tradeoffs between short- and long-term. These concerns grow with organization size—barely noticeable in a five engineers in a startup but consuming the majority of effort in a 250-person engineering organization.

Current GenAI isn’t adept at handling these nuanced organizational aspects. For successful organizational adoption, we must integrate AI-assisted workflows with traditional engineering concerns.

The Scatterbrained Senior Engineer

Working with AI can feel like pairing with a scatterbrained senior engineer, hyper-productive but inconsistent and flaky. It accommodates whatever you ask, without pushing back on questionable decisions. It doesn’t consider complex tradeoffs. Nor does it bring intent to its work. It just generates output, with wildly varying consistency.

To properly integrate AI, we need to address both its inherent inconsistency and the lack of intentionality.

The Stabilization Challenge

AI produces inconsistent output because it’s essentially a stochastic process sampling probabilities over tokens. This is partly what makes AI so powerful—it can generate diverse solutions to the same problem. But it’s also a challenge.

If we already use a particular library for a task, we don’t want AI introducing alternatives and causing dependency explosion. If we’ve established a UI style, we don’t want it arbitrarily creating different patterns.

We need to stabilize AI—constrain its outputs to align with established standards and practices.

The Intent Gap Problem

AI tackles problems exactly as presented, ignoring missing context. It readily assumes, hallucinates, or generates information it lacks—while ignoring critical aspects not explicitly mentioned.

AI doesn’t prioritize codebase maintainability, future evolution, or separation of concerns. It doesn’t consider that functionality might already exist elsewhere or that capabilities might belong to different systems. It simply does what you ask, without questioning whether more context is needed.

Earlier, I mentioned that engineers constantly face alignment challenges and short- versus long-term tradeoffs. Current AI completely overlooks these considerations.

To prevent codebases from spiraling into AI-powered spaghetti messes, we must actively address this lack of intentionality.

Key Organizational Concerns for AI Adoption

There are six critical areas¹ that engineering organizations must address for successful AI adoption:

1. Structural Intent. Where should a change happen, and under what constraints? We must ensure AI-generated changes don’t harm maintainability and domain cohesion by adding unnecessary dependencies, duplicating functionality, or weakening separation of concerns.

2. Code Reviews. How do we effectively review AI-assisted changes, validate architectural alignment, and identify bugs, security risks, or testing gaps?

3. Project-Specific Context. How do we ensure AI respects our tech stack choices and coding standards? How do we constrain its output to align with our project’s specific requirements?

4. Knowledge Sharing. How do we share best practices for working with AI? As capabilities evolve rapidly, how do we keep the entire engineering organization current?

5. Feedback Loops. We’re all learning how to work with AI—there’s no definitive playbook. How do we quickly identify and address emerging issues? How do we maintain adaptability as the landscape shifts?

6. Tooling Flexibility. AI tools evolve weekly. We can’t commit to a single tool long-term and must be wary of vendor lock-in. How do we maintain flexibility to change tooling as needed?

Implementation Ideas

Here are practical ideas for addressing these concerns:

1. Structural Intent. This is the most critical organization-wide concern. Implement a lightweight process that defines structural intent before AI-supported development begins. For example, prepare Architecture Decision Records (ADRs), ideally with input from the entire team.

2. Code Reviews. AI-augmented development increases PR volume. To maintain review quality, implement checklists like Definition of Done. AI can help by summarizing changes and scanning for security issues. A useful test: if an AI summary of a code change lacks coherence, the change itself may have underlying issues.

3. Project-Specific Context. Many AI tools allow you to provide project-specific context. For instance, Cursor Rules let you encode coding standards and tech stack preferences directly into the AI’s context, helping constrain its output and reduce complexity explosion.

4. Knowledge Sharing. Create dedicated spaces for AI knowledge sharing. Combine written resources (prompt collections, best practices) with interactive sessions (demos, discussions, dedicated channels). Early hackathons can accelerate adoption by quickly moving from theory to practice.

5. Feedback Loops. Integrate AI adoption discussions into team retrospectives. Establish community-driven support channels for cross-organizational support. Use periodic deep-dives and surveys to maintain an accurate org-wide understanding of adoption progress.

6. Tooling Flexibility. Maintain flexibility to switch between foundation models. Balance standardization (teams using fewer tools) with exploration of emerging alternatives. Consider adopting a single AI-native IDE like Cursor to provide common workflows while allowing engineers to choose different underlying models.

Adoption Challenges to Anticipate

It’s tempting to overengineer AI adoption. Instead, balance thoroughness, pace, and innovation through iteration. Start with minimal guidelines and refine continuously. Trying to implement too many guardrails while the field evolves rapidly will fail. We’re in uncharted waters—maps help, but we must watch the sea.

Beyond changing workflows, internal resistance will likely be a challenge. Two common objections to AI adoption I hear:

Job security concerns. Some developers resist using AI tools, fearing they’ll be replaced. So far jobs aren’t disappearing but evolving. Ironically, those who resist may find themselves less relevant as the industry advances. The best job security might come from mastering these new tools.

Capability skepticism. Often, this stems from negative experiences with less capable models early on. Many developers underestimate just how much AI capabilities have advanced recently.

The Path Forward

Embracing AI for developer productivity isn’t optional. We must do so thoughtfully and deliberately. Fast iterations and tight feedback loops will guide our adoption journey as we discover what works.

“Not all those who wander are lost”

This ancient wisdom from Hillel the Elder emerged as a central theme during my recent conversation on the CTO Confessions podcast. It captures a fundamental lesson I’ve learned through years of leadership: the willingness to take action, knowing mistakes will happen, matters more than striving for perfection. And perhaps counterintuitively, the more senior your leadership role, the more valuable it becomes to show your human side—your low points, your mistakes, and yes, even your bad jokes.

Throughout the conversation, we explored what this means for leading engineering organizations. Here are the key insights that emerged:

• Intuition backed by systems thinking: Remember that gut feeling when something’s off, but you can’t quite put your finger on it? I’ve learned to embrace these moments. Rather than dismissing intuition as irrational, I use it as a signal to dive deeper with systematic analysis. We explored this through a story of how a nagging feeling about a contract led to discovering a crucial omission—a realization that would later save the company during COVID. The key isn’t just trusting your gut—it’s using that initial signal to find the logical inconsistencies that your intuition is picking up on.
• Connecting technology and business: You know that moment when you’re explaining a complex technical constraint and see glazed eyes across the room? That’s where the Spider-Man drawings come in. During our chat, I shared how this simple visual analogy helps executives instantly grasp project trade-offs better than any technical explanation could. But it’s more than just clever analogies—we explored how technical leaders can build genuine understanding by combining hard data with intuitive examples, always remembering that the person across the table brings valuable expertise from a different domain.
• Work and life integration: I used to think leadership meant maintaining a professional distance. I was wrong. In the podcast, we explored how authentic leadership requires thoughtful integration of personal and professional sides. When I’m exhausted after being sick, I tell people—not for sympathy, but because humans fill information voids with their own narratives. We discussed how this approach transforms team dynamics, while still maintaining healthy boundaries. It’s not about oversharing; it’s about creating space for genuine human connection.
• Culture of safe mistakes and real feedback: Want to hear about a half-million euro mistake I made? In the podcast, we dove deep into how leaders can transform mistakes from sources of fear into catalysts for growth. We explored how broadcasting mistakes—rather than hiding them—fundamentally changes organizational dynamics. When leaders show vulnerability first, it creates space for honest feedback to flow in both directions, building the foundation for genuine psychological safety.
• The role of humor in leadership: Those awkward three minutes before a big meeting starts? We discussed how these moments present unexpected leadership opportunities. It’s not about being funny—it’s about creating moments of human connection that make the serious conversations more impactful. The podcast dives into how this approach helps break down hierarchical barriers while actually strengthening leadership effectiveness.

We unpacked many other topics during our conversation—from concrete advice for aspiring engineering leaders to pondering about Europe’s unique position to lead the GreenTech revolution.

Want to hear the full conversation? You can find the episode on Spotify, Apple podcast, or CTO confessions website.

More Leadership Conversations

If you enjoyed this episode, you should listen my more recent discussion on the alphalist podcast, where I explore navigating ambiguity and AI’s impact on software development.

But let’s start at the beginning.

Who am I?

I’m a CTO leading a 250-strong engineering organization at Enpal, a GreenTech unicorn in Germany.

I’m also an engineering executive who hasn’t coded for 7 years.

Actually, that’s a lie! I did spend two hours three years ago helping a friend with Google Sheets automation. Total time around code, even reading it? Less than 20 hours in five years.

At the same time, I am what you might call a tech native. I’ve been programming since I was 10. For 20 years, I’ve lived and breathed engineering, whether writing complex Scala code or designing geographically distributed systems that tangle intimately with the CAP theorem.

I lean on my technical background frequently in leadership work—whether setting tech strategy, sparring on architecture proposals, or defining post-mortem standards.

Enough about my background. Still curious? Check out my LinkedIn.

Why code?

As a CTO leading sizable organization, my role is centered on strategic initiatives and organizational leadership, leaving no time for coding myself. It is, however, my responsibility to understand engineering work, and coding is at the heart of it.

I’ve been following Generative AI developments closely for the last two years. I’ve also been using ChatGPT regularly, mostly for writing support and research.

Despite my background in machine learning, I’ve wrestled with understanding GenAI’s true value in software development. It’s useful, no doubt. But for what tasks? How much does it boost productivity? Where does it fall short?

Human vs AI /take 1

So, I ran an experiment. I wanted ChatGPT to generate Scala code similar to what I used in my conference demo on type classes in 2016. Here’s the prompt I used:

> Please provide a fully-functional Scala code for implementing type class that represents statistical library with 5-10 most common statistics methods that abstracts away the implementation of numbers

Quite a mouthful. I noticed that generated code didn’t support custom numeric types, so:

> Please extend it so it can work with any number type, not only with Numeric from Scala, but any custom type that implements basic arithmetic, regardless of how the concrete operators and methods are called

And that was it! 123 lines of non-trivial Scala code. Reading through, I didn’t spot any issues with the implementation.

I chose this test because type classes are an advanced concept and Scala implementation relies on the Scala-only mechanism of implicits.

I hadn’t expected ChatGPT to succeed with no guidance other than the high-level requirements in two prompts.

I knew then that I must understand GenAI capabilities to support software development!

Human and AI /take 2

I set out to have an experiment with practical results. So, I chose to built a simple homepage.

I added constraints to make it interesting:

• A programming language I haven’t used before
• A cloud environment I’m not familiar with
• Production-grade quality standards
• Professional development workflow

Without knowing what to expect from GenAI while coding, I chose vanilla ChatGPT-4o.

It was Saturday morning, and I was ready to start.

Okay, cut! Cut! Results first! Some readers are executives, so outcomes first!

Uncovering the Outcomes

The experiment was a success! This executive was a productive developer with the help of GenAI. I finished the project in 28 hours while adhering to the self-imposed constraints.

The outcomes:

• A homepage with a custom domain is online: www.ivankusalic.com. This is where you are right now!
• Subscribing for the upcoming newsletter works.
• The code is thoroughly tested with unit tests and integration tests.
• The project is ready for real-world use, with features like logging, HTTPS enforcement, simple rate-limiting, input validation, and user input sanitization.

The development experience was smooth overall. Only about 5 of the 28 hours were frustrating, mostly spent debugging dependencies. The rest was genuinely enjoyable—I even found it hard to step away.

And to say that ChatGPT was “useful” is an understatement!

What I Learned Along the Way

Let’s dive into the insights from this experiment.

ChatGPT Capabilities

• ChatGPT proved tremendously useful in hands-on development. Though GenAI has limitations, it’s a powerful productivity boost. Without it, I’d have likely spent three times longer on the project—and with far more frustration.
• ChatGPT required direction for non-trivial development tasks. I had to stay clear on my goals, plan each next step, and track open issues to make the most of it.
• It needed guidance on what mattered. For instance, it didn’t suggest sanitizing user input, even when prompted for security improvements. While I was impressed by the testing scenarios it generated, it still missed a few critical ones.
• ChatGPT had a habit of hallucinating. It often forgot content it had just helped create, used placeholder references, or brought back outdated elements we’d already moved past. Amusingly, it kept generating tests that its own code couldn’t pass.
• However, hallucinations were less of an issue than I expected—they were easy to catch. Only once or twice did it take me 10 minutes to spot one.
• A bigger issue was its tendency to shift directions unpredictably. Especially during debugging, it kept suggesting new approaches—like switching libraries or changing dependency management.
• It frequently suggested suboptimal code changes to solve immediate issues—like adding unnecessary dependency injection in production code just to bypass a broken test setup.
• It tended to add complexity with little payoff. For example, when doing simple email validation, it kept trying to complicate the regex.
• ChatGPT missed intricate bugs. For instance, it couldn’t catch invalid pattern matching when extracting values from a POST request.
• At times, it missed even trivial bugs, like a DNS entry where the Host accidentally included the full domain.

Development Workflow

• An apt analogy for working with GenAI: it’s like driver/navigator pair programming, with the human in the navigator’s seat and the AI taking the wheel.
• My seven-year-old development workflow remained largely unaffected. I relied on familiar tools and habits: heavy local Git use for work-in-progress, driving implementation with positive tests, adding negative tests, then refactoring—all while navigating the codebase with Vim and terminal.
• I learned not to just accept its suggestions but to narrow down the approach when facing issues, with clear instructions when the approach is a constraint that needs to be satisfied.
• Cutting down the noise benefited both human and the AI—like focusing on one test or bug at a time.
• The main workflow change was frequent copy-pasting to and from the ChatGPT app. I rarely used the browser for research or debugging and visited StackOverflow only twice.
• It was a big help with visual design, an area I’m neither skilled in nor enjoy. It saved time and delivered better results than I could on my own.
• Another area where it shined was in writing tests. It was excellent at generating unit tests and fairly effective for integration tests. Hopefully, as an industry, we can finally agree that tests are not just vital—they’re now absolutely worth the effort!
• ChatGPT was helpful but unpredictable in debugging. I developed a pattern: I’d let it attempt debugging 2-3 times. If that failed, I’d shift to understanding the issue more deeply myself, either guiding it with more specifics or resolving the problem solo.
• It was least helpful with refactoring. Partly, this was due to the back-and-forth copying with the ChatGPT app—a gap that specialized tools may bridge. Still, complex refactoring needs a broader perspective, so I don’t expect a quick fix from tools alone.

Personal Insights

• Getting back into programming was surprisingly easy, even after 7 years. ChatGPT made the process less frustrating, though I’m confident I could have completed the project solo with similar results. It just would have taken longer.
• Compared to traditional coding, working with AI is just as engaging but less frustrating. The satisfying elements remain: problem-solving, software design, and driving engineering quality. But some of the annoyances—like boilerplate code, endless debugging searches, and sifting through low-quality articles—are reduced.
• Overall, I found AI less frustrating than expected. Hallucinations were a smaller issue than anticipated, and even the copy/pasting felt manageable—I was still faster with AI than I would have been without it.
• One pattern I noticed: my prompts grew more concise over time. While debugging, I often just pasted exceptions without any added context.

Questions for the Road Ahead

After concluding the experiment, I have a clearer understanding of what GenAI can and cannot do currently. However, I’m far from having all the answers. Here are some open questions:

• What is the productivity boost when programming regularly? It’s likely to be smaller, as writing code or handling recurring issues will often be quicker to address manually.
• How effective is GenAI with larger codebases, especially for newcomers? I haven’t explored this at all given the nature of the project.
• How differences among languages, frameworks, and libraries manifest in the development workflow with GenAI? I’ve only explored using basic HTML, CSS, and JavaScript.
• How should organizations integrate GenAI to increase developer’s productivity?
• Even—what is the future of the software developer’s role?

The Bottom Line?

Overall, I’m pleased with the experiment—the project outcome exceeded my expectations, and I gained concrete insights into using GenAI in software development.

One thing is clear: as an engineering executive, I can’t leave GenAI adoption to chance—the impact is too profound. Moving forward, my role will include not only enabling engineers to use GenAI effectively but also setting standards and processes to maximize its benefits. I don’t know exactly how that will take shape yet, but some ideas are already forming.

Does this experience change how I see my role as CTO? It does not. With or without ChatGPT, I’m still responsible for 250 people, so I won’t be coding anything soon.

Would I want to return to programming over being an engineering executive? A resounding no—I thrive on the impact, strategy, problem-solving, and the people side of my role. If anything, using JavaScript as a backend language put Ivan the Developer to rest more effectively than management ever could.

(Read on to dive deeper into the journey throughout this experiment. Otherwise, thank you for reading!)

Update: I’m exploring how engineering organizations can effectively adopt AI for software development productivity in my follow-up article “Strategic AI Adoption: Engineering Organization Transformation”. Check it out!

From Concept to Code

Back to beginning. This was to be the GenAI-powered experiment, and that’s how it started.

Choices first

I kicked it off with ChatGPT to decide on the tech stack—Vercel with Jekyll. The exploration phase spanned 11 interactions and covered setting requirements, evaluating hosting platforms, diving deeper into Vercel features, and considering future scalability.

As I’ve used ChatGPT for research in the past, no surprises here.

> Time used: 1h. Total time: 1h. ChatGPT usage: Main research tool.

Laying the Groundwork

It took about half an hour to set up a clean environment. Here’s a rough outline of the steps:

• Created a new SSH key and added it to Github
• Set up my old dotfiles
• Set up the newest version of Ruby via Brew
• Created a new Jekyll project
• Created new repo and made the initial commit

So far so good. Very minimal support from ChatGPT—only one question during SSH key generation.

I chose a development environment with the command line and Vim—a comfortable choice since I use iTerm regularly and Vim my go-to editor. Thinking about it, this setup might be a bit quirky given my role.

Having my old .gitconfig made me happy—it felt like I’ve last coded weeks and not years ago. It felt comfy, familiar, professional.

> Time used: 30min. Total time: 1h30min. ChatGPT usage: Minimal research support.

And We’re Live!

Four commits later, I had a clean Jekyll setup for a one-page website, without that pesky footer.

Next, I focused on getting the homepage live quickly. Small iteration and incremental releases and all that good stuff!

This was straightforward but took a while. I had to figure out how to override Jekyll defaults and understand the project structure, which meant a bit of digging into the gem structure of Jekyll’s Minima theme. Nothing too complex as I did a lot of Ruby years ago.

As the page was served locally, I focused on deployment. This part was a breeze. After creating a Vercel account and a new project linked with my GitHub, it only took one git push and the static page was live. With a glorious "TEST homepage" to show for my efforts!

It took 10 minutes to setup a custom domain – trivial as I already had the domain. Now the “TEST homepage” was live on my domain!

I tested the page on both desktop and mobile. On mobile, an unsightly hamburger menu was tarnishing my pristine “TEST homepage”, so I removed it. I also updated the message to “The page is currently under construction. Please come back soon.” and called it a day.

That afternoon, I turned to ChatGPT a few times for trivial questions rather than Googling. I was still getting back into using Git locally, but it already proved valuable when I went down a wrong path with the setup.

> Time used: 4h30min. Total time: 6h. ChatGPT usage: Light research support.

One-page Site

A new day, and still the weekend! Time to create a static page I’m not embarrassed to show to people.

This was me and ChatGPT all the way.

Copywriting took about an hour, followed by a couple more hours of tweaking to get the design I liked. This was my first time using ChatGPT for HTML and SASS styling. Initially, it dumped everything into a single file, index.markdown, so I guided it to extract parts of HTML to fit Jekyll’s structure, using the Minima theme as a blueprint. I did the same with styling, going from inline CSS to modular SASS that Jekyll supports.

This was something I would struggle with on my own—I never delved deeply into CSS, nor do I have an eye for design. But working with ChatGPT made it straightforward.

A particularly noteworthy moment came when I wasn’t sure how to structure links and a photo into a header section. I’d seen a clean, minimalist one-pager a friend used, so I simply asked ChatGPT:

> I want to have a profile picture as circle on the left side of header information. Similar as placement on: {link-to-friends-page}. Please provide content/code for jekyll's index.markdown

Wow, the generated code was exactly what I wanted.

In this session, I was fully pairing with ChatGPT. It was delivering what I asked for, and I was tweaking it further. The only tedious part was the copy-pasting to and from the ChatGPT app.

Adding a favicon took longer than expected—full 45 minutes. Generating it was easy, but getting it to display properly was frustrating. The culprit? Caching. I was reminded of the old saying: “There are only two hard things in Computer Science: cache invalidation and naming things.” I found it both ironic and reassuring that my first unexpectedly time-consuming task was a caching issue. Some things haven’t changed in the last seven years, after all.

It was late, but I had a live website I’d feel good about sharing.

> Time used: 3h. Total time: 9h. ChatGPT usage: Full-on pairing.

Towards Newsletter

The work week had started, so my first few free hours didn’t come until late Tuesday evening.

I knew the next topic was to prepare for a newsletter, as I plan to create one in the near future. The first step would be to let people show interest by sharing their email address.

This was a fun session. First, I researched, with ChatGPT, what to use for storing subscriber data.

I chose Vercel’s KV store as it was directly supported by Vercel and was a proper store to integrate with.

I needed to choose a programming language for serverless functions and settled on JavaScript. Initially, I considered Ruby, but I know Ruby well, whereas I’ve only dabbled in JS a few times. Plus, JS felt like a better challenge—as a developer, I’ve always preferred strong type systems, and JS is the exact opposite: a weakly typed, dynamic language, infamous for silent error handling. I even resisted the urge to use TypeScript. After all, I was looking for a challenge.

After choosing JS, I did a quick, 10-minute ChatGPT-guided introduction to the necessary tools to set up a local environment. Installing NodeJS was straightforward, and I was off to a solid start.

Even writing the integration test for the KV store was easier than expected. The only hiccups were related to npm and dependencies. Oh well, another thing that didn’t change with time.

ChatGPT was invaluable for setup, tooling, and debugging both code and dependencies.

I went to bed quite late, but with a sense of accomplishment. After all, I was successfully writing, reading, and deleting from the KV store in my toy integration test.

> Time used: 4h. Total time: 13h. ChatGPT usage: Continuous usage for research and pairing.

Mounting Frustration

Next, I carved out time on Thursday evening.

This time, my goal was to add subscription functionality and connect it to the KV store.

I started by asking ChatGPT what information to store about a newsletter subscriber. It suggested a lot I didn’t need, but also covered everything I did. I settled on the following data format:

key: subscriber:email
data: {
  email: email
  first_name: firstName
  subscription_date: subscriptionDate
  referral_source: "ivankusalic.com"
}

Next, I worked on the function that stores a subscriber in the KV store:

async function addSubscriber(email, firstName)

With ChatGPT’s help, I first created the function. The code was straightforward, but I appreciated that it handled details like using the YYYY-MM-DD format for the subscription date.

Next, I asked it to generate tests, and it provided two positive and one negative integration test:

it('should successfully add a subscriber')
it('should overwrite an existing subscriber when adding with the same email')
it('should handle trying to add a subscriber with invalid email')

I repeated the process for getSubscriber and deleteSubscriber functions, then confirmed directly in the KV store that each function made the expected changes.

Next, I created a simple helper function for basic email format validation, using regex. This was all ChatGPT; I only rejected using any third-party libraries.

I also requested detailed unit tests, and ChatGPT generated 19 of them. Here, ChatGPT hallucinated a bit—it created reasonable examples of ill-formatted emails and negative tests, but a few were beyond what the simple regex could handle. I opted to keep the regex straightforward and dropped three overly ambitious tests.

Finally, I spent most of my time creating a serverless function to expose the Subscribe API. In hindsight, this turned out to be the most challenging part of the entire experiment.

The first implementation ChatGPT provided was basic, so we iterated to improve it. Once again, I opted not to add external dependencies. The result was still robust, including input validation, simple rate-limiting, HTTPS enforcement, and logging.

That wasn’t the hard part, though. Getting the tests to run was a true exercise in frustration. I learned that JS can either use require or import/export syntax for dependencies—but they can’t be mixed. I kept running into exceptions and ended up pasting them directly into ChatGPT. It struggled to resolve the issues, and we went through various testing libraries in search of a fix.

Eventually, I gave up on mocking altogether and switched to pure integration tests for my new API, writing directly to the KV store. I managed to get these tests working, though I couldn’t replicate internal server errors in an integration test.

Overall, it was a frustrating experience. It highlighted some limitations of ChatGPT—it kept switching between libraries and flipping between dependency management approaches. It also required more guidance, requiring me to reason through the code and issues in greater detail.

This might sound negative, but considering I hadn’t used JS seriously before, it was manageable. While frustrating at times, it would have taken me much longer without ChatGPT.

> Time used: 4h. Total time: 17h. ChatGPT usage: Debugging and code generation, frustrating.

Subscriptions Up and Running

The work week was over, and the Friday evening session was more fun.

I added a newsletter section to the page, quickly styled the form asking for first name and email, and added client-side JavaScript to send the data to the Subscribe API I created before.

Since I’d already used ChatGPT for styling, everything went smoothly. Even calling the API worked almost on the first try. There was just one bug—a wrong API path for the serverless function, another ChatGPT hallucination which took five minutes to fix.

After that, I made a few smaller refactorings and called it a day.

> Time used: 3h. Total time: 20h. ChatGPT usage: Smooth full-on pairing.

Staying Updated: New Subscriber Alerts

On Saturday morning, I began with some light refactoring of code and tests.

I also wondered if I was finished—after all, the subscription feature was up and running

I decided to set up an email notification to a dedicated address whenever someone subscribes. This not only keeps me informed of new subscribers but also creates functionality I’ll need when the time comes to send out the newsletter.

Equally relevant, I wanted to experiment with the project a bit more. I also had a nagging awareness that I hadn’t implemented proper unit tests with mocks for my Subscribe API. However, it was such a beautiful morning that I didn’t want to dive into JS dependency hell just yet.

After a quick research with ChatGPT, I settled on using SendGrid as the service for sending out emails.

The SendGrid setup proved surprisingly frustrating. I wanted to send emails from my custom domain, but SendGrid wouldn’t recognize the DNS entries. Since this process can take a while, I wasn’t sure if something was wrong or if I just needed to wait. It turned out the DNS entries were incorrect.

Ironically, SendGrid had provided them—I had simply copy-pasted their CNAME data without modification. The issue was simple: SendGrid provided Host entries that included the full domain name instead of just the prefixes. My domain register, Namecheap, didn’t catch it, nor did ChatGPT. And since I hadn’t dealt with DNS setup in a while, I missed it too. A quick Google search helped. There might be a lesson here as one of the simpler bugs so far was the one that slipped through the cracks of three systems and one human.

In parallel, I began implementing the functionality for sending out emails. The concept was straightforward: I would send an email whenever a new subscriber clicked the submit button. This meant the Subscribe API would need to call a new API—the Send Email API.

I decided it was acceptable for this notification to fail; what mattered was that the subscriber data was stored in the KV store. So, I set about creating a function to be called from the serverless function behind the Subscribe API:

function emailMeAboutNewSubscriber(email, firstName)

Not the best name, but naming things is the second hard thing in computer science!

By now, the process felt familiar—ChatGPT and I were iterating on tests and implementation in parallel.

The most interesting development was that I successfully implemented unit tests for the new functionality with proper mocks. It took effort, but this time I didn’t waver. ChatGPT remained stoic as always.

Emboldened by this success, I turned my attention to the issue that had defeated me on Thursday: transforming those Subscribe API integration tests into proper unit tests. It was bloody work. ChatGPT was confused. I was confused. We were mocking functions, then modules, and then even more modules. In the end, it all came together, and I learned more about JS module loading mechanisms than I ever wanted to know.

After a bit more work, the emails started arriving in my inbox as expected.

> Time used: 6h. Total time: 26h. ChatGPT usage: Winning together against the mocks.

Finishing Touches

It was time for the final tweaks—adding analytics support and sanitizing user input.

After one last deployment, the experiment came to a close.

> Time used: 2h. Total time: 28h. ChatGPT usage: Pairing for the win.

Story in Numbers

Project timeline:

• 8 days, spanning two weekends and 3 workday evenings
• 28 hours total, including 3 hours of copywriting

The stack:

• ChatGPT - GenAI support for research and coding
• Vercel - cloud environment serving the webpage
• Vercel services - KV store, serverless functions, analytics
• Namecheap - domain name register
• SendGrid - email delivery service
• git/Github - version control
• Jekyll - static page generator
• JavaScript - backend programming language
• NodeJS - local JavaScript runtime
• Vim - editor/IDE
• iTerm - command line interface

The codebase:

• Frontend: 7 custom HTML files, 3 custom SASS files, 1 custom JS function
• Backend: 2 serverless JavaScript APIs and 7 supporting functions
• Tests: 51 unit tests and 9 integration tests

Here is the git log of my commits during the experiment:

That’s it! Thank you for reading!

While tech is undeniably complex, our approach to explaining it doesn’t have to be.

The presentation centered on a key insight: communication effectiveness depends on the listener’s understanding, not the speaker’s explanation. Tech leaders must transform complex concepts into accessible language that resonates with business stakeholders, using relatable analogies and real-world examples.

At its core, tech stands at crossroads of being an engineering discipline and art form. Unlike traditional engineering with physical constraints, software development offers endless possibilities. This duality makes tech unintuitive for non-technical stakeholders.

Tech leaders should develop empathy for business colleagues. Consider a CEO with an operations background, used to measurable metrics, suddenly navigating the ambiguous world of tech development. Understanding this perspective helps bridge the gap between traditional business approaches and technology’s unique challenges.

The power of storytelling was the central theme of the talk.

One particularly effective analogy I use compares engineering quality to Excel models:

• Multiple sheets => multiple services
• Input and config sheets => deteriorating separation of concerns
• Editing by multiple people => race conditions
• Analyst working on a model alone => onboarding, bus factor
• Editing someone else’s excel => readability and maintenance
• Hardcoding into existing formula => code smells
• Formulas vs constants => copy/pasting

I’ve explored numerous other analogies and metaphors that create intuitive understanding of tech, from comparing software systems to buildings, to illustrating quality trade-offs through Spider-Man sketches.

Ultimately, successful technical leadership requires more than just technical expertise—the ability to build connections through storytelling, intuition, and shared experiences is crucial. As technology increasingly drives business success, this skill becomes indispensable.

To explore more about bridging the tech-business gap and discover other powerful analogies, download the presentation deck.