A field guide for the knowledge worker still living the co-work life: why AI coding is no longer just for software engineers, three build patterns and four delivery classes for thinking about what to make, and six starter projects to find the parts of your job that have software-shaped solutions.
Building software for your own work is now a foundational knowledge-worker skill.
The argument isn't that you should become your organization's software engineer — it's that the people who build are compounding their gains over everyone else, and the barriers you assume are stopping you are mostly gone. The catch: until you start, it's nearly impossible to see which of your work problems actually have software-shaped solutions. So this episode maps the territory — three build patterns, four delivery classes, six categories of work, six starter projects — and then tells you to just go build something.
As Lovable, Replit, Claude Code, and Codex came online, knowledge workers outside engineering started using code to solve their own problems. This isn't non-engineers playing engineer — it's finding new ways to do their existing jobs with software they build themselves.
NLW describes a parent from his town: multiple expensive AI subscriptions, years of AI-assisted work — and AI coding still feels totally foreign. Living the co-work life without ever venturing into Claude Code territory now genuinely leaves knowledge workers behind.
Per OpenAI's recent enterprise research covered earlier this week, around late April/early May the percentage of tokens consumed agentically via API flipped past tokens used non-agentically through ChatGPT, and the number has done nothing but rise since.
Firms in the top 10% of enterprise AI users consume about 8.3 times as much AI as average firms — up from a 2.6× gap in January — and their use cases are far more sophisticated, reaching into systems and overall disruption. Builders are compounding their advantages.
From a February baseline, engineering's enterprise Codex usage grew 5×. Every other function grew more: finance and accounting 20×, sales 41×, and legal a staggering 108×. AI coding in the enterprise is no longer an engineering story.
The early-days assumption was that non-engineers would suddenly try to become their organization's software engineers. That's stubbornly persisted despite not being where people actually are: the real case for AI coding is doing your own job better with software you build yourself.
The reason to start now, per NLW: until you actually build, it's extremely hard to recognize which of your work problems have software-shaped solutions. The activity you already do is well-suited to software support, and the barriers you assumed existed are mostly gone.
The common reasons people haven't dived in: they think they're 'not a technical person' (if you juggle multiple AI subscriptions, you're technical enough), they fear breaking something irredeemably, they bounced off a terminal interface, or a tutorial had them build something irrelevant to their actual work.
The output stays identical but you stop making it by hand: renaming files, syncing lists, filling templates, reworking exports. The test: the person receiving the work wouldn't notice anything changed, and if the software broke you'd just go back to manual steps. Great starting point because you already know what correct looks like.
A report becomes a live dashboard, a deck becomes a web app, a status email becomes a self-serve page. The payoff isn't just time saved — a recurring task becomes an actual asset and a way to outperform and stand out.
Interviewing every person, monitoring hundreds of sources, testing thousands of copy variations — jobs that didn't exist because the manual version was never practical. The risk: with nothing proven to copy, you'll sometimes build capabilities nobody uses. That's just part of the cost of doing business.
A prototype's job is to answer a question, test an idea, or move a decision forward — including as a new way to explain features you'd like to see to other teams. Optimize for speed, clarity, and representative examples, not security, depth, or usability.
A tool built for yourself or a small team that handles a real need reliably. Unlike a prototype it actually has to work, but because it's for you, you can skip perfect UX, permissions rigor, visual polish, and edge cases wherever the trade-off makes sense.
Once other people depend on it, failure costs trust, time, money, or access. It needs realistic-load reliability, pathways to solve problems, and enough security and access control for its users — but it can still be discrete software for a specific, knowable group, not mass consumption.
Even durable personal and production software can be disposable — useful for one goal, one period, then retired. We never would have built that before because the cost couldn't be justified. That equation has changed, and it opens up a lot of interesting opportunities.
NLW's own worked example: a prototype tested whether AI could extract shareable themes from transcripts (it couldn't until Fable and GPT), personal software turned that into the extraction pipeline behind aidailybrief.ai, a second pipeline auto-posts to Twitter and LinkedIn, and a sponsor reporting portal is now crossing into true production software — with a massive further leap if it ever became a sellable product.
Nobody outside can tell you exactly what to build, but the common patterns fall into six buckets: presentation work, content work, data work, document work, inbox work, and admin work. Presentation work alone is full of upgrades — HTML pages instead of PDFs, interactive explainers for things you explain repeatedly, self-serve calculators, comparison tools, onboarding walkthroughs, automated status pages, and lookup tools for reference material.
Turning transcripts into summaries, long things into short things, one thing into five posts — if you're doing it manually in ChatGPT or Claude each time, it works, but there's no reason the entire process can't be automated end to end. The same step-up applies to data translation, template filling, and bulk document work.
Once you start building, you'll squint at things you pay for and think 'I could just build that.' Often you shouldn't: a vendor whose whole mission is that product has far more capacity than you do as the 68th item on your to-do list. NLW's social pipeline skipped the X and LinkedIn APIs entirely by plugging into Typefully — saving 'a huge amount of anguish and agony and tokens.'
Turn the spreadsheet ritual you can do with your eyes closed into an inspectable pipeline — drop the raw export, preview the transformation, download the same trusted deliverable. Or build a watched folder that reads invoices and receipts, normalizes fields, flags low-confidence values, catches duplicates, and produces the same old spreadsheet with you doing review instead of manual input.
Anywhere you owe someone recurring numbers, stop sending snapshots — build a focused page that refreshes from the source, answers the key questions automatically, and maybe lets them interrogate the data with AI instead of coming to you. For scenario models that outgrow Excel, expose the variables — price, volume, timing, headcount — as an interactive page.
The watcher is a personal agentic researcher tracking unpredictable changes — competitor pricing, job posts, regulator guidance — filtering noise and alerting when it matters. The pattern reader digests piles nobody has time to read (support tickets, sales transcripts, survey answers), groups themes, compares segments, and links claims back to source passages, staying persistently up to date.
The watcher-style projects sound a lot like personal agent software such as OpenClaw or GroqBot — and that's the point. A key thing to watch in coming months and years is how many of today's custom-software builds get solved by agents with the right pre-programming and customizability. When simpler approaches win, we should be cheering.
Start with training wheels via Lovable or Replit, or stay in your existing ecosystem with Codex or Claude Code — then take whatever seemed vaguely interesting and try to build it. Maybe it amounts to nothing. But building software for the sake of doing your own work better — not for release — is now a foundational capacity knowledge workers need to have.