AI agents are not a passing phase; they are changing how software gets built. The same dynamics we see in code generation are emerging in other fields: lawyers drafting contracts, analysts building financial models, consultants assembling decks, researchers structuring reports.
In our experience, AI accelerates early output, amplifies structure (good or bad), and struggles when foundations are unclear. Below is the mental model we use and some of the lessons we’ve learned. Many of these patterns extend beyond software and may prove useful wherever AI agents are part of the workflow.
If you need a small push - a GUI, a report, lightweight edge functionality - constraints can be minimal. Provide a clear business description, iterate a few times, and you’ll often reach a usable result quickly. The 'quick win' category is expanding: tasks that required structure last year may not require it next year. Boundaries are shifting as model capability improves.
Architecture does not emerge automatically from generated code. If you’re building core functionality that future features will depend on, restraint is mandatory. Core systems require a clean algorithmic structure that will scale with what comes next. Early shortcuts compound. Poor structural decisions create hidden constraints, and the agent will later struggle to extend or refactor code it generated under vague direction.
Instead: define the structure first, write the function signatures yourself, explicitly label inputs and outputs, then ask the agent to implement or improve that specific function. Constrain the scope, expand only when the foundation is sound.
AI excels at the first 80%. You can stand up an impressive demo in hours.
But the remaining 20% (hard edge cases, integration, reliability, performance) will take significantly longer than the demo itself. The agent still helps, but progress slows as complexity rises.
Fast demos are not production systems, budget your time accordingly.
Large language models operate within token limits. That limit defines how much context they can consider at once. While newer models are improving - e.g. Claude using iterative pipeline-style reasoning - the constraint still exists.
This means they cannot “remember” your entire codebase, and they may miss interactions outside their current context window. Large tasks must be broken into deliberate, scoped units. Treat agents as powerful but bounded collaborators. The better you define scope, structure, and constraints, the better they perform.
AI agents are probabilistic systems. The same prompt can produce different implementations across runs or models. That variability is useful during exploration but risky in production workflows.
AI does not simply make development fast, it changes the process: more time reviewing than typing, more time designing constraints, less time writing boilerplate, more emphasis on tests and validation.
AI lowers the cost of generation, but that does not automatically lower the cost of correctness. If anything, it raises the importance of tests, observability, and review discipline. Larger teams should adapt their processes to benefit.
This point is especially relevant in other industries: LLMs have hallucinated legal clauses, fabricated citations, and invented contractual obligations. Even with added validation layers, the underlying models are optimized for likely output, not guaranteed correctness.
The same dynamic applies to code: agents generate convincing solutions, not necessarily correct ones. Subtle logic errors, incomplete edge-case handling, and silent performance problems build up over time. To mitigate, ask the agent to explain assumptions explicitly, request adversarial test cases, manually review the core logic. Use the agent to accelerate thinking, not replace it. Confidence is not correctness.
The real skill is not clever prompting. It is designing the structure, holding the reins when foundations matter, and letting the agents run when the direction is clear. Strong engineers gain leverage, weak structure is amplified.
AI is a force multiplier for clarity, discipline, and technical judgment - and a risk without them.
In our experience, AI accelerates early output, amplifies structure (good or bad), and struggles when foundations are unclear. Below is the mental model we use and some of the lessons we’ve learned. Many of these patterns extend beyond software and may prove useful wherever AI agents are part of the workflow.
1. Think of them as fast horses
AI agents are like carriage horses that charge the moment you loosen the reins. The key is how tightly you harness them before letting them run.Light harness: quick wins
If you need a small push - a GUI, a report, lightweight edge functionality - constraints can be minimal. Provide a clear business description, iterate a few times, and you’ll often reach a usable result quickly. The 'quick win' category is expanding: tasks that required structure last year may not require it next year. Boundaries are shifting as model capability improves.
Tight harness: foundational features
Architecture does not emerge automatically from generated code. If you’re building core functionality that future features will depend on, restraint is mandatory. Core systems require a clean algorithmic structure that will scale with what comes next. Early shortcuts compound. Poor structural decisions create hidden constraints, and the agent will later struggle to extend or refactor code it generated under vague direction.
Instead: define the structure first, write the function signatures yourself, explicitly label inputs and outputs, then ask the agent to implement or improve that specific function. Constrain the scope, expand only when the foundation is sound.
2. Vibe coding and the 80/20 rule
AI excels at the first 80%. You can stand up an impressive demo in hours.
But the remaining 20% (hard edge cases, integration, reliability, performance) will take significantly longer than the demo itself. The agent still helps, but progress slows as complexity rises.
Fast demos are not production systems, budget your time accordingly.
3. Token limits are a thing
Large language models operate within token limits. That limit defines how much context they can consider at once. While newer models are improving - e.g. Claude using iterative pipeline-style reasoning - the constraint still exists.
This means they cannot “remember” your entire codebase, and they may miss interactions outside their current context window. Large tasks must be broken into deliberate, scoped units. Treat agents as powerful but bounded collaborators. The better you define scope, structure, and constraints, the better they perform.
4. They are not deterministic (a reminder)
AI agents are probabilistic systems. The same prompt can produce different implementations across runs or models. That variability is useful during exploration but risky in production workflows.
5. They change the shape of work
AI does not simply make development fast, it changes the process: more time reviewing than typing, more time designing constraints, less time writing boilerplate, more emphasis on tests and validation.
AI lowers the cost of generation, but that does not automatically lower the cost of correctness. If anything, it raises the importance of tests, observability, and review discipline. Larger teams should adapt their processes to benefit.
6. Confidence is not correctness
This point is especially relevant in other industries: LLMs have hallucinated legal clauses, fabricated citations, and invented contractual obligations. Even with added validation layers, the underlying models are optimized for likely output, not guaranteed correctness.
The same dynamic applies to code: agents generate convincing solutions, not necessarily correct ones. Subtle logic errors, incomplete edge-case handling, and silent performance problems build up over time. To mitigate, ask the agent to explain assumptions explicitly, request adversarial test cases, manually review the core logic. Use the agent to accelerate thinking, not replace it. Confidence is not correctness.
7. Prompting is not the point
The real skill is not clever prompting. It is designing the structure, holding the reins when foundations matter, and letting the agents run when the direction is clear. Strong engineers gain leverage, weak structure is amplified.
AI is a force multiplier for clarity, discipline, and technical judgment - and a risk without them.