Every line of code your team writes is a future liability. Every custom-built system is a maintenance tax that your company will pay for the lifetime of the product. As a Principal Engineer, my primary job is not just to deliver software. It is to protect the company’s ability to win. If we are building things that don’t make us unique, we aren’t innovating. We are just creating overhead.

What is the secret sauce

When a Product Manager or a Lead Engineer suggests building a custom solution, they are usually focused on the perfect fit. To make sure the business wins, I have to focus on the opportunity cost.

The rules are simple:

• Build the Core: If the technology provides a unique competitive advantage, the capability that makes customers choose us over a competitor, we build it. This is where we want our best minds focused.

• Buy the Context: If the technology is a standard industry requirement (Auth, Payments, CRM, Messaging), we buy it. Building a custom billing system does not make us a better Fintech or AI company. It creates a maintenance burden that steals velocity from the work that actually differentiates us.

The Framework: The Core vs. Context Matrix

To make this decision objective rather than emotional, I use the Core vs. Context Matrix, inspired by the Eisenhower matrix. It forces us to ask two questions:

• Is this mission-critical? (e.g. if it’s down, we can’t sell or serve customers, or we breach legal requirements or SLAs)

• And does it differentiate us? (e.g. it changes win-rate, retention, or unit economics in a way competitors can’t easily copy)

Two caveats.

Not all decisions are equal. Some are easy to undo, while others become permanent architecture. When a decision is hard to reverse, we bias toward proven vendors. When it is reversible, we can afford to experiment and learn quickly. A useful heuristic is this: if it would take quarters and a migration to undo, treat it as irreversible.

The Non-critical + Differentiating quadrant is essentially Research and Development. My experience as a professional researcher taught me that this is the preferred hiding spot for pet projects. These investments must be time-boxed with explicit success criteria to avoid a backlog of never-ending experiments.

Building the Core

Even when the matrix says Build, the trap is overbuilding. A Principal Engineer avoids the perfect fit fallacy by focusing on opportunity cost. When we decide to build the Core, we must do it with lean execution.

• Define interfaces early to allow parallel work

• Build thin and iterate fast to prove the differentiation hypothesis

• Instrument heavily to see if the custom build is actually moving the needle

• Invest in testability and operability from day one to prevent the system from becoming a burden

The Maintenance Tax

Engineers love to build. Teams often believe they can do better or cheaper than a vendor. But the sticker price of a vendor is often lower than the Total Cost of Ownership (TCO) in the early years. When you build Context, you are paying for future security patches and documentation that a specialized vendor would have already provided. I would rather pay a vendor to handle the boring complexity of global tax compliance so my engineers can focus on work that provides value to the business.

Buying is Not a Silver Bullet: The Integration Tax

Buying has its own risks. As I discussed in my previous post on evaluating software vendors. the Buy path introduces the Integration Tax. You must watch out for:

• Operational coupling: A vendor outage becomes your outage

• Data model mismatch: Forcing your logic into a vendor’s rigid schema

• Observability gaps: The system becomes a black box when things go wrong

• Contract and Security review overhead: The hidden time spent with legal and compliance

Even with these risks, a complex buy is usually safer than a distracted build. When we buy Context, we are buying time. In a high growth environment, time is the only resource we cannot manufacture.

Adopt + Integrate

Sometimes the best answer is Adopt + Integrate. This means adopting a market leader and integrating it deeply enough to meet product needs without owning the full complexity. You buy the foundation (Stripe, Okta, AWS) and build a thin abstraction layer around it. This allows you to own the workflows and data model boundaries while preserving an exit strategy by designing for migration up front. This approach works best when:

• The capability is Context, but must feel seamless in the product experience

• The vendor solves most of the problem, and the remaining gap is specific to your workflow

• The system needs strong internal controls, observability, and governance

The Context to Core transition

A common misconception, especially in the cloud-computing age, is that infrastructure is never Core. However, you must also recognize that some foundations become differentiating as the company scales. For instance, infrastructure cost efficiency becomes a competitive advantage for high-volume platforms. Latency can become a product feature in fintech. In these cases, what started as a Buy decision may eventually need to move to a Build strategy to protect your unit economics or performance edge.

Decision Checklist for Your Next Meeting

Use these five questions to audit your next Build vs. Buy proposal:

1. Differentiation: Does this feature help us win a deal or retain a customer in a way a vendor cannot?

2. Time to Value: Can a vendor get us to market in weeks instead of the quarters a custom build would take?

3. The Maintenance Owner: Who is the named engineer responsible for security patches and updates for this custom system in two years?

4. Reversibility: If we build this and fail, or buy this and it sucks, how hard is it to switch?

5. The Exit Strategy: If the vendor triples their price or goes bankrupt, do we have a plan to migrate?

6. Data Ownership and Portability: If we need to leave this vendor, can we export our data in a complete, usable format, and migrate without losing history, integrity, or critical workflows?

The Real Outcome

The goal of a Buy vs. Build strategy isn’t to save money in the short term. It’s to ensure that when we do decide to build, we are doing it with maximum focus and zero distractions.

We buy the foundations so we can build the skyscraper.

I’ve also been on the other side of it. While scaling a product into new markets, expansion surfaced risks we didn’t expect. The system was running, customers were paying, and momentum was real. But when we load-tested the platform for global scale, uncomfortable gaps appeared. We had to slow down on purpose, refocus on a small set of foundational checks, and be honest about what was production-ready versus what was merely functioning. That pause protected speed later and made the next phase of growth possible.

This is the difference between Seed and Series A. In a Seed round, investors bet on the founder. In a Series A, they bet on the engine. Diligence isn’t a code review and it isn’t about perfection. It’s about risk containment. Investors aren’t trying to eliminate risk. They’re trying to price it. Unidentified risk can’t be priced. It gets flagged. And during a fundraise, a “wait” is effectively a silent no.

Debt vs. Deal-Breakers

As I’ve written before, tension between Product and Engineering is healthy. Shipping always comes before polishing, and learning in production is part of the game. Technical debt isn’t a failure. It’s a deliberate trade.

The problem isn’t debt. The problem is when debt stops being priced and starts becoming unmanaged risk.

In practice, the line is simple. If a technical risk can’t be explained to an investor in one sentence, along with who owns it and when it gets resolved, it’s no longer debt. It’s a liability. VCs aren’t looking for perfect code. They’re looking for evidence that you understand your risk surface and actively control it.

This is where Series A diligence breaks teams. Under questioning, systems that mostly work suddenly reveal brittle assumptions. Decisions that made sense at Seed speed can’t be justified under Series A scrutiny. Not because they were wrong, but because no one owns them anymore.

Investors don’t eliminate risk. They price it. Risk that’s named, bounded, and owned can be priced. Risk that’s vague, undocumented, or tribal knowledge can’t. That’s what turns a conversation from yes into come back later.

Four Examples of Unpriced Risk

These aren’t edge cases. They’re the first questions that surface when an investor starts pressure-testing a Series A stack.

The Bus Factor

If your lead engineer disappears tomorrow, can someone unfamiliar with the system deploy, debug, and roll back within 48 hours? When core knowledge lives in one person’s head, velocity looks high until it isn’t. Investors don’t fear complexity. They fear single points of failure.

The License Trap

Are you building critical parts of your product on copyleft licenses that quietly force you to open-source your IP? This often isn’t discovered by engineering at all. It surfaces late through legal diligence, when timelines are tight and options are expensive.

The Snowflake Infrastructure

If your cloud environment is a collection of hand-crafted settings rather than reproducible infrastructure, you don’t have scale. You have fragility. Systems that can’t be recreated from code can’t be trusted under growth or incident response.

The Mystery Cloud Bill

If you can’t tie your monthly cloud spend to specific features or customers, you can’t explain your margins at 10× scale. Under diligence, “we’ll optimize later” isn’t a strategy. It’s an unanswered question.

Each of these maps to a different category of risk: people, legal, infrastructure, and financial. And they’re only part of the picture. Other risks don’t show up as outages or invoices, but as delivery bottlenecks, ownership gaps, and governance blind spots that only appear under scrutiny.

What Should Founders Do?

Most founders don’t discover these risks while building. They discover them when an investor, lawyer, or technical auditor starts asking questions they weren’t expecting. By then, timelines are tight, options are limited, and the conversation shifts from momentum to remediation.

To avoid that, I use a Series A Technical Readiness Scorecard to pressure-test systems before diligence begins. It’s the same framework I’ve used when helping teams prepare for expansion, audits, and investor scrutiny. It’s designed to surface unpriced risk while there’s still time to act.

The Scorecard covers five areas that routinely come up in Series A diligence and expansion reviews, and helps you:

• Identify risks that could stall or slow a round before your first VC meeting

• Replace vague answers with clear ownership and timelines

• Focus effort on the issues that actually affect valuation and confidence

Use the Series A Technical Readiness Scorecard to pressure-test your stack before diligence begins.

If you’re planning to raise, or preparing your stack for the next phase of scale, the goal isn’t perfection. It’s knowing where the risks are, which ones matter, and being able to speak to them with confidence.

Get the Scorecard & Prepare for Diligence

I also offer a 1-week Technical Due Diligence Audit for teams that need a deep-dive assessment, a prioritized remediation plan, and a scorecard they can take straight to their board.

That tension is not a failure of alignment. It is a feature of a healthy organization.

Left unmanaged, tension turns into friction. Managed well, it becomes one of the organization’s greatest sources of leverage. My goal is not to eliminate this tension, but to ensure it consistently produces business value rather than organizational drag.

This is the lens I use to evaluate whether Product–Engineering collaboration is working well at exmox: do we convert tension into outcomes, without degrading systems or sacrificing long-term execution speed?

The trade-off: Velocity vs. Stability

My perspective as Principal Engineer is that Product-Engineering collaboration is never a battle to be won. It is a continuous negotiation between two equally valid forces:

• Velocity: Driven by Product’s need to learn quickly, ship, and capture opportunity.

• Stability: Driven by Engineering’s responsibility to protect systems, users, and long-term execution speed.

Velocity without stability leads to outages, churn, and compounding rework. Stability without velocity leads to missed markets and stalled growth. The job is not to choose one over the other; it is to channel both toward the same outcome.

The Common Goal Framework

The most effective way to align these forces is to replace the us vs. them narrative with a shared business objective. Instead of starting with positions like "Product wants this tomorrow" versus "Engineering says it will break", the conversation starts with purpose:

"We need this launch to unlock the next phase of growth.”
“WIthout this we miss a critical market opportunity.”

Once the goal is clear, the conversation changes. The question is no longer who is right, but what is the fastest acceptable path to the outcome. That framing turns conflict into design.

The Middle Layer: Architecture as an Enabler

As Principal Engineer at exmox, I work closely with both the CTO and the CPO, I see architecture as the creation of business options. If Engineering builds systems that are too rigid to adapt under pressure, they have failed the business just as surely as if they had built something unreliable. High-quality architecture deliberately prices in change. It ensures that today’s speed does not become tomorrow’s constraint.

This work begins early, during Discovery. When Engineering is involved from the start, we identify The $0 Feature: technical shortcuts where we achieve 80% of the value with 5% of the effort by leveraging existing tools or clever architectural tweaks.

Discovery is where we decide whether we are intentionally building a disposable prototype to learn, or a foundation meant to scale.

Facilitating Trade-Offs: The End-of-Year Dilemma

When Product pushes for speed and Engineering raises concerns, the answer is rarely a hard yes or no. It is a priced trade-off. Consider a common high-stakes scenario: it’s November. Product wants to launch a campaign to capture end-of-year traffic. Engineering warns that the architecture is brittle and may fail under 2× load.

We don’t pick a side. We re-engineer the risk:

• Reducing Surface Area: Aggressively disabling non-essential services via feature flags so the checkout flow survives peak load.

• Accepting Operational Debt: Agreeing to a manual database cleanup in January in exchange for December revenue.

• Strategic Throttling: Introducing a virtual waiting room to protect system integrity, sacrificing some conversion to preserve brand trust and uptime.

In this model, risk isn't ignored; it’s priced. Debt isn't hidden; it’s tracked. Everyone understands what is being gained now and what must be paid back later.

The Value Arbitrator

In these moments, the key is to arbitrate value, not to defend a function or department.

That means weighing business impact against technical integrity. Sometimes that requires telling Product that a shortcut is too expensive because the Cost of Delay for the next three months would be catastrophic. Sometimes it means asking Engineering to accept risk because the Opportunity Cost of missing the market is higher than the cost of a January rewrite.

This arbitration must also protect Operational Excellence. Every new feature increases the tax on the system. Treating maintenance as optional is how roadmaps slow down invisibly. Sustainable velocity comes from systems that are actively cared for, not just extended.

The Real Outcome

The success of this approach isn’t measured by a single launch date. It’s measured by trust.

When teams see that trade-offs are explicit, technical debt is repaid, and business goals are shared rather than weaponized, conflict fades. Product and Engineering don't need to agree on everything. They need to share responsibility for outcomes.

That shared responsibility is how organizations ship faster over time without breaking the systems, or the people, that power them.

Ever feel like you’re juggling a million things at once? Building a product, talking to users, fixing bugs, and guess what—oh yeah, marketing too! If you're a solo founder or part of a lean team, you know the hustle is real.

Well, imagine having a full-fledged marketing guru by your side, but without the coffee breaks or 3 PM slumps.

Let’s build an Autonomous AI Marketer?

Picture this: an AI-powered tool that doesn’t just automate tasks but actually learns and optimizes your entire marketing strategy. It’s like having a seasoned strategist who knows your target audience, crafts personalized campaigns, and adapts on the fly—all while you focus on building your product.

Why It’s Perfect for Indie Hackers

1. Time-Saver Extraordinaire: Marketing can be a time sink. With an AI marketer, you can automate everything from social media scheduling to email campaigns, freeing up hours for you to focus on other critical aspects of your business.

2. Budget-Friendly: Traditional marketing agencies can be expensive. An autonomous AI won’t break the bank and can often operate on a fraction of the cost of hiring a human team.

3. Data-Driven Decisions: Forget guesswork. This AI dives into analytics, pulls data-driven insights, and can even predict trends. It’s like having a crystal ball but way more accurate.

4. Personalization at Scale: Crafting personalized messages manually can be a nightmare. AI handles it effortlessly, creating tailored interactions that connect with your audience on a deeper level.

5. Adaptability: Markets evolve, and so does your AI marketer. It continuously learns from campaigns, adapts strategies, and ensures you’re never left in the dust of changing trends.

Taking the Plunge

I am building a tool to help me market my side projects.

The first step is content generation catered to a target audience.

Roadmap

• The next step will automated content sharing on the platforms used by your audience

The goal is to automate reach and have data at your fingertips.

The Human Touch

While an AI marketer is powerful, it’s not a complete replacement for the human touch. Think of it as a supercharged assistant ready to amplify your efforts. Use the insights it provides to get creative and add your unique human flair to campaigns.

Final Thoughts

The entrepreneurial journey is exciting and full of challenges. By embracing tools like Autonomous AI Marketers, you're not just surviving the hustle; you're thriving. Let the tech handle the grind, while you focus on big-picture innovation.

So, fellow indie hackers, are you ready to supercharge your marketing efforts and give your business the edge it deserves?

Happy hacking! 🚀

Here’s how I built Briefly, an AI-powered system that helped me declutter my inbox, organize my newsletters, and finally take control of my content consumption. And the best part? I built the first version in just one day.

The Problem: Content Overload

I love staying informed, but my inbox has become a black hole. I was subscribed to dozens of newsletters, from tech updates to finance tips, and couldn’t keep up. The more I ignored them, the more they piled up. It wasn’t just emails—it was a symptom of a larger issue: content hoarding.

When I finally found the time to catch up, I’d spend hours reading dozens of articles in one sitting. However, during one of these marathon sessions, it struck me that many of the tech newsletters I subscribed to shared the same articles. I was wasting time reading the same content over and over again.

I realized I needed a system to:

1. Automatically sort and categorize my newsletters.

2. Remove duplicates and irrelevant content.

3. Deliver a curated feed of the most important updates.

The Solution: Briefly (Version 1)

I have been using LLM a lot recently. So I decided to build Briefly, an AI-powered tool that would process my emails, organize them, and present them in a clean, easy-to-read feed. Here’s how I did it in just one day:

1. The AI Agent: My Email Assistant

The first step was creating a Python agent to handle my emails. This agent:

• Fetches Emails: Using the Gmail API, it accesses my inbox every morning.

• Deduplicates Content: It uses hashing techniques to identify and remove duplicate emails.

• Categorizes Newsletters: It sorts emails into categories like Tech, Finance, and Health.

This agent became my personal email assistant, tirelessly working behind the scenes to declutter my inbox.

I built the agent with Pydantic AI: a Python agent framework designed to make it less painful to build production-grade applications with Generative AI built by the team behind Pydantic.

It was a pleasant experience. The framework helped me focus on the core logic using tools I am already familiar with.

2. The Feed: A Simple Web App

For the first version, I built a server-rendered web app using FastAPI. It’s not fancy, but it gets the job done. The app:

• Fetches newsletters from the database.

• Displays them in a simple, no-frills feed.

• Allows me to see my curated newsletters in one place.

I spent most of my time fighting the OAuth2 specification to authenticate with the Gmail API. It was a headache, but I finally got it working!

Of course, the UI is AI-generated!

3. The Database: Turso

I needed a fast, scalable, and easy-to-use database to store the processed articles. That’s where Turso came in. Turso is a serverless, globally distributed SQLite database that allowed me to:

• Store all my newsletters in one place.

• Access them quickly, no matter where I was.

• Scale effortlessly as my data grew.

With Turso, I had a reliable foundation for my system.

The Results (So Far)

Even in its early stages, Briefly has already made a difference. Every morning, I wake up to a curated feed of the most important newsletters, neatly organized and free of duplicates. I no longer feel overwhelmed by the sheer volume of content—instead, I feel in control.

Here’s what Briefly has done for me so far:

• Saved Time: No more sifting through hundreds of emails.

• Reduced Stress: A clean inbox is a happy inbox.

• Improved Focus: I can now focus on the content that matters most.

What’s Next?

This is just the first version of Briefly, and I’m excited to keep improving it. Here’s what I’m planning next:

1. A Full-Fledged Nuxt 3 Web App:

   • I’ll replace the FastAPI feed with a modern, responsive Nuxt 3 app.

   • This will include better UI/UX, search, and filtering features.

   • Content management

2. Summarization:

   • Use AI to summarize long newsletters into bite-sized updates.

3. Personalization:

   • Learn my preferences and prioritize the content I care about.

Open-Sourcing Briefly

As I continue to improve Briefly, I plan to open-source future versions. My goal is to make it accessible to others who might be facing the same challenges with content overload. By sharing the code, I hope to:

• Encourage collaboration and innovation.

• Help others learn from my approach (and mistakes!).

• Build a community around tools that make our digital lives easier.

Stay tuned for updates, and feel free to reach out if you’re interested in contributing or just want to chat about AI, productivity, or battling inbox chaos!

I might even turn it into a platform to allow others to use it without coding and hosting it themselves.

Lessons Learned

Building Briefly taught me a few valuable lessons:

1. Start Small: You don’t need a perfect product on day one. A simple prototype can already make a big difference.

2. OAuth2 is Tricky: Most of my time was spent wrestling with OAuth2 authentication. If you’re working with APIs, be prepared for some frustration!

3. AI is a Game-Changer: Even a basic AI agent can solve real-world problems in ways that feel almost magical.

Final Thoughts

Content hoarding is a modern problem, but it’s not insurmountable. With a little creativity and the power of AI, I was able to take control of my inbox and reclaim my time—all in just one day. If you’re struggling with content overload, I encourage you to explore how technology can help. Who knows? You might just build the next Briefly.

What about you? Have you ever used AI to solve a personal problem? Let me know in the comments!

Sell your Company

When you engage with a software vendor, you’re not just evaluating their product—you’re selling them your business. You want to show that you are a serious customer and provide the account manager with the context they need to offer a proposal tailored to your needs.

Here’s how to do it effectively:

• Explain What You Do: Share clearly and concisely explaining your business. Highlight your industry, core mission, and what sets you apart.

• Clarify Your Business Model: Help the vendor understand how your organization operates and how their software fits into your processes.

• Provide Scale Numbers and Customer Names: Share metrics like team size, number of users, or transaction volumes. If you work with well-known customers, name-drop them to showcase your credibility.

Get Technical

While your counterpart at the vendor might not always be technical, it’s crucial to dive into the most important technical details.

• Share Key Technical Details: Be upfront about your tech stack, infrastructure, and integration requirements. This ensures the vendor understands what’s needed to make the software work for you.

• Walk Through Use Cases: Describe one or two of your primary use cases. This will help you clearly articulate your needs and set expectations.

• Gauge Their Expertise: Vendors hear similar questions daily. If they struggle to answer, it’s a red flag that they’re not skilled or your use case isn’t common. Ask for examples of existing customers with similar use cases to validate the vendor’s claims.

• Name-Drop Competitors: Mentioning that you’re evaluating other vendors prompts the salesperson to highlight their product’s advantages. Keep the focus on your requirements to prevent the conversation from derailing into generic sales pitches. Discussing technical details ensures the software meets your requirements and minimizes surprises down the road.

Support

Support can make or break your experience with a new tool. Ask the right questions upfront:

• See the Tool in Action: Request a live demo or a detailed walkthrough to see how the software performs.

• Understand Migration Support: Determine what tools or resources the vendor provides to help you transition from your current stack to theirs. This will ensure you have the necessary assistance for a smooth implementation.

Money

Budgeting is an essential part of the evaluation process. Here’s how to handle pricing discussions:

• Get a Quote Based on Real Use Cases: Vendors often offer generic pricing until you provide specifics. Use your use cases to get a customized quote.

• Name-Drop Competitors Again: It’s fair to let them know you’re exploring other options. This can encourage them to provide competitive pricing.

• Ask for a Demo and Trial: Push for a demo if it’s not readily offered. Many vendors are willing to negotiate free trials, even if it’s not mentioned on their website. A little flattery, like acknowledging their expertise or a feature you genuinely admire about their product, can set a positive tone for negotiations.

Wrapping Up

Interacting with software vendors is both an art and a science. You can make informed decisions that benefit your business by clearly communicating your needs, evaluating their expertise, and strategically handling pricing and support discussions. Remember: the goal is a partnership, not just a purchase.

The full code is available on GitHub.

Part 1: Red-Nosed Reindeer Data Analysis

The Red-Nosed Reindeer nuclear fusion/fission plant engineers needed help analyzing unusual data from their reactor. Each report contains a list of numbers called levels. A report is considered “safe” if it meets two criteria:

1. All the levels are either increasing or decreasing.

2. Any two adjacent levels differ by at least 1 and at most 3.

AI Behavior: A Clever Start

When I asked Aider to scrape the challenge and store it as a file, it surprised me. Instead of copying the entire challenge, it summarized the problem, extracting the key requirements and ignoring the fluff. Its output included a short description and an example, which was oddly efficient! It’s learning how to cut to the chase – a promising sign.

Red, Green, Refactor

1. Red: Writing Failing Tests

Following the test-driven development (TDD) approach, I wrote tests based on the example input. Aider generated:

• Tests for valid inputs to compute individual parts of the solution.

• Failing test cases for edge cases like empty input or invalid formats.

2. Green: Implementation Code

Aider then implemented the code. The solution was surprisingly clean and idiomatic for Elixir. It:

• Followed Elixir conventions and project structure.

• Handled all test cases, including edge cases and error conditions.

• Broke down the problem into smaller, reusable functions:

  • parse_reports/1: Validates the input.

  • parse_line/1: Converts strings to numbers.

  • safe_report?/1: Contains the main logic.

• Used helper functions for checking increasing or decreasing patterns.

It even employed the with keyword, elegantly focusing the logic on the happy path while bubbling errors up.

The parse_report function handled errors gracefully

3. Refactor

There wasn’t much refactoring needed – the code was already better than I expected! It followed idiomatic patterns and was well-structured.

Hallucination Alert!

December 2023?!

At one point, Aider claimed the puzzle input wasn’t available until December 2024 (spoiler: it’s December 2nd, 2024). After I pushed back, it acknowledged the mistake and told me to fetch the data myself. Classic junior dev vibes: “If I can’t do it, it must be impossible!”

Fine, I retrieved the data manually.

Wrong Puzzle?!

With the real input in hand, I ran into another hiccup. The AI struggled because the test inputs had uniform rows, but the real input didn’t. This was a case of overfitting to the test cases – a valuable lesson in ensuring tests are as generic as possible.

Once I clarified the issue, the AI fixed the solution and apologized. Success! However, it inadvertently broke the tests during the process. After a quick nudge to run the tests during refactoring, it resolved the issue quickly. A good reminder to be explicit in instructions when collaborating with an AI.

Part 2: The Harder Variant

As always, Advent of Code’s second part added complexity to the challenge.

1. New Tests

I started by creating tests for the updated requirements. Aider adapted smoothly, generating comprehensive tests for the additional logic.

2. Implementation

The implementation phase went smoothly. Aider continued to follow the idiomatic patterns established earlier and handled the new requirements without much trouble.

3. Success!

The solution worked on the first try. It felt great to see the AI growing more reliable with each iteration.

Reflections on Day 2

Today reinforced some key takeaways for working with AI assistants:

• Testing discipline is non-negotiable. Overfitting to edge cases can derail your progress, so always aim for generic tests.

• Be explicit in your instructions. Even smart tools like Aider need clear guidance to avoid breaking things inadvertently.

• AI can be a great collaborator. Its ability to focus on implementation details lets me stay focused on the higher-level logic and architecture—a fantastic productivity boost for senior engineers and engineering managers.

Day 2 was a mix of learning, problem-solving, and junior dev humor. Can’t wait to see what Day 3 has in store!

For this journey, I’m using Aider as my AI assistant, powered by Claude Sonnet 20241022 from Anthropic. The setup includes the aider.nvim plugin integrated with Neovim. So far, Aider + Claude has been surprisingly reliable – it feels like working with a junior dev with a large memory who’s super confident but occasionally clueless. Dangerous? Yes. Manageable? Absolutely, with strict testing practices.

In the rest of the article I will mention Aider but keep in mind that the results vary greatly based on the model used.

Part 1: Getting Started with the First Challenge

First up, let’s fetch the Day 1 challenge. Aider makes this easy with its /web command, which uses Playwright to scrape web pages.

One cool feature of Aider is its ability to commit changes directly to Git and run CLI commands. It’s a little like having an overachieving intern who documents everything meticulously.

Here’s my process:

1. Write Tests First

I began by asking Aider to create tests based on the examples provided in the challenge. It generated:

2. Generate Production Code

Next, I asked Aider to write the production code to pass those tests. It required explicitly adding files for context, which I found useful for keeping the AI focused.

3. Run the Tests

Running the tests confirmed that the example passed. A solid start.

Solving the Challenge

Advent of Code provides unique inputs for each participant. I asked Aider to fetch my input and store it in a file.

The result?

Great success!

My thoughts so far

I’m impressed by how effective Aider is with minimal and sometimes vague prompts. While I didn’t love every stylistic choice it made, the experience reminded me of reviewing code from junior developers at work: functional, decent style, but room for improvement. It’s oddly nostalgic.

Part 2: The Harder Variant

Advent of Code challenges always include a second part—a more difficult twist on the original problem. Here’s how it went:

1. Fetch the Challenge

For the first time, Aider struggled to retrieve the content automatically. Perhaps the site’s structure was to blame. No worries; I added it manually.

2. Repeat the Process

Just like Part 1, I wrote tests based on the example and asked Aider to implement the solution. It delivered:

3. Great Success Again!

Refactoring

To wrap things up, I spent some time refactoring the code. While Aider’s solutions worked, there’s always room to clean up and improve readability. Refactoring is a satisfying part of the process, turning a rough draft into something polished.

Conclusion

Day 1 is in the books, and it’s been a blast so far. Using Aider feels like a hybrid experience between mentoring and pair programming.

It has been an eye-opener. Collaborating with Aider has shown me just how far AI tools have come – not just as coding assistants but as reliable collaborators for problem-solving. For senior engineers and engineering managers, I believe this kind of tool is invaluable for keeping in touch with the code by building prototypes. It allows you to focus on higher levels of abstraction, like architecture and overall design, while letting the AI handle implementation details.

That said, this experience has reinforced an important lesson: testing discipline is crucial when working with AI. Reliable software isn’t just about getting things to work – it’s about ensuring they keep working as expected. With proper testing practices, tools like Aider can become powerful allies in any developer’s toolkit.

Stay tuned for Day 2. Here’s to more challenges, more learning, and a productive Advent of Code 2024!

This year marks a new chapter for me in Advent of Code – one that involves ChatGPT and Large Language Models (LLMs). It’s the first time I’ll be integrating AI into my problem-solving process, and I’m curious (and a little excited) to see how it changes the experience. Will it speed me up? Will it change how I think about problems? Will it completely break my brain by solving everything before I even get my coffee? Let’s find out.

What is Advent of Code?

If you’re unfamiliar with it, Advent of Code is an annual programming event from December 1st to December 25th. Each day, a new coding puzzle is released, increasing in complexity as the month progresses. It’s a perfect blend of brain-teasing challenges, algorithm design, and competitive fun. Some people use it to learn a new programming language, while others try to dominate the leaderboard. For me, it’s always been about exploring creative solutions – and now, experimenting with AI.

What Impact Can LLMs Have on the Advent of Code?

LLMs, like ChatGPT, bring something new to the table. They’re great at quickly generating boilerplate code, explaining complex algorithms, or even debugging tricky issues. However, using them during Advent of Code isn’t without challenges. LLMs might:

• Solve problems too quickly, taking away the fun of struggling and figuring things out.

• Suggest solutions that are overly complex or not optimized for the leaderboard.

• Miss nuances in the problem statement (because hey, even AI can misread).

That’s why I’ve decided to set a few rules to keep things fair, challenging, and enjoyable.

Rules for My AI Engineer

I’ve defined some ground rules for how I’ll collaborate with my AI assistant this year:

1. AI is a collaborator, not a substitute.

I’ll guide the AI and review every suggestion it makes. No copy-pasting solutions without understanding them.

2. Use AI for learning, not cheating.

If I’m stuck, the AI can help explain concepts or suggest approaches, but I’ll avoid direct solutions unless necessary. Also, I will not use it to automate my participation in the leaderboard. (I am curious though about what others will do.)

3. Stay human-driven.

Creativity and problem-solving are still the priority. The AI will support me, but it won’t drive the process.

The Setup

Here’s the tech stack I’ll be using this year, including my AI assistant:

• Aider: A fascinating tool (found at aider.chat) that acts as an autonomous AI agent. It’s capable of:

  • Fetching the daily instructions,

  • Writing and editing code,

  • Creating and running tests,

  • Committing changes to a Git repository.

This setup is robust enough for the AI to participate independently in Advent of Code if I let it. It could even climb the leaderboard on its own—though I’m not planning to let it take over entirely.

That’s it for Day 0! I’m excited to see how this setup evolves over the next 25 days. Stay tuned as I share insights, challenges, and maybe even a few AI-driven “aha” moments along the way. Happy coding!

Not because they do but because of how we do them.

They are long, not well-defined, and most people attending don’t know what they are doing here and would like to go back to their activities.

The typical meeting experience expects you to come into a room, be told about a subject, and you should start throwing ideas, and asking relevant questions on the spot…

It is not a delightful experience…

I don’t know, but I don’t work like that. Most engineers don’t. We tend to be analytical people. We prefer to think, to check some ideas first, and we like to sound smart…

Why do meetings suck?

Most meetings are useless. In my experience with some processes, we can cancel most of them.

Calling for a meeting should be forbidden if we don’t answer the following questions upfront.

• Agenda

  • What are we going to talk about? (why is it important)

  • Who will lead the discussion?

  • What outcome is expected?

• Participation

  • Why is your presence required?

  • What is expected from every participant before, during, and after the meeting?

• Documentation

  • Supporting documents that must be reviewed, and read before attending the meeting

  • List of questions, answers

  • Link to an internal chat channel to discuss the topic at hand

You should write down a document containing at least the meeting agenda when calling for a meeting. You should also explain why this meeting is essential, what outcome is expected, and the documents that must be consulted to support the meeting.

Your document should invite participants to write down their questions ahead of time so we can start the conversation asynchronously. That’s why I prefer to put a link to a Slack thread where the Q&A can happen. Then we put the final answers in the document.

Doing so the actual meeting may be no longer relevant.

Why do we need meetings?

Writing down the expected outcome, providing the documentation, and inviting participants to communicate is the essence of meetings.

We don’t need to sit together in a physical or virtual room to do that. At least we can initiate the process offline so that the actual gathering makes more sense.