Engineering

AI Has Changed Our Tools, Not Our Standards

AI has accelerated how Cinder ships software, but great engineering still requires accountability, judgment, and craftsmanship. The tools have changed. The standards have not.

AI tool insights from senior engineer Wes Sankey

From customer-facing chatbot hallucinations to the deletion of production databases, the potential pitfalls of vibe coding are emerging as serious risks. Companies leveraging AI tools in any meaningful way must stop and reflect on how to use them without risking business stability.

At Cinder, AI is deeply embedded in how we build software as well as the software itself. AI has accelerated our ability to ship beyond what was imaginable before these tools were available. What once took months now takes weeks: We recently shipped a completely revamped metrics experience on our platform, going from prototype to final product in a shockingly compressed timeframe. But we know these tools are no panacea, and we’re working hard to understand how to pragmatically and safely leverage them while maintaining high engineering standards.

So how exactly are we balancing the risks of AI with our commitment to excellence at Cinder? We haven’t found a silver bullet, but we have some practical principles that guide our approach to productively and pragmatically navigating these tools.

It Doesn’t Matter How We Got There. We Always Own the Outcome

A core company value at Cinder is “Own the Outcome.” We believe in a culture of extreme ownership where we take complete responsibility for the work we produce. What does this mean when AI is increasingly doing more of our work? It means we take complete responsibility for the work we produce, regardless of how that work was produced.

If a financial analyst delivers a report with the assistance of interns who reported inaccurate data, the analyst whose name is on the report is responsible for the errors. In the same way, you wouldn’t blame PostgreSQL for inadvertently deleting data due to an incorrectly written migration script, or you wouldn’t blame your CI pipeline for deploying buggy code that you wrote. Owning the outcome means AI didn’t delete your production database, you did. The sophistication of the tools we use to do our work is rapidly increasing, but they are still just tools.

We Understand There Is No Free Lunch

In his 1986 paper No Silver Bullet, legendary software engineer Fred Brooks described the difference between accidental complexity and essential complexity. The software industry has invented ways of managing accidental complexity, including higher-level languages and powerful IDEs, which have resulted in significant productivity gains. But they can only do so much to mitigate essential complexity, which is the irreducible complexity that arises from the problem domain. At Cinder, we view AI as a powerful tool for reducing accidental complexity, but not for eliminating essential complexity.

Understanding this distinction is increasingly important as code generation becomes commodified: the essential complexity of prioritizing what to build is becoming the primary constraint on engineering teams. From Brooks: “The hard thing about building software is deciding what to say, not saying it.” Technical constraints and manual friction that existed prior to LLMs acted as a useful prioritization bottleneck. Now that we have the ability to build a dozen proof-of-concepts in a single day, the limiting factor is no longer implementation capacity, but judgment.

AI can generate a database migration in seconds. What it cannot do is determine whether the migration should happen, how it affects downstream systems, what rollback strategy is required, or whether the business impact justifies the risk. The complexity hasn’t disappeared, it’s just moved.

We Hone Our Craft (With AI’s Help)

Finally, we firmly believe that there is no replacement for deeply knowledgeable, battle-tested engineers who intimately understand topics ranging from database index optimization to asymptotic analysis. To most effectively leverage AI, you need to understand what AI produces, and there are no shortcuts here. The risk isn’t in using AI, it’s letting it think for you.

We use AI to amplify our learning and development by leveraging it as a thought partner. We don’t outsource our thinking to AI; we strengthen our thinking with it. Here are a couple ways we do that:

  • Use AI to generate thoughtful questions that force us to articulate our reasoning and expose gaps in our thinking. Matt Pocock’s grill-me skill is a great starting point for this. It interrogates our design decisions and resembles an always-available staff engineer conducting a design review.
  • Periodically write the code for a feature without AI assistance, then let AI critique it and suggest opportunities for improvement. Ask it to validate assumptions, consider edge cases, and suggest alternatives.

These approaches help mitigate the very real risk of atrophy that occurs when you stop thinking for yourself and delegate anything requiring effort to AI.

AI Has Changed Our Tools, But Not Our Standards

AI has been a complete game changer for how we deliver software at Cinder, but it hasn’t changed what great engineering requires: accountability, judgment, and craftsmanship. The tools will continue to evolve. Our responsibility for the systems we build will not.

Get a demo