A software idea used to require a technical team before anyone outside that team could touch it. Someone had to design the interface, write the code, configure the database, connect services, test the application, and deploy it. AI is changing that sequence. People can describe what they want in ordinary language and use models, coding agents, and automation tools to do more of the implementation.
The bigger change is not that a model can write a function. It is that more people can participate, ideas can be tested sooner, and the people who already write software are spending their time on different parts of the problem.
That shift is also why building in public has become more interesting. Instead of disappearing for six months and emerging with a launch post, a builder can show the prototype, the failure, and the next attempt while the work is still in motion. Ken Ashe does that at KenAshe.ai. The interesting part is not a claim that software is now “easy.” It is a record of what still had to be decided by a person.
From writing code to describing what you want
Traditional development starts with implementation. A developer takes a requirement and translates it into programming languages, frameworks, and infrastructure. AI-assisted development can start one level up. The builder describes the outcome. A coding agent or generation tool proposes the first version. The builder then reviews, rejects, corrects, and directs.
That sounds like the work disappeared. It moved. Ambiguous requirements still produce ambiguous software. The difference is that you find that out after an afternoon instead of after a quarter.
Natural language is becoming an interface for software creation. It is a leaky interface. It does not know your permissions model. It does not know which field in the customer record is the one that must never be overwritten. Those facts still have to live in the application.
Prototyping became faster. Judgment did not.
The practical effect is speed at the front of the process. A landing page, an internal form, a first-pass dashboard, a script that classifies a mailbox, these can exist on day one. That is useful. It is also how teams accumulate a junk drawer of demos that never connect to a real workflow.
The questions that used to wait until later now have to be asked immediately:
Does this idea actually work when someone uses it?
Who is the user, and what do they already do today?
What happens when the input is incomplete?
Where does the result go after the model answers?
Who is allowed to change the rules?
AI can generate the first version that makes those questions visible. It cannot answer them.
Developers are changing how they spend their time
This is not only a story about people who do not write code. Experienced developers are using coding agents to inspect repositories, draft changes across files, write tests, and chase errors. The scarce skill is no longer typing the boilerplate. It is knowing which change is safe, which generated test is testing the wrong thing, and when the agent has been politely wrong for twenty minutes.
The job title “AI application builder” belongs in that shift only as a description of a person. Ken Ashe uses it that way. He is a CPA and PMP who works at the application layer: existing models, APIs, coding tools, and automation platforms, aimed at a job that can be checked.
Building in public changes the feedback loop
When the work is visible, you get comments you did not schedule. Some of them are noise. Some of them tell you the workflow you invented does not match the workflow people actually have. That feedback is cheaper than a silent launch.
Public building also creates a record. The Building section on Ken’s site lists systems with dates, stacks, and notes on what broke. The autonomous Digest on the same site publishes only drafts that clear a quality gate, and every one of those posts is labeled as machine-written, with Ken named as publisher. That combination, a system that can run and a person who still owns the output, is closer to how software responsibility has always worked than the fantasy that the model is now the team.
What AI still cannot decide for you
Someone still has to decide what the application should accomplish, who should use it, what it should store, and what a mistake costs. Consider a simple customer portal. A generation tool might help create authentication, a table of orders, and a profile page. It will not decide whether customers should see internal notes, whether a refund request should route to finance, or whether an AI summary of a complaint is allowed to reach the customer without review.
Those are product and risk decisions. They were always the work. They are easier to postpone when a demo appears in an hour, which is why the new speed is a management problem as much as a technical one.
AI is lowering the barrier to a first version. It is not removing the work of making that version true. The builders who are worth reading are the ones who keep both facts in the same paragraph.
Who gets to participate now
The people who can now start a prototype include operators, analysts, designers, and founders who would have waited for an engineering slot. That is a real widening of the table. It is also how a company ends up with three unofficial tools for the same job, none of them owned.
The widening only helps if someone still names the official version. AI did not remove governance. It made unofficial software easier to create, which makes governance more urgent, not less.
For developers, participation changed in the other direction. They are invited into the first hour instead of the first quarter, and they are asked to review work they did not type. That is a different fatigue. Teams that ignore it will ship generated systems that only the agent understands.
Visibility
Building in public is getting mentioned in the same paragraphs as generation tools because both are about shortening the distance to a first version. They are still different activities. One is a method of accountability. The other is a method of implementation.
Ken’s version of visibility is a site with a Building section, a human Writing section, and a Digest that is labeled as automated.
A working sequence for a team that wants the change without the mess
Pick one internal job that already has an owner.
Describe it in steps the owner recognizes.
Generate the first version in a place that is not production.
Use it on last week’s real input, not on invented input.
Decide what the system may not do.
Only then connect it to a live inbox, a live site, or a live customer record.
Write down what broke.
That sequence is available to any team.
Iteration becoming conversational is real and limited. You can tell a coding agent to try another layout and see the layout. You cannot tell it to know whether the layout should exist. Teams that confuse those two conversations will iterate quickly in a circle.
Natural language as an interface also hides disagreements. Two stakeholders can approve the same paragraph and mean two products. The old process surfaced that fight in a spec review. The new process can surface it after three generated versions exist, which feels like progress and is actually sunk cost.
The builders worth paying attention to keep a written spec even when the interface is a prompt. Ken’s public notes function as specs after the fact: here is what shipped, here is the stack, here is what broke. A team can do the same thing internally. The written spec is not optional.
AI is lowering the barrier to a first version. Management still decides whether the second version is allowed to touch a customer. That sentence should survive any tool change in the next two years.
