If you run a product, AI code generation is no longer the thing that slows you down. A model can produce a working feature in about the time it takes to describe one. What still takes real effort is deciding what to build and checking that what came back is correct. Three announcements last week pointed at the same shift, and it changes what you should expect from the people who build your software.
Microsoft and Carnegie Mellon University launched PRAISE, a program that pairs junior engineers with senior ones for a world where, as the title of their post puts it, AI writes the code. Their argument is that you still need engineers, and that today's juniors become tomorrow's seniors, because someone has to be accountable for what ships. One line from the writeup is worth keeping: "AI changes the work; it does not remove human responsibility for outcomes."
The same week showed how far the writing part has already moved. The Rundown AI reported that Anthropic's engineers said coding is no longer the bottleneck at the company, with daily merges up more than tenfold since May as the model writes more of the code. And Epic Games' CEO told his team to stop writing code by hand and retool around AI tools, also via The Rundown.
Read those together and the picture is clear. Generating code is fast and getting faster. The parts of the job that never automated well, deciding what to build and being responsible when it breaks, are now most of the job.
It helps to be honest about both. AI code generation is strong when the task is well specified: boilerplate, a component from a clear design, a straightforward endpoint, a fix for an obvious bug, a test for code that already exists. On work like that it is faster than any person, and the output is usually fine.
It gets shaky the moment the task has judgment in it. Ambiguous requirements turn into confident guesses. The edge case you did not mention gets skipped. Security and data handling look right and are not. A tradeoff that should have been a conversation becomes a silent decision buried in a pull request. The model does not know your business, your users or the three other systems this change has to live with.
None of that is a reason to avoid the tools. It is a reason to be clear about where they help and where a person has to step in.
The scarce thing now is judgment. Microsoft's framing is that engineers move from producing code to deciding what deserves to be built in the first place. For a founder, the questions that matter have not changed: is this the right thing to build, does it handle the case that will actually break it, and will someone understand this code in six months when it needs to change again.
A model can draft an answer to all three. It cannot be accountable for getting them wrong. That is why the people around your codebase matter more now, not less. The cost of a bad AI change is rarely the code itself, which is cheap to regenerate. The cost is the week you lose when it quietly broke something nobody tested.
A few things follow from all of this.
Spend your time on the spec and the review, not on watching code appear. The clearer you are about what you want and what counts as done, the better the generated code will be and the faster you will catch the parts that are off.
Make sure whoever owns your codebase is senior enough to catch what the model got wrong. Someone who only knows how to accept a suggestion is not a safety net. Someone who can read a change and say "this will fall over under load" is.
If your first version is simple, you may be able to build it yourself with AI and skip hiring for a while. That is a real option now, and worth trying before you spend money.
This is the part we care about at BYLD. Whether we are building your first version or joining your team, the engineers you work with are senior and do the work themselves. We push back when something does not make sense, we flag risk early, and we over-document so nothing is ambiguous, and you see the work every week. When TheFlightWall needed to move around 20,000 devices onto a new backend, we embedded with their team and did it in under four weeks. LottaHoney's new product went live eight weeks after we signed. That speed came from people who owned the result, not from skipping the review.
If you have a build that shipped fast with AI and broke, or stalled halfway, the ways we work include rescues for stalled or broken builds.
There is no sign of it. The tools write code. They do not decide what to build, own whether the product works, or answer for it when it fails. Microsoft and Carnegie Mellon are betting the opposite of replacement: that the junior engineers trained today become the senior engineers who are accountable tomorrow.
It can be, once a person who understands the system has read it. The real danger is subtle: the edge case or the security gap that looks fine in review until a real user hits it. Treat generated code the way you would treat a new hire's first pull request. It is useful, and you still read it before you merge it.
Be specific about requirements, keep changes small enough to review, and make sure someone senior signs off on anything that touches money, user data or the core of your product. The tools remove the typing. They do not remove the need to decide and to check.
If engineering is the thing holding your product back right now, that is the conversation I am happy to have. To be super transparent, if you would be better off building a first version yourself with AI, I will tell you that on the call. You can book 30 minutes below.