AI Future Fridays: Everyone Gets to Make the Tool They Need

Welcome to AI Future Fridays. Every week this column takes one force shaping the near future, tells you the truth about it, and hands you something to build before Monday. This week's force is authorship: software is becoming something people make for themselves, the way they've always made spreadsheets and jigs and index cards.

Here's what makes this moment different from every other "anyone can code" promise. The promise used to be that you'd learn to think like an engineer. That was the toll booth, and most people drove past it. What changed is that the tools learned to meet people where they already are, in plain sentences about plain problems, and the first crowd through the gate wasn't junior developers. It was the operations manager with nine years of workarounds and a very specific complaint about one missing button.

The Signal From People Building Their Own Software at Work

The tell isn't the impressive builds. It's how boring the useful ones are.

When Lenny Rachitsky asked his audience what they'd made with AI coding tools, he got more than a thousand replies inside a day, and the roundup that came out of it reads less like a product showcase than a list of small indignities finally dealt with. Rob Balderstone built a randomizer that picks who speaks first at standup. Kevin Kirkpatrick built himself a tracker for work accomplishments, because the annual review always arrives with ten months of wins already forgotten. Olena Vozna shipped a browser extension that handles the dance of sending someone your availability. Marissa Goldberg automated her own meeting prep. You can read the whole list in Lenny's Newsletter roundup of what people are building, and the pattern holds all the way down.

None of that is a startup. All of it is a Tuesday that got shorter.

The named scene that stuck with us came from outside tech entirely. In February 2026, Liz Plosser, who ran Women's Health as editor in chief and has never worked as a programmer, sat down and built a working wellness app, then published the whole messy account of it as I Vibe Coded a Wellness App on her newsletter. She didn't hire anyone. She didn't learn a language. She described what she wanted, argued with a model about it, and ended the week holding software she'd made. Ten years ago that sentence required a budget and a roadmap and somebody else's priorities.

The Backstory of End User Programming, From VisiCalc to Vibe Coding

The myth worth killing first: that programming has ever belonged to programmers. It hasn't, not for a single decade of the personal computer's existence.

In 1979 VisiCalc landed on the Apple II and handed millions of accountants a programming environment, which nobody called a programming environment because it had rows in it. HyperCard shipped with every Mac in 1987 and a generation of teachers, librarians and museum staff built real applications in it without once describing themselves as developers. Then came Excel macros, Access databases, SharePoint lists, and eventually the whole low-code industry, every wave arriving with the same two reactions: delight from the people doing the work, and a nervous memo from IT.

• 1979: VisiCalc makes the spreadsheet the most-used programming tool on earth, under a different name.
• 1987: HyperCard puts application-building in the hands of anyone with a Mac and an idea.
• 1993 onward: Excel macros and Access quietly run entire departments, usually built by one person who then can't take a vacation.
• 2010s: Low-code platforms sell the same promise with a license fee and a governance committee.
• February 2025: Andrej Karpathy names the new version of the old habit, and the term vibe coding goes from a single post to Collins Dictionary's word of the year inside ten months.

So the shift isn't that ordinary people started building software. It's that the ceiling moved. A spreadsheet could model your problem but it couldn't send an email at 6am, watch a page for changes, or hold a login. The jump from a formula to a running program used to be the exact point where a person had to either learn to code or go find somebody who had. That jump is what collapsed, and if you want the practical version of how it collapsed, our guide on how to vibe code walks the whole loop.

Which also explains why the first builds are so unglamorous. People aren't dreaming up new categories of software. They're finishing things they started years ago in a sheet and hit a wall on, which is why so much of this begins in a spreadsheet somebody outgrew and ends as something with a schedule attached.

The Countermove: Build the One Tool Your Week Is Missing

The street finds its own uses for things, and the use here is almost rudely simple. You don't need a product idea. You need the one piece of software nobody was ever going to build for you, because you're the only person on earth who needs it.

Start by getting specific about the complaint. Most people can't name their missing button, because they stopped noticing the workaround around year two. So go find it in your own calendar instead. Look at last week and mark every block of time you spent moving information from one place to another without making a single decision. That's the shortlist. The winner is whichever one you'd be relieved to never do again.

• Describe the Tuesday, not the tool. Say "every Tuesday I open these three things, copy these numbers into that sheet, and email whoever is behind." Don't say "build me a dashboard." The agent is better at designing the thing than you are, and worse at guessing your week.
• Keep the first version ugly. One screen, one job, no login, no styling. Ugly ships, and ugly is also easy to throw away, which you'll want to do twice before you get it right.
• Write down the steps you take now. Your existing manual process is the specification, and it's a better one than anything you'd invent from scratch. If you want the disciplined version of this, read how to write a workflow spec before you start prompting.
• Decide where it lives before you build it. A tool on your laptop is a demo. A tool that runs on a schedule somewhere you don't have to think about it is infrastructure, and the difference is about ten minutes of setup.
• Give it a mouth. It should tell you what it did, and say something loudly when it fails. Silent tools rot without anyone noticing.

Then there's the version of this that doesn't involve building software at all, which is honestly where most people should start. A lot of "I need a tool" turns out to be "I need this to happen every Monday without me," and that's an agent with a schedule rather than an app with a screen. We keep a directory of those at the agent workflow directory, and the recurring ones are the single highest-value thing a non-developer can set up this weekend. Build the app when the agent genuinely can't do it.

Whatever you make, the test of a good first build is whether it survives contact with your actual next week. Not whether it's clever. Not whether anyone else would want it. Whether, next Tuesday, the thing you used to do by hand quietly happened without you.

The Fine Print on AI Generated Code Security and Maintenance

Now the part the enthusiasm usually skips, because the optimism in this column is only worth anything if it survives the numbers.

The code these tools write is frequently insecure. In its 2025 GenAI Code Security Report, Veracode tested 80 coding tasks across more than 100 large language models and found that about 45 percent of the generated code introduced a security vulnerability. The models have gotten markedly better at writing code that runs and barely better at writing code that's safe, and those are different skills that improve on different curves. Professional developers know this and behave accordingly: Sonar's 2026 State of Code survey of more than 1,100 developers found 96 percent don't fully trust AI-written code, while only 48 percent always verify it before committing. That gap between what people believe and what people check is where the trouble lives.

What that means in practice is a clean line, and it's worth drawing it for yourself before you build:

• Fine: a tool only you use, holding information you'd be comfortable emailing to yourself, with no public address and no sign-in page.
• Careful: anything your team uses, anything that connects to a system of record, anything with a password box.
• Not yours to ship: customer records, payment details, health information, anything with a login that strangers can reach. That needs somebody who reviews code for a living, and no prompt substitutes for that.

The second cost is quieter and catches more people. The tool you build is now yours to keep alive. Anything that reads another system will eventually meet a redesign, and the classic end-user-programming tragedy is the brilliant macro nobody can repair after its author leaves. That's a solvable problem now rather than a fatal one, which we covered in the edition on automations that repair themselves, but solvable still means you have to do the solving. Keep a one-paragraph note of what the thing does and which accounts it touches. Future you will need it, probably on a bad day.

The Forecast for Building Your Own Software Through 2027

The honest read on the next eighteen months is that the composition of "people who build software" changes faster than the total number of them.

Hostinger's own usage data puts it starkly: 63 percent of people using vibe coding and AI app builders have no coding background, and the company's own builder crossed a million users inside its first year. On the professional side, the Sonar survey has developers reporting that 42 percent of what they commit is already AI-generated or AI-assisted, with an expectation of 65 percent by 2027. Read those two numbers side by side and the picture isn't engineers being replaced. It's the definition of the job splitting in two, with review and judgment moving to the center of the professional half while the amateur half grows a new wing entirely.

The part most Western coverage misses is where the growth is loudest. In IDC research sponsored by OutSystems on low-code and generative AI adoption across Asia Pacific, 49 percent of organizations in Southeast Asia and Hong Kong called low-code critical to automation and future-proofing, against 31 percent in Australia. The places with the thinnest supply of hireable senior engineers are the places adopting fastest, which is exactly what you'd predict and exactly the opposite of how this story usually gets told.

The next wave of software won't be written by more developers. It'll be written by the people who were already doing the work, in the gaps where no developer was ever coming.

Three things we'd bet on by mid-2027. First, the ugly personal tool becomes an ordinary artifact of office life, the way a shared sheet with automation bolted on is now, with all the same governance headaches. Second, the serious fights move to maintenance and data, not creation, because making the thing stopped being the hard part. Third, someone sells a weekend build to an employer who then can't maintain it, and that story gets written up as a cautionary tale when the real lesson is that nobody told the builder where the line was.

The Horizon for Software You Write Yourself

Proportion first, because the honesty is what earns the rest. Nobody will look back on this decade and grade it on how many people learned to ship a web app. It gets graded on whether we ended the wars, stopped the genocides, and turned the warming around, and a homemade tracker doesn't outrank any one of those. Authorship isn't a cause. It's leverage, and what people do with leverage is the only part that matters.

But leverage has never been nothing. For most of computing's history, the person who understood a problem best had the least power to fix it, and the person with the power to fix it had to have the problem explained to them, badly, through a ticket, in a quarter that was already full. Every workaround you've ever built by hand is a small monument to that arrangement. Closing the distance between understanding a problem and fixing it gives something back to warehouse pickers, shop stewards, nurses, organizers and clerks that no productivity statistic captures, which is the ability to make the thing you need without asking.

One line belongs in an edition like this. A tool you build for your own work is not the same invention as a tool built to watch other people's. The moment a homemade app starts counting your coworkers' keystrokes or scoring your neighbors, it has stopped being authorship and become something with bars on it, and the fact that a non-developer built it makes that worse rather than charming. Build for the work in front of you. Never build a cage, however small and well-intentioned the first version looks.

And then the future worth wanting, which is smaller than it sounds. A florist in Tacoma has a delivery run sheet now. It isn't pretty: one page, white background, a list that sorts itself by neighborhood and flags the two addresses where the buzzer never works. She built it in an evening after nine years of writing the same list on the back of an order pad, and she built it in the first place because nobody was ever going to make delivery software for a shop with one van. On a Saturday in June she'll hand it to whoever's driving the van, and they'll never know that for most of the history of software, a tool that specific, for a problem that small, belonging to a person that ordinary, simply did not get made. That's the whole thing. Not a revolution. A page that sorts itself, finally, for the person who needed it.

Before Monday: Your Build Your Own Tool Checklist

You've got a weekend and the barrier is lower than it's been in your working life. Here's how to spend a couple of hours of it.

1. Audit last week for dead time. Open your calendar and mark every block you spent moving information between places without making a decision. Five minutes, and the list will surprise you.
2. Pick the one you'd be relieved to lose. Not the biggest. The most repetitive, the one with the clearest start and finish.
3. Write the manual steps down in order. Plain sentences, the way you'd explain it to a new hire. This is your spec, and it's the single biggest factor in whether what you get back works.
4. Ask for the smallest working version. One screen, one job. Refuse the extra features it offers you on the first pass.
5. Draw your own data line before you paste anything. Decide now what never goes into this tool: customer records, card details, anything with a password. Write that down next to the spec.
6. Put it somewhere it keeps running. If it needs to happen on a schedule, set it up as a recurring job rather than something you remember to open.
7. Use it once for real, on Monday. Then fix the one thing that annoyed you. Two rounds of that and you'll have something you keep.

Frequently Asked Questions

• Can you really build software with AI if you have never coded?+
  Yes, for small tools, and that's where most of the real use is. Hostinger reports that 63 percent of people using vibe coding and AI app builders have no coding background, and the things they ship are modest by design: a tracker, a form, a one-page internal tool. The skill that carries over isn't syntax, it's describing a process precisely, which is the same skill behind no-code AI automation generally.
• Is AI-generated code safe to use at work?+
  Treat it as unreviewed code, because that's what it is. Veracode's 2025 GenAI Code Security Report found that roughly 45 percent of AI-generated code introduced a security vulnerability across 80 coding tasks and more than 100 models. For a personal tool with no customer data and no public login, the risk is yours alone and usually small. The moment real customer records, payments or sign-ins are involved, it needs a person who reviews code for a living.
• What should I build first?+
  Build the thing you already do by hand every week, not the idea you think is clever. The best first builds are embarrassingly small: a sheet that reformats itself, a checklist that knows today's date, a page that shows one number. Pick the task you'd be relieved to never do again, write down the steps you take now, and have the agent build exactly that. What we learned building BYOBot covers why the small scope wins.
• Will the tool I build still work in six months?+
  Only if you plan for that from the start. Anything that reads another system can break when that system changes, which is why the tools that survive are the ones that run somewhere permanent, log what they did, and tell you when they fail instead of failing silently. Keep a short note of what it does and which accounts it touches, and you'll be able to fix or rebuild it in an afternoon.