Making things with a computer used to be like building a bridge. It’s turning into something closer to growing orchids — and that changes who gets to try.
Today’s Software is Grown rather than Strictly Engineered — Image by Gemini
For most of its history, software borrowed its language from construction. Architecture. Blueprints. Foundations. Structural code. The metaphor was accurate for the work as it was actually done: somebody drew a plan, somebody laid the bricks one at a time, and at the end the thing either held weight or it didn’t.
It was also a barrier to entry.
Bridges are built by licensed people. You don’t wander over on a Saturday and add a steel girder because you had an idea. The construction metaphor told a couple of generations that software was a credentialed activity, that the barrier to entry was a set of arcane skills acquired over years, and that if you didn’t have them, the only thing to do was admire the work from a distance and hire someone.
That barrier is coming down, and it’s coming down fast enough that a lot of people who would enjoy what’s on the other side haven’t noticed yet.
The reason is that making software no longer looks much like bricklaying. You describe what you want in ordinary sentences. Something on the other end produces a working thing. You look at it, say what’s wrong, and it adjusts. The work has moved from assembly to something more like tending: setting conditions, watching what comes up, correcting gently, and waiting for the results to take shape.
There’s a better metaphor for this than construction, and it belongs to a hobby that has never required a license. Making software now resembles horticulture — and specifically, the fussy, patient, environment-obsessed practice of growing orchids.
If you have ever kept a plant alive on purpose, you already have most of the temperament this work rewards. What follows is an argument that the rest is easier to pick up than you think, and a practical suggestion for how to start on your own computer, on your own time, in a way that leaves whatever you make entirely and permanently yours.
Growing without soil
Most flowering plants are terrestrial. They put roots into the ground and take everything they need from it. The soil is pantry and foundation at once.
Orchids mostly don’t work that way. The majority of the ones people grow at home are known as epiphytes: in the wild they live attached to the bark of trees, high up, with their roots hanging in open air. They aren’t parasites. They use the tree for structure and nothing else. Water arrives as rain and as runoff down the trunk. Food arrives as bits of decaying leaf litter washed past. Their roots are sheathed in a spongy white tissue that soaks up moisture the moment it’s available and then seals in what it caught.
An epiphyte’s whole strategy is: pick a good host, hold on cleanly, and get very good at absorbing what flows past. It does not build a trunk. It borrows one.
This is now an exact description of how software gets made.
For decades, making anything with a computer meant building nearly all of it yourself. If you wanted a program that stored information, you built the data structures. If you wanted it to talk to another computer, you built that networking conversation from the ground up. Most of the labor went into substrate — the equivalent of forging your own nails before you could start on the birdhouse.
Almost none of that is necessary anymore. The storage data structures exist. The network plumbing exists. The hard, tedious foundations have been built and rebuilt so many times that they’re now just there, the way electricity is there when you plug something in. What’s left for a person to do is the interesting part: deciding what to build, and shaping it as it grows.
The grower does not build the flower
Nobody assembles a blossom. There is no step in the process where a grower makes petals. The grower manages perhaps five things — how much light and for how long, temperature and especially the drop between day and night, humidity, moving air, and the timing of water and food — and the plant does the rest. The expertise sits entirely in the conditions.
The growers whose plants are spectacular are not more dexterous than the ones whose plants sulk. They are more precise about conditions and more patient about maintaining them. That’s the whole secret: precision and patience, and these are available to anyone willing to practice them.
Making software with these tools is just the same. You are not typing the thing into existence. You are describing the conditions under which the right thing is what naturally comes out.
Those conditions are more ordinary than they sound. What is this for? Who is going to use it, and what do they already know? What should happen when something goes wrong — not the pleasant case, the ugly one? What does “finished” look like, specifically enough that you’d recognize it? What should this absolutely never do?
When someone gets an excellent result from one of these tools on the first try, the credit almost never belongs to a clever turn of phrase. It belongs to the fact that they knew what they wanted, said so clearly, and mentioned the constraints that mattered before anything got built. When someone gets confident nonsense, that’s usually a readout of the environment too: the request was vague, or it contradicted something said earlier, or the essential detail lived in the person’s head and never made it into the conversation.
Growers have a word for the state you’re aiming at. The plant is happy. It’s an imprecise word and every grower knows exactly what it means: roots firm and green, new growth coming in, the thing doing what it wants to do without being fussed over. Projects can be happy in the same way, and you can feel it within an hour of starting. It shows up as the ratio of what you keep to what you throw away.
Stake it early
Orchids with tall flower spikes get staked. A thin bamboo cane goes into the pot and the spike gets clipped to it as it grows, adjusted every week or so as it extends.
The stake doesn’t make the plant grow. It decides which direction the growth goes, and it keeps the weight of the eventual bloom from snapping the stem.
The timing is not negotiable. You stake early, while the spike is still soft and pliable. Once it has grown crooked and hardened, that’s the shape it keeps. You can’t straighten it later without breaking it.
The equivalent here is deciding what “working” means before anything gets built. Not in technical terms — in plain ones. If you’re making a seed-starting calculator, the stake is a sentence like: given a last-frost date of May fifteenth, tomatoes should tell me to start seeds indoors on March twenty-seventh. That’s a specific claim you can check. Say it out loud before you start, and you have a stake. Skip it, and you’ll get something that looks like a seed calculator and produces dates you have no way to evaluate.
This is the single habit that separates people who enjoy this from people who quit, and it has nothing to do with technical skill. It’s the difference between “make me something for planning my garden” and “I want to type in my zip code and get a list of what to plant this month, sorted by when it goes in the ground.” The second one grows straight because you gave it something to grow along.
The kindness that kills
Ask any orchid society what kills the most plants and the answer comes back immediately: overwatering. Not neglect. Not pests. Not cold. Attention, applied too often.
The mechanism is worth knowing because it explains something important. Those exposed aerial roots evolved for air. They need oxygen at the surface, and they get it during the dry stretches between waterings, when the bark in the pot dries out and air moves back in. Keep everything permanently damp and the roots suffocate. Rot moves in and hollows them out.
The cruelty is in the timing. Roots rot invisibly, down in the pot, for weeks. The leaves stay green that entire time because the plant is living on stored reserves. By the time the foliage finally wilts, the root system is largely gone. The wilting isn’t the beginning of the problem. It’s the end of it.
Working with these tools has a failure that behaves identically, and it’s caused by the same excess of well-meant input.
A long working conversation accumulates. Six versions of the same idea, three of which you abandoned. A correction that contradicts a correction from an hour ago. Instructions you gave, changed your mind about, and never explicitly withdrew. The conversation keeps producing results the whole time. Nothing announces a problem. But underneath, the assistant is trying to satisfy a pile of half-retracted, mutually incompatible wishes, and the quality is quietly rotting.
The symptoms are specific enough to recognize once you know them. It starts referring to things that don’t exist, often things that existed in an earlier version. It reintroduces a problem you fixed twenty minutes ago. It gets weirdly cautious and hedging. It reopens a decision you’d settled, offering a helpful alternative to something you already chose for reasons it no longer remembers.
None of that means the tool is broken. It means the pot is waterlogged.
The remedy is the same as the remedy for a wilting orchid: stop adding water and look at the roots. In practice, that means starting a fresh conversation. Bring the current version of the thing and a clean statement of what you want next. Leave the wreckage of how you got here behind. There is no value in old conversation that outlives the work it was for, and there’s real cost.
New growers resist this. The instinct is that the assistant “understands the project now” and starting over throws that away. It’s exactly backwards. What it’s holding is a snapshot going stale by the minute. A fresh pot with fresh bark beats a familiar pot full of muck.
Repotting
Every year or two an orchid has to be repotted, and it usually has nothing to do with the plant outgrowing its container.
The bark in the pot breaks down. New bark is coarse and open, full of air gaps. Two years of watering grinds it into fine particles that pack together and hold water where air used to be. The medium slowly turns into the thing it was chosen to prevent.
Repotting is disruptive. It stresses the plant and sets it back for a few weeks. Growers do it anyway, on a schedule, because a small predictable setback beats a large unpredictable collapse.
Anything you build over time collects the same kind of sediment. You ask for a feature and get one. A week later you ask for something similar in another part of the project and get a second, slightly different version of the same idea, because nothing remembers the first. Neither one is wrong. The accumulation is the problem: four ways of doing one thing, three of which behave a little differently in ways nobody will notice until something goes strange.
So every so often, you go through and tidy. You ask, in plain language, whether there are places doing the same job in different ways, and you consolidate them. You take out the extra layers that got added when the assistant was being thorough on your behalf. It isn’t glamorous, and it isn’t an admission that you did something wrong. It’s what the bark does. It’s maintenance.
One rule worth adopting from the start, because it saves more trouble than anything else on this list: when something is almost right — one wrong word, one date off by a day, one label in the wrong place — fix that one thing, or ask for that one thing specifically. Don’t ask for the whole piece again.
Asking for the whole piece again is how a working thing becomes a broken thing. What comes back will differ in ways you never asked about, and one of those differences will eventually be a step backwards in something you’d already gotten right and stopped checking.
Blooming happens on its own schedule
The common household orchid initiates its flower spike in response to a cue from the environment — most reliably a sustained drop in night temperature over several weeks. A grower who wants blooms provides the cue and then waits. There is no way to hurry it. Pulling on a developing bud does not open the flower. It destroys it.
The version of this mistake in software is the enormous single request: describing an entire ambitious project in one long paragraph and expecting the whole thing back, finished. It’s seductive because it sometimes almost works. What comes back looks complete. It has all the right pieces with all the right names. The problems are spread thinly all through it, and they’re invisible, because something that large doesn’t get examined. It gets glanced at.
Work in pieces small enough to actually check. Get one thing working. Look at it — really look, which is possible because it’s small. Confirm it does what you said it should. Then move on to the next piece, from clean ground.
Each round gives you something you know is right, and the next round builds on solid footing instead of on an accumulating pile of things you assumed were fine. In Stack Overflow’s 2025 survey of more than forty-nine thousand developers, the single most common complaint about AI tools — from two-thirds of respondents — was solutions that are “almost right, but not quite.” Not solutions that fail. Solutions that look finished and are subtly wrong.
Almost-right is more dangerous than obviously-wrong, because obviously-wrong announces itself immediately and cheaply. Almost-right sails through, gets used, and surprises you later. Everything in this piece — stake it early, small steps, check as you go, fresh pots — exists to catch that one thing, because nothing else will.
Professionals wrestle with this daily. It is not a beginner problem, and being new to it is not a disadvantage. If anything, someone who checks carefully because they’re unsure is in better shape than someone who skims because they’re confident.
Planting your first thing
Here’s what a first season actually looks like, on your own computer, with no prior experience.
Use your own machine and your own account. Not the work laptop. Not the company subscription. This matters enormously and it gets its own section below — read that part before you start, because it’s much easier to begin cleanly than to untangle it later.
Sign up for one assistant, personally. Any of the major ones will do for a first project, and any of them will get you further than you expect. Use a personal email address, ideally not the one you use for anything work-adjacent. A free tier is enough to find out whether you like this. Paid tiers are roughly the price of a decent orchid, and considerably harder to kill.
Pick something small that you actually want. The projects that get finished are the ones the maker wanted for themselves. If you already grow things, the obvious candidates are right in front of you: a page that tells you what to start indoors this week based on your frost dates. A log for what you planted where, and when it bloomed. A watering schedule that knows a cactus and a fern want different treatment. A label maker that prints tidy tags for the greenhouse bench. A page for the plant society newsletter. A record of which cross produced which seedling, with photos.
Ambition is fine later. Keep it simple and you can finish your first one in an afternoon.
Ask for it in ordinary words, and mention what “working” means. Something like: I’d like a single web page where I enter my last frost date and it shows me a list of vegetables with the week to start each one indoors and the week to plant it out. I want to be able to open it on my phone in the greenhouse. If I enter May fifteenth, tomatoes should say to start indoors around March twenty-seventh. That last sentence is your stake along which the process grows. Say a version of it every time. Notice you don’t need a formula, just provide real examples of acceptable results and the rest will follow.
Let it explain, and ask when you don’t follow. These tools are patient in a way no human teacher can be. There is no such thing as a question too basic, and nobody is watching. “What does that word mean” is a perfectly good message to send. So is “explain that to me like I’ve never done this before,” which is not embarrassing, it’s efficient. This is also a great way to catch assumptions that might not be right simply because your instructions were not clear and the assistant took a guess.
Keep your work in one folder that you own. Make a folder on your own drive — call it whatever you like — and keep everything in it. When you have a version that works, save a dated copy before you start changing things. That’s the whole backup strategy for a first project, and it’s the equivalent of taking a cutting before you attempt a risky repot. Later you can learn tidier ways. This one has saved more amateur projects than any tidier way ever will.
Expect the first attempt to be wrong, and treat that as normal. It is normal. It’s the same as the first tray of seedlings that failed to sprout. You didn’t fail a test. You learned something about your conditions.
Assistants that can work with files on your computer are worth graduating to. Most of the major providers now offer a desktop application that can read and write files in a folder you choose, rather than only chatting in a browser window. That’s the point where this stops feeling like asking questions and starts feeling like working alongside someone. Start in the browser. Move to the desktop app when the copying and pasting starts to annoy you — that annoyance is the signal, and it usually shows up in week two.
Give yourself a season, not an evening. The first attempt is not perfect and almost everybody’s fourth attempt is at least satisfying. The gap between those two is a couple of weekends, which is a very short time to acquire a capability you’ll have permanently.
Your own patch of ground
Now the part that’s easy to get wrong at the start and expensive to fix afterward.
Do this on your own equipment, on your own time, using an account you pay for personally, with a personal email address. Not your work computer. Not the company’s AI subscription. Not the account your employer provisioned for you. Not during hours you’re being paid for.
This isn’t about secrecy or about breaking rules. It’s about clean title.
Most employment agreements contain a clause assigning to the employer the rights to things you create. The scope of those clauses varies enormously, and their reach usually turns on a small number of factual questions: Was it made on your own time? Was it made without the employer’s equipment, supplies, facilities, or confidential information? Is it unrelated to the employer’s business or to work you actually did for them?
Several states have written those questions into law specifically to protect employees. California’s Labor Code section 2870 is the best-known: an assignment clause can’t reach an invention you developed entirely on your own time without using your employer’s equipment, supplies, facilities, or trade secret information, as long as it doesn’t relate to the employer’s business or anticipated research and didn’t result from work you did for them. Washington, Illinois, Minnesota, Kansas, Delaware, North Carolina, Utah, New Jersey and others have similar provisions, and several require employers to give written notice of them. Specifics differ by state and your own agreement is the document that governs, so it’s worth actually reading both. Most people have never opened theirs.
Notice what those statutes hinge on. Own time. Own equipment. Own supplies. Not the employer’s confidential information. Those are exactly the boundaries you maintain by simply doing this at home, on your own machine, with your own account, on a Saturday. The protection is not something you argue for later. It’s something you build in from the first evening, at no cost, by choosing which laptop to open.
There are practical reasons beyond ownership. Work devices are managed and frequently monitored, and that’s usually disclosed in a policy nobody reads. Corporate AI accounts operate under agreements between the vendor and your employer, and conversation history in those accounts can be retained, reviewed, and exported by the organization. Files created on company equipment sit inside company backup systems. None of that is sinister — it’s normal enterprise hygiene — but all of it entangles anything you make there with an entity that isn’t you. And if you leave that job, the account goes away, and whatever lives inside it may go with it.
The boundary runs both directions, and the other direction matters just as much. Don’t put your employer’s confidential material into your personal account. Not customer data, not internal documents, not anything covered by an agreement you signed. Keeping the two worlds cleanly separate is what makes each of them safe.
What you get in exchange for this small discipline is worth more than it looks like at first.
You get something that is unambiguously yours. Not “yours unless someone asks a lawyer.” Yours. It can be given away, sold, licensed, published under your own name, or handed to a grandchild. It’s an asset in the ordinary sense: it belongs to your estate, it can be left to someone, and it doesn’t evaporate when you change jobs or retire.
People who grow things understand this instinct already. A gardener with a good cultivar knows exactly what they have — the seed you saved from your own plant is yours, and the cutting you take goes where you say it goes. Something you make in your own greenhouse, on your own bench, on a Sunday, has the same clean provenance. That’s worth protecting, and protecting it costs nothing except the decision to open the right laptop.
Where the metaphor stops
Plants have no adversaries. Nothing studies your orchid looking for a weakness to exploit. Software connected to the wider world does have adversaries, and the moment you’re handling other people’s information — names, addresses, payments, anything private — you’ve crossed from gardening into something with real stakes for people who never agreed to be part of your experiment. That’s a fine place to go eventually. It’s a bad place to start, and when you get there, ask for help from someone who does it professionally.
And some software genuinely does need the bridge-building approach: specified rigorously, verified exhaustively, nothing allowed to emerge that wasn’t proven first. The systems that fly airplanes and run hospitals are built that way for excellent reasons.
Most software isn’t that. Most software is a small useful thing that helps somebody do something they care about. That category is enormous, it is wide open, and it has never in the history of the field been this reachable.
An invitation
A grower’s expertise is invisible in the finished flower. It’s in a hundred small decisions made weeks earlier, most of them decisions to restrain. Not watering today. Not repotting until the season is right. Not moving the plant to a brighter window because brighter seems better. Cutting the damaged root back to healthy tissue rather than leaving a piece that might recover. Noticing the leaf that’s gone slightly pale and adjusting before it burns.
That’s the same skill this new kind of making rewards. Knowing what you want. Saying it plainly. Setting good conditions and then letting the thing come up. Watching closely. Correcting gently and early. Being willing to start a fresh pot. Waiting.
None of that is technical. All of it is learnable, and much of it is already sitting in the hands of people who have never once considered that any of this was for them.
If you’ve kept an orchid in bloom, you have done something harder and more patient than making your first useful program will be. The difference is that nobody ever told you that you couldn’t grow orchids.
Nobody’s telling you now, either. Open your own laptop, on your own time, with your own account. Plant something small. See what comes up.
Sources
- Stack Overflow, 2025 Developer Survey, AI section — survey.stackoverflow.co
- DORA / Google Cloud, 2025 State of AI-assisted Software Development (September 2025) — dora.dev
- California Labor Code section 2870, on employee invention ownership — law.justia.com