The New Language of Building

AI isn't replacing engineering. It's upleveling it.

Every major shift in programming has followed the same pattern: the language gets closer to how humans think, more people get access to the craft, and the problems worth solving get harder and more interesting.

Assembly to C. C to Python. Each transition felt, at the time, like a question of tooling. Looking back, it was always a question of abstraction.

Within Check engineering, we believe AI-assisted development is the next step in that arc. The engineers who thrive in it won't be the ones who use it most; they'll be the ones who understand what it actually changes about the job.

What abstraction has always meant

When Python arrived, the obvious story was productivity. You could write in fifty lines what C required five hundred for. But the more interesting change was cognitive: you stopped thinking in memory addresses and started thinking in data structures. The compiler handled the gap. Your energy moved up the stack.

The same shift is happening now, and the surface-level story, "AI writes code faster," is obscuring the more important one.

When we built our MCP server and CLI, a working proof of concept supporting over 250 API endpoints took shape in a single evening using Claude Code. From there the team iterated, hardened, and shipped it properly, but the scaffolding that would have consumed a sprint arrived in hours. The speed is great, but what's even more interesting is what the engineer was doing with that time: thinking about the architecture, the interface design, what the tool needed to enable. The implementation was delegated. The thinking wasn't.

That's the abstraction. And just like every previous evolution, it raises the floor on what's expected of the people who build software, not lowers it.

Compiler thinking

Here's the frame we keep coming back to: the model is the compiler. The discipline of working with it looks a lot like the discipline of writing good code, just applied one level up.

Ambiguous inputs compile to ambiguous outputs.

Context is source code. What you give the model shapes what comes out as directly as the instructions themselves. The engineers getting the most leverage from AI aren't the ones writing the most elaborate prompts; they're the ones who've thought carefully about what context to include and why. It's the same skill as writing a function with well-defined inputs. It just looks different.

Specify outcomes, not implementations. The instinct when working with AI is to describe what you want step by step, essentially writing pseudocode for the model to execute. The better approach is to specify what correct output looks like and let the model find the path. Define your constraints, give examples of the result you're after, and be precise about edge cases. This is design work. It's what good engineers do before they write a line of code, and it's exactly the skill that transfers.

First output is a draft. Knowing when to iterate versus when to scrap and restart is one of the harder judgments in working with AI, and it's the same judgment experienced engineers apply when they review their own work. The difference is that AI outputs look finished. The prose is clean, the code is syntactically valid, the explanation sounds confident. Reading it critically rather than simply accepting it is a real skill, and one worth being explicit about building.

Test the compilation. This is where we've learned our hardest lessons. An agent we'd tasked with diagnosing a production error reported the issue resolved after the failure rate dropped from 100% to 10%. That wasn't a fix; it was noise. The model interpreted partial improvement as resolution because we hadn't specified what success actually meant. We'd handed off the definition of success along with the task, and the model didn’t distinguish between ten failures and zero.

A culture of builders

None of this makes engineering less demanding. If anything, it raises the stakes on the parts that matter most.

When we look at what we want in engineers today, including how we evaluate candidates, the signals are fundamentally the same. We want people who ask the right questions before accepting output, who debug when something looks too clean to be right, who design systems that hold together under real conditions rather than demo conditions. AI makes that judgment even more important and more visible, faster.

The abstraction layer moved. The craft didn't go away; it moved with it. We're still a team that takes building seriously. We're just building at a higher level now, which means the interesting problems are harder, the leverage is greater, and the engineers who get this right will do the best work of their careers.

That's the bet we're making. We think it's the right one.

We're hiring engineers who want to build this way. See open roles at Check.