This is part two of our roundtable write-up. It covers what changes in documentation, culture, hiring and delegation once AI does most of the building. In short, AI for engineering teams only works as well as what the team has written down. So the leaders at our roundtable are making standards and culture explicit, rethinking the first year of an engineering career and treating delegation as a skill to practice.
An engineering leader at our roundtable described a test most companies would fail. Hand an AI the transcript of a team meeting and ask what was decided. It will read every word with equal weight. So it can’t know that one colleague talks constantly and says little. Nor can it know that a quiet colleague rarely speaks, but must be heard when he does.
People inside the company know all this without being told. In his view, that unspoken knowledge is most of what companies call culture fit. AI tools don’t have it, and neither do new hires on their first day.
Our roundtable, called “AI changed the work. Did we?”, brought together speakers from our team and from one of our clients. Meanwhile, roughly thirty engineers in the audience voted on each prompt in real time. A companion article covers how the work itself is changing. This one looks at the teams doing it: what they write down, whom they hire and how they delegate.
Whatever you haven’t written down, your AI tools will guess
AI tools work from what you tell them, so someone has to state what good looks like. Yet most organizations, the product leader argued, have never written down what good code or good design means to them. Instead, standards live in people’s heads, and newcomers pick them up over time.
AI tools, however, have to guess at anything unwritten. So, in his view, the companies that pull ahead will make their standards explicit. Those same documents also help every person on the team.
For a practical start, list the corrections your senior people make most often to AI output. Each one is a standard nobody has written down yet. Then turn the list into short documents: coding conventions, architecture principles, security rules and a definition of done. Keep them in the repository, close to the code. Many AI coding tools can read instruction files stored there, so the same rules guide both people and agents.
Culture is a document too
The product leader applied the same logic to culture, citing a principle he attributed to one of the Collison brothers. A cultural value only means something if its opposite could also run a successful company.
He named Stripe and Shopify among the companies getting the most from AI. In his view, their honest, written-down cultures spare their AI tools from guessing.
By contrast, most companies run on what the anthropologist Edward T. Hall called high-context communication. There, meaning depends on who spoke and how much weight they carry. That is exactly what the meeting transcript can’t capture. So the more context a company writes down, the faster new hires and AI tools become useful.
Another guest noted how far many companies still have to go. They put “AI-first” on the landing page, but little changes behind it. Meanwhile, one engineering leader now screens job candidates for openness to working with machines.
The first year of an engineering career is changing
Several speakers focused on the next generation of engineers. One engineering leader recently hired a couple of people fresh from internships. He told them the starter tasks of five years ago no longer matter, since AI can sketch a web service in minutes.
Instead, his team teaches them to structure prompts and build a personal feedback loop. The learning also runs both ways. The newcomers have shown senior engineers workflows they had never considered. His advice to graduates: be willing to drop much of what you just learned, and teach the people above you.
Another guest agreed that you can forget most of what college teaches, with one exception. A graduate’s grasp of how systems work lets them ask for the right thing. Without it, they risk shooting themselves in the foot without noticing. A third speaker wondered what happens to people who never read code at all.
Even so, the audience showed little interest in the obvious safeguard. On a scale of 1 to 5, they mostly disagreed (2.4) that teams should sometimes build without AI on purpose to protect their skills. One guest explained the majority view. For everyday work, going without AI only holds you back. The time to work without it is when you want to learn something for yourself.
A few practices follow from this. First, pair new hires with senior engineers to review AI output together, since that is where judgment gets passed on. Second, teach security basics early. As one engineering leader noted, schools rarely cover them, and AI tools still sometimes make insecure design choices. Finally, ask new hires to demo their own AI workflows to the team. It costs an hour, and on this roundtable’s evidence, the seniors often learn the most.
Everyone has an army of interns now
The product leader also made a case for some naïveté. A friend of his advises startups at Y Combinator. She once told founders building hard technology to consult a marketing expert rather than ChatGPT. Yet the teams that asked ChatGPT did better. A 60 percent answer in minutes, which they could test and improve, beat a 75 percent answer three days later.
Roles are converging too. Executives are building prototypes again. As a result, engineering leaders spend much of their time explaining why an impressive prototype might collapse at a hundred customers or run up a large cloud bill.
One leader noted that scalability also means fitting business needs nobody has imagined yet. That judgment comes “with time and practice and scars,” he said, and AI doesn’t have it. He expects executives and engineers to keep moving closer. Still, he doubted engineers should be the ones meeting twenty customers to size up a market. Meanwhile, the moderator pointed to the rise of forward-deployed engineers, who build in front of the client.
The product leader summed it up this way. Everyone now has an army of interns, which makes everyone a VP. And delegation is the skill most people have never had to learn.
Everyone now has an army of interns, which makes everyone a VP. And delegation is the skill most people have never had to learn.
Delegating to AI works much like delegating to a team. You give a clear brief, agree on checkpoints and decide in advance how you will verify the result. According to the product leader, checking every line yourself is the low-leverage option. Instead, rely on specs, tests and review processes that scale with the volume of work.
- The corrections seniors make most often to AI output
- Coding conventions and architecture principles
- Security rules and a definition of done
- Cultural values whose opposite could also run a company
- Instruction files in the repository, close to the code
- Teach prompt structure and a personal feedback loop
- Pair them with seniors to review AI output together
- Cover security basics early
- Keep their grasp of how systems work
- Ask them to demo their AI workflows to the team
The factory still needs a new floor plan
Economic historians have described the same pattern. In a well-known 1990 paper, the economist Paul David argued that electricity took decades to lift factory productivity. The gains came only once owners rebuilt their factories around small electric motors on each machine, instead of one central drive shaft.
The same lesson applies to AI today.
Organizations that simply drop AI into existing workflows, using it to speed up tasks that were designed for a world without it, are likely to see modest results and conclude it was overhyped. The real gains will go to those willing to rethink how work is organized around what the technology makes possible.
The work has changed, and the good news is that people get to choose how they change with it.
Frequently asked questions
1. Why do written standards matter for AI for engineering teams?
AI tools work from what you tell them, so they have to guess at anything unwritten. Yet most organizations have never written down what good code or good design means to them. Instead, standards live in people’s heads. Making them explicit helps AI tools and every person on the team.
2. Where should a team start documenting its standards?
List the corrections your senior people make most often to AI output. Each one is a standard nobody has written down yet. Then turn the list into short documents: coding conventions, architecture principles, security rules and a definition of done. Keep them in the repository, where many AI coding tools can read them.
3. How should teams onboard new engineers when AI does most of the building?
Teach them to structure prompts and build a personal feedback loop. Pair them with senior engineers to review AI output together, since that is where judgment gets passed on. Also, teach security basics early. Finally, ask them to demo their own AI workflows, because the seniors often learn the most.
4. How do you delegate work to AI well?
Treat it like delegating to a team. Give a clear brief, agree on checkpoints and decide in advance how you will verify the result. Checking every line yourself is the low-leverage option. Instead, rely on specs, tests and review processes that scale with the volume of work.
TechQuarter builds custom platforms and the AI that runs on them. We bring engineering and product leaders together to talk openly about how that work is changing. Also, we adapt the technology to fit how your team already works. Rethinking how your team builds with AI? Work with us.
