We're Hiring a Foundational Engineer. The Company Is Fake. The Work Is Not.

Fictional job post: Aster Loop is an invented company, and this opening does not exist. We are not collecting applications. The company, compensation, product, and hiring process below are illustrative. This post was written on July 18, 2026, as a realistic thought experiment about where software engineering work may be moving.

Role: Foundational Engineer, AI-Native Systems

Company: Aster Loop, a fictional seed-stage startup

Location: Remote, with four hours of working overlap between UTC-5 and UTC+2

Employment: Full time

Illustrative compensation: US $175,000 to $225,000 base, plus 0.35% to 0.80% equity

About Aster Loop

Aster Loop is building an AI-native operations platform for teams whose most important work still lives across inboxes, spreadsheets, internal tools, and human memory.

The product turns that fragmented work into governed workflows. People define the outcome and retain authority over consequential decisions. Agents handle bounded execution. Every action should be inspectable, reversible where possible, and accountable to a human owner.

We are an 11-person fictional team in private beta. You would join as our fourth engineer and work directly with the founders, product lead, and early design partners.

The role

We need an engineer who can own the layer between intent and production.

You will still write code. You will also decide what should be built, turn ambiguous requests into executable specifications, divide work between humans and agents, verify what comes back, secure the execution path, and help the result survive contact with real operations.

This is not a prompt-engineering role. It is not a project-management role dressed up as engineering. It is a hands-on systems role for someone who can move from a user workflow to an architecture, from an architecture to a working change, and from a working change to a reliable operating system.

What you will do

• Turn messy product and operational problems into explicit outcomes, constraints, interfaces, and acceptance criteria.
• Decide which work belongs to people, coding agents, model calls, deterministic services, or no software at all.
• Build production software across the stack, while using AI tools where they create real leverage.
• Orchestrate changes across agents, branches, tools, browsers, test environments, and deployment workflows.
• Review both human-written and machine-generated code, then verify the full behavior beyond the diff.
• Build evaluation systems for quality, reliability, latency, cost, maintainability, and repeated behavior.
• Make repositories legible to humans and agents through clear architecture, conventions, boundaries, and operating instructions.
• Design permission scopes, approval gates, audit trails, and safe failure paths for automated actions.
• Work with users to fit new capabilities into existing workflows instead of shipping isolated features.
• Protect coherence over time by reducing architectural drift, removing dead complexity, and making ownership visible.

What success looks like

In your first 30 days, you will map one customer workflow from intent to execution, ship a narrow production improvement, and document the system well enough that another engineer or bounded coding agent can make a safe follow-up change.

By day 60, you will own one end-to-end workflow. That includes its specification, implementation, evaluations, permissions, deployment path, observability, and human approval points.

By day 90, that workflow should be running in real customer operations with known reliability and cost boundaries. The team should understand how it works, how it fails, and who steps in when it does.

Six months in, success means more than shipping quickly. The product should be easier to reason about because you worked on it.

You may be a fit if

• You have built and operated production systems end to end. We care more about the evidence than a specific number of years.
• You can go deep in code without losing sight of the surrounding product, workflow, and business constraint.
• You write specifications that reduce ambiguity without pretending uncertainty has disappeared.
• You use AI coding tools, but you do not confuse plausible output with verified work.
• You can design tests and evaluations for systems whose behavior is partly probabilistic.
• You understand least privilege, secret boundaries, approval paths, and the risks created when software can act.
• You communicate clearly in writing because context is part of the system.
• You can tell us when the right answer is to simplify, integrate, or not build.

Helpful, not required

• Experience with agent orchestration, evaluation harnesses, tool-calling systems, or human approval workflows.
• Experience designing event-driven systems, queues, durable jobs, or distributed workflows.
• Experience working with enterprise integrations and messy operational data.
• Experience in an early-stage startup where architecture, product judgment, customer work, and implementation overlapped.

We do not expect one person to arrive with every item. We do expect you to know where your judgment is strong, where it is still developing, and how you close the gap.

How we work

• Humans own direction and consequential decisions.
• Automation earns authority through bounded scope, evidence, and reliable operation.
• A passing test is evidence, not proof that the workflow is right.
• Speed matters, but speed that creates invisible complexity is borrowed time.
• Clear context is infrastructure.
• The person who ships a system shares responsibility for how it behaves after launch.

The fictional interview process

1. A 30-minute conversation about a system you built and the trade-offs you made.
2. A 60-minute architecture session based on a messy customer workflow.
3. A paid, three-hour working exercise in a small repository with an optional coding agent.
4. A final conversation about ownership, judgment, and how we would work together.

No puzzle interviews. No unpaid take-home project. AI tools are allowed, but you must be able to explain and verify what they produce.

Read the original essay: The Foundational Engineer Is Moving Upward