FPGA PA

Blog › Solve harder problems

Solve harder problems

AI is taking the work. Whether it takes the job depends on what we do with the hours.

Published 2026-08-22. AI assisted in writing this post.

The previous post on this site argued that FPGAs missed the AI accelerator market for two structural reasons. The first was silicon: a GPU spends the dominant share of its die on the core compute element, while an FPGA must spend a large fraction of its die on the machinery of reconfigurability, so the large-language-model boom was never available to programmable logic at any level of tooling. The second was economic, and it governed everything else: the cost of changing what the hardware does was too high. A GPU recompiles. An FPGA gets re-engineered. The essay closed on a conditional: if AI agents can absorb a large share of that cost of change, the second boom — the specialized systems that deployed AI creates demand for around the tensor computation — can go to FPGAs.

That conditional has an uncomfortable corollary. The engineering cost being absorbed is us.

This post is about what to do with that. The short version is that the constraint on FPGA work is moving, from how fast a design can be executed to which designs are worth executing, and that the second constraint rewards a skill most of us have never been given the hours to practice.

What is being automated

It helps to be specific about the work that is leaving.

Ask an FPGA engineer what consumed last week and the answer is rarely architecture. It is the hour waiting for synthesis to confirm a one-line change. The crash two hours into place and route. The constraint file that describes a clock that no longer exists. The forum thread from 2014 that almost matches the error message. The license server. The hundreds of lines of UVM scaffolding required before the first interesting assertion. The timing report that has to be read, by a person, to find the one path that matters.

None of that is engineering judgment. It is the cost of getting the tools to accept judgment that was formed in the first twenty minutes.

The industry’s own numbers say this load is already past capacity. The 2024 Wilson Research Group study, sponsored by Siemens EDA, reports that 87 percent of FPGA projects shipped with at least one non-trivial bug escaping into production. That is not a field short of problems. It is a field short of hours, spending the hours it has on execution and still not finishing.

This is the layer that current AI tooling attacks first, because it is the layer where the work is most regular: boilerplate, search, translation of tool output into plain language, first drafts of testbenches, log parsing, the mechanical reading of reports. It is also the layer the association’s own tooling work targets, for the same reason.

So the phrase “AI is taking our jobs” deserves a more precise restatement. AI is taking the part of the job that was never the job. The question is what the engineer does with the hours that come back.

What the measurements say

The candid summary of the evidence is that the hours do come back, but not evenly, and not where an expert might expect.

The largest field study so far followed 5,172 customer-support agents after a generative assistant was introduced. Productivity rose 15 percent on average. The gain was concentrated among the least experienced workers, who got faster and better. The most experienced saw small speed gains and small declines in quality.

A pre-registered experiment with 758 consultants at Boston Consulting Group found a similar shape. On eighteen tasks that sat inside what the authors call the jagged frontier of the model’s competence, consultants using GPT-4 finished 12.2 percent more tasks, 25.1 percent faster, with quality rated about 40 percent higher. On a task deliberately chosen to sit outside that frontier, the same tool made them 19 percentage points less likely to reach the right answer. The model was wrong with confidence, and the consultants extended it trust it had not earned.

The study closest to our own work is the least flattering. In 2025 METR ran a randomized trial with sixteen experienced open-source developers completing 246 real tasks in repositories they had maintained for years. With AI tools allowed, tasks took 19 percent longer. The developers had predicted a 24 percent speedup, and after finishing, still believed they had been 20 percent faster. METR’s follow-up in February 2026 found the same developers now appear roughly 18 percent faster with the tools, but with a confidence interval wide enough to include no effect, and with selection problems the authors flagged themselves.

Three things follow.

First, the gain is real and largest on unfamiliar ground. Novices gain more than experts. Tasks inside the model’s competence gain; tasks outside it lose.

Second, for an expert working on familiar ground, the machine is not yet a multiplier, and the feeling of speed is unreliable. If you want to know whether a tool is making you faster, time it. Do not ask yourself.

Third, and this is the point of the post: the condition under which an expert gains most is the condition of stepping outside familiar ground. That is also the condition of working on a bigger problem. The evidence does not say that AI makes a good engineer faster at what they already do. It says it makes them viable at what they could not previously afford to attempt.

The bank teller precedent

Whether fewer hours per task means fewer engineers depends on something the hours do not tell you: whether the demand for the work is elastic.

The standard case study is the automated teller machine. James Bessen’s account for the IMF documents that between 1988 and 2004 the number of tellers required to run an average urban branch fell from about twenty to about thirteen. A cheaper branch was a branch worth opening, and urban branches increased 43 percent. Total teller employment did not fall through 2010. The task was automated; the occupation grew, because the task had been the bottleneck on how many branches a bank could afford.

The story has a second half that is less often told. After roughly 2010, mobile banking absorbed the transactions the ATM had left to humans, and teller employment has been declining since. Automation expands an occupation while the human still holds the part the machine cannot do, and while there is unmet demand for that part. When both conditions lapse, the expansion ends.

For FPGA engineering the first condition is plainly met today and the second is a matter of observation. Most engineers in this field can name a project that was scoped, judged to need an FPGA, and never started, because the engineering cost did not pencil out against a microcontroller and a compromise. The instrument that needed a custom acquisition path. The network function that was offloaded badly to software because the FPGA team was booked for eighteen months. The small-volume product for which a bitstream was the right answer and six engineer-months was the wrong price. Demand for programmable logic is elastic because its price has been high for forty years.

When the price falls, the number of designs that pencil out rises. That is the positive case — the second boom of the previous post, arriving through the same mechanism as the branch network. The ATM’s second act is the warning attached to it: the expansion lasts as long as the engineer keeps moving toward the part of the work the machine cannot do.

Where the constraint moves

A crude model makes the shift visible.

The output of an engineering group is roughly

problems chosen × rate of execution.

For the entire history of the field, the second term has been the binding constraint. Execution was so expensive that problem selection barely registered as a separate activity. You worked on whatever the schedule handed you, and the schedule handed you whatever could be finished.

When the execution rate rises, the constraint moves to the first term. The question is no longer how fast the design can be built but which design is worth building, and that question turns out to be harder than it looks.

Einstein and Infeld made the point in 1938: formulating a problem is often more essential than solving it, because solving may be only a matter of mathematical or experimental skill, while raising a new question requires imagination. Richard Hamming made it uncomfortable in 1986. His habit at Bell Labs was to sit down at lunch with people from other departments and ask, “What are the important problems of your field?” and then, a week later, ask what they were working on. He was not welcome at that table for long. His observation about colleagues who worked with the office door closed was that they were more productive in the short run and, a decade later, were working on slightly the wrong problems. Not by much. By enough.

Most FPGA engineers have never been allowed to practice the first term. The schedule filled every hour with the second. That is the constraint that is being removed, and it is the most optimistic fact in this essay: for the first time, problem selection is affordable.

Problem finding is a skill, and it has been measured

It is tempting to file “find bigger problems” under inspiration, where it cannot be taught. The research says otherwise, and it is older than most of the tools we use.

In the mid-1960s Jacob Getzels and Mihaly Csikszentmihalyi put a few dozen students from the School of the Art Institute of Chicago in a studio with twenty-seven objects and asked each to produce a still life. Roughly half selected objects quickly and began drawing. The other half spent far longer handling, arranging, and rejecting objects, treating the task as a problem to be formulated rather than a problem to be solved. Independent judges rated the second group’s work as more original. Follow-ups about seven years later, and again roughly eighteen years later, found that the students who had spent the most time formulating the problem were the ones most likely to have sustained careers in art. Many of the quick starters had left the field.

Later work made the mechanism testable. Reiter-Palmon and colleagues gave 195 people six ill-defined, everyday problems and measured their ability to construct a problem definition before solving it. Problem-construction ability predicted both the quality and the originality of the solutions. More usefully, simply instructing people to engage actively in constructing the problem before solving it raised originality, and people with strong construction ability did best when the cues in the situation were diverse and inconsistent. Related work finds that experts engage in more deliberate problem construction than novices do.

The engineering translation is direct. Time spent formulating the problem is not overhead. It is the part of the work that predicts whether the rest was worth doing, and it responds to deliberate practice.

The homogenization risk

There is one finding that should temper the instinct to hand problem selection to the machine as well.

In 2024 Doshi and Hauser ran an experiment in which some writers could request story ideas from a language model. Stories written with the machine’s ideas were rated more creative, better written, and more enjoyable, especially for the least creative writers. They were also measurably more similar to one another than stories written without it. The authors describe the result as a social dilemma: each individual is better off, and the collective produces a narrower range of new work. The BCG experiment reported a similar narrowing in the variety of its consultants’ output.

If every engineer in the field asks the same assistant which problem to work on, the field converges on the same problems. The individual benefit is real and the collective cost is invisible until the interesting niches are empty.

Diversity of problem selection therefore has to come from people with different histories. Hamming’s open door was a mechanism for this; he was borrowing other people’s problems. A practitioner association is the same mechanism at larger scale. This one already spans India, the United Kingdom, the Middle East, and North America, and commercial and defense work, which is to say it already holds a wider distribution of problems than any one employer or any one model. That is not a marketing claim. It is the structural reason an association has something to contribute here that a tool vendor does not.

Imagination is trainable, within limits

The second instinct worth tempering is the belief that creativity training works as well as its vendors say.

The most cited review, by Scott, Leritz, and Mumford in 2004, pooled seventy studies and found an average effect of about 0.64 standard deviations, with the strongest results from programs that taught specific cognitive skills and heuristics through realistic, domain-appropriate exercises rather than from programs aimed at attitude or motivation.

In 2024 Sio and Lortie-Forgues re-examined the field with 169 studies and 844 effect sizes, including a substantial number of unpublished ones. The raw average was 0.53. After four different corrections for publication bias, the estimate fell to between 0.29 and 0.32. Restricting to the nineteen highest-quality studies lowered it further, and only one study in the entire literature had been pre-registered. The one moderator that survived was the same one Scott found: training with cognitive content outperforms training without it.

The fair reading is that problem-finding skill is probably trainable, the effect is modest rather than dramatic, and the measurement is weak. Engineers will recognize the situation. It describes a technique that likely works, supported by a literature that has never been run to the standard the question deserves.

What to do, as an engineer

The practical response follows from the research rather than from optimism.

Reallocate the returned hours on purpose. When a tool gives back the hour you used to spend on scaffolding, the schedule will try to absorb it into more scaffolding. Getzels’s finding is that the time spent formulating is the time that predicts the outcome, so the returned hour should go there, deliberately and on a calendar, before it goes anywhere else.

Write down the problems you have already declined. Every engineer carries a short list of designs that were judged too expensive to attempt. That list is the first place to look, because the cost that disqualified them is the cost that just changed. Hamming’s description of the scientists he admired was that they carried ten or twenty important open problems in mind and tested every new idea that came along against the list. The habit is cheap and the hit rate is not zero.

Ask the question. Hamming’s question is uncomfortable precisely because the answer is usually “not the important ones.” Ask it of colleagues at lunch and of yourself on Monday. Reiter-Palmon’s result suggests the instruction alone has an effect; the act of constructing the problem before solving it improves the solution.

Use the machine for breadth, and verify at the edge. The jagged-frontier result cuts both ways. The tool is strongest where you are weakest, which is exactly where cross-domain problems live, so use it to read into the adjacent discipline you would never have had time for. It is also where it fails without telling you, so the judgment at the boundary stays with the engineer.

Time yourself. The METR developers were confident and wrong. Measure whether a tool is actually faster for you on the work you actually do, and be ready for the answer to differ by task.

The broader point

The previous post closed with the observation that the FPGA may not have needed a better C compiler. It may have needed a machine that could become the FPGA engineer.

That machine is arriving in pieces, and each piece takes a piece of the work. The response that the evidence supports is not to defend the work. It is to notice that the work was never the scarce thing. The scarce thing was always the engineer’s judgment about what was worth building, and for forty years that judgment was rationed by the cost of building it.

The shackles were not the tools. They were the hours the tools consumed. With the hours returning, the instruction is the title.

Solve harder problems.

Sources

  • Siemens EDA / Wilson Research Group, “2024 FPGA Functional Verification Trend Report.” Reports that 87 percent of FPGA projects had non-trivial bug escapes into production. resources.sw.siemens.com
  • Brynjolfsson, Li, and Raymond, “Generative AI at Work,” Quarterly Journal of Economics 140(2), May 2025. 5,172 customer-support agents; 15 percent average productivity gain, concentrated among less experienced workers; small speed gains and small quality declines for the most experienced. academic.oup.com
  • Dell’Acqua et al., “Navigating the Jagged Technological Frontier,” Harvard Business School Working Paper 24-013, September 2023; published in Organization Science, 2025. 758 BCG consultants; 12.2 percent more tasks, 25.1 percent faster, and roughly 40 percent higher quality inside the frontier; 19 percentage points less likely to be correct outside it. papers.ssrn.com
  • Becker, Rush, Barnes, and Rein (METR), “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” July 2025. 16 developers, 246 tasks; 19 percent slowdown with AI allowed, against a forecast 24 percent speedup and a post-hoc belief of 20 percent. arxiv.org
  • METR, “We are Changing our Developer Productivity Experiment Design,” February 24, 2026. Follow-up estimates and the selection-effect caveat. metr.org
  • Bessen, “Toil and Technology,” Finance & Development, International Monetary Fund, March 2015. Tellers per urban branch, the 43 percent increase in urban branches, and teller employment through 2010. imf.org
  • U.S. Bureau of Labor Statistics, Occupational Outlook Handbook, “Tellers.” Documents the decline in teller employment since the early 2010s and projects continued decline. bls.gov
  • Einstein and Infeld, The Evolution of Physics, Cambridge University Press and Simon & Schuster, 1938. The passage on the formulation of a problem. archive.org
  • Hamming, “You and Your Research,” Bell Communications Research Colloquium, March 7, 1986. Transcript. cs.virginia.edu
  • Getzels and Csikszentmihalyi, The Creative Vision: A Longitudinal Study of Problem Finding in Art, Wiley, 1976. The still-life study and the first follow-up; the eighteen-year follow-up is reported in Csikszentmihalyi’s later work. books.google.com
  • Reiter-Palmon, Mumford, O’Connor Boes, and Runco, “Problem Construction and Creativity: The Role of Ability, Cue Consistency, and Active Processing,” Creativity Research Journal 10(1), 1997. tandfonline.com
  • Doshi and Hauser, “Generative AI enhances individual creativity but reduces the collective diversity of novel content,” Science Advances 10(28), July 2024. science.org
  • Scott, Leritz, and Mumford, “The Effectiveness of Creativity Training: A Quantitative Review,” Creativity Research Journal 16(4), 2004. 70 studies; effect size and moderators. doi.org
  • Sio and Lortie-Forgues, “The Impact of Creativity Training on Creative Performance: A Meta-Analytic Review and Critical Evaluation of Five Decades of Creativity Training Studies,” Psychological Bulletin 150(5), 2024. 169 studies, 844 effect sizes; bias-adjusted estimates. doi.org