An Engineer, Not an Assistant

Every AI coding company is now "an AI engineer." The phrase has been so thoroughly drained by marketing that it's almost embarrassing to use.

So let's use it anyway, and mean something precise by it.

The spectrum of AI coding tools

Every tool in the AI coding space lives somewhere on a spectrum. At one end: tools that complete the line you were typing. At the other end: tools that write the app you weren't typing at all.

Autocomplete. GitHub Copilot, Tabnine, Codeium. You're writing code. The tool predicts the next token, the next line, occasionally the next block. You stay in the driver's seat. The tool makes you faster at a thing you were already doing.

Assistant. Cursor, Continue, inline chat in most IDEs. You tell the tool what to do in natural language and it writes the code you would have written, inside your editor, in front of your eyes. You review each change. You stay the engineer. The tool is a very fast junior who never needs a coffee.

Engineer. A shorter list. The tools where you describe the feature, and the tool reads the codebase, plans the work, writes the files, wires the backend, runs the tests, and opens a pull request. You step in when it asks you to, not every five seconds. You're the product person, not the typist.

The three levels feel like points on a continuum but they aren't. Each step is a different contract between human and machine. The first gives you speed. The second gives you leverage. The third gives you absence, the ability to step away from the code entirely while the code still gets written.

Most people in the industry treat the third level as a future thing, a theoretical destination. We built Appsanic because we think it's already here for one specific and enormous domain: mobile apps.

Why "assistant" isn't enough for mobile

An assistant works well when the human is a programmer. You know what you want to build. You have opinions about structure. You can tell the difference between good code and code that'll hurt you in a month. The assistant accelerates you by ten, maybe twenty times.

Mobile apps break that assumption in two directions at once.

On one side: the people who most want to build mobile apps (founders, indie makers, domain experts with an idea) often aren't programmers. They can describe what they want. They can't read a diff and know whether it'll hold up under the third user story no one thought about. An assistant that makes them responsible for code review is offering a sports car to someone who doesn't have a license.

On the other side: mobile development is unusually demanding about what launches. iOS and Android have their own submission bureaucracies. React Native has its own arcana about builds, signing, Expo managed vs. bare workflows, EAS, OTA updates, and the seven ways to break your app by upgrading a dependency. This is hostile terrain for an assistant. Every time the code hits a real build wall, the human has to know what that wall is and how to climb it.

An engineer handles those walls. An assistant hands them back to you.

What changes when the AI is the engineer

When you move from "helps me write code" to "writes the code for me," something quiet and profound happens. The unit of work changes.

With an assistant, your unit of work is a line, a function, a file. You think in code, and the AI follows your thoughts down into implementation. Good work looks like "I cleaned up this module." Slow work looks like "I'm stuck on this bug."

With an engineer, your unit of work is a feature. A flow. A product decision. You think in user facing outcomes: "signup should require phone verification," "there should be a way to tag a note," "the timeline should load incrementally when the user scrolls." The AI translates those outcomes into a plan, the plan into code, the code into working software. Good work looks like "I launched this feature." Slow work looks like "I'm not sure what to build next."

The second kind of "slow" is a much better kind to be stuck on.

There's a real craft involved in thinking at the feature level instead of the file level. Many engineers have to actively retrain themselves to work this way. It's a different muscle. But the people who never wrote code at all? They were already thinking this way. They just didn't have a tool that could meet them there.

Three stories from people who never wrote code before

We pay close attention to who uses Appsanic, and the composition isn't what you'd expect from a developer tool. Three composite profiles from real users (details changed, arcs real):

Maria, a physiotherapist. Maria treats patients with chronic lower back pain. For years she'd print exercise handouts and watch most of them end up crumpled in kitchen drawers. She had a clear idea: an app that shows each patient their own daily exercise list, lets them tap when they've done it, and quietly pages her if they miss three days in a row. She'd tried to hire a developer. She'd taken one Swift tutorial and quit on day three.

Her first Appsanic prompt was: "An exercise tracking app my physiotherapy patients can use daily. I need to assign each patient their own list, they check off what they did, and I want to see who's not keeping up."

Twelve minutes later she had the patient side app. Fourteen minutes after that, the clinician dashboard. Two days of polishing, a week of waiting on Apple review, and she had 30 patients on the app. Three months later, adherence to her home exercise prescriptions doubled. Her own income grew in parallel. Patients who do the work get better faster, and word of mouth compounds.

Maria still doesn't write code. She writes prompts.

James, a founder. James had an idea for a B2B SaaS tool, a CRM for small contractors who work alone. He is a great salesperson, a great operator, a mediocre coder who had built enough Rails apps ten years ago to know he was mediocre at it. He would have hired a technical cofounder, but the idea to launch loop was going to take six months of recruiting alone.

Instead, he built v1 in three weekends. Not a demo. The version that got his first ten paying customers. He released weekly updates for eight months. Eight months in he hired his first engineer, not to rebuild the app, but to maintain it while he ran the company. That engineer took the Appsanic generated codebase, read through it in a weekend, and said, "Actually, this is fine. I'd have written it this way."

The company now has 400 paying customers. It's his first profitable business. The part of the dream that always died early, "I need to find someone to build it with me," never died. Because that part of the job was never the bottleneck.

Priya, a PM at a large company. Priya works on an internal tool team. She has ideas that her engineering org never has capacity to build. The specific idea she keeps getting no on: a mobile companion app for field technicians, to let them photograph a part and auto log the entry in the CMMS. Six months of pitching, no traction.

One weekend she built it in Appsanic. Not production ready, but real enough to install on a tester's phone and run a 10 person pilot. The pilot data made the case the six months of pitching couldn't. Engineering rebuilt it properly the following quarter. She didn't "launch" the final app. She delivered the proof.

This is the quiet use case: the prototype you couldn't justify having an engineer spend a sprint on is now a weekend you spend alone. The gatekeepers change.

The craft shift: thinking at the feature level

If there's one skill that separates people who thrive with Appsanic from people who don't, it's the shift from implementation thinking to feature thinking.

Implementation thinking sounds like: "I need a button. The button should call this function. The function should take these parameters."

Feature thinking sounds like: "When a user finishes editing a draft, they should see a confirmation that it's saved. If they close the app mid edit, the draft should be there when they come back. Syncing happens in the background. They should never see a spinner for it."

Same feature. Different level of description. The second version gives the agent enough context to make fifty small implementation decisions correctly, without you having to spell them out one by one.

Practicing the shift: for the next feature you want, try writing the prompt before writing code. Don't mention functions or files or libraries. Describe what the user sees, what they feel, what they should never have to think about. You'll find that the prompt is often clearer than the spec you'd have written.

What Appsanic is not

It's worth being honest about what we aren't building.

We aren't an "AGI for programming." There are problems, especially novel ones, where a human engineer's intuition still beats anything we can build. Research code. Infrastructure with hard realtime constraints. Algorithmic work outside the training data. We aren't pretending to cover every corner of software.

We aren't a replacement for engineers inside tech companies. Appsanic makes individual engineers dramatically more productive, but it doesn't eliminate the need for people who understand your system end to end. Our users include the ICs at many companies, not the workforce count.

We aren't promising mobile development is "solved." The App Store still has weird rules. Android still fragments by vendor. Users still find the one bug you didn't test for. We're making a specific shape of the problem ("I know what I want, I need it built and launched") dramatically easier.

What we're working toward

The next year or two at Appsanic looks like this, roughly:

Fewer surprises in the deploy path. App Store submission, TestFlight, Play Store rollouts, OTA updates, all should be as automatic as the code writing is today. We're close, not there.

More understanding of large codebases. An agent that plans well at feature one should still plan well at feature forty, once the codebase has its own conventions and history. That's a harder problem. Much of our engineering work is here.

Better collaboration with humans. The best future isn't the agent writing code alone. It's the agent and a person working as a small team. We're building tools that let an engineer jump into the agent's work at any point, fork the approach, redirect, and stay in the loop without reengaging every five minutes.

The quiet ceiling. Every new model we release (Fast, Pro, the next one, the one after that) moves the line of what an engineer less builder can plausibly attempt. That ceiling has been rising steadily and we have no reason to think it stops rising.

The invitation

If you're an engineer: use Appsanic on the boring parts of your day. Notice what gets faster. Notice what you stop wanting to do yourself. Tell us what's still rough. We read the messages.

If you're someone who couldn't build an app before: give it twenty minutes. Describe something you've always wanted to exist. Watch it appear. The experience doesn't really translate to text.

We're building an engineer. Not an assistant. The difference is the point, and the difference is what turns a domain expert into a builder, a founder into a maker, and an idea into an app that actually exists.

Come build something.