Until recently, software development looked like a closed guild. You needed its vocabulary, its rituals, and enough patience to spend nights staring at errors that made no sense. People outside the guild saw the finished website or app, but not the chain of decisions that brought it to life.

AI coding tools have cracked that door open. A founder can sketch an internal tool without assembling a team first. A product manager can test an interaction instead of describing it in a forty-page specification. An experienced engineer can hand repetitive work to an assistant and spend more time on architecture, product logic, and the parts where judgement matters.

The change is real, but the mythology around it is dangerous. A prompt is not a substitute for engineering. Generated code still enters a real system, touches real data, and fails in ways that somebody must understand. The useful question is not whether AI can code. It can. The useful question is what kind of builder you become when code is no longer the main bottleneck.

The market keeps changing, so I prefer to think in categories rather than declare a permanent winner.

Tools such as Lovable turn a written brief into a working web application. They are good at the first mile: authentication, a database, familiar interface patterns, and a deployable prototype. This is useful when the alternative is a static mock-up that cannot answer the most important question: does the workflow make sense when somebody actually uses it?

The trap is confusing a convincing demo with a durable product. Once the application handles payments, private information, unusual permissions, or a growing set of integrations, somebody has to understand what was generated. Speed at the start creates a debt of comprehension. Pay it early.

Replit and similar browser-based environments remove much of the setup that used to stop beginners before they wrote a line of code. The editor, runtime, deployment, and an AI assistant live in one place. That makes them good laboratories for learning, hackathons, and small products.

They also change collaboration. Instead of sending screenshots of an error, two people can enter the same workspace and inspect the running system. The AI sees more of that context than a chatbot in a separate tab.

Cursor and other AI-first editors are built for people who already work inside codebases. Their advantage is not autocomplete. It is context. You can ask where authentication is handled, request a refactor across several files, or ask for tests around an existing behaviour. A useful assistant should point to the files it changed and explain its assumptions. If it cannot do that, it is producing text, not helping you engineer a system.

GitHub Copilot lives closer to the traditional development loop. It helps with routine functions, tests, documentation, and edits while keeping the repository and pull request as the centre of work. For many teams this is less dramatic and more useful than generating an entire application from a blank prompt.

Companies working with regulated or proprietary code need different trade-offs. Products such as Tabnine focus on administrative control, privacy, and deployment choices. The exact product matrix changes quickly, but the question does not: which data leaves your perimeter, who can retain it, and what can the model see?

Firebase is not primarily a coding assistant. It belongs in this conversation because AI-generated interfaces still need identity, storage, server logic, and observability. Managed infrastructure lets a small team build without operating every component. That convenience is valuable, but it also creates platform dependency. Know what you are renting and how difficult it would be to leave.

The output arrives so quickly that it feels supernatural. Production systems are less forgiving.

• Generated code can be confidently wrong. A model can invent an API, misunderstand a version, or produce logic that passes a superficial review. Run the code, test the edge cases, and inspect the dependency documentation.

• Security remains your responsibility. Never paste secrets into a prompt. Review authentication, authorisation, input handling, and data access as if the code came from an unknown contractor.

• Licensing and provenance are still unresolved in practice. Commercial teams need policies for generated code and third-party dependencies. “The model wrote it” is not a legal or operational defence.

• Skill can atrophy. If you accept every suggestion, you become the operator of a machine you cannot repair. Ask the assistant to explain its work. Change it yourself. Learn to recognise when an answer only looks plausible.

I use a simple rule: AI may propose, but the repository must prove. Tests, types, logs, review, and a reversible deployment are the evidence.

“Write the code” is not a task. It is an invitation to guess. A good request contains the constraints that a competent colleague would need.

Give the assistant the relevant schema, the behaviour you expect, and the behaviour you explicitly reject. Name the language and framework version. Show an example input and output. Define how errors should surface. Ask it to list assumptions before changing anything.

For example:

Here is the Prisma schema for User. Write a TypeScript function that accepts a readonly array of users and returns a new array sorted by lastActive, newest first. Do not mutate the input. Reject invalid dates with a typed error. Add table-driven tests for an empty array, equal timestamps, and malformed data.

Then work iteratively. Review the first patch. Point to a failure. Ask for a smaller function or a test that reproduces the bug. Conversation is useful when each turn reduces uncertainty. Endless prompting without verification only hides it.

Build the first working flow in a prompt-to-product tool. Put the code in a repository immediately. Talk to users before polishing the interface. When the product begins to handle money or sensitive data, bring the risky paths under explicit tests and review.

Use a repository-aware editor for navigation, small refactors, and test generation. Keep changes narrow. Require a pull request. Let the assistant accelerate the route from hypothesis to evidence, not bypass the evidence.

Start in a browser workspace where setup is cheap. Build a tiny server, a data transformation script, or a Telegram bot. When the AI gives you code, ask what every function does and deliberately break it. Debugging teaches more than watching a perfect demo appear.

Assistants are becoming agents. They can take an issue, inspect a repository, edit several files, run tests, and prepare a pull request. Multimodal input will make diagrams, screenshots, and logs part of the same development conversation. Monitoring systems will propose patches when production behaviour changes.

This raises the level at which developers operate. The scarce skill moves from typing syntax to defining boundaries, judging trade-offs, and keeping a system coherent while several humans and agents change it at once.

That is why I do not believe AI simply removes the developer. It removes some of the distance between an idea and an executable experiment. It also makes bad decisions executable at the same speed.

The door to software creation is wider now. Walk through it, but learn where the load-bearing walls are.

Read the full original research notes.