Faisal Md shares practical software-engineering lessons on using AI coding tools with human oversight, choosing system architectures that fit a team's size, and reducing security risks in backend systems.
Faisal Md is most useful for practical technical content on AI coding oversight, right-sized architecture, and backend security trade-offs.
Best for
A B2B software consultancy commissioning a technical collaboration series on AI coding and system design.
Not for
An AI productivity vendor seeking reach-led endorsement, paid testimonial, or guaranteed purchase recommendation.
Key takeaways
An AI-built e-commerce shop can look finished while cart and data handling are broken.
Microservices can help scaling and isolation but burden a six-person team with coordination and debugging.
Plain-text backend logs can expose sensitive data, and phishing can steal credentials despite expensive defences.
Check first: Confirm recent audience demographics, per-post impressions, engagement, and whether they accept partnership work.
Main ideas
AI can write the code, but someone still has to own the architecture · Match the architecture to the team that has to run it, not to what the pattern promises · Data you never collect is risk you never carry
Faisal Md shares practical software-engineering lessons about where tools and architectures help—and where human judgment still matters.
In four LinkedIn posts, they examine AI-assisted coding, microservices, backend logging and phishing.
The examples help developers and technical leaders weigh trade-offs: an AI-built shop can look finished while its business logic is broken; microservices can improve independent scaling and deployments but overwhelm a six-person team; and ordinary logs can expose sensitive data.
Follow Faisal Md for concise, scenario-led explanations that connect engineering choices to their consequences.
Faisal Md turns abstract technical risks into situations readers can reason through.
The e-commerce example contrasts a polished interface with faulty cart and data handling, making code review and architectural oversight part of the lesson—not an argument against AI tools.
The microservices post acknowledges benefits, including scaling Search for Black Friday and isolating a Recommendations outage, before showing how service coordination and debugging burden a small team.
The security posts highlight overlooked entry points: sensitive information in plain-text logs and credential theft through a convincing login clone.
Across these examples, the recurring contribution is practical trade-off analysis rather than blanket advice: keep the useful technology, but account for the people, failure modes and data around it.
Faisal Md writes about the judgment calls around engineering tools rather than the tools themselves.
Read more
Across four posts, the same priority recurs: a pattern, tool, or defence is only as good as the team's ability to run and check it, so the person supervising must remain accountable for the reasoning. The posts typically use a short scenario that looks like a win, a turn that shows what it costs, and a plain takeaway — usually ending with a question that invites other practitioners to weigh in.
AI can write the code, but someone still has to own the architecture
The argument is that AI coding tools are genuinely useful for repetitive, low-level work, but should be managed as supervised juniors rather than autonomous builders.
Read more
Directing the work module by module keeps the build organised, but the output needs line-by-line review: a finished-looking interface says nothing about whether the underlying business logic exists. Teams can outsource typing, not critical thinking; the senior engineer remains responsible for the architecture the tool misses.
After paying for an Antigravity.Google subscription, Faisal Md built a small e-commerce project with a product catalog, a list, and a simple frontend, prompting one module at a time instead of with one large prompt.
The tool skipped the boilerplate quickly, but the files held many bugs: the interface looked complete while basic data handling and cart behaviour were often missing.
They compare the arrangement to managing a junior developer and say the project would have been a disaster without a full review of every module.
Match the architecture to the team that has to run it, not to what the pattern promises
Faisal Md treats service separation as a sound idea that becomes a liability when adopted ahead of a team's size.
Read more
The benefits are clear — independent deploys, targeted scaling, and one service failing without taking checkout down — as are the coordination costs: simple changes spanning several services, ordered deploys, faults that surface only across service boundaries, and feature work giving way to plumbing. The conclusion is that the architecture was designed for a much larger company than the one operating it, not that the pattern itself was wrong.
A six-person team splits an e-commerce app into Auth, Payments, Inventory, Search, Recommendations, Notifications, and Checkout.
Payments ships daily, Search scales alone for peak traffic, and a Recommendations crash leaves checkout online.
Then adding a 'summer sale' badge means changing and correctly sequencing three services, and a small network delay between Auth and Inventory causes checkout to fail silently, taking two days of log digging across three servers to find.
The recurring position is that convenience-driven logging quietly creates a second, unhardened store of sensitive information, and the fix is data minimisation rather than better protection of the logs.
Read more
If a system records everything, it will eventually record credentials, payment details, and private conversations; attackers can read the log files instead of attacking the protected database. The recommended practice is to stop collecting what is not needed and automatically filter sensitive values before anything is written to disk.
A team logs every user action to trace errors faster; the daily plain-text log files end up holding passwords, payment details, and personal chats.
In Faisal Md's account, attackers bypass the main database entirely and open the logs.
The post asks how often a team audits what actually reaches production logs.
Faisal Md challenges the assumption that major breaches come from sophisticated zero-day exploits in enterprise firewalls, locating the weak point instead in ordinary user behaviour.
Read more
The attack does not drop obvious malware; it captures valid credentials and an active session, after which security monitoring sees nothing unusual because the access is legitimate. The conclusion: software defences have limited value while the human layer stays unguarded, making user-level awareness and verification a priority.
A user clicks a link that looks normal and lands on a near-identical clone of a corporate login portal, sometimes differing by one character, such as a lowercase 'l' replaced by the number '1'.
Believing a session has timed out, the user enters credentials and a multi-factor code.
The fake portal records both, hands the attacker a live session token, and redirects the user back to the real site.
Across the posts, the writer presents the case for a practice fairly, then shows what it costs, leaving the judgment to the reader rather than endorsing a product or method.
Read more
The topics are framed as balances — AI speed against code quality, architectural flexibility against operational overhead, fast incident response against data exposure, software defence against human judgment — and the writing stays with the scenario and the decision rather than tool promotion. Three of the four posts close with a direct question inviting practitioners to share their experience, keeping the pieces open to discussion rather than presenting advice.
The microservices post lists the operational wins first, then the six-person team's coordination failures, and ends by asking whether a setup meant to speed a team up has ever slowed it down. The AI coding post likewise credits the tool's speed, details the broken logic it left behind, and asks other developers whether they supervise these tools or trust them to handle logic alone.
Shows whether AI coding tools can handle an e-commerce build on their own—and the oversight Faisal Md considers non-negotiable.
Read more
Faisal Md paid for an Antigravity.Google subscription and built a simple e-commerce project with a product catalog, list, and frontend UI, directing the AI module by module instead of using one giant prompt.
The UI looked polished, but the files hid many bugs: basic business logic, data handling, and cart behaviour were often missing.
They compare the tool to a junior AI developer and conclude that teams can outsource typing, but not critical thinking or code review.
For brands planning a campaign
A technical collaboration could turn this into a practical series on AI-assisted development with an architecture-review step: a build-along episode, a code-review checklist, or a debate on when a senior engineer must inspect every module.
Shows when service separation helps and when it slows a team down, through a concrete failed trade-off.
Read more
A fast-growing e-commerce startup splits into Auth, Payments, Inventory, Search, Recommendations, Notifications, and Checkout.
The benefits appear: Payments deploys daily, Search scales for Black Friday, and Recommendations crashes without taking checkout offline.
But with only six engineers, a summer-sale badge requires coordinated changes across three services; a small network delay between Auth and Inventory causes a silent checkout failure that takes two days to trace.
Faisal Md argues the architecture was built for a 200-person company, not a six-person team.
For brands planning a campaign
This is a ready-made episode or workshop on architecture fit. A consultancy could sponsor a framework for deciding when to split services, or a case-study discussion on reversing premature microservices.
Shows what a common backend logging habit exposes and why data minimisation matters for security.
Read more
Many teams log every user action in plain text to find errors faster.
Faisal Md explains that these logs can capture passwords, payment details, and personal chats, creating a target attackers can read without touching the main database.
The fix: stop collecting unnecessary data and filter sensitive information before writing anything to disk.
The closing question asks how often a team audits what reaches production logs.
For brands planning a campaign
A collaboration could focus on secure logging and data minimisation: a practical audit checklist, a before-and-after demo of log filtering, or a joint webinar on reducing breach exposure in backend systems.
Shows where high-profile breaches often begin and why human-layer security changes the priority list.
Read more
Faisal Md challenges the assumption that hackers rely on complex zero-day firewall exploits.
A single click on a normal-looking link can route a browser to a clone of a corporate login portal, sometimes with a one-character swap, such as a lower-case 'l' replaced by the number '1'.
When the user enters credentials and an MFA code, the fake portal captures them and hands the attacker an active session token.
The takeaway: expensive software defences mean little if the human layer remains unguarded.
For brands planning a campaign
A security-awareness campaign could use this as a narrative spine: phishing simulation results, MFA-resilience content, or a training series showing how a fake portal steals a live session rather than dropping obvious malware.
Approach: short cautionary narratives built around a trade-off4
AI coding tools under human architectural control1
Architecture choices sized to the teams that run them1
Backend logs as an unguarded privacy and security exposure1
Security failures that start with a single click1
AI coding tools under human architectural control
In a first-person account of paying for an Antigravity.Google subscription to test "vibe coding," Faisal Md describes building a basic e-commerce project — a product catalog, a list, and a simple frontend — with module-by-module prompts rather than one large prompt.
Read more
The tool quickly removed repetitive boilerplate and low-level coding.
But the files contained many bugs, and the finished-looking interface lacked basic business logic such as data handling and cart behavior.
The lesson: treat AI tools like a junior developer and review every module.
The typing can be outsourced; critical thinking cannot.
The post asks other developers whether they supervise these tools or trust them to handle logic alone.
Splits work into modules, prompts each separately, then reviews every generated module before moving on.
Polished output is no quality signal: the interface looked correct while the underlying logic was broken or absent.
For brands planning a campaign
Faisal Md can anchor a collaboration series on where AI coding tools earn their place and where architectural oversight remains essential. Their module-by-module approach and failed-logic example give brands concrete, reproducible material for explainers aimed at engineering leaders weighing tool adoption.
Architecture choices sized to the teams that run them
A narrative follows a fast-growing e-commerce startup that split one application into seven services — Auth, Payments, Inventory, Search, Recommendations, Notifications, and Checkout.
Read more
It presents the early gains as real: independent deploys, targeted scaling during peak traffic, and surviving a service crash without losing checkout.
It is just as concrete about the costs.
With a six-person team, a simple "summer sale" badge required coordinated changes and ordered deploys across three services.
A network delay between Auth and Inventory caused a silent checkout failure that took two days of log digging to diagnose.
Feature work stalled as the team kept services talking to each other.
The conclusion: the architecture was built for a 200-person company, not a six-person team.
Faisal Md asks readers whether a setup meant to speed a team up has ever slowed it down.
Pressure-tests an architecture choice against team size, showing the trade-offs through everyday operational events rather than abstract principles.
The post does not dismiss microservices; it distinguishes a sound pattern from a mismatch between the pattern and the team applying it.
For brands planning a campaign
A useful case study for content on right-sizing system architecture, cloud cost, and technical debt for smaller engineering organisations. Brands can build a workshop, webinar, or co-authored series around when to split a system — and when not to.
Backend logs as an unguarded privacy and security exposure
The argument starts with a common practice: logging every user action to find errors faster.
Read more
Faisal Md warns that writing all user data to plain text files eventually captures private passwords, payment details, and personal chats, creating a target outside the hardened database.
In this account, attackers skip the database and read the daily text logs.
The suggested practice is to stop collecting unnecessary data and automatically filter sensitive information before anything is written to disk.
The post asks teams how often they audit what actually reaches production logs.
Traces a routine engineering convenience to its security consequences, then proposes data minimisation and pre-write filtering as fixes.
For brands planning a campaign
A strong fit for content on logging hygiene, data minimisation, and commonly misplaced security investment. The scenario gives brands a specific, teachable angle for developer-focused material on privacy-by-design in backend systems.
The post challenges the assumption that breaches stem from complex zero-day exploits in enterprise firewalls.
Read more
In the described pattern, a user clicks a link that looks normal and lands on a near-identical clone of a corporate login portal — sometimes differing by a single character, such as a lowercase "l" replaced by the number "1".
Believing a session has timed out, the user enters credentials and a multi-factor code.
The fake portal captures the login, hands the attacker a live session token, and redirects the user to the real site, leaving monitoring tools to see ordinary activity.
The conclusion: expensive software defences mean little if the human layer stays unguarded.
Walks through an attack sequence step by step, showing exactly where the credential and session are lost.
For brands planning a campaign
A direct fit for awareness and human-risk content aimed at security and engineering audiences, including simulated-phishing and MFA education. The single-character detail gives brands a memorable hook for campaigns on why technical controls need user-level reinforcement.
Approach: short cautionary narratives built around a trade-off
Across all four posts, the structure is consistent: a concrete scenario or decision, a fair account of its appeal, a "reality check," and a plain-language takeaway.
Read more
Three of the four end with a question for other practitioners.
The topics are framed as trade-offs rather than tool endorsements — AI speed against code quality, architectural flexibility against operational overhead, fast incident response against data exposure, and software defence against human judgement.
The writing sticks to scenarios and decisions, with little jargon.
Hashtags cluster around SoftwareEngineering, TechLeadership, CyberSecurity, and related engineering and security tags.
Explains engineering decisions through short worked scenarios, then invites readers to share their experience.
For brands planning a campaign
The format suits co-authored explainers, comment-driven discussion campaigns, and practitioner roundtables: each piece ends with a question a brand can turn into a prompt. Partners get a credible engineering voice that raises trade-offs rather than promoting a tool, a fit for cautious technical audiences.
Faisal Md's posts show they used Antigravity.Google to test AI-assisted coding.
Read more
Ask whether sponsorship, affiliate activity or another commercial relationship was involved.
Antigravity.Google
Mention
Faisal Md says they paid for a subscription and used the tool to build a basic e-commerce project, then described the need to review its code and business logic.
Read more
Ask whether the post involved a brand partnership.
Faisal Md writes short, concrete posts about the judgment calls around engineering tools, not just the tools themselves.
Read more
Strong entry points include a first-person account of building an e-commerce project with an AI coding tool—prompting module by module, then finding broken business logic behind a finished-looking interface—a narrative about a six-person team that split its app into seven services too early, a post on backend logs quietly collecting passwords and payment details, and one on credential phishing that beats expensive defences.
The recurring move is to acknowledge a practice's appeal, show its costs and leave the judgment to readers, often with a closing question.
Together, these four posts show the pattern; the comparison creators below go deeper into hands-on security testing, security awareness storytelling and defender-side visibility.
Both write for developers about the security consequences of everyday development decisions, making their case through a single worked example rather than general advice.
Read more
Hassain recounts testing a booking-style platform where a feature that appeared correctly limited in the interface failed on the server. A companion post argues that shipping new features without security testing leads to breaches, losses and lost trust.
Hassain drills into a specific flaw: a permitted range, a negative value entered anyway, a balance left in an illegal state and a checkout that still completed.
The post pairs the walkthrough with a feature-versus-security infographic.
Faisal Md focuses on the decision, describing what a practice costs a team and closing with an open question rather than a reproduction or checklist.
Both open with a short human story and make the same point: reused credentials and look-alike emails can defeat technical controls, while a secondary verification step offers a cheap fix.
Read more
Adebisi's posts describe a colleague whose reused password unlocked bank, email and company files after a breach, and a law-firm employee who wired funds after receiving a message that matched a real partner's signature, closing line and writing style.
Adebisi's posts end with a company promotion and newsletter signup, and use workplace anecdotes about situations involving named colleagues. Faisal Md names no employer or service; their posts end with a question for other practitioners and frame the subject as an engineering trade-off rather than an awareness tip.
Both argue that defenders should assume the outer wall will eventually fail, making what happens after a foothold more important than a thicker perimeter.
Read more
Horne uses the medieval castle analogy, noting that a real castle's layers each assumed the one before might fail. A companion post argues that attackers are not trying to hack Kubernetes but to reach the data and identities behind it.
Horne focuses on what happens after a breach: lateral movement, credential theft, cloud access, runtime visibility and east-west traffic.
The posts link to a technical breakdown of Kubernetes threats.
Faisal Md focuses on decisions before and around the build, including how far to trust an AI coding tool, when a small team should split a system, what to write to logs and where a user's click gives away a live session.
For a technical content collaboration, Faisal Md is a topic-relevant but unproven-reach test option.
Read more
The four LinkedIn posts address practitioner subjects: AI-assisted coding, system design tradeoffs, backend logging risk, and credential-based cyberattacks.
That gives a buyer a concrete reason to explore a series on using AI coding tools with architectural oversight and common system design pitfalls.
The only audience figure is 622 LinkedIn followers, observed October 8, 2026.
Treat this as a fit-and-test opportunity, not a scale buy.
Before committing, ask for recent audience demographics and, for professional attributes such as job role or seniority, any audience survey documenting those details.
Also request per-post impressions and engagement for comparable topics, depth, and formats to set delivery expectations based on current results rather than accumulated page metrics.
LinkedIn followers
622
LinkedIn account record for the profile that published the reviewed posts · 2026-10-08
Four LinkedIn posts cover software engineering: using AI coding tools under human architectural review, choosing system architecture to fit team size, auditing what backend logs store, and how credential phishing defeats expensive security tooling.
Read more
None describes a sponsorship offer, paid partnership, media kit, rate card, format list, brand collaboration example, or official inquiry route for partnership work. Buyers can approach Faisal Md through the public LinkedIn profile; ask whether they accept partnership work and negotiate terms, formats, and deliverables from scratch.
Good fit: a B2B software consultancy commissioning a technical collaboration series on using AI coding tools with real architectural oversight and on the system design mistakes smaller teams make.
Read more
Faisal Md’s posts line up with that brief.
The strongest piece is a first-person account of paying for an Antigravity.Google subscription and building a basic e-commerce project by prompting module by module rather than with one large prompt.
The tool cleared repetitive work quickly, but the files held many bugs, and the interface looked finished while data handling and cart behaviour were missing or broken.
Their stated rule — treat the tool like a junior developer and review every module, outsource the typing but not the critical thinking — gives a consultancy a concrete oversight argument and a failure case, not just a general opinion.
A second piece applies the same thinking to architecture: a fast-growing e-commerce startup splits into Auth, Payments, Inventory, Search, Recommendations, Notifications, and Checkout, gaining daily payments deploys and targeted Black Friday scaling.
The trade-off is a six-person team, a summer-sale badge that forces coordinated changes across three services, and a silent checkout failure that takes two days to trace through logs.
That is usable workshop material on right-sizing architecture, cloud cost, and technical debt.
Two other posts add adjacent depth for a developer audience: sensitive data accumulating in plain-text backend logs, with data minimisation and pre-write filtering offered as the fix; and credential phishing that steals a live session token through a near-identical login clone, challenging the assumption that breaches need a zero-day.
The writing style also suits co-branded content.
Each post sets out a scenario, gives the appealing case fairly, turns to a reality check, and lands on a plain-language takeaway.
Three of the four close with a question rather than a product plug, positioning the creator as a trade-off explainer for cautious engineering buyers.
The audience data limits the deal’s scale, not whether to run it.
The only audience figure available is 622 LinkedIn followers, observed October 8, 2026; geography, job role, seniority, and per-post engagement data are unavailable.
That supports a paid test series with defined topics and formats, not a reach-led or scale-committed buy.
Before contracting, ask for recent audience demographics, per-post impressions and engagement on comparable technical posts, and confirmation of whether the collaboration would run on LinkedIn only or extend to a newsletter or other channel.
The posts document no sponsorship policy, format list, or pricing, so negotiate terms from scratch; the practical starting point is a direct approach through the public LinkedIn profile.
When to choose a specialist
Poor fit: an AI productivity vendor seeking a reach-led endorsement — a paid testimonial, guaranteed purchase recommendation, and short-form video placement aimed at a broad non-specialist audience, judged on follower growth and views.
Read more
The posts document no sponsorship offer, rate card, media-kit format, or commercial example, and no inquiry route for partnership work, so a buyer cannot select a packaged deliverable or treat any format as proven.
None of the three or four posts is video, so a video-led placement cannot be judged from the available work.
The AI post is the clearest obstacle to a paid testimonial or guaranteed purchase recommendation.
It recounts using an AI coding tool for a fee, but ends with the tool failing at basic business logic and the human having to fix the mess: a cautionary review, not an endorsement.
A sponsored recommendation would conflict with the post’s conclusion.
Audience scale is another mismatch.
The only audience figure available is 622 LinkedIn followers, observed October 8, 2026; reach, engagement, demographic, and geography data are unavailable, so the account cannot support a performance target based on views or follower growth.
The audience that can be inferred is practitioner-oriented — software engineering, tech leadership, backend development, and cybersecurity — and would likely reject a soft, general-marketing sales message.
A better match is an established reach creator in the consumer AI space, or a paid-placement channel where the vendor controls the message and does not need creator-authored praise.
If the vendor still wants to work with Faisal Md, the realistic option is a sponsored educational piece or webinar on evaluating AI coding tools in production, with the vendor accepting critical trade-offs and no promised recommendation.
A worked campaign example
Worked campaign angle for the good-fit brief: a three-part sponsored series plus one live session, under a working title such as “Who is the senior engineer in the room?”
The consultancy’s technical reviewers co-host, the creator provides the practitioner voice, and each episode focuses on one idea with an inspectable artefact.
Episode one, “Module by module: putting a review gate on AI coding,” is anchored to the Antigravity build.
Faisal Md walks through prompting a small e-commerce app one module at a time, shows the polished interface, then opens the files and marks where data handling and cart behaviour broke.
The deliverable is a short code-review checkpoint list viewers can apply at the end of each AI-generated module: what happened to the data, what happens on the edge case, and what happens when the cart is emptied or re-entered.
The hook is the line that carries the argument: the typing can be outsourced, the critical thinking cannot.
Episode two, “Seven services, six engineers: right-sizing the architecture,” draws on the split-app story.
Its asset is a decision framework: map the services under consideration, count the people who will own them on call and in releases, cost out a cross-service change such as a shared promotion badge, and test a dependency failure.
In the story, a small network delay between Auth and Inventory silently breaks checkout and takes two days to find.
The episode ends on the post’s counterfactual: this was a good pattern applied to the wrong-sized organisation.
Episode three, “What your logs already know,” uses the backend logging post.
The asset is a log-audit drill teams can run in a sprint: sample the fields written to disk, flag anything that would be sensitive if the log store were opened, then move filtering to before the write instead of after.
The phishing post becomes the human-layer segment of that episode or the live session: a walkthrough of a login clone that differs by one character, captures credentials and an MFA code, and hands over a live session token — showing why software controls alone do not close the gap.
The live session is a 45-minute practitioner roundtable, using the posts’ closing questions as audience prompts: whether the team supervises AI tools or trusts them with logic, whether a setup meant to speed work has slowed it, and how often logs are audited.
Create each episode to work as a standalone article or clip, with the framework, checklist, and audit template downloadable on their own; resources that only work inside the article will not travel.
For the consultancy, the value is a defensible, unpopular-but-accurate position, delivered by a working engineer rather than a salesperson: cautious adoption with named review steps.
Before writing, confirm whether the collaboration runs on LinkedIn only or includes other channels; agree topics and episode lengths, and whether the consultancy’s reviewers appear by name; license the specific examples and adjust any details that could identify a client; and set expectations from a test-stage baseline rather than a reach guarantee, given 622 followers and no engagement data.
To establish measurable proof before scaling, run episode one first and review completion, comment quality, framework downloads, and qualified inquiries before commissioning the rest.
If those results do not support the series, choose a different creator with documented technical video output and audience data rather than promising reach.
Jony Hassain is the stronger choice when the campaign calls for a hands-on offensive-security demonstration rather than a coding-tool review.
In the posts, Hassain walks through a business-logic flaw in a test platform: a balance feature allowed a negative value, a manipulated negative balance, and checkout logic still completed orders.
That gives the consultancy a concrete vulnerability narrative—front-end limits versus missing server-side validation—for a security-focused episode or workshop on why feature work and security testing must be scheduled together.
A second post supplies a cost case: an e-commerce site launches features without security testing and faces a $2.5M breach, lost trust, and legal penalties.
The trade-off is scope.
Hassain's posts cover penetration testing, bug bounty, and secure coding, but not AI coding assistants, module-by-module prompting, or right-sizing a split architecture—the core of the proposed Faisal series.
A consultancy wanting one creator to cover both AI oversight and system design would lose that breadth by switching.
The posts also provide no audience, engagement, or commercial-format data; ask for those before deciding whether to test a collaboration, and clarify whether the format is an article or live exploit walkthrough.
Kareem Adebisi is the better fit when the buyer's task shifts toward security awareness for a general business audience.
Read more
The posts tell accessible breach stories—reused passwords turning one breach into account takeover, and a lookalike partner email leading to a $50k wire transfer sent overseas—and each ends with a practical habit: use a password manager or verify through a second channel. The writing carries a clear organisational voice and recurring newsletter call to action, which can suit a consultancy selling security training or managed awareness.
The trade-off is depth and commercial tone.
The posts are awareness-led and include a product pitch for Forward Velocity, but lack the engineering-level build detail, architecture trade-offs, and AI coding oversight at the heart of the consultancy's proposed series.
Switching to Adebisi would shift the campaign from practitioner engineering debates to employee-training content.
Before deciding, ask for audience, engagement, and commercial-format data.
Robert Horne is the stronger pick when the campaign calls for strategic security architecture rather than hands-on coding oversight.
Read more
The posts argue that layered defence is not a bigger moat: firewalls keep most attackers out, but once inside, lateral movement and credential theft do the damage.
They also argue that Kubernetes is rarely the target itself, but the fastest route to identities and cloud resources.
Together, the posts give a consultancy a zero-trust and assume-breach narrative for a series on architecture decisions at scale, including runtime visibility and east-west traffic.
The trade-off is abstraction.
The arguments rely on analogies and concepts—castle moats and attacker paths—with less inspectable build process, code review, or AI-tooling process than Faisal's posts.
A buyer seeking practical modules on prompting, cart logic, log audits, or a decision framework for microservices would move away from the concrete material that makes a software-consultancy collaboration usable.
Horne is better for a strategic episode or keynote than for the full series.
Before deciding, ask for audience, engagement, and commercial-format data.
This page draws on four LinkedIn posts by Faisal Md about AI-assisted coding, splitting an application into services, sensitive data in backend logs, and credential phishing.
Faisal Md's account was observed on 8 October 2026.
The posts carry no publication dates, engagement figures, audience demographics, or job-role detail, and these four posts are a starting selection rather than a complete record of the account's output, so no order or development over time can be established.
Comparisons with other creators rest on two posts each and are enough to compare approach, not to characterise a full body of work.
No signature work, talks, videos, transcripts, or commercial or sponsorship terms are available in the posts here.
