Building Wrought with Wrought: An Introduction
There’s a fundamental problem with how we use AI for software engineering today.
We take a single large language model — usually the most capable one we can afford — and ask it to do everything. Architecture decisions, debugging, code generation, testing, reviews. One model, one context, one set of trade-offs applied uniformly to every task.
It’s like hiring one person to be your architect, developer, tester, and code reviewer simultaneously. Even the most brilliant engineer would tell you that’s a bad idea.
The Multi-Model Reality
Different engineering tasks demand different capabilities. A thorough investigation of a production incident requires deep analytical reasoning — the kind of slow, careful thinking that benefits from a model optimized for complex reasoning. But generating boilerplate code from a well-defined specification? That needs speed and precision, not deep contemplation.
Code review demands a different perspective entirely — one that can hold multiple concerns in mind simultaneously: correctness, security, performance, and maintainability. Testing requires yet another mindset: adversarial thinking, edge case generation, boundary analysis.
The right model for every task isn’t just a tagline. It’s an engineering principle.
What Is AI Engineering?
We believe “AI Engineering” is an emerging discipline — distinct from prompt engineering, ML engineering, or traditional software engineering.
AI Engineering is about:
- Methodology over prompts: Structured pipelines that encode engineering best practices, not ad-hoc conversations with a chatbot
- Orchestration over manual effort: Automatically routing each engineering task to the ideal model and workflow
- Outcomes over outputs: Measuring success by the quality of shipped software, not the volume of generated code
Think of it this way: prompt engineering is about getting a good response from a model. AI Engineering is about building reliable software systems that happen to use AI at every stage.
Building in Public
We’re building Wrought with Wrought. Every feature of the platform is developed using its own methodology — reactive pipelines for bug fixes, proactive pipelines for new features, audit pipelines for quality assurance.
This blog series will share what we learn along the way:
- Architecture decisions: Why we chose certain technologies and patterns
- Results and outcomes: What multi-model orchestration actually achieves in practice
- The philosophy: Why engineering methodology matters more than raw model capability
- State of AI Engineering: Our observations on this emerging field
We’ll share the philosophy, the results, and the lessons learned. We believe the ideas behind AI Engineering should be discussed openly — they’ll shape how our industry builds software for the next decade.
What’s Next
In upcoming posts, we’ll dive into:
- Why we chose a multi-model architecture and what trade-offs that creates
- How structured engineering pipelines differ from ad-hoc prompting
- Real results from using Wrought on production projects
- Our vision for where AI Engineering is heading
If you’re interested in following along, join the waitlist to get early access when Wrought launches.
This is the first post in the “Building Wrought with Wrought” series. Follow along as we build an AI engineering platform using its own methodology.