What do we mean by working AI-first?

Great to see all the engagement around our recent announcement that we will no longer charge for programming. It sparked some thoughts and debate, in comments, DMs, and around the lunch table at HETCH. Here we try to answer the most common questions.

Are you just "vibe coding" now?

We do something else that we currently call Agent Assisted Development (AAD). It's a working name, but it describes how we work fairly well.

For us, this means AI shouldn't "guess at a solution" in some kind of yolo dialogue, but should work from a technical specification and clear constraints that our AI tech leads (also a working name) set for our agents before coding begins. From there, there's a continuous dialogue between agent and human where specifications get updated, documentation gets established, and the solution emerges.

When we start an AAD project (greenfield or existing codebase), we always begin with the same base template for agents and sub-agents. The process should be as repeatable and deterministic as possible, which isn't entirely simple with generative AI.

Sure, hand on heart, we sometimes cheat and vibe-code a bit anyway, especially when projects are very small and clearly bounded. But even then we do it with our own patterns and practices as the foundation — just like our agents.

Doesn't the code get messy and hard to maintain?

It does, if you vibe-code without control and without shared constraints. Again, we strive to create repeatable and deterministic flows.

In our model, new code follows our patterns and practices, and we work with quality as a default. TDD is the default where it fits, error handling and logging are in place, and code is reviewed by senior developers. The goal is for the code to be easy to understand, easy to change (no one-shotting), and safe to run in production.

Are you really saving time if you're still active in the process?

Yes. How much depends on the project, but the common thread is that we save a lot of time on code production itself and on iterations. The point isn't to "push out more code". The point is to reach working solutions faster.

Will you change your business model?

In the short term: no, we still trade time for money. In the longer term, we see two possible paths:

• We can do more projects at the same pace (because we become more efficient), or
• We need to keep evolving how we charge so that the model reflects where the value is actually created. But it can be hard to charge for the value we create at the customer, since we'd then charge differently for the same solution.