DEV Community: Jerry Schneider

Software Is Entering Its IKEA Era

Jerry Schneider — Sat, 28 Mar 2026 01:45:19 +0000

Every few days, someone confidently declares that AI is about to wipe out software engineering.

I don't buy that.

I think software is much closer to woodworking than people realize.

Before industrialization, furniture was made by hand. If you wanted a table, a chair, a cabinet, or a bed frame, you needed a skilled craftsperson. The work took years of training. It was slow, specialized, and expensive. Good furniture was not broadly accessible because it could not be. Every piece required real human expertise, and that expertise did not scale cheaply.

Then industrialization happened.

The craft of making furniture did not disappear. It changed.

Machines, standardization, and repeatable manufacturing processes made it possible to produce furniture at much larger scale and much lower cost. The average quality was often lower than what a master craftsperson could produce by hand, but that was only part of the story. The bigger change was that an entirely new market opened up. Furniture became accessible to far more people. Businesses like IKEA could exist. A thing that once required expert labor for every unit could now be produced in enormous volume by a system.

Handmade furniture did not go away. There is still a market for beautiful, custom, ultra-high-quality work. But the center of gravity changed. Some artisans were displaced. Some adapted. Some moved further upmarket. And alongside all of that, a much larger market for cheaper, faster, more standardized output came into existence.

I think software is going to follow a very similar path.

Software Has Been Craft Work for a Long Time

For most of its history, building software has looked a lot like skilled handcraft.

You needed people with deep, specific knowledge. You needed years of training. You needed teams of specialists who could translate ambiguous human needs into precise technical systems. Every meaningful piece of software required a large amount of manual effort from people who knew what they were doing.

That made software powerful, but it also made it expensive. There are countless products, automations, internal tools, and business ideas that never got built, not because they were bad ideas, but because the cost of making software was too high. The custom work involved was too specialized. The economics did not work.

AI Lowers the Cost of Production

AI is making it cheaper and faster to produce software that is good enough for many use cases. Not perfect. Not elegant. Not deeply original. But good enough.

There are companies that will now build internal tools they never would have funded before. There are small businesses that will buy software they could never previously afford. There are workflows that stayed manual for years because no one was going to assign a full engineering team to automate them. There are product ideas that used to die in a spreadsheet that may now become viable.

The important question is not just whether AI can replace some portion of current engineering labor. The important question is what happens when software itself becomes far more manufacturable.

When that happens, you don't just get substitution. You get expansion.

You get more software.

And Yes, a Lot of It Will Be the IKEA Version

Good enough code that is customizable enough for most applications.

When you industrialize a craft, you get standardization. You get lower costs. You get accessibility. You also get a lot more average output.

Some of it will be flimsy.

Some of it will be ugly.

Some of it will work surprisingly well for the price.

Some of it will be disposable.

Some of it will be “good enough” in exactly the way the buyer needed.

There will absolutely be a flood of mediocre AI-assisted software. There will be overconfident companies, sloppy implementations, badly framed cost-cutting strategies, and executives who mistake faster production for complete replacement of judgment. There will be chaos, overcorrection, and a lot of noise.

Some people will be displaced. Some categories of work will shrink. Some tasks that used to justify a full human workflow will get compressed into something smaller.

That is not the same thing as saying software engineering jobs disappear. It means the structure of the market changes.

Industrialization Changes the Work Before It Eliminates It

People talk as if the only possibilities are: either software engineering remains exactly what it has been, or it vanishes, but that is usually not what happens to crafts or professions.

The tools change first.

Then the workflow changes.

Then the expectations change.

Then the skill mix changes.

Eventually, the job title survives while the actual work looks very different.

Software engineers may spend less time manually producing obvious code and more time shaping systems. Less time writing boilerplate and more time defining constraints. Less time assembling known patterns by hand and more time evaluating tradeoffs, validating outputs, debugging weird behavior, understanding real user needs, and deciding what quality means in context.

That is still engineering. In some ways, it is more engineering and less typing.

High-Craft Software Will Still Exist

Even after industrialization, handmade furniture did not become pointless, it became differentiated.

If you want something deeply customized, unusually durable, aesthetically excellent, or built around exact needs, you still want real craftsmanship. In fact, the abundance of cheap mass-produced alternatives can make true quality stand out more, not less.

I think the same thing will happen in software.

There will still be demand for systems that are reliable, maintainable, secure, deeply integrated, and thoughtfully designed. There will still be software where correctness matters. There will still be edge cases, constraints, and human realities that don't fit cleanly into standardized generation.

When code becomes easier to generate, discernment becomes more valuable. When anyone can produce output, the differentiator shifts toward knowing what should be built, how it should be shaped, where the risks are, what corners cannot be cut, and what makes something actually good.

The Bigger Story Is Market Expansion

One reason I am skeptical of the “all jobs go away” framing is that it assumes the size of the software market stays basically fixed. I don't think it will.

When making something gets cheaper, people don't merely buy the old amount for less money. They start buying things that previously were not worth buying at all.

Cheap furniture did not just replace expensive furniture. It furnished more homes.

AI-generated and AI-assisted software will not just compete with existing software teams. It will also create a much larger market for software in places where custom development was previously too expensive, too slow, or too inaccessible.

Some of the work will move downward into highly standardized production. Some of it will move upward into higher-leverage oversight, architecture, integration, and quality. Some entirely new categories of work will appear because the economics now support them.

That seems much more plausible to me than “software engineering stops existing.”

I’ve Heard This Story Before

My dad worked in television for about forty years. He started in the late 1970s, right as one era was ending and another was beginning. The first great golden age of television was fading, and cable was rising into what you could probably call a second golden age.

For a long time, the industry changed less than people might expect. The scale grew. Availability exploded. More channels, more content, more reach. But the basic operating model and economics stayed recognizable. Television was still television. Prime time still mattered. The machinery of the industry still made sense to the people inside it.

Then the 2010s happened.

Streaming did not just compete with network and cable television. It reorganized the entire landscape. Very quickly, the old structure stopped being the center of gravity. The audience changed. The business model changed. Distribution changed. Viewing habits changed. Many of the jobs my dad did over the course of his career simply do not exist anymore.

The industry did not die, it transformed into something that most people inside it probably could not have fully envisioned until after it happened.

Johnny Carson was eventually followed by Letterman, Leno, Conan, and then a parade of Jimmys. But even that version of the industry turned out not to be permanent. It was gradually overtaken by something far more fragmented: MrBeast, the Paul brothers, YouTubers, Twitch streamers, podcasters, TikTok creators, and countless internet-native personalities who built audiences outside the old system entirely. The old model was not replaced by a new host. It was replaced by a new landscape.

My dad jokes that prime time is what paid for his retirement, and I think that line captures a lot. That whole world was real. It was massive. It shaped careers, businesses, and lives. It also largely does not exist anymore in the form that once felt permanent.

That does not mean television ended. There is more video content than ever. More ways to watch it. More creators. More distribution. More total output. But the old structure was not preserved just because it had once seemed foundational. It was replaced by a new one.

I think software may be heading for a similar kind of shift.

For People Who Love Solving Problems, This Could Be a Golden Age

A lot of programmers don't actually love typing code for its own sake, they love solving problems.

They love understanding systems. They love building tools. They love making messy things clean. They love turning ambiguity into structure. They love the feeling of gaining leverage over a problem that looked impossible a few hours ago. That part is not going away.

The problems are changing. The tools are changing. The constraints are changing. The surface area of what one person can build is changing. For people who do this for the love of the game, that is exciting because everything will be in motion.

There will be new abstractions, new workflows, new product categories, new expectations, and new kinds of technical judgment. There will be new opportunities to build things that were previously out of reach. There will be a massive amount of room for experimentation.

If you like problem solving more than you like protecting old workflows, this moment is full of possibilities.

The Transition Will Be Messy

Industrialization is disruptive.

There will be companies that overcorrect badly. There will be teams that are reduced too aggressively. There will be low-quality software shipped at scale because someone decided speed mattered more than understanding. There will be a period where many people are asked to operate in systems that have changed faster than the norms around them.

If your current job is mostly composed of work that is easy to standardize, I don't think denial is a useful response. The market is changing. Pretending otherwise will not help. The better response, at least to me, is adaptation.

Learn the tools.

Understand the new economics.

Move toward the parts of the work where judgment matters.

Get better at problem framing, system design, evaluation, communication, and taste.

Become the person who can work with the new machinery without mistaking it for magic.

That seems like a far more grounded response than mourning a version of the craft that was never going to stay frozen in time.

Some jobs will shrink. Some will disappear. Some will be reborn in altered forms. Entire new layers of software work will appear. New tools will create new expectations. New economics will produce software that would never have existed under the old model. And a lot of what feels central today may someday feel like prime time television: once dominant, deeply real, and eventually no longer the thing that anchors the industry.

If your goal is to keep building, keep learning, and keep solving interesting problems, it might be the most interesting moment the field has seen in a very long time.

The craft of making software is not disappearing. But like every craft touched by new machinery, new economics, and new distribution, it is going to change shape.

Some people will spend too much energy mourning that.

I would rather spend mine learning the new tools and exploring what becomes possible next.

The Problem With `git add .`

Jerry Schneider — Tue, 24 Mar 2026 03:04:20 +0000

When I first learned I could run:

git add .

Instead of adding files one at a time, I felt like I had discovered some secret Git trick.

No more:

git add file1
git add file2
git add file3

Just stage everything and move on.

And honestly, for a while, that was an upgrade. It removed friction. It made committing faster. It felt like the kind of thing that separated people who were comfortable in Git from people who were still fumbling through it.

But like a lot of “smart” shortcuts, it worked best right up until real life got involved.

Sometimes I had a tmp file sitting around and committed it by accident.

Sometimes I had changes I liked in one file and changes I definitely did not like in another.

Sometimes I forgot to switch branches before starting a new ticket and ended up with a mix of unrelated edits.

And lately, with more AI-assisted coding tools in the mix, I’ve ended up with even more repo noise than I used to. Cursor in particular is great at helping me think and explore, but it also tends to leave behind markdown files and other artifacts that are useful while I’m working and absolutely not something I want in a commit.

That was the point where git add . stopped feeling smart.

The problem wasn’t that Git was bad. The problem was that git add . assumes everything in your working tree belongs together. And a lot of the time, that’s just not true.

Real Work Is Messy (for me at least, maybe you're different)

In theory, a commit is supposed to represent one coherent idea.

In practice, a working tree often looks more like this:

one file with the actual fix
one file with a failed attempted fix
one file with a cleanup you’re not sure you want
one file you edited while debugging
one random note or markdown file created during exploration
one change that really belongs on another branch entirely

How often does your working tree actually contain just one coherent change?

You can deal with that using standard Git commands. You can manually add files one by one. You can use patch mode. You can keep opening git status and re-reading the same list over and over until you convince yourself you know what should be staged.

I’ve done all of that.

But in a normal day of development, the issue usually is not “is this possible in Git?” The issue is “what is the lowest-friction way to do the right thing?”

That is the bar I care about.

Because if the right thing is annoying, I am much more likely to do the easy thing.

And for a long time, the easy thing was git add ..

What I Actually Wanted

I didn’t need some giant Git UI.

I wanted a very small workflow improvement:

show me the files that matter
let me inspect them one at a time
let me stage only the ones I want
make the whole thing fast enough that I’ll actually use it

That was it.

So I wrote a tiny add function for my dotfiles.

It uses git status --porcelain to collect files that need attention, pipes them into fzf, gives me a preview for whatever file is currently selected, and then stages only the files I choose.

That sounds simple because it is simple. But it ended up changing my workflow more than I expected.

The Function

Here’s the function from my dotfiles:

function add() {
  # Get files that need to be staged during rebase
  # This includes: unmerged paths (conflicts), modified files, new files, etc.
  local files
  files=$(git status --porcelain | grep -E '^(UU|AA|DD|AU|UA|DU|UD)' | sed 's/^...//')

  # If no merge conflicts, check for regular unstaged files
  # Include MM (staged but edited again), M (modified), D (deleted), and ?? (untracked)
  if [[ -z "$files" ]]; then
    files=$(git status --porcelain | grep -E '^MM |^ M |^ D |^D |^\?\?' | sed 's/^...//')
  fi

  # Sort and remove duplicates
  files=$(printf '%s\n' "$files" | sort -u)

  if [[ -z "$files" ]]; then
    echo "No files need to be staged."
    return 0
  fi

  # Use fzf to select files with appropriate preview
  local selected_files
  selected_files=$(printf '%s\n' "$files" | fzf -m \
    --header='Select files to stage (Tab: multi-select, Enter: confirm)' \
    --preview 'cd $(git rev-parse --show-toplevel) && {
      file={};
      status=$(git status --porcelain "$file" 2>/dev/null | cut -c1-2);

      if echo "$status" | grep -q "??"; then
        # New file: show contents in green
        while IFS= read -r line || [ -n "$line" ]; do
          printf "\x1b[32m%s\x1b[0m\n" "$line";
        done < "$file" 2>/dev/null

      elif echo "$status" | grep -qE " D|D "; then
        # Deleted file: show contents in red from HEAD
        git show HEAD:"$file" 2>/dev/null | while IFS= read -r line || [ -n "$line" ]; do
          printf "\x1b[31m%s\x1b[0m\n" "$line";
        done

      else
        # Modified file: show diff
        git diff --color=always "$file" 2>/dev/null ||
        git diff --cached --color=always "$file" 2>/dev/null ||
        echo "Binary file or no changes"
      fi
    }' \
    --preview-window=right:60%:wrap)

  if [[ -n "$selected_files" ]]; then
    # Convert newlines to array and add each file
    while IFS= read -r file; do
      (
        cd $(git rev-parse --show-toplevel) &&
        [[ -n "$file" ]] &&
        git add "$file" &&
        echo "Staged: $file"
      )
    done <<< "$selected_files"
  fi
}

It is just a focused wrapper around one very common decision: which files should go into this commit?

Why This Feels Better Than `git status` + `git add`

Instead of treating git add as the mechanical thing I do before git commit, I use it as a first review of the changes themselves.

I can move through the list file by file and immediately see:

yes, this belongs
no, that was an experiment
that markdown file is just tooling noise
this file is from a different line of work and should stay out
this one needs a second look before I stage it

That sounds minor, but it changes the feel of the whole workflow.

A normal git status gives you a list.

This enables intention.

A Few Details That Make It Great

What makes this more useful than a generic fzf wrapper is that it is opinionated in the right places.

If I’m in the middle of a rebase, it surfaces conflicted files first. It also catches easy-to-miss states like files that were staged and then edited again. And the preview adapts to the file: file contents for new files, file contents from HEAD for deleted files, diff for modified files.

That means I’m not staging based on filenames and vague recollection. I’m staging based on the actual code changes.

Why AI Makes This Matter More

I think this kind of workflow matters more now than it did a few years ago.

AI coding tools are genuinely useful, but they also make it much easier to generate clutter. Scratch markdown files. notes-to-self. temporary planning documents. throwaway code paths. files that were useful during exploration but were never meant to become part of the final change.

That is not really a criticism. It is just a side effect of a more exploratory workflow.

The more your tools help you branch out while thinking, the more you need a clean way to narrow back down before committing.

That is where selective staging becomes more important.

Not because the repo is huge.

Not because Git got harder.

Just because the path from “working” to “ready to commit” now tends to produce more debris.

The Branch Mistake Case

One of the most common real-world cases for this is embarrassingly simple:

I start changing files before I switch branches.

Now I have some work that belongs to the new ticket and some work that definitely does not.

Could I stash things? Sure.

Could I do some more elaborate cleanup? Of course.

But sometimes the fastest route is just being able to stage exactly the files that belong to the commit I’m making right now.

It gets me out of a very normal mess efficiently.

This Made Me Commit More Often

The most important effect of this function is not that it helps me avoid bad commits.

It is that it lowers the cost of good commits.

When I know I can quickly inspect what changed, skip the junk, and stage only the relevant files, I feel much less resistance to committing early.

“Commit early and often” is one of those bits of advice that is obviously correct and weirdly hard to follow in practice.

The reason it is hard is not philosophical. It is usually just friction.

If every commit feels like I have to manually sort through a pile of ambiguous changes, I am more likely to wait.

If I wait, the pile gets bigger.

If the pile gets bigger, the commit gets messier.

If the commit gets messier, I wait even longer.

This function helps break that cycle.

When committing becomes cheap again, git history gets cleaner almost automatically.

Small Shell Improvements Compound

I like this kind of shell customization because it solves a very specific annoyance without introducing much complexity.

It's a tiny tool that makes one repeated decision easier.

That is the sweet spot I keep coming back to in my dotfiles.

The reason I like little workflow tools like this is not that they are clever. It is that they can quietly change your defaults.

Most of the time, the gap between a sloppy workflow and a clean one is not knowledge. It is friction.

If the better path asks for more effort, the shortcut usually wins.

If you can remove enough friction that the better path becomes the simpler one, your habits improve almost by accident.

That is what this function did for me. It made a careful commit easier to make than a careless one.

And that is usually when the right choice starts winning without a fight.

How I Made fzf Feel Snappy Again in Large Repositories

Jerry Schneider — Sat, 21 Mar 2026 02:59:59 +0000

Most of the time when I’m working in the terminal, I’m navigating files. Usually that looks like some combination of:

cd
ls
find
grep

Which works fine… until a project gets large. Then it turns into:

cd src
ls
cd components
ls
cd something
find . -iname something

I wanted something closer to Ctrl+P in an editor. A quick fuzzy search that lets me jump to files or directories instantly. So I added a small function to my .bashrc that lets me browse the filesystem with fzf like a tiny interactive file browser:

fuzzy search files and directories
preview files
preview directory contents
open files in $EDITOR
cd into directories

The Function

Here’s the function from my dotfiles.

# Browse files and directories with fzf - cd to directories, open files with $EDITOR
function browse() {
 command -v fzf >/dev/null || { echo "fzf not found" >&2; return 1; }

 local selection fifo="/tmp/browse_$$"

 # Create named pipe
 mkfifo "$fifo"

 # Run find (or fd if available) in background, writing to named pipe (suppress job control)
 if command -v fd >/dev/null 2>&1; then
   { fd -H -t f -t d . > "$fifo"; } &
 else
   { (find . -type f -o -type d 2>/dev/null | sed 's|^\./||') > "$fifo"; } &
 fi
 local find_pid=$!

 # Run fzf reading from named pipe
 selection=$(fzf ${1:+-q "$1"} --preview 'if [[ -d {} ]]; then ls -la {}; else bat --style=numbers --color=always --line-range :50 {} 2>/dev/null || cat {} 2>/dev/null || echo "Cannot preview file"; fi' < "$fifo")
 local exit_code=$?

 # Kill background process and cleanup (suppress all output)
 kill $find_pid >/dev/null 2>&1
 wait $find_pid >/dev/null 2>&1
 rm -f "$fifo"

 [[ $exit_code -ne 0 ]] && return $exit_code

 [[ -z "$selection" ]] && return

 if [[ -d "$selection" ]]; then
   builtin cd "$selection"
 elif [[ -f "$selection" ]]; then
   ${EDITOR:-vim} "$selection"
 else
   echo "Selection is neither a file nor a directory: $selection" >&2
   return 1
 fi
}

Now I can run:

browse

or even:

browse bash

And instantly fuzzy-search everything under the current directory.

Streaming Results to `fzf` with a Named Pipe

This is the most interesting part.

Instead of running find first and piping into fzf, the function uses a named pipe.

mkfifo "$fifo"

Then find (or fd for better performance) runs in the background writing results into the pipe:

fd ... > "$fifo" &

And fzf reads from the pipe:

fzf < "$fifo"

This means:
fzf can start immediately while results are still being discovered. For large directories this feels much faster and allows you to make a selection before find completes.

Binding the Function Directly in Bash

Instead of triggering browse by injecting a command into the prompt, I prefer binding it directly to a key in Bash.

Here’s the helper I use:

## Bindings ##
bind_bash_function() {
 local key="$1"
 local fn="$2"
 local wrapper="__bind_${fn//[^a-zA-Z0-9_]/_}"

 eval "
$wrapper() {
 local __line=\$READLINE_LINE
 local __point=\$READLINE_POINT

 $fn

 READLINE_LINE=\$__line
 READLINE_POINT=\$__point
}
"

 bind -m emacs-standard -x "\"$key\": $wrapper"
 bind -m vi-insert      -x "\"$key\": $wrapper"
}

bind_bash_function '\C-f' browse

This binds Ctrl+F directly to the browse function.
The small wrapper saves the current command line (READLINE_LINE and cursor position), runs the function, and then restores the line afterwards. That way the binding behaves more like a temporary tool: it runs, does its work, and then returns you to exactly the same prompt state you were in before.

This makes the interaction feel much smoother, especially if you trigger it while you’re in the middle of typing a command. The helper also binds the key for both Emacs-style and vi-style editing modes so the behavior stays consistent regardless of the editing mode in use.

Why I Prefer This Over Other Tools

There are plenty of file navigation tools out there, but I like this approach because it stays simple and fits naturally into my shell. It:

lives entirely in my .bashrc
only depends on fzf (and bat if you want color)
can be bound directly to a key like Ctrl+F
returns you to exactly the same command line after it runs

Binding it directly to a key makes it feel less like a command I have to remember and more like a built-in capability of the shell. It’s just a small shell upgrade, but it removes a surprising amount of friction from everyday workflows.

Small Shell Improvements Compound

I treat my dotfiles like a collection of tiny productivity improvements. Each one only saves a few seconds, but when you run thousands of shell commands every week, those seconds add up. This browse function ended up being one of my favorites.

DEV Community: Jerry Schneider

Software Is Entering Its IKEA Era

Software Has Been Craft Work for a Long Time

AI Lowers the Cost of Production

And Yes, a Lot of It Will Be the IKEA Version

Industrialization Changes the Work Before It Eliminates It

High-Craft Software Will Still Exist

The Bigger Story Is Market Expansion

I’ve Heard This Story Before

For People Who Love Solving Problems, This Could Be a Golden Age

The Transition Will Be Messy

The Problem With `git add .`

Real Work Is Messy (for me at least, maybe you're different)

What I Actually Wanted

The Function

Why This Feels Better Than git status + git add

A Few Details That Make It Great

Why AI Makes This Matter More

The Branch Mistake Case

This Made Me Commit More Often

Small Shell Improvements Compound

How I Made fzf Feel Snappy Again in Large Repositories

The Function

Streaming Results to fzf with a Named Pipe

Binding the Function Directly in Bash

Why I Prefer This Over Other Tools

Small Shell Improvements Compound

Why This Feels Better Than `git status` + `git add`

Streaming Results to `fzf` with a Named Pipe