I asked DeepSeek to design a band-pass filter. What I learned wasn't about the filter.

A developer prompted DeepSeek to design a band-pass filter with a 1 kHz lower cutoff, 10 kHz upper cutoff, and a gain of 50 using a 741 op-amp. The model produced a clean two-stage design and flagged the 741's 1 MHz gain-bandwidth product as leaving almost no margin at that gain, recommending better op-amps and an alternative topology. The developer notes the model could write a Python script to sweep frequency and input voltage but could not execute it, concluding that AI writes the test while the human still runs it.

My prompt: "Design a band-pass filter with lower cutoff at 1 kHz and upper cutoff at 10 kHz. Use a 741 and set the gain to 50." It gave a clean two-stage design. It also flagged the 741's 1 MHz gain-bandwidth product, which leaves almost no margin at a gain of 50, and recommended better op-amps and an alternative topology. So DeepSeek gave me a textbook solution—and named the 741's limits itself. What it couldn't know is what I never told it: my supply rails and my maximum input amplitude. That raised the real question. What solution was I expecting? In a classroom, the textbook answer is appropriate. In the lab, building a prototype, will it meet spec? Probably—maybe. Better still: why not ask DeepSeek to test it? Sweep the frequency from 0.1 kHz to 100 kHz, vary the input from 0.1 V to 5.0 V, and plot the output. But can DeepSeek run that test? It can write the Python script. It cannot execute it. So the boundary is clear. AI writes the test. I run the test. There are tools emerging that close this gap—MCP servers that let a model drive ngspice or LTspice directly—but for now, the experimenter is still me. Which means the next step is mine: run the sweep, and see whether the prototype matches the simulation.