Field report / 7 November 2026

A prompt now gets you much further into a piece of software than it did a year ago. A musician can ask what a groovebox's controls are doing, trace a firmware path and begin building a different instrument around the same hardware. A photographer can ask whether a camera feature is absent, disabled in a menu, or present but unreachable. The speed is startling. The important question is what happens after the first plausible answer.

From vibe coding to evidence

In February 2025, Andrej Karpathy described “vibe coding”: telling an AI system what you want, trying what it makes and continuing by feel. It was an apt name for fast sketches. A 2025 study of the practice describes the shift from writing each line to working through conversation. Useful software can begin that way. But the moment the code must drive a sampler, survive an update or alter a camera, the physical result becomes the judge.

“Vibe engineering” is a useful name for the next move: keep the speed of conversation, then require a traceable chain from observation to explanation to working test. Reverse engineering itself is decades old. The recent change is that an agent can help traverse many of its repetitive steps, connect evidence from different tools and propose the next experiment. It cannot make an untested inference true.

Reverse Engineer Anything (REA) is a sharp example of this shift. It connects a coding agent to local inspection of binaries, firmware, JavaScript and Electron applications, .NET assemblies and runtime behaviour. Native work calls on tools such as Ghidra, Hopper or IDA where available. REA returns observations, code paths and limitations for the agent to use; it does not hand back a trustworthy original source tree at the press of a button. Its DX-Ball sound-panning case study shows the standard worth aiming for: a recovered C function compared with the original x86 over 3,205 behaviour cases, plus a matching 63-byte compiled function. That is a specific result, with a specific test, rather than a screenshot of convincing pseudocode.

The FM-1 became a small laboratory

The M-VAVE FM-1 Open repository gives builders application source, development material and a workbench route to firmware updates. Its device engine is supplied as a binary SDK under separate terms, so “open” describes a real opportunity, not every byte in the machine. The small keyboard has become a useful place to try genuinely different instrument designs on the same controls.

Melodee, built from the Felucca line, takes the FM-1 towards a song-making system: four internal synth/MIDI parts, four more MIDI tracks, a shared effect rack and a web editor. Its project documents releases and build provenance while distinguishing automated checks from tests with an actual connected follower. FM-Stud1o is another original, eight-track groovebox direction, with its own engines and editor. These are different musical products on one hardware platform, not merely alternate colour schemes for the factory screen.

Our FM-1 firmware guide follows more branches of this scene. What makes it exciting is the speed of the loop: document the buttons and display, make a playable idea, then see if it still feels right on the keys. Source code and a successful build are milestones. Saved projects, MIDI timing, audio load and recovery paths decide whether a musician can trust it.

Behringer opens a different door

Music Tribe has published the Behringer KICK source: application code, an audio-engine library, a hardware communication layer and a Buildroot Linux image. Our closer look at the KICK repository explains the split. This is a manufacturer releasing substantial internals, whereas much firmware work begins with a community trying to discover them. It is a promising base for builders, with component licences and branding limits to respect. The repository by itself is not proof of a finished community firmware or an installed alternative instrument.

A more established manufacturer-sanctioned route is Korg's logue SDK, which lets developers make custom oscillators and effects within a defined interface. That narrower opening can be musically powerful: the device remains a stable host while the creative part is replaceable. The KICK and FM-1 show how much further a public platform might go when application and system layers are available.

Other machines are changing shape

DOOM OS for the Roland SP-404MKII is one of the clearest working examples right now. Its maintainers describe a modified firmware with a graphical pattern sequencer, mixer, instruments, arpeggiator, parameter locks and effect automation, and provide a patching route and manual. It is a working project that changes the workflow of a beloved sampler; the authors also own the compatibility and recovery questions that come with modifying an update image.

op1r for the original OP-1 takes another route: open mod code, plugin-style additions and a PC test harness for audio and screen experiments. A user supplies their own original OP-1 firmware image to build the modified one; the project does not distribute Teenage Engineering's firmware. The test harness is especially interesting. It moves some iteration off the hardware, where a broken build costs a restart rather than a performance. Neither project makes every instrument “hackable” in the same way: processor, firmware format, signing and community knowledge still set the terrain.

The camera market is the next live question

Camera firmware is where the excitement needs the most careful language. A Sony A7 IV 6.02 research project documents service-mode access, a verified backup and read-only firmware study. Its author has made a shutter-angle display appear, but reports that the dial and touch paths still do not reach the angle setter. Custom LUT parsing and storage paths are present, while the product's runtime UI gate remains unresolved. A menu appearing is not the same as a usable, dependable feature.

Fujihack is investigating Fujifilm firmware and publishing what it learns; it does not advertise a ready public hack. There is a historical precedent in OpenMemories-Tweak for older Sony PlayMemories cameras. The current Sony and Fuji investigations suggest a more demanding frontier: product-specific UI routes, imaging pipelines, signed updates and recovery all have to agree before a laboratory discovery turns into a camera someone can take to a job.

Why does this matter to the market? Firmware determines visible capabilities, workflow and useful life as much as the sensor does. It is reasonable to expect buyers to ask harder questions about update policies and whether features are exposed through supported APIs. That is an inference from these projects, not evidence of imminent unlocks across today's camera ranges. Manufacturer-supported extension points could give photographers useful custom tools with a clearer maintenance path; community research can still reveal where the boundaries really are.

Where the interesting work goes next

Three directions look particularly alive. First, new instruments on existing boxes: the FM-1, DOOM OS and op1r put musical identity into software a musician can actually try. Second, better evidence tools: REA's value rises when every claimed behaviour can be traced to an address, capture, test or measurement. Third, supported openings from manufacturers: code or SDKs can let a community invent without first breaking through a locked door.

The bottleneck is increasingly verification. A 2026 binary-analysis benchmark cautions against assuming that strong source-code performance transfers automatically to stripped binaries. Real devices add timing, storage, thermal limits and failure recovery. The thrilling part is that more people can now reach the first experiment. The engineering part is making the second, tenth and hundredth experiment agree with reality.