Matt Delacour

Why Experience Still Beats Knowledge in AI-Assisted Engineering

2026-05-05T00:00:00+00:00

Six weeks ago, my brother went to an Anthropic event in London. Then he called me: “I built a working prototype in two days. This is crazy.”

I asked him to push his code to github and to share it. He asked: “What do you mean? How do I do that?

The first commit made me smile when I saw he committed a failed curl command.

And nonetheless, he is right, “this is crazy”. He had a working prototype without even knowing what a terminal was.
We are going through a fascinating revolution.

The economics behind that revolution are shifting fast.

The cost of prototyping has been massively reduced. Some already think that code is going to become disposable as the cost of writing keeps getting cheaper. We, engineers, often want to rebuild everything from scratch. Whether in a new programming language (eg Rust/Golang) or with new patterns and libraries. This is definitely easier today than a decade ago and the cost of doing so went down.

However, while AI gives you knowledge, it cannot give you judgment. Judgment is what makes you pause before adding a cache layer because you’ve felt what a cache invalidation bug looks like at 2am. Judgment is recognizing you’re over-engineering before the codebase makes it obvious.
This is the gap. Non-engineers using AI don’t know the questions they aren’t asking. And AI — however capable — can only answer what it’s asked.

Think about what you actually get when you hire a junior engineer. You spend months transferring context - the unwritten rules, the past mistakes, the reasons. It’s painful. But that investment compounds. They grow, develop taste, become senior, eventually lead.

With LLM, at least today, you have to transfer the context over and over. They don’t learn on your specific use case, it does not grow. It does not accumulate judgment from your codebase, your incidents, your specific constraints.

However the model, it is not capable of becoming your senior engineer. The trap is not incompetence - it’s misplaced trust. You would not hand over unsupervised access to your production database to a junior engineer after a few weeks of never growing. And interesting engouh, we are seeing people spinning up armies of agents with full access to their system.

And while product stakeholders can now share their vision and help polish the product without competing for engineering resources; let’s not confuse “prototype” with “production-ready” software.

Today my brother’s prototype works and he wanted to go live using the family business data warehouse. That is where I had to draw a line to make sure we would not leak the business data (sales, customers, products, etc.).

If you’re a software engineer: your value isn’t writing code faster. It’s knowing which questions to ask before the code is written. It’s providing clarity. It’s to understanding the tradeoffs.
If you’re a product stakeholder: prototype freely. But find an engineer before you ship.

Releasing a tiny ORM for CRUD operations.

2025-10-28T00:00:00+00:00

Previously, I explored how to set up a project without relying on an ORM (see the previous post</a>).

To recap, not using an ORM can be a good thing, as it reduces the number of dependencies in your binary. There are many benefits to it. It also helps gain clarity into the queries executed (easier to debug performance issues). The downside is that boilerplate needs to be copied for simple manipulations, and tests should always be added. This makes the data layer more verbose.

Tradeoffs</h2>
While handwritten SQL queries make sense in many use cases, simple operations are often performed. Those are most likely going to be a CRUD one.
At first, I wanted to use `sqlx-crud</code></a>, which was precisely what I aspire to do. But the library seems unmaintained, as the last release was a few years ago. So bugs were not addressed, and dependencies were not updated. This is why I decided to release a Rust library,` `tiny-orm</code></a>, that focuses on CRUD SQL operations. I also took the time to look at the different libraries and their approach.`
`My main goals and philosophy were:`
To have the least amount of dependencies</li> Tackle all the boilerplate of the CRUD operations</li> Add no complexity by default</li> Can fit real-world problems</li> It is easy to maintain</li> </ul> Thus, I decided to make the following technical tradeoffs. Tradeoff 1: Only support CRUD operations</h3> ORMs can get complex very quickly. Looking at a full ORM like SeaORM</a>, it can do a lot, from generating the schemas to handling relations between tables. Because most of the boilerplate I had to copy and paste over and over in my production services was around CRUD operations (aka inserting, updating, and deleting a record). And even more, handling the logic about partially updating only the values of your struct that are different (as seen in my previous post). Thus, I decided to focus only on CRUD operations (bulk insert/update, as of the time of writing) and leave the rest aside (schema generation, migrations, table relations, etc.). And even then, I ended up adding extra features like the ability to skip fields that are not set through a wrapper called SetOption</code></a>. Supporting all the databases and their differences (e.g., handling UUIDs, RETURN statements, etc.) was more than I thought. Tradeoff 2: Use SQLx QueryBuilder</h3> Looking at a few repositories, I realized that many had to reinvent the wheel. How to parse parameters? How to deal with datetime values? How to parse input and sanitize it? etc. Since I wanted to keep maintenance of the library to a minimum and since it’s built on top of SQLx, I decided to use their QueryBuilder</a>. This allows me to be compatible with PostgreSQL, MySQL, and SQLite right away. Tradeoff 3: Do not use compile-time checked queries</h3> SQLx allows you to check queries at compile time against a local database. That’s an excellent feature that makes the code more robust. While I like the idea of compile-time checks, I don’t want to impose such restrictions on downstream users of this library (and even if SQLx’s compile-time checks can run offline after initializing a metadata JSON file). Tradeoff 4: Supports for multiple versions of SQLx</h3> When I started this library, SQLx was on 0.7.</code>. Then they release 0.8.</code> soon after. A lot of libraries update to the latest dependencies and call it a day. Libraries should be flexible and avoid enforcing a specific version of their dependencies when possible. Even if there were breaking changes between 0.7.</code> and 0.8.</code>, I decided to add a feature flag sqlx-0.7</code> to work around some limitations when upgrading SQLx. Note: I did not find a way to make my code and macros dependent on the version of SQLx installed by the user. There should be logic to detect the SQLx version being used automatically. I see the feature flag as a workaround only. Feedback from the community</h2> I started designing the library’s API layer based on some of my assumptions. One of the best things that happened was when I asked for feedback in the #rust topic of Reddit. joshka</a> opened an issue with detailed feedback and ideas. Even if I have no real ambition for this library, this was a fantastic moment that forced me to get back to the whiteboard. Some of his ideas were to add smart defaults with good examples. Now the crate is easy to use and understand by default, while keeping a lot of flexibility for others. For example, we can make assumptions by just looking at the name of the struct (see this example</a>). #[derive(Debug, FromRow, Table, Clone)] // Same as adding the following manually // #[tiny_orm(table_name = "todo", return_object = "Self", exclude = "create,update")] struct Todo { id: i32, created_at: DateTime<Utc>, updated_at: DateTime<Utc>, description: String, done: bool, } #[derive(Debug, FromRow, Table, Clone)] // Because the struct name starts with "New", it would automatically use the following options // #[tiny_orm(table_name = "todo", return_object = "Todo", only = "create")] // The primary key will be auto-generated by the database and returned once the record is created. struct NewTodo { description: String, } #[derive(Debug, FromRow, Table, Clone)] // Because the struct name starts with "Update", it would automatically use the following options // #[tiny_orm(table_name = "todo", return_object = "Todo", only = "update")] struct UpdateTodo { id: i32, done: bool }</code></pre> I like the idea of multiple structs for different sets of actions (e.g., adding a new record vs. updating it). It makes the code very explicit and makes certain types of mistakes impossible (eg, updating the created_at</code> field). It is still possible to have all the methods available in the same struct. The following would provide all CRUD methods for the unique struct Todo. #[derive(Debug, FromRow, Table, Clone)] #[tiny_orm(all)] struct Todo { id: i32, created_at: DateTime<Utc>, updated_at: DateTime<Utc>, description: String, done: bool, }</code></pre> In the end, I learned a lot from building my own Rust crates. I found that dealing with AST and macros was painful at first, but it got easier once I understood how to debug them. But that should be its own post.



Simple CRUD only using SQLx
2024-03-20T00:00:00+00:00
Most use cases require some simple CRUD operations. And that was true even for a new API we built that is now used by one of our user-facing products.</p>
The goal of this article is not to debate whether using an ORM is a good or bad idea. Because there are very few resources on doing CRUD without an ORM in Rust, I wanted to share my experience.</p>
A few guidelines we had</p>

Centralize insert and update logic to make it obvious</li>
Having complete control of the SQL queries since some of the background tasks have to be optimized</li>
Most of us have a data background (data engineering or data science), which gives us high confidence in writing good, optimized SQL queries</li>
Prototype fast, but also build for the long term</li>
</ul>
The Example: User Model</h2>
So we organized the project without an ORM, instead implementing a structure and helpers to make CRUD operations as easy as possible.</p>
Let’s jump into it</p>
Let’s take the following example.</p>
struct</span> Users</span> {</span></span>
    id</span>:</span> i32</span>,</span></span>
    created_at</span>:</span> chrono</span>::</span>DateTime</span>,</span></span>
    updated_at</span>:</span> chrono</span>::</span>DateTime</span>,</span></span>
    email</span>:</span> String</span>,</span></span>
    password</span>:</span> String</span>,</span></span>
    preferred_color</span>:</span> Option</span><</span>Enum</span>>,</span></span>
    last_login_at</span>:</span> Option</span><</span>chrono</span>::</span>DataTime</span>>,</span></span>
}</span></span></code></pre>
First, we can see that only the last two fields are Optional. This means that every time you pull a row from your database, you have the certainty of which field is potentially null or not. This would be the equivalent of a Model</code> in something like SeaOrm.</p>
What about creating and updating a row?</p>
I did not like the idea of a generic struct where anything could be modified (eg, ActiveModel</code>). Instead, I want us to be very explicit about what can be created and updated. Moreover, I want to ensure we centralize the business logic for each operation.</p>
First, let’s have a look at the following.</p>
struct</span> Users</span> {</span></span>
    id</span>:</span> i32</span>,</span></span>
    created_at</span>:</span> chrono</span>::</span>DataTime</span>,</span></span>
    updated_at</span>:</span> chrono</span>::</span>DataTime</span>,</span></span>
    email</span>:</span> String</span>,</span></span>
    password</span>:</span> String</span>,</span></span>
    preferred_color</span>:</span> Option</span><</span>Enum</span>>,</span></span>
    last_login_at</span>:</span> Option</span><</span>chrono</span>::</span>DataTime</span>>,</span></span>
}</span></span>
</span>
struct</span> UpdateUsers</span> {</span></span>
    id</span>:</span> Option</span><</span>i32</span>>,</span></span>
    email</span>:</span> Option</span><</span>String</span>>,</span></span>
    password</span>:</span> Option</span><</span>String</span>>,</span></span>
    preferred_color</span>:</span> Option</span><</span>Option</span><</span>Enum</span>>>,</span></span>
    last_login_at</span>:</span> Option</span><</span>Option</span><</span>chrono</span>::</span>DataTime</span>>>,</span></span>
}</span></span></code></pre>Introducing SetOption</h2>
We can see that we wrap all of the fields that could be updated by another Option<></code> . The goal here is to check whether a field is set. To make things more explicit than having another Option<></code> . I went with the following approach</p>
#[derive(</span>Builder</span>,</span> Debug</span>,</span> Clone</span>)]</span></span>
struct</span> UpdateUsers</span> {</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    id</span>:</span> SetOption</span><</span>i32</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    email</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    password</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    preferred_color</span>:</span> SetOption</span><</span>Option</span><</span>Enum</span>>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    last_login_at</span>:</span> SetOption</span><</span>Option</span><</span>chrono</span>::</span>DataTime</span>>>,</span></span>
}</span></span>
</span>
#[derive(</span>Debug</span>,</span> Clone</span>,</span> Default</span>,</span> PartialEq</span>,</span> Eq</span>,</span> PartialOrd</span>,</span> Ord</span>,</span> Hash</span>)]</span></span>
enum</span> SetOption</span><</span>T</span>> {</span></span>
    Set</span>(</span>T</span>),</span></span>
    #[default]</span></span>
    NotSet</span>,</span></span>
}</span></span></code></pre>
This simple SetOption</code> enum, working similarly to the Option</code> enum, clearly identifies which field was set by the user intentionally and which is left. Thus, setting a field to None</code> means creating or updating the field with a NULL</code> value.</p>
Builder Pattern for Flexibility</h2>
You might also have noticed the macro Builder</code> set at the UpdateUsers</code> struct. This uses the [builder-pattern</code> macro](https://lib.rs/crates/builder-pattern), which is very simple and has few dependencies. The goal is to build the UpdateUsers</code> Struct as we go in our code. It gives us much more flexibility than having to fill out all the fields at once.</p>
This makes the logic in the code so much easier to read.</p>
// Each of those fields could be constructed in</span></span>
// different places of the code based on some logic</span></span>
let</span> update_user</span>:</span> UpdateUsers</span> =</span> UpdateUsers</span>::</span>new</span>()</span></span>
    .</span>id</span>(</span>user</span>.id)</span></span>
    .</span>preferred_color</span>(</span>new_color</span>)</span></span>
    .</span>build</span>()</span></span></code></pre>
Next, centralize the business logic.</p>
#[derive(</span>Builder</span>,</span> Debug</span>,</span> Clone</span>)]</span></span>
struct</span> UpdateUsers</span> {</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    id</span>:</span> SetOption</span><</span>i32</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    email</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    password</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    preferred_color</span>:</span> SetOption</span><</span>Option</span><</span>Enum</span>>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    last_login_at</span>:</span> SetOption</span><</span>Option</span><</span>chrono</span>::</span>DataTime</span>>>,</span></span>
}</span></span>
</span>
impl</span> UpdateUsers</span> {</span></span>
    pub async fn</span> update</span>(</span>sqlx_conn</span>) -></span> Result</span><</span>Users</span>,</span> anyhow</span>::</span>Error</span>> {</span></span>
        if</span> self</span>.id.</span>is_not_set</span>() {</span> // is_not_set() is implemented at the SetOption enum</span></span>
            // return Err</span></span>
        }</span></span>
        if</span> self</span>.email.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.password.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.preferred_color.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.last_login_at.</span>is_not_set</span>() {</span></span>
            // return Err</span></span>
        }</span></span>
        let mut</span> query</span> =</span> sqlx</span>::</span>QueryBuilder</span>::</span>new</span>(</span>"UPDATE users SET updated_at = now()"</span>);</span></span>
        </span></span>
        if let</span> Set</span>(</span>email</span>)</span> =</span> self</span>.email {</span></span>
            query</span>.</span>push</span>(</span>", email = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>email</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>password</span>)</span> =</span> self</span>.password {</span></span>
            query</span>.</span>push</span>(</span>", password = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>password</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>preferred_color</span>)</span> =</span> self</span>.preferred_color {</span></span>
            query</span>.</span>push</span>(</span>", preferred_color = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>preferred_color</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>last_login_at</span>)</span> =</span> self</span>.last_login_at {</span></span>
            query</span>.</span>push</span>(</span>", last_login_at = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>last_login_at</span>);</span></span>
        }</span></span>
        query</span>.</span>push</span>(</span>" WHERE id = "</span>);</span></span>
        query</span>.</span>push_bind</span>(</span>self</span>.id.</span>value</span>()?);</span> // method `value() to retrieve T implemented at SetOptions</span></span>
        query</span>.</span>push</span>(</span>" RETURNING *"</span>);</span> // Return the updated row</span></span>
</span>
        query</span></span>
            .</span>build_query_as</span>()</span></span>
            .</span>fetch_one</span>(</span>sqlx_conn</span>)</span></span>
            .</span>await</span></span>
            .</span>map_err</span>(</span>|</span>e</span>|</span> e</span>.</span>into</span>())</span></span>
        }</span></span>
}</span></span>
</span>
#[derive(</span>Debug</span>,</span> Clone</span>,</span> Default</span>,</span> PartialEq</span>,</span> Eq</span>,</span> PartialOrd</span>,</span> Ord</span>,</span> Hash</span>)]</span></span>
enum</span> SetOption</span><</span>T</span>> {</span></span>
    Set</span>(</span>T</span>),</span></span>
    #[default]</span></span>
    NotSet</span>,</span></span>
}</span></span></code></pre>
Let’s look at what is happening. We first need to construct the UpdateUsers</code> using the builder pattern, which gives us the flexibility to set any field at any time.</p>
Then we run some sanity checks like “field ID has to be set” or “At least one of the fields has to be set, otherwise there is nothing to update”</p>
Then we construct a query using sqlx::QueryBuilder</code> so that we only update the fields that have been set. Also, notice that we automatically added the updated_at</code> field so users cannot forget about it.</p>
Even if this looks verbose, a tool like Copilot will fill in 80% of the boilerplate at the end :)</p>
The main benefit is that all the business logic can be centralized in one place. Thus, whenever someone wants to “update a user,” we can validate as many things as we want (e.g., that the password is valid and stored as a hash).</p>
Complete Implementation</h2>
Overall, this could look like the following.</p>
let</span> user</span> =</span> Users</span>.</span>select_by_email</span>(</span>sqlx_conn</span>,</span> "an_email"</span>);</span></span>
let</span> update_user</span> =</span> Updater_users</span>::</span>new</span>().</span>id</span>(</span>user</span>.id);</span></span>
...</span></span>
update_user</span>.</span>password</span>(</span>new_password</span>);</span></span>
...</span></span>
update_user</span>.</span>preferred_color</span>(</span>new_color</span>);</span></span>
...</span></span>
let</span> user</span> =</span> update_user</span>.</span>build</span>().</span>update</span>(</span>sqlx_conn</span>).</span>await</span>?;</span></span></code></pre>
At the end, the code looks like the following.</p>
#[derive(sqlx::</span>FromRow</span>,</span> Debug</span>,</span> Default</span>,</span> Clone</span>,</span> PartialEq</span>,</span> Eq</span>)]</span></span>
struct</span> Users</span> {</span></span>
    id</span>:</span> i32</span>,</span></span>
    created_at</span>:</span> chrono</span>::</span>DataTime</span>,</span></span>
    updated_at</span>:</span> chrono</span>::</span>DataTime</span>,</span></span>
    email</span>:</span> String</span>,</span></span>
    password</span>:</span> String</span>,</span></span>
    preferred_color</span>:</span> Option</span><</span>Enum</span>>,</span></span>
    last_login_at</span>:</span> Option</span><</span>chrono</span>::</span>DataTime</span>>,</span></span>
}</span></span>
#[derive(</span>Builder</span>,</span> Debug</span>,</span> Clone</span>)]</span></span>
struct</span> CreateUsers</span> {</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    email</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    password</span>:</span> SetOption</span><</span>String</span>></span>m</span></span>
}</span></span>
</span>
#[derive(</span>Builder</span>,</span> Debug</span>,</span> Clone</span>)]</span></span>
struct</span> UpdateUsers</span> {</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    id</span>:</span> SetOption</span><</span>i32</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    email</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    password</span>:</span> SetOption</span><</span>String</span>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    preferred_color</span>:</span> SetOption</span><</span>Option</span><</span>Enum</span>>>,</span></span>
    #[default(</span>NotSet</span>)]</span></span>
    last_login_at</span>:</span> SetOption</span><</span>Option</span><</span>chrono</span>::</span>DataTime</span>>>,</span></span>
}</span></span>
</span>
impl</span> NewUsers</span> {</span></span>
    pub async fn</span> create</span>(</span>sqlx_conn</span>) -></span> Result</span><</span>Users</span>,</span> anyhow</span>::</span>Error</span>> {</span></span>
        if</span> self</span>.email.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.password.</span>is_not_set</span>() {</span></span>
            // return Err</span></span>
        }</span></span>
        sqlx</span>::</span>query_as</span>(</span></span>
            r#"</span></span>
    INSERT INTO users (email, password, created_at, updated_at)</span></span>
    VALUES ($1, $2, now(), now())</span></span>
    RETURNING *</span></span>
    "#</span>,</span></span>
        )</span></span>
        .</span>bind</span>(</span>self</span>.email.</span>value</span>()?)</span></span>
        .</span>bind</span>(</span>self</span>.password.</span>value</span>()?)</span></span>
        .</span>fetch_one</span>(</span>pool</span>)</span></span>
        .</span>await</span></span>
        .</span>map_err</span>(</span>|</span>e</span>|</span> e</span>.</span>into</span>())</span></span>
    }</span></span>
 }</span></span>
</span>
impl</span> UpdateUsers</span> {</span></span>
    pub async fn</span> update</span>(</span>sqlx_conn</span>) -></span> Result</span><</span>Users</span>,</span> anyhow</span>::</span>Error</span>> {</span></span>
        if</span> self</span>.id.</span>is_not_set</span>() {</span> // is_not_set() is implemented at the SetOption enum</span></span>
            // return Err</span></span>
        }</span></span>
        if</span> self</span>.email.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.password.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.preferred_color.</span>is_not_set</span>()</span> &&</span></span>
            self</span>.last_login_at.</span>is_not_set</span>() {</span></span>
            // return Err</span></span>
        }</span></span>
        let mut</span> query</span> =</span> sqlx</span>::</span>QueryBuilder</span>::</span>new</span>(</span>"UPDATE users SET updated_at = "</span>);</span></span>
        query</span>.</span>push_bind</span>(</span>Utc</span>::</span>now</span>());</span></span>
        </span></span>
        if let</span> Set</span>(</span>email</span>)</span> =</span> self</span>.email {</span></span>
            query</span>.</span>push</span>(</span>", email = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>email</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>password</span>)</span> =</span> self</span>.password {</span></span>
            query</span>.</span>push</span>(</span>", password = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>password</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>preferred_color</span>)</span> =</span> self</span>.preferred_color {</span></span>
            query</span>.</span>push</span>(</span>", preferred_color = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>preferred_color</span>);</span></span>
        }</span></span>
        if let</span> Set</span>(</span>last_login_at</span>)</span> =</span> self</span>.last_login_at {</span></span>
            query</span>.</span>push</span>(</span>", last_login_at = "</span>);</span></span>
            query</span>.</span>push_bind</span>(</span>last_login_at</span>);</span></span>
        }</span></span>
        query</span>.</span>push</span>(</span>" WHERE id = "</span>);</span></span>
        query</span>.</span>push_bind</span>(</span>self</span>.id.</span>value</span>()?);</span> // method `value() to retrieve T implemented at SetOptions</span></span>
        query</span>.</span>push</span>(</span>" RETURNING *"</span>);</span> // Return the updated row</span></span>
</span>
        query</span></span>
            .</span>build_query_as</span>()</span></span>
            .</span>fetch_one</span>(</span>sqlx_conn</span>)</span></span>
            .</span>await</span></span>
            .</span>map_err</span>(</span>|</span>e</span>|</span> e</span>.</span>into</span>())</span></span>
    }</span></span>
 }</span></span>
</span>
impl</span> Users</span> {</span></span>
    pub async fn</span> select_by_id</span>(...) -></span> Self</span> {</span></span>
        ...</span></span>
    }</span></span>
    // And any other method to retrieve the users with your business logic.</span></span>
}</span></span>
</span>
// -------------------</span></span>
// SetOption util</span></span>
#[derive(</span>Debug</span>,</span> Clone</span>,</span> Default</span>,</span> PartialEq</span>,</span> Eq</span>,</span> PartialOrd</span>,</span> Ord</span>,</span> Hash</span>)]</span></span>
enum</span> SetOption</span><</span>T</span>> {</span></span>
    Set</span>(</span>T</span>),</span></span>
    #[default]</span></span>
    NotSet</span>,</span></span>
}</span></span>
</span>
/// Implement `From` for `SetOption` to allow for easy conversion from a value to a `SetOption`.</span></span>
/// Mostly used by the `[into]` attribute of the builder-pattern macros</span></span>
/// ```</span></span>
/// let set_option: SetOption<i32> = 1.into();</span></span>
/// assert_eq!(set_option, SetOption::Set(1));</span></span>
/// ```</span></span>
impl</span><</span>T</span>></span> From</span><</span>T</span>></span> for</span> SetOption</span><</span>T</span>> {</span></span>
    fn</span> from</span>(</span>value</span>:</span> T</span>) -></span> Self</span> {</span></span>
        SetOption</span>::</span>Set</span>(</span>value</span>)</span></span>
    }</span></span>
}</span></span>
</span>
impl</span><</span>T</span>></span> SetOption</span><</span>T</span>> {</span></span>
    pub fn</span> value</span>(&</span>self</span>) -></span> Result</span><&</span>T</span>,</span> anyhow</span>::</span>Error</span>> {</span></span>
        match</span> self</span> {</span></span>
            SetOption</span>::</span>Set</span>(</span>value</span>) =></span> Ok</span>(</span>value</span>),</span></span>
            SetOption</span>::</span>NotSet</span> =></span> Err</span>(</span>anyhow!</span>(</span>"Value is not set"</span>)),</span></span>
        }</span></span>
    }</span></span>
    pub fn</span> is_set</span>(&</span>self</span>) -></span> bool</span> {</span></span>
        match</span> self</span> {</span></span>
            SetOption</span>::</span>Set</span>(</span>_</span>) =></span> true</span>,</span></span>
            SetOption</span>::</span>NotSet</span> =></span> false</span>,</span></span>
        }</span></span>
    }</span></span>
</span>
    pub fn</span> is_not_set</span>(&</span>self</span>) -></span> bool</span> {</span></span>
        match</span> self</span> {</span></span>
            SetOption</span>::</span>Set</span>(</span>_</span>) =></span> false</span>,</span></span>
            SetOption</span>::</span>NotSet</span> =></span> true</span>,</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
A few notes here</p>
Note 1: We only use the attribute sqlx::FromRow</code> at the Users</code> object. This is because we never retrieve a partially created or updated user.</p>
Note 2: For “complex” (or custom) queries, we have a queries/...</code> folder in which we create a struct that corresponds to the result of the query. This gives us a lot of flexibility and clarity.</p>
Note 3: I wish I could iterate over the fields of my Struct easily to have a logic like. That would require creating a macro and parsing the AST.</p>
for</span> name</span>,</span> value</span> in</span> my_struct</span>.</span>fields</span>() {</span></span>
    if</span> name</span> ==</span> "id"</span> {</span></span>
        // This has to be set otherwise return an error</span></span>
    }</span> else</span> {</span></span>
        query</span>.</span>push</span>(</span>", {name} = "</span>);</span> // just to illustrate the idea</span></span>
        query</span>.</span>push_bind</span>(</span>value</span>);</span></span>
    }</span></span>
}</span></span></code></pre>
To conclude this article, after doing it, what are the pros and cons of this approach compared to using an ORM?</p>
Pros</strong></p>

Fewer dependencies. We added smaller dependencies like builder-pattern</code>, but the reality is that those macros are so simple that they haven’t been updated since 2021, since they are stable.</li>
We only use some of the concepts of an ORM that we like (eg Model</code> and ActiveModel</code> for which I took some inspiration from (see seaORM here</a>)</li>
All the business logic is centralized, and we can lock down how each object is inserted and updated</li>
All of our custom/complex queries are plain-based SQL, which are easy to debug and prototype first (vs converting SQL <> ORM logic back and forth)</li>
We have total control of the queries and how we want to handle them (eg: manipulating a query to force using an index, etc.)</li>
We use Sqlx for everything we need (eg, Migrations, queries, transactions, etc.)</li>
</ul>
Cons</strong></p>

We have to reimplement some of the boilerplate that an ORM covers, like the ability to insert or update specific fields in our database</li>
All this custom code (or boilerplate) has to be tested</li>
This misses the ability to generate Struct from a CLI that inspects the database (eg with SeaORM here</a>)</li>
</ul>
In the end, we like where we landed with our approach. We could have used something bigger, like SeaORM, but we felt that we would be embarking on too many concepts for our simple use case.</p>
While implementing all that logic was not trivial at first (first time the team built in Rust), it was primarily because we were looking for how we wanted to structure the project (also first time building a web API for a user-facing product). Now that we have this pattern and built our experience, the second project would be much faster if we used the same approach.</p>
This is why, I ended up creating a simple library that do just that. It’s very well tested and comes with smart default. More about it in the next post</a></p>

Matt Delacour

Why Experience Still Beats Knowledge in AI-Assisted Engineering

Releasing a tiny ORM for CRUD operations.

Simple CRUD only using SQLx

The Example: User Model</h2> So we organized the project without an ORM, instead implementing a structure and helpers to make CRUD operations as easy as possible.</p> Let’s jump into it</p> Let’s take the following example.</p>

Introducing SetOption</h2> We can see that we wrap all of the fields that could be updated by another Option<></code> . The goal here is to check whether a field is set. To make things more explicit than having another Option<></code> . I went with the following approach</p>