The LAXIMA Manifesto
Software is being rewritten.
And we refuse to keep writing it the old way. This is what we believe, and how we build.
The 60-second version
The LAXIMA manifesto is a point of view on building software in the post-code era. We believe software is now specified in English, executed by agents that own goals instead of following scripts, and verified by evals instead of opinions. The fifteen tenets below are that worldview: how good AI automation gets scoped, built, and judged.
00 / Preamble
For fifty years we told computers what to do, one line at a time. That era is over. We now describe what we want and the machine negotiates the rest. Most software teams have not internalized this yet — they still staff for it, price for it, and architect for it as if the marginal cost of a line of code were the same as it was in 2018. It is not. This is a field guide to the new regime. The tenets below are not marketing — they are the principles we build by.
The tenets at a glance
What we believe.
English is the new programming language.
The hot new programming language is English. If you can specify a system clearly in plain prose, you can build it. The scarce skill is no longer typing syntax — it is thinking clearly, decomposing problems, and knowing what "done" looks like. What counts now is specification quality, not memorized API surface.
Agents are colleagues, not macros.
An agent that only does what you explicitly tell it is a macro with a marketing budget. A real agent plans, uses tools, observes, corrects, and escalates. The bar is a system that owns a goal — not one that executes a checklist. If a human still has to babysit every step, the automation has failed.
Evals beat opinions.
Without evals, every shipped AI system is a vibes-based deployment. Write the evaluation harness before the agent. A feature is not "done" when it runs — it is done when it beats a measurable, versioned benchmark that anyone can re-run. Teams that ship without evals are not engineering; they are gambling.
Context is the product.
The model is a commodity. The prompt is a commodity. The moat is the context pipeline — which documents, which tools, which memory, which retrieval, which guardrails, in what order, with what freshness. 90% of our engineering time goes into context and data plumbing, not into prompting. Anyone who thinks "prompt engineering" is the hard part has not shipped a real system.
Software 3.0 is probabilistic.
Software 1.0 was code. Software 2.0 was weights. Software 3.0 is prompts orchestrating weights, calling code, calling tools. It is non-deterministic by construction. Stop trying to unit-test it like a pure function. Start treating it like a distributed system that occasionally hallucinates — with retries, fallbacks, human-in-the-loop escalation, and statistical SLAs.
The unit of delivery is the workflow, not the feature.
Real problems are not "feature" problems. They are workflow problems — a messy sequence of humans, spreadsheets, emails, CRMs, and Slack messages duct-taped together. The goal is to replace workflows end-to-end and measure the labor hours, dollars, and error rates eliminated.
Taste is the last scarce resource.
When anyone can generate a prototype in an afternoon, the bottleneck becomes judgment: what to build, what to kill, what looks cheap, what feels trustworthy. Taste — design taste, product taste, code taste, operational taste — is the last moat that does not commodify. It is worth optimizing ruthlessly for — and refusing to ship work that is merely functional.
Ship in days, not quarters.
The correct first response to a well-scoped automation problem is a working prototype in a week, not a 40-page proposal in a month. Speed of iteration is now the dominant variable. Six-month discovery phases are a failure mode dressed up as rigor. Scope small, ship fast, and let reality correct the plan.
Cost per task, not cost per seat.
Pricing software by how many humans touch it is an artifact of a world where humans did the work. The honest unit is the cost of completing a task: dollars per invoice processed, per ticket resolved, per lead qualified. That framing forces honesty. Any automation worth building must drive that number down by an order of magnitude.
Observability or it did not happen.
Every agent action is logged, traced, replayable, and attributable. Every model call has a version, a cost, a latency, and an eval score attached. If you cannot answer "what did the agent do last Tuesday at 2:14am and why?" you do not have a product — you have a liability. Instrument first, optimize second.
Humans in the loop, not on the hook.
Full autonomy is a lie we tell at conferences. Real systems have a dial: fully autonomous for the boring 80%, human-approved for the consequential 15%, human-owned for the irreversible 5%. The job is to draw that line correctly — and to move it leftward responsibly as trust compounds.
The engineer still owns the stack.
The hottest lie in our industry right now is that the solution engineer no longer needs to know what is happening under the hood — that a good prompt is a substitute for understanding systems, types, networks, databases, memory, and the failure modes of the stack you are shipping. It is not. An engineer who cannot read the diff the agent produced, who cannot reason about latency and idempotency, who cannot tell a valid migration from a dangerous one, is not piloting an agent — they are a passenger hoping the autopilot holds. The agent raises the ceiling of what one literate engineer can do by an order of magnitude. It does not raise the floor of what an illiterate one can do at all. The engineers who thrive still crack open the code the agent wrote, still run the query by hand, still read the RFC, still sketch the architecture on paper before asking for a generation. Taste and technical literacy are the two things humans cannot outsource. Everything else, eventually, the agents will.
Own the reversibility.
The right question is never "can the agent do this?" — it is "what happens when the agent does this wrong at 3am on a holiday?" Every automated action must be reversible, rate-limited, or gated. Design for the blast radius of failure before the happiness of the happy path.
The org chart is the bottleneck.
Most AI projects fail not because the models are bad but because the organization around them is incoherent. Sometimes the honest finding is that a department structure is wrong, or that the KPIs reward the wrong thing. AI will not fix an org where the political will does not match the technical ambition — shipping into a broken org is a cruelty to everyone involved.
Trash in, trash out.
No model — frontier or otherwise — will rescue you from bad data. A hallucination is often just a polite surfacing of the contradictions already sitting in your CRM, your docs, your spreadsheets, your Slack. Before you train, fine-tune, or prompt anything serious, audit the inputs: schema drift, duplicate rows, stale fields, broken encodings, silent nulls, the "free text" column nobody owns. Data quality is not a preprocessing step you do once and forget — it is a continuous discipline with owners, SLAs, tests, and alerting. Never ship an automation on top of a dataset you do not trust, because the only thing worse than a manual process is a confident, automated, wrong one.
Closing
If any of this sounds obvious, good — it should be, in ten years. If any of it sounds heretical, also good — that is the gap between teams building for the new regime and ones still pretending the old playbook works. The point is not to sprinkle "AI" on a roadmap. It is to rethink the roadmap.
— The LAXIMA team
This is how we think about building with AI.
The same thinking runs through everything we publish. Dig into the guides to see it applied.
Read the guides