DEV Community: Tim Cadenbach

AI Should Stop Generating the Same Code Over and Over

Tim Cadenbach — Fri, 11 Sep 2026 21:55:33 +0000

AI coding tools have become ridiculously good...guess we can all agree.
You can describe an application, wait a few minutes, and suddenly you have React components, API endpoints, database models, authentication, migrations and a decent-looking application...it seems to be magically. Then you dig into the code, try to change something and something you didn't even remotely touch breaks. Then you spend another few thousand tokens explaining the architecture the AI itself created 30 minutes ago.
I was sick of it....

A new way to build business apps

As part of a platform for small businesses I'm currently working on I am also experimenting with a different architecture for AI-built business software: let AI describe the application, then compile the repeatable parts deterministically especially do not have the AI build things like authentication, connectivity, database stuff...you name it. That has all been solved for 20 years and we shouldn't ask AI to build it over and over again, failing over and over again at getting things right.

The AI only has to write YAML using my own vocabulary.
Think about something like this:

entity: expense_claim

fields:
  submitted_by:
    type: reference
    targetEntity: person

  amount:
    type: money
    currency: EUR
    required: true

or this..a little bit more involved:

entity: assumption
ownedBy:
  parent: scenario
  via: scenario
  as: table
display: statement
fields:
  statement:
    label: Assumption
    type: text
    required: true
  scenario:
    label: Scenario
    type: reference
    required: true
    indexed: true
    targetEntity: scenario
    onDelete: cascade

And this isn't limited to entities or CRUD.
Automations can be described in the same vocabulary:

automation: build_segment_grid
name: Lay out a segment's lifecycle
effects:
  - type: createForEach
    set:
      scenario: '{{record.scenario}}'
      segment: '{{record.id}}'
      point: '{{source.id}}'
      label: '{{record.name}} {{source.label}}'
      flex:
        pick:
          entity: revenue_plan
          filters:
            - field: scenario
              operator: eq
              value: '{{record.scenario}}'
            - field: tier
              operator: eq
              value: flex
          sort:
            - field: name
              direction: asc

We can describe the whole application with YAML definitions, from entities, relations, workflows, automations, permissions up to views and screens and readymade widgets...its all in YAML.

Yet, The exact YAML isn't really the important part.
It could be JSON. It could eventually be authored visually. Most of the time it may simply be written and modified by an AI.

The important part is the level of abstraction.

The definition says what the business application should do. It doesn't describe how ASP.NET should register a controller, how EF Core should configure a relationship, how Vue should render the form or how an MCP tool should expose the operation, and ASP.NET is just an example here I use as thats the first target compiler that exists today. More to come.

Yet...those things can be derived.

So...isn't this just another code generator?

And hey, YAML rings a bell. Someone must have built something like this before. Absolutely!

Lowdefy, for example, takes a similar approach in some ways: you describe an application using YAML instead of manually writing all the implementation code.

But there is one important architectural difference.

Lowdefy's YAML describes an application for the Lowdefy runtime. The runtime interprets that configuration and provides the UI, data connections, actions, authentication and other application machinery.
That is a perfectly valid architecture, but your application is fundamentally expressed in terms of that runtime.

My approach is different and goes way beyond that!

Compiling actual code from YAML

For my project theres two options...The first is to run the application on the Cordango platform. The definition is compiled into an internal JSON representation which the platform uses to build and run the app.

The platform adds some nice things on top, like apps sharing company data and reacting to each other's events without somebody having to manually build an integration between every single tool. But that's not really what I want to talk about here.

The second path is the more interesting one for this article:

What if that YAML is compiled into actual source code?

Not a starter template. Not a few generated models you still have to wire together. An actual standalone application with a frontend, backend, database model, migrations, authentication, permissions, business logic, REST/OpenAPI and MCP.

Something you can take, build, run and host yourself.

The current architecture looks roughly like this:

                App Definition
                     |
                     v
            Deterministic Compiler
                     |
          +----------+----------+
          |                     |
          v                     v
       Frontend               Backend
      Vue / Vuetify        ASP.NET Core
          |                     |
          |          +----------+----------+
          |          |          |          |
          |       REST/API     MCP      Commands
          |       OpenAPI                Workflows
          |                     |       Permissions
          |                     |       Calculations
          |                     |
          +----------+----------+
                     |
                  EF Core
                     |
              Database Model
                 Migrations
                     |
                 PostgreSQL

Today the first complete target generates ASP.NET Core + EF Core + PostgreSQL + Vue 3/Vuetify but Node/Typescript is on its way, Python is being planned and more to come.

And because all of those pieces come from the same application definition, they don't have to be separately invented and kept in sync.

If the definition says an expense_claim exists, that isn't just a database table.

The compiler can derive:

the entity model
persistence
migrations
CRUD operations
permissions
forms and views
REST/OpenAPI
MCP access
commands and workflows

Change the definition and the generated implementation changes with it.

The YAML isn't configuration for the generated application. It is the source from which the application is compiled.

And this leads to one of my favorite slightly ridiculous consequences:

You could literally gitignore the code

I'm serious.

If your App Definition is stored in Git and you pin the compiler/generator versions required to build it, the generated source becomes a build artifact.

Given the same application definition, generator version and scaffold version, the compiler generates the same files again.

So technically your repository could look roughly like this:

my-app/
├── cordango.yaml
├── apps/
│ └── expenses/
│ ├── app.cordango.yaml
│ ├── entities/
│ ├── roles/
│ ├── views/
│ └── workflows/
└── .gitignore

while this:

generated/
├── api/
├── web/
├── Dockerfile
└── docker-compose.yml

could simply be regenerated whenever you need it.

Now, whether you should gitignore all generated source is a different discussion. Keeping generated code in Git can obviously be useful for reviewing changes, deployments and debugging.

But architecturally, you don't have to treat it as the source of truth anymore.

That's the important part.

The definition is the source. The code is an output.

And unlike a traditional runtime-based no-code platform, taking that output doesn't mean taking a dependency on my hosted service.

There is no Cordango account requirement, licence server, model API or phone-home service involved in running the generated application.

The current standalone runtime is small enough that it can either be referenced as a package or embedded into the generated project itself.

So you can generate the application, take the source, and host it wherever you want.

An AI should reason about what you want to achieve not fundamentals

With this approach, the AI gets more headroom to reason about the actual business problem instead of spending context and tokens on code we've already solved a thousand times.

It also has far less room to accidentally break unrelated implementation details. If it changes a workflow, it changes the workflow definition. The compiler handles the rest.

The AI can still misunderstand the requirement, of course. But those are business-level mistakes, not random implementation drift.

And it doesn't even have to be a coding model...I literarily build one of the sample apps with ChatGPT...yes the old standard one, not codex.

A nice added extra...it saves a ton of token

I don't want to make this the main part but yes, using YAML saved a ton of token. I compared the generated examples vs the YAML definition with Anthropic's tokenizer and the result was up to 98% fewer token consumed...lets see how that adds up when more work is done but it definitely saves you..some huge chunk.

What now? How does this work?

YAML alone doesn't solve much if the AI still has to read an entire repository every time something changes. So Cordango comes with a CLI around the application model.
The basic loop becomes:

Describe a change
      ↓
AI changes the relevant definition
      ↓
cordango check
      ↓
cordango build
      ↓
Deterministically generated application

The AI works on the small semantic representation, not hundreds of generated controllers, migrations, components and API files, the CLi gives the AI the tools it needs to do that. And because the compiler understands the vocabulary, it can reject invalid definitions before they ever turn into source code.

cordango check
cordango build --target app --generator dotnet-vue

That's really the whole bet.

Want to have a look?

https://www.github.com/cordango
https://docs.cordango.com
https://www.cordango.com

All feedback welcome, negative, positive, roast it, praise it...give it a try!

make the thing AI has to understand smaller, more meaningful and harder to accidentally break.

The DevRel Index

Tim Cadenbach — Sat, 06 Jun 2026 14:53:07 +0000

Every DevRel team I've watched get cut in the last two years was cut because nobody at the top could see what they did. Smoower is my answer to that. An index that makes the work visible, comparable, and impossible to ignore.

The DevRel Index is a public index of developer relations activity across companies. It looks at the public surface of DevRel: docs, GitHub activity, developer content, community presence, events, integrations, package ecosystems, response patterns, and other signals that show whether a company is actually investing in developers or just saying it does.

What an index can actually change

The shift I want is the same shift that happened to SEO twenty years ago.

Before tools like Moz, Ahrefs, and SEMrush, search marketing was a black box. People knew it mattered, but nobody could prove it relative to anyone else. Then a handful of indexes came along, gave the discipline a shared vocabulary and a comparable surface, and the entire field professionalised within five years. Budgets stabilised. Job titles got senior. Boards started asking informed questions instead of suspicious ones.

DevRel needs the same moment. We need:

A way to see, for any given company, what their public DevRel surface actually looks like, to compare that surface across companies in the same category and to track changes over time, so a board can see whether DevRel investment is moving the needle in a measurable direction
Most importantly, a shared method that does not change every time a new vendor wants to sell you a dashboard
That is the bet behind Smoower. Build the index first. Argue about the methodology in public. Let companies see themselves and their competitors in the same frame. Make the conversation possible at all.

What Smoower actually does, in plain language
Smoower is an index of developer relations activity across companies.

We collect public signals (documentation freshness, content cadence, community presence, conference participation, plugin ecosystems, response times in public channels, and a few other things), score them against a methodology that is documented and open, and produce a comparable per-company score over time. You can look up your company. You can look up your competitors. You can see how a category like "AI infra" or "developer tools" trends quarter over quarter.

It is not a productivity tool for individual DevRel folks. It is a visibility layer for the field as a whole. The point is not to grade humans. The point is to make the discipline legible to the people who decide whether the discipline continues to exist next year.

If you are running DevRel right now and you want a way to walk into a budget conversation with something other than vibes, that is who this is built for.

This was not possible two years ago

I want to be honest about something. If I had tried to build Smoower in 2023, it would have been a glorified spreadsheet with a small research team feeding it by hand. That is what every previous attempt at a DevRel index actually was. Slow, expensive, biased toward whoever the analyst at the firm happened to like, and updated maybe twice a year.

The reason this version can exist now is LLMs.

Here is the specific problem they solve. DevRel output is heterogenous in a way most categories are not. One company's signal is a polished docs site. Another's is a Discord with 40,000 messages a month. Another's is a YouTube channel. Another's is twenty engineers writing essays on their personal blogs. None of those surfaces look anything like each other on the wire. A traditional crawler can count pages, count members, count posts. It cannot tell you that the docs site has not been touched in eighteen months while the Discord is full of unanswered questions. It cannot tell you that one company's blog post has actual technical depth and another's is the same press release published seven times in different fonts.

LLMs can. Not perfectly, but well enough to normalise. They can read a docs page and judge whether it is fresh or stale. They can read a community thread and identify whether the question got an answer. They can compare two technical blog posts and tell you which one is doing real DevRel work and which one is content marketing wearing the costume.

That normalisation is what makes a fair index possible at all. Without it, you are either reducing everything to a few crude counts, which is what most existing "DevRel scorecards" already do and why nobody trusts them, or you are paying analysts to read each surface by hand, which is what boutique research firms charge fifty thousand dollars a year for and which can never update in real time.

The narrative layer matters too. A raw score is useful, but it is not what a board reads. What a board reads is "your community response time dropped 40 percent this quarter, and here is what changed." Generating that summary, for every company in the index, every quarter, used to require a human writer. Now it requires a model, a methodology, and a careful editorial pass. Same output, very different cost curve.

Why now, honestly

There is a more personal piece to this. After getting laid off from DeepL, I spent a few weeks talking to other DevRel people who had been through the same thing. The pattern was depressingly consistent. Good work, often great work, that nobody upstairs could see or compare. Quiet teams getting quietly removed. People rebuilding their careers from a position of "I cannot prove what I did, only describe it."

I do not want the next wave of DevRel people to walk into that meeting carrying screenshots and anecdotes. I want them to walk in with a number. Their number, the industry's number, a chart, a methodology, a thing the CFO can read.

That is what Smoower is for.

It is going to launch incomplete. Indexes always do. The first version of any benchmark is wrong in interesting ways, and we will iterate in public on the methodology, the signal set, the weights, all of it. That is the deal. I would rather ship a measurable thing we can argue about than wait another two years for the perfect framework while more teams get cut.

If you run DevRel at a company, or you care about DevRel surviving as a discipline, I would like you to come look at it when it goes live, push back on it, and tell me what we are getting wrong. That is how an index becomes a standard. Not by being right on day one.

I will write more about the methodology soon.

Go check it out!