Conversation summary

View post View summary View on LinkedIn

You can build it. You still have to sell it. You still need engineers.

A generated summary of the whole thread: engineer-led products are already shipping, a product is still not a business, independence does not skip customers, and AI still does not replace engineering judgement.

Original post

What the conversation actually said

The original post is a counter to the claim that AI will soon do what software engineers do end to end. In the comments the claim is sharper: a good engineer can now ship a real product without a traditional team or a funding round, keep the equity, and still cannot be replaced by a prompt. Almost nobody disputes that engineers still matter. They disagree about what the new speed is actually worth. The arguments below are the whole thread, not only the parts that agree with the post.

It is already happening. Several people treat “zero months” as late. They are already shipping, running more than one independent project, or calling it less than zero. One person describes building a serious clinical system in weeks and putting expensive incumbents on notice. Others are simply having a crack. The author’s own follow-up is that this was already feasible, and that “engineer” here includes architects and tech leaders who know how a system has to look — not only people writing tickets.

Code is not a product, and a product is not a business. This is the largest cluster of replies. Building it is not the same as people coming. Marketing, sales, go-to-market, distribution and support are named as the hard parts. One person says engineering is no longer the bottleneck — sales is. Another says an app is just the product and you still have to build a business around it, which is how consultancies have always made money from half-finished software. Distribution gets its own warning: the market will be flooded with millions of things nobody subscribes to.

That disagreement is not resolved. Someone answers that marketing and sales are commodities and engineering is art. The author keeps both sides: you have nothing to sell without working software; AI-only junk will be abundant; a skilled engineer can now reverse the old deal and pay for commercial help after there is something real, instead of taking a sliver of an imaginary pie to build vapourware. Several people land in the middle. Ideas are cheap and execution is everything. Both illusions are false: that engineering excellence is all you need, and that you can run a complex system in production with no engineers and only AI.

If everyone can build, who buys? If an idea can be remade just by hearing it, independence might mean more builders and a smaller market. The replies split. Cheap clones and throwaway personal tools will kill a lot of small paid utilities. Bigger ideas that were not feasible for one person suddenly are. Slow incumbents get disrupted, which still employs engineers who do not want to found. Open-source clones of expensive enterprise software are another version of the same pressure: people are fed up with subscriptions, and some think we are close to offering favourite products for free. One colder question sits underneath: how many new and original software products can there possibly be?

Independence is not independence from other people. You are never independent of customers. AI does not replace relationships or trust; without them a business is fighting uphill. One person would rather see cooperation than a celebration of solo founders, and flags equity going to zero when a flight of fancy hits real operational complexity. Another asks whether the engineer even wants to be in sales and marketing — a one-person company is nice, spreading the work is better. The author agrees most engineers would hate running the commercial side, and still says the ones who want to now can. The insult in the other direction is the same shape: poor engineers who believe the headline are in for a bump; poor founders who think they can ship without engineers will have a worse one.

The craft did not go away. Rapid prototyping still dies on complexity, versioning, data contracts, and systems that have to stay reasonable as they grow. Agents take more of the grunt work; their performance is not always predictable. The author’s version: models are poor decision-makers on design, returns are diminishing, and it is easy to waste time and money on a lemon. Deciding what to build is now part of the engineering value, because you can build almost anything you can see in your head — which is also why some people feel overwhelmed by their own ideas.

Safety is a real split, not a side note. One analogy is handing a room of unprepared three-year-olds uranium Lego and hoping they do not assemble a critical mass. The author does not wave that off: people with no technical understanding can unleash software that is effectively reviewing itself. The argument is that AI-generated systems need more governance than human-written code, not less, and that the people who can keep control are the same professionals the scaremongering says you no longer need. If you are not qualified to validate the technical result, you are putting total trust in the model.

The agent thread is how some engineers think they will actually ship. Always-on agents that own a domain, talk to each other, and send work to a cloud environment is one picture. A reply pushes back: agents are not bound by human role limits, so why slice them into personas except to help the operator? Another picture is a router you talk to, with cheaper tokens because you plan before you spin up code. Local boxes versus cloud agents is treated as an engineering hosting choice, not a religion — control and cost on one side, hardware limits and the ability to boot a server and film the result on the other. The through-line from the original post is who is directing the work. An army of agents still needs someone who can describe the system.

Read the conversation on LinkedIn